• Like
  • Save
Analyzing OAuth
Upcoming SlideShare
Loading in...5
×
 

Analyzing OAuth

on

  • 3,820 views

This presentation digests and analyzes the OAuth versions 1.0 and 2.0. ...

This presentation digests and analyzes the OAuth versions 1.0 and 2.0.

Doing a deep dive into OAuth I found myself forced into a puzzle with many pieces. This was worthwhile as OAuth is quite cool. For those interested in a quick-start check this slide-deck - I hope it saves others from puzzling.

Statistics

Views

Total Views
3,820
Views on SlideShare
3,819
Embed Views
1

Actions

Likes
6
Downloads
0
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Analyzing OAuth Analyzing OAuth Presentation Transcript

    • Analyzing OAuthOliver PfaffFebruary 11, 2012
    • Contents▶ Setting the scene▶ Fundamentals▶ Assessing – IAM practices – IT-security▶ Conclusions▶ Further information▶ Appendix – OAuth 1.0 details – OAuth 2.0 detailsFebruary 2012 - All rights reserved 2
    • Setting the SceneBackground Authentication Authorization IAM (Identity and IT-security Access Management) Federation Same use cases (e.g. SSO) considered by: ▶ Enterprise IAM camp: resources owned by legal entities ▶ Internet IAM camp: resources owned by individual usersFebruary 2012 - All rights reserved 3
    • Setting the SceneAbout OAuth▶ OAuth (Open Authorization) is an initiative of the Internet IAM camp: – Aims at a use case in cloud computing, SOA and Web 2.0 by addressing access control for composite applications: • 3rd-party applications accessing resources owned by individual users on their behalf – Wants to obsolete naive approaches such as: • 3rd-party applications presenting credentials (e.g. username/password) of individual users – Has - at a first glance - analogies with approaches in enterprise IAM e.g. • 3-party security protocols such as Kerberos, SAML • Classical Web access management▶ Development and standardization is currently ongoing in an IETF working group: – oauth – Web Authorization Protocol (security area)February 2012 - All rights reserved 4
    • Setting the SceneComposite Applications User e.g. myself User agent (Web browser) Composite application e.g. photo-lab Web application Web applications Web APIs Web API Authn/Authz Authn/Authz examples: Service e.g. Flickr User-owned resources e.g. my photosFebruary 2012 - All rights reserved 5
    • Setting the SceneAuthenticating/Authorizing Composite Applications▶ Folklore: services need to enforce authentication and authorization at Web applications and Web APIs.▶ The access control predicate “self” (requests from John Doe may access resources of John Doe) prevails with Web applications in Internet IAM. It is no appropriate Web API enforcement target. Mandating the same approach: – Requires 3rd-party applications to present user credentials to access user- owned resources via Web APIs – Leads to a dissemination of private information into 3rd-party applications▶ Traditional Web security does not do the trick: – Relies on a 2-party authentication and authorization model suitable to model resource owners in client role but not facilitating (on the level of a security protocol standard) the client role of a proxy acting on end users’ behalf.▶ An approach beyond traditional Web security is needed to facilitate a 3-party authentication and authorization model where composite applications act on behalf of end users (requests from 3rd-parties that are explicitly entitled by John Doe may access resources of John Doe).February 2012 - All rights reserved 6
    • Setting the Scene Vs. Traditional Web Security User User agent Traditional Web applications Web security CompositeTraditional application Authn/AuthzWeb security Beyond traditional Web applications Web APIs Web security Authn/Authz Service Authn/Authz User-owned resources February 2012 - All rights reserved 7
    • Setting the SceneUse Case▶ Facilitate access to protected user resources hosted in the network: – Via Web APIs – By 3rd-party applications – On a discretional basis (controlled by resource owners) – In a constrained way (time, functional scope…) – Without revealing user credentials (shared with services) to 3rd-parties – Independent of the means of user authentication deployed by services and 3rd-party applications▶ Real-world analogy: valet parkingFebruary 2012 - All rights reserved 8
    • FundamentalsOAuth Versions▶ Community specification OAuth Core 1.0 (2007): – Emerged from proprietary protocols such as Flickr API Auth, Google AuthSub▶ Community specification OAuth Core 1.0 Revision A (2009): – Addresses a session fixation attack (cf. http://oauth.net/advisories/2009-1)▶ IETF version 1.0 (2010): – Publishes the community specification OAuth Core 1.0 Revision A (plus errata and various editorial changes) as RFC 5849 (informational)▶ IETF version 2.0 (work-in-progress): – Standards track work itemFebruary 2012 - All rights reserved 9
    • FundamentalsOAuth System Entities ▶ Resource owner: Resource owner – Capable of delegating access rights for HTTP client protected resources to 3rd-parties – Presenting a HTTP client HTTP server – E.g. individual users (represented by Intermediary their user agents) ▶ Intermediary: HTTP client – Requesting protected resources on behalf of resource owners HTTP server – Presenting a HTTP client and server Service – E.g. composite applications ▶ Service: – Hosting protected resources and responding to requests from intermediaries – Presenting a HTTP server – E.g. cloud servicesFebruary 2012 - All rights reserved 10
    • FundamentalsOAuth Tokens and Credentials ▶ Tokens present means to refer to access rights delegated to intermediaries: – Issued by services based on access rights granted to intermediaries – Presented by intermediaries when ( ) accessing protected resources. , Referred access rights are to-be- enforced by services. – Take one of the following forms: Token Key • Identifier: reference allowing to Identifier Self-contained retrieve the delegated access rights • Self-contained: object embodying this information Credential ▶ Credentials comprise pairs of a token and a key (shared-secret).  Provide means for request authentication purposes  OAuth 2.0 supports bearer tokens. Then the key portion is absent.February 2012 - All rights reserved 11
    • FundamentalsMain OAuth Protocol Phases▶ OAuth credentials usage phase: – Employs credentials in 2-party exchanges (between intermediaries and services) to access resources via Web APIs. – Specified on base of: • HTTP access authentication framework (RFCs 2616/2617) • OAuth-defined WWW-Authenticate/Authorization HTTP headers.▶ OAuth credentials acquisition phase: – Presents a 3-party protocol asking resource owners to delegate access rights to intermediaries and establishing related credentials between intermediaries and services. – Specified by tying 2-party exchanges together: • Between intermediaries as well as servers and resource owners: o HTTP redirects to establish a 3-party context across resource owners, intermediaries and services. • Between intermediaries and servers: o OAuth-defined HTTP request and response messages (employing OAuth WWW-Authenticate/Authorization HTTP headers with credentials established a priori or before the current step). – Exchanges for acquiring OAuth credentials are called flows.February 2012 - All rights reserved 12
    • Fundamentals OAuth Credentials Usage Intermediary Service ▶ RFC 2616 defines the HTTP access HTTP HTTP authentication framework esp. headers client server for HTTP request authentication e.g.: – WWW-Authenticate response header Access 1. GET/POST... resource – Authorization request header 2. 401 Unauthorized ...w/o OAuth WWW-Authenticate: OAuth ▶ RFC 2617 instantiates this framework forcredentials realm=“acme.com" HTTP basic and digest authentication. Acquire ▶ OAuth employs this framework by OAuth … defining WWW-Authenticate andcredentials Authorization headers according the needs of its use case. n. GET/POST...Authorization: Access OAuth…,oauth_token= ▶ Note: OAuth also allows transfer of resource “ad180jjd733klru7”,… corresponding protocol parameters in:with OAuthcredentials – URI query parameters n+1. 200 OK – POST request bodies OAuth credential (a posteriori object, established through OAuth) February 2012 - All rights reserved 13
    • FundamentalsOAuth Credentials Acquisition Resource Inter- owner 3. Redirect resource owner to intermediary mediary 4. Obtain credential (authenticated with ) 2. Delegate 0. Access resourceaccess rights to 1. Redirect resource without OAuth intermediary owner to service credential (denied)(authenticated with ) 5. Access resource with OAuth credential (permitted)Examples of OAuth support: OAuth Resource access endpoints endpoint Service OAuth credential (a posteriori object, User resp. 3rd-party client credentials (shared established through OAuth) secret or asymmetric key; a priori objects, independent from OAuth) Not shown: initiating request from resource owner to intermediary and corresponding response (cf. diagrams below)February 2012 - All rights reserved 14
    • FundamentalsOAuth Specification Coverage▶ The OAuth specifications instantiate these fundamental exchanges for the Web. In particular they define: – Overall sequence of protocol steps in HTTP: • 2-party request/response exchanges for request authentication with OAuth • 3-party request/response exchanges for OAuth credential acquisition – HTTP access authentication headers for request authentication with OAuth – URI query as well as HTTP request/response entity-body parameters for OAuth credential acquisition▶ But they leave various details to mutual agreements between intermediaries and service providers. OAuth specifications do currently not cover: – Content, format and protection of self-contained tokens for resource access – Access right objects referred to by identifier tokens – In-band negotiation of OAuth protocol options – Interactions between resource and authorization servers (concerns OAuth 2.0)▶ Some of the white-spots can be expected to become addressed over time (e.g. self-contained tokens for resource access). Others are intentionally out-of-scope (e.g. objects referred to by identifier tokens).▶ The appendix digests the IETF versions 1.0 and 2.0 (work-in-progress) of OAuth and provides more details.February 2012 - All rights reserved 15
    • Assessing - IAM PracticesUse Case Comparisons▶ Identity provisioning and federation: – Identity provisioning (e.g. SPML, SCIM) and federation (e.g. SAML, OpenID) enable the sharing of user identity in a persistent resp. transient fashion – OAuth enables sharing of user resources - not user identity▶ SSO: – SSO (e.g. Kerberos) enables users to subsequently authenticate at multiple systems or applications and access them after a single initial authentication – OAuth allows services to authenticate 3rd-party applications as entities acting on behalf of a user – not as the actual user.▶ Access control: – Access control techniques (e.g. XACML) express authorizations and allow to enforce and manage them. Such techniques may be specific to certain access control models (e.g. DAC/MAC/RBAC) or generic. – OAuth is specific to the access control model DAC. It defines how resource owners may delegate authorizations – not their actual expression, enforcement and overall managementFebruary 2012 - All rights reserved 16
    • Assessing - IAM PracticesBenchmarking Against▶ Other 3-party security protocols for the Web: – Kerberos defines a 3-party SSO protocol. It is not native to Web and has a Web integration based on the HTTP access authentication framework (RFC 4559). Common Web browsers and servers support this integration providing SSO to Web applications based on e.g. Windows domain logins. – SAML defines another 3-party security protocol that is addressing cross- domain Web browser SSO, identity federation and SLO. The SAML protocols are profiled for the Web. – OAuth presents a complementary approach as it is addressing a use case (delegation of access rights) not covered by the 3-party protocols above.▶ Classical Web access management: addresses initial authentication and SSO for Web applications based on traditional Web security and extends that by adding vendor-specific authorization functionality as well as means of auditing: – Resources typically are assumed to be owned by legal entities. – Due to this fact, access control enforcement via Web APIs can usually be done in a way which regards composite applications as clients in the traditional 2-party authentication and authorization model.February 2012 - All rights reserved 17
    • Assessing - IAM PracticesAuthorization Subsystem Integration Web container Protected HTTP PEP resources Authorization decisionClient: user agent or request/responsecomposite application “Self“ code path OAuth code path in DAC in DAC ▶ Determine owner of requested resource ▶ Determine owner of requested resource ▶ Get the authenticated user identity ▶ Get the authenticated OAuth token ▶ Check whether owner of requested credential and its identifier portion resource and user identifier match ▶ Find access right object referred by this identifier ▶ Check whether owner of requested resource and owner in referred access right object match ▶ Check whether request context (method, time…) matches referred access right objectFebruary 2012 - All rights reserved 18
    • Assessing - IT-SecurityRelation to SAML / XACML▶ For constrained user agents/networks (e.g. smart phones, mobile networks): – Express access rights based on XACML policy syntax locally upon authorization servers – Exchange access right objects via SAML profile of XACML (policy queries/ statements) between authorization and resource servers – Request decision making based on XACML context syntax locally upon resource servers or between authorization and resource servers▶ Else: – Express self-contained authorization grants based on SAML profile of XACML (policy statements) – Express self-contained access tokens based on SAML profile of XACML (policy statements) – Externalize initial client authentication to STS-style entities and express the authenticated client identity in SAML assertion syntax (when performing subsequent authentication against authorization servers).▶ The identified deployments of SAML and XACML with OAuth are optional. On an architectural level it is instructive to ‘instantiate’ OAuth exchanges with SAML and XACML abstractions as these OASIS standards deliver specific syntaxes (in the XML form-factor) for things OAuth leaves abstract.February 2012 - All rights reserved 19
    • Assessing - IT-SecurityHTTP Security▶ Historically, HTTP security was confined to the bearer model, modulo: – Kerberos-in-HTTP goes beyond bearer but does not bind HTTP message contents into the cryptographic protection – Performing SSL/TLS client authentication and honoring SSL/TLS state on HTTP or Web application level allows to go beyond bearer.▶ Starting with OAuth, HTTP security can extend beyond bearer in a way that binds HTTP message contents to cryptographic keys and is independent of SSL/TLS: – This concerns exchanges between intermediaries and services. With OAuth 1.0 the proof model is compulsory for them, with 2.0 it is an option. – Making proof optional does not fall behind current practices: HTTP state retained in session cookies is subject to limitations of the bearer model. – However this is critical from a user and solution deployment perspective: • Normal users will not understand given options and their implications (user agents are no party in choosing such options but users have a stake). • OAuth does not yet provide discovery or in-band negotiation mechanisms regarding this (bearer vs. proof) as well as other protocol options (e.g. HMAC algorithm). There is not yet a configuration meta-model. Hence adding options to the protocol is likely to result in a situation where interacting endpoints need to sort out settings in a manual fashion on a mutual basis.February 2012 - All rights reserved 20
    • Assessing - IT-SecurityPseudo-Authentication▶ OAuth can be employed in a mode allowing intermediaries to authenticate users: – The intermediary does not perform (usual) authentication for its users – The intermediary requests specific resources from services (triggered by users) – The service initiates the OAuth exchange – The intermediary redirects the user to the service – The user authenticates against the service and delegates access rights (subject to OAuth deployment details) – The service redirects the user to the intermediary – The intermediary obtains the OAuth credential – The intermediary obtains user details from the service (not defined in OAuth) – If successful, the intermediary regards this user as authenticated▶ This OAuth deployment mode is known as pseudo-authentication (cf. http://nat.sakimura.org/2011/05/15/dummys-guide-for-the-difference-between- oauth-authentication-and-openid/).▶ Using OAuth in pseudo-authentication mode way produces authorization side- effects: access rights may be granted to intermediaries. It should not be used for federated login-only purposes.February 2012 - All rights reserved 21
    • Assessing - IT-SecurityFurther Observations▶ Intermediaries present inline, trusted 3rd-parties: – Intermediaries that are in possession of valid OAuth credentials or that can obtain them may access protected resources of resource owners i.e. resource owners need to trust intermediaries. – I.e. the enforcement does not limit intermediaries to act only on behalf of self (resource owners).▶ As this is not enforced, it might make sense to abstract from the requirement that intermediaries do access protected resources in a way that reflects resource owner actions synchronously. – Allows to support further use cases aiming at delegating to other users (e.g. members of a care team in health-care) rather than intermediaries acting on behalf of self (the patient).▶ As a further implication it might also make sense to enforce OAuth-style checks at Web applications i.e. for accesses via usual Web browsers, not only at Web APIs for accesses via intermediary applications – When delegating to other individual users rather (rather than intermediaries acting on behalf of self) one should not restrict that users to the Web API point-of-entry.February 2012 - All rights reserved 22
    • Assessing - IT-SecurityMain OAuth Ingredients▶ OAuth is an initiative in the intersection of IT-security and IAM: – It delivers IAM functionality – But the abstractions it actually defines or considers are specific to IT-security: • Framework for putting independent Web entities (esp. resource owners and intermediaries) into relation through HTTP redirects. This process is: o Initiated by intermediaries o Steered by services • Proof model for sustaining HTTP state • Cryptographic checksums for HTTP request contents • Extensive threat and security considerations▶ Regarding IAM, OAuth presents a ‘molecule’ i.e. supplies a framework allowing to mount ‘atomic’ elements provided by others such as – Existing authorization subsystem infrastructure and technology together with their native object model – Syntaxes to express self-contained tokens (e.g. SAML, JWT) – Syntaxes to express authorization policies according DAC along with corresponding authorization decision requests and responses (e.g. XACML) rather than coining own currencies.February 2012 - All rights reserved 23
    • Conclusions▶ OAuth addresses a problem in application composition for Web environments: delegation of resource access to 3rd-parties on behalf of resource owners.▶ Defines a 3-party security protocol embedded with HTTP which: – Allows to delegate access rights to 3rd-party clients on a discretionary basis. – Enhances the security model for sustaining HTTP session state by adding support for proof. – Extends the HTTP access authentication framework by defining means to sign HTTP request messages (HMAC-based symmetric checksums).▶ Delivers an additional solution pattern for Web security addressing a use case in cloud computing, SOA, and Web 2.0: – Services providing Web APIs: need to consider OAuth as it presents the current mainline to delegate access rights to 3rd-party clients on a discretionary basis. – Intermediaries calling such APIs: need to consider OAuth as services are likely to require that.▶ OAuth is an emerging technology currently being shaped out: – Version 1.0 addresses the underlying use case with little degrees of freedom. – Version 2.0 (work-in-progress) simplifies the 3-party handshake for the actual use case but otherwise adds various degrees of freedom. This presents a premium and a burden at the same time.February 2012 - All rights reserved 24
    • Further Information▶ Working group / community: – http://datatracker.ietf.org/wg/oauth/ – http://oauth.net/ – http://hueniverse.com/oauth/▶ Specs: – OAuth 1.0 community spec: http://oauth.net/core/1.0/ – OAuth 1.0a community spec: http://oauth.net/core/1.0a/ – OAuth 1.0 RFC: http://tools.ietf.org/html/rfc5849.txt – OAuth 2.0: http://tools.ietf.org/id/draft-ietf-oauth-v2-23.txt et al. (work-in-progress)▶ Testing: – http://googlecodesamples.com/oauth_playground/ – https://code.google.com/oauthplayground/February 2012 - All rights reserved 25
    • Appendix - OAuth 1.0 DetailsTokens and Credentials▶ Token form-factors: – Tokens always come in form of identifiers in OAuth 1.0. – Self-contained tokens are not supported in OAuth 1.0.▶ Credential types: – 3rd-party client credentials: native objects to identify intermediaries and authenticate them (established a priori) – Temporary credentials: OAuth-created objects to identify intermediaries and authenticate them • Temporary credentials are ephemeral objects subsequently being replaced by token credentials during an OAuth 1.0 credentials acquisition phase. • They provide a means of indirection (allow to reference the intermediary with a different identifier than in 3rd-party client credentials). • OAuth 2.0 discontinues temporary credentials as they imply extra roundtrips and have an impact on state management efforts. – Token credentials: OAuth-created objects to identify delegated access rights and authenticate access requests.February 2012 - All rights reserved 26
    • Appendix - OAuth 1.0 DetailsCompass to Main Abstractions Involves Resource Invokes Delegates owner Acquires Access Service Intermediary right(s) Refers to Acquires Temporary credential Refers to Used to create Token credential Required to access protected Accesses Resource OwnsFebruary 2012 - All rights reserved 27
    • Appendix - OAuth 1.0 DetailsService Endpoints▶ Resource access endpoint: – Used by intermediaries to request resources. – E.g. https://serviceprovider.example/businessFunctionality▶ OAuth endpoints: – Temporary credential acquisition: • Used by intermediaries to request temporary credentials. • E.g. https://serviceprovider.example/obtainTemporaryCredential – 3rd-party client entitlement: • Used by resource owners to delegate access rights to intermediaries. • E.g. https://serviceprovider.example/entitleIntermediary – Token credential acquisition: • Used by intermediaries to request token credentials. • E.g. https://serviceprovider.example/obtainTokenCredentialFebruary 2012 - All rights reserved 28
    • Appendix - OAuth 1.0 DetailsHigh-Level Protocol Exchange Resource Inter- owner 4. Redirect resource owner to intermediary mediary 1. Obtain temporary 0. Access 2. Redirect resource credential resource w/o owner to service credential 3. Delegate (denied) access rights to 5. Obtain token intermediary 6. Access resource credential with credential (permitted) 3rd-party client Token creds Temp creds Resource entitlement acquisition acquisition access OAuth endpoints endpoint Service 3rd-party client credentials (shared secret User credentials (shared secret or asymmetric keying association) or asymmetric keying association) Not shown: initiating request from resource owner to intermediary and corresponding response (cf. diagrams below)February 2012 - All rights reserved 29
    • Appendix - OAuth 1.0 DetailsMain Protocol Steps▶ OAuth credentials usage phase: – Access protected resources upon services • Intermediaries request protected resources at resource access endpoints • These requests are authenticated based on 3rd-party client and token credentials▶ OAuth credentials acquisition phase: – Acquire temporary credentials from services • Intermediaries request temporary credentials at corresponding endpoints • These requests are authenticated based on 3rd-party client credentials – Entitle intermediaries upon services • Resource owners entitle intermediaries at 3rd-party client entitlement endpoints • These requests are authenticated based on native user credentials – Acquire token credentials from services • Intermediaries request token credentials at corresponding endpoints • These requests are authenticated based on 3rd-party client and temporary credentialsFebruary 2012 - All rights reserved 30
    • Appendix - OAuth 1.0 DetailsOAuth Credentials Usage Service Resource Inter- Resource owner mediary access endpoint 1. GET/POST... (request 3rd-party client resource) 2. GET/POST...Authorization: OAuth Authn inter- (request service resource) mediary via , . Authz 3. 200 OK (service resource) intermediary 4. 200 OK (3rd-party client resource) via access right objects.▶ While serving requests from resource owners, intermediaries may: – Find matching token credentials in their local state (from former acquisitions). • With respect to service state they may match (shown above) or not - due to e.g. expiry (need to re-acquire token credentials) – Not find matching token credentials (need to acquire token credentials) 3rd-party client credentials (shared secret Token credentials (shared secret) or asymmetric keying association)February 2012 - All rights reserved 31
    • Appendix - OAuth 1.0 DetailsAccess Protected Resources▶ Request from intermediary: – Intermediaries access resources by making OAuth-authenticated HTTP requests. Required OAuth parameters: • Checksum parameters: detailed below • Nonce/timestamp parameters: detailed below▶ Response to intermediary: – Services authenticate resource access requests i.e. verify provided cryptographic checksums – Services enforce the 3rd-party client entitlement as represented in an access right object referred to by the token credentials. – (If valid and entitled) services respond with requested resourcesFebruary 2012 - All rights reserved 32
    • Appendix - OAuth 1.0 DetailsOAuth Credentials Acquisition Service Resource Inter- Resource OAuth owner mediary endpoints access endpoint 1. GET/POST... (request 3rd-party client resource) 2. GET/POST... (request service resource) 3. 401 Unauthorized WWW-Authenticate: OAuth… 4. POST... (request temp. creds, provide callback endpoint) Authn intermediary via 5. 200 OK (temp creds ) Issue temp creds 6. 302 Redirect (to 3rd-party client entitlement endpoint) 7. GET... (request 3rd-party client entitlement page) 8. 200 OK (3rd-party client entitlements page) 9. GET/POST... (request delegation of 3rd-party client entitlements) Authn user via 10. 302 Redirect (to OAuth callback endpoint ) Assign delegated rights Create verification code 11. GET... (OAuth callback endpoint ) 12. GET/POST... (request Authn intermediary token creds, ) via , Check verification code 13. 200 OK (token creds ) Issue token creds 14. GET/POST...Authorization: OAuth Authn inter- (request service resource) mediary via 15. 200 OK (service resource) , . Authz 16. 200 OK (3rd-party client resource) intermediary via access Prerequisite for OAuth credentials acquisition exchange Created during OAuth credentials acquisition exchange right objects.February 2012 - All rights reserved 33
    • Appendix - OAuth 1.0 DetailsAcquire Temporary Credentials▶ Request from intermediary: – Intermediaries request temporary credentials by making OAuth-authenticated POST requests. Required OAuth parameters (in authentication header): • Checksum parameters: detailed below • Nonce/timestamp parameters: detailed below • oauth_callback: URL to which services redirect resource owners after completing the 3rd-party client entitlement step▶ Response to intermediary: – Services authenticate temporary credential requests – (If valid) services respond with temporary credentials. Required OAuth parameters (in entity body of HTTP response): • oauth_token: identifier portion of the temporary credentials • oauth_token_secret: shared-secret portion of the temporary credentials • oauth_callback_confirmed: Boolean to differentiate protocol versions▶ Temporary credentials acquisition must be conducted via SSL/TLS.February 2012 - All rights reserved 34
    • Appendix - OAuth 1.0 DetailsEntitle Intermediaries▶ Request from resource owner: – Triggered by intermediaries via HTTP redirection response – The resulting request must use the GET method. Required OAuth parameters (in query component of redirection URI): • oauth_token: identifier portion of the temporary credentials. This identifies the intermediary.▶ Response to resource owner: – Services authenticate requestors and establish their resource ownership before accepting entitlements of 3rd-parties – After receiving such entitlements, services trigger a request to intermediaries (to callback URL in oauth_callback) via HTTP redirection response. – The resulting requests must contain following OAuth parameters (in query component of redirection URI): • oauth_token: identifier portion of the temporary credentials • oauth_verifier: the verification code, a random value passed to the intermediary via the resource owner▶ The redirects transfer OAuth parameters and their values via URL queries.▶ Details how services conduct entitlement requests, including whether they use SSL/TLS are not defined in RFC 5849.February 2012 - All rights reserved 35
    • Appendix - OAuth 1.0 DetailsAcquire Token Credentials▶ Request from intermediary: – Intermediaries request token credentials by making OAuth-authenticated POST requests. Required OAuth parameters (in authentication header): • Checksum parameters: detailed below • Nonce/timestamp parameters: detailed below • oauth_verifier: the verification code▶ Response to intermediary: – Services authenticate token credential requests and check verification codes – Services check that resource owners have delegated access rights to intermediaries – (If valid) services respond with token credentials. Required OAuth parameters (in entity body of HTTP response): • oauth_token: identifier portion of the token credentials • oauth_token_secret: shared-secret portion of the token credentials▶ Token credentials acquisition must be conducted via SSL/TLS.February 2012 - All rights reserved 36
    • Appendix - OAuth 1.0 DetailsProgressing Service-Side State Objects representing Objects representing intermediaries granted access rights • Client identifier 3rd-party • User identifier0. Established • Client key client credential • User shared secret (or means toa priori validate asymmetric keying) • Client identifier (in, from authn)1. Acquire temp • Callback URL (in)credentials • Creds identifier (out) Temporaryrequest/response • Creds key (out) credential • User identifier (in, from authn) • Creds identifier (in, updated in token acquisition step) • Access right details (beyond2. Entitle 3rd- OAuth, in)party clients • Verification code (out)request/response • Client identifier (in, from authn) • Creds identifier (in, from authn)3. Acquire token • Verification code (in)credentials • Creds identifier (out) Tokenrequest/response • Creds key (out) credential In: Information provided with requests Out: Information provided with responsesFebruary 2012 - All rights reserved 37
    • Appendix - OAuth 1.0 DetailsHTTP Authentication▶ The OAuth-defined HTTP authentication employs cryptographic checksums to perform entity and data origin authentication.▶ OAuth checksums are created for HTTP requests in the following protocol steps: – Acquire temporary credentials – Acquire token credentials – Access protected resources▶ The key portions from following credentials are used in OAuth checksum creation: – Acquire temporary credentials: 3rd-party client credentials – Acquire token credentials: 3rd-party client and temporary credentials – Access protected resources: 3rd-party client and token credentialsFebruary 2012 - All rights reserved 38
    • Appendix - OAuth 1.0 DetailsHTTP Authentication Mechanisms▶ OAuth supports following cryptographic mechanisms for HTTP authentication: – HMAC-SHA1: • Computes checksum=HMAC-SHA1(key,text) according RFC 2104 where: o k e y concatenates the shared-secrets in 3rd-party client and temporary or token credentials o t e x t is described below – RSA-SHA1: • Computes checksum=RSASSA-PKCS1-V1_5-SIGN(key,text) according PKCS#1 v2.1 (RFC 3447) where: o k e y is the intermediary‘s private key o t e x t is described below – PLAINTEXT: • Concatenates the shared-secrets in 3rd-party client and temporary or token credentials i.e. does not provide a real checksum (must be used with SSL/TLS).▶ This digest assumes HMAC-SHA1 as checksum creation algorithm (unless otherwise noted)February 2012 - All rights reserved 39
    • Appendix - OAuth 1.0 DetailsHTTP Authentication Payload▶ The OAuth checksum includes following information in its payload: – The HTTP request method – The authority part as declared by the HTTP Host request header field – The path and query components of the request URI – The OAuth protocol parameters excluding oauth_signature – (Some) further request parameters included in the request entity-body▶ Hence the OAuth checksum provides data origin authentication for a subset of the information contained in HTTP requests, not the whole HTTP request.February 2012 - All rights reserved 40
    • Appendix - OAuth 1.0 DetailsHTTP Authentication Parameters▶ Validating OAuth-defined checksums depends on metadata shared between intermediaries and services. This metadata is expressed in following parameters: – oauth_consumer_key: identifier portion of the 3rd-party client credentials (as a means to refer to the corresponding key) – oauth_token: identifier portion of the temporary or token credentials (as a means to refer to the corresponding key) – oauth_signature_method: specifies the checksum computation mechanism (HMAC-SHA1, RSA-SHA1, or PLAINTEXT) – oauth_signature: actual value of the checksum▶ These parameters need to be present in OAuth-authenticated HTTP requests i.e.: – Acquire temporary credentials • Note: the oauth_token parameter value is empty (no such value is available at this point) and may be omitted. – Acquire token credentials – Access protected resourcesFebruary 2012 - All rights reserved 41
    • Appendix - OAuth 1.0 DetailsFurther Protocol Parameters▶ OAuth uses nonces and timestamps (generated by intermediaries) to facilitate safeguards against replay (on side of the services): – oauth_nonce: random, uniquely generated string – oauth_timestamp: current time (as number of seconds since the Epoch)▶ These parameters need to be present in OAuth-authenticated HTTP requests i.e.: – Acquire temporary credentials – Acquire token credentials – Access protected resourcesFebruary 2012 - All rights reserved 42
    • Appendix - OAuth 2.0 DetailsOverall Changes▶ Additional entity (authorization server) decoupling OAuth-specific endpoints from resource access endpoints on the side of a service.▶ Additional abstraction (authorization grant) facilitating additional flows to acquire tokens▶ Alternative token form-factors (identifier vs. self-contained). In case of self- contained tokens: various syntax options such as SAML, JWT▶ Alternative token families (bearer vs. proof)▶ Decoupled lifetime for access right and token objects (refresh token)▶ Extensible protocol abstractions (e.g. own authorization grant types)▶ Wording e.g. “resource server“ or “access token“ instead of “server“ or “token“ respectively. Token rather than credential-centric terminology due to addition of the bearer token family. – To ease comparison this digest uses the same terms in the OAuth 1.0 and 2.0 sections for abstractions that correspond each other.February 2012 - All rights reserved 43
    • Appendix - OAuth 2.0 DetailsChanges for OAuth Credentials Usage▶ Ability to use tokens in the form of self-contained objects▶ Protocol syntax esp. OAuth parameter naming▶ Checksum creation: – Subject to family (proof vs. bearer) and type of token (e.g. MAC token type) – In case of the MAC access authentication: • Support of HMAC-SHA256 • Checksum creation always uses singular shared-secrets as keys. • Secrets shared are established between authorization servers and intermediaries. This may be done through: o OAuth 2.0 protocol based on MAC-type tokens o Set-Cookie response header fields Manual, out-of-band handling o • Details of HTTP request canonicalization in order to create the input for checksum creation (e.g. inclusion of port number defaults, request body)▶ Does otherwise correspond OAuth 1.0 on a conceptual levelFebruary 2012 - All rights reserved 44
    • Appendix - OAuth 2.0 DetailsOAuth Credentials Usage Service Resource Inter- (resource owner mediary server) 1. GET/POST... (request 3rd-party client resource) 2. GET/POST...Authorization: MAC Authn inter- (request service resource) mediary via Authz inter- 3. 200 OK (service resource) mediary via 4. 200 OK (3rd-party client resource) access right objects Token credentials (shared secret)February 2012 - All rights reserved 45
    • Appendix - OAuth 2.0 DetailsAccess Protected Resources▶ Request from intermediary: – Corresponds to OAuth 1.0 (with the above remarks) – Note: OAuth 2.0 supports self-contained tokens but there is not yet a specification that profiles the contents of such tokens for resource access. • draft-ietf-oauth-v2-bearer-16.txt stays abstract • draft-ietf-oauth-saml2-bearer-10.txt and draft-jones-oauth-jwt- bearer-03.txt describe tokens in interaction with authorization servers.▶ Response to intermediary: – Corresponds to OAuth 1.0 (with the above remarks) – Resource and authorization servers need to interact. This involves: • Key or data “tourism” (in case of MAC access authentication): Obtain key for request authentication purposes from authorization servers o o Delegate request authentication to authorization servers • Local or remote PDP (in case of identifier as token form-factor): o Request access right objects from authorization servers o Delegate decision making to authorization serversFebruary 2012 - All rights reserved 46
    • Appendix - OAuth 2.0 DetailsChanges for OAuth Credentials Acquisition▶ Authorization servers as distinguished system entities with following endpoints: – 3rd-party client entitlement (aka authorization endpoint): – Token credential acquisition (aka token endpoint):▶ Authorization grants as additional abstraction▶ Additional flows to acquire tokens (subject to chosen type of authorization grant)▶ No temporary credentials. Credentials acquisition becomes a 2-step process: – Entitle intermediaries upon authorization servers • Resource owners delegate access at 3rd-party client entitlement endpoints. • These requests are authenticated based on native user credentials – Acquire token credentials from authorization servers • Intermediaries request token credentials at corresponding endpoints. • These requests are authenticated based on 3rd-party client credentialsFebruary 2012 - All rights reserved 47
    • Appendix - OAuth 2.0 DetailsOAuth Credentials Acquisition OOB Resource Inter- Authz Service owner mediary server (resource server) 1. GET/POST... (request 3rd-party client resource) 2. GET/POST... (request service resource) 3. 401 Unauthorized WWW-Authenticate: MAC… 4. 302 Redirect (to 3rd-party client entitlements endpoint) 5. GET... (request 3rd-party client entitlements page) 6. 200 OK (3rd-party client entitlements page) Authn user via 7. GET/POST... (request delegation of 3rd-party client entitlements) Assign delegated rights 8. 302 Redirect (to OAuth callback endpoint ) Create authorization code 9. GET... (OAuth callback endpoint ) 10. GET/POST... (request token creds ) Authn intermediary via 11. 200 OK (token creds ) Issue token creds 12. GET/POST...Authorization: MAC Authn inter- (request service resource) mediary via 13. 200 OK (service resource) Authz inter- 14. 200 OK (3rd-party client resource) mediary via access right objects Prerequisite for OAuth credentials acquisition exchange Created during OAuth credentials acquisition exchangeFebruary 2012 - All rights reserved 48
    • Appendix - OAuth 2.0 DetailsEntitle Intermediaries▶ Request from resource owner: – Triggered by intermediaries via HTTP redirection response. Required OAuth parameters (in query component of redirection URI): • response_type: type of requested authorization grant (e.g. Code) • client_id: the identifier of the intermediary • redirect_uri: URI to which authorization servers redirect resource owners after completing the 3rd-party client entitlement step • scope: the scope of the access request • state: opaque value used by the intermediary to maintain state between request and callback.▶ Response to resource owner: – Authorization servers authenticate requestors and establish their resource ownership before accepting entitlements for 3rd-party clients. – After receiving such entitlements, authorization servers trigger a request to intermediaries (to URL in redirect_uri) via HTTP redirection response. – The resulting requests must contain following OAuth parameters (in query component of redirection URI): • code: the authorization code • state: as aboveFebruary 2012 - All rights reserved 49
    • Appendix - OAuth 2.0 DetailsAcquire Token Credentials▶ Request from intermediary: – Intermediaries request tokens by making OAuth-authenticated requests. Required OAuth parameters (in entity body of HTTP request): • grant_type: type of authorization grant (e.g. authorization_code) • code: the authorization code • redirect_uri: same value as above (serves verification purposes)▶ Response to intermediary: – Authorization servers authenticate token requests – Authorization servers check that resource owners have delegated access rights to intermediaries – (If valid) authorization servers respond with tokens. Required OAuth parameters (in entity body of HTTP response): • access_token: the MAC key identifier (for MAC-type tokens) • token_type: type of the token (mac for MAC-type tokens) • expires_in: the lifetime in seconds of the token • refresh_token: the refresh token which can be used to obtain new tokens using the same authorization grant • scope: the scope of the token • mac_key: the MAC key • mac_algorithm: the MAC algorithm (e.g. hmac-sha-1)February 2012 - All rights reserved 50
    • Appendix - OAuth 2.0 DetailsProgressing Service-Side State Objects representing Objects representing intermediaries granted access rights • Client identifier 3rd-party • User identifier0. Established • Client key client credential • User shared secret (or means toa priori validate asymmetric keying) • User identifier (in, from authn) • Client identifier (in) • Callback URL (in) • Scope (in) • Further access right details (beyond OAuth, in) • Client state (in)1. Entitle 3rd- • Authorization code (out)party client • Client state (out)request/response • Client identifier (in, from authn) • Authorization code (in) • Creds identifier (out) Token • Creds key (out) credential • MAC algorithm (out)2. Acquire token • Further token metadata (out)credentials • Refresh tokenrequest/response In: Information provided with requests Out: Information provided with responsesFebruary 2012 - All rights reserved 51
    • Appendix - OAuth 2.0 DetailsDegrees of Freedom▶ OAuth 2.0 provides significantly more degrees of freedom than version 1.0▶ To ease comparison with OAuth 1.0 as well as to keep this digest handy following assumptions were made up to here: – 3rd-party client type and profile: • Confidential client • Web application – Authorization grant type: authorization code (family: bearer, form-factor: identifier) – Access token type: MAC (family: proof, form-factor: identifier) – Protocol flow: • 3-legged exchange • No refresh token▶ The following section identifies alternatives without exploring alternate protocol flows facilitated by them in detail.February 2012 - All rights reserved 52
    • Appendix - OAuth 2.0 Details3rd Party Client Types and Profiles▶ 3rd-party client types (cf. draft-ietf-oauth-v2-23.txt): – Confidential: • Capable of maintaining the confidentiality of their credentials or capable of secure client authentication using other means. – Public: • Incapable of maintaining the confidentiality of their credentials and incapable of secure client authentication using other means.▶ 3rd-party client profiles (cf. draft-ietf-oauth-v2-23.txt): – Web application: • Confidential 3rd-party client running on a Web server. – User-agent-based application: • Public 3rd-party client in which the client code is downloaded from a Web server and executes within a user agent (e.g. Web browser) on the resource owners device. – Native application: • Public 3rd-party client installed and executed on the resource owners device.February 2012 - All rights reserved 53
    • Appendix - OAuth 2.0 DetailsAuthorization Grant▶ Abstraction referring to access rights delegated to intermediaries: – To-be-supplied by intermediaries when requesting tokens – Consumed by authorization servers (at token endpoints), in some cases also produced by them (at authorization endpoints)▶ OAuth specifies following types (supplementary ones may be added): – Authorization code (for token pull via authorization and token endpoints): short- lived, one-time usage reference values – Implicit (for token push via authorization endpoint): tokens are provisioned • Simplified exchange for constrained intermediaries – Resource owner credentials (for token pull via token endpoint): resource owner credentials are supplied when requesting tokens • Accommodates an otherwise deprecated practice in a mitigated flavor – 3rd-party client credentials (for token pull via token endpoint): 3rd-party client credentials are supplied when requesting tokens • Limited to 3rd-party client-controlled resources; so-called 2-legged exchange.▶ Note: credential-type grants use owner’s access right objects i.e. do not depend on specific objects representing delegations (in contrast to other grants above).February 2012 - All rights reserved 54
    • Appendix - OAuth 2.0 DetailsAccess Token▶ Abstraction also referring to access rights delegated to intermediaries - at another level of indirection: – To-be-supplied by intermediaries when requesting protected resources – Consumed by services (resource servers) – Produced by authorization servers (at token endpoints) on base of authorization grants or refresh tokens presented by intermediaries▶ OAuth specifies following types (supplementary ones may be added): – MAC • Family: proof • Form-factor: identifier – Bearer • Family: bearer • Form-factor: self-containedFebruary 2012 - All rights reserved 55
    • Appendix - OAuth 2.0 DetailsCompass to Main Abstractions Involves Resource Invokes Delegates owner Passed to Entitle Access Authorization Intermediary intermediaries right(s) server Refers to Authorization Refers Acquires to grant* Used to create Acquire tokens Used Refresh to create token Access Used to re-new token Required to access protected Service Resource Owns (resource Accesses server) *: Assumes the authorization grant type authorization codeFebruary 2012 - All rights reserved 56
    • Author▶ Oliver Pfaff oliver.frank.pfaff@gmail.comFebruary 2012 - All rights reserved 57