Analyzing OAuth

Analyzing OAuth

Oliver Pfaff
February 11, 2012

Contents

▶ Setting the scene
▶ Fundamentals
▶ Assessing
– IAM practices
– IT-security
▶ Conclusions
▶ Further information
▶ Appendix
– OAuth 1.0 details
– OAuth 2.0 details

February 2012 - All rights reserved 2

Setting the Scene
Background

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 users


Setting the Scene
About 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)


Setting the Scene
Composite 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 photos


Setting the Scene
Authenticating/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).


Setting the Scene
Vs. Traditional Web Security

User

User agent

Traditional
Web applications Web security
Composite
Traditional application Authn/Authz
Web security Beyond
traditional
Web applications Web APIs Web security
Authn/Authz Service Authn/Authz

User-owned resources


Setting the Scene
Use 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 parking


Fundamentals
OAuth 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 item


Fundamentals
OAuth 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 services


Fundamentals
OAuth 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.


Fundamentals
Main 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.


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 for
credentials
realm=“acme.com" HTTP basic and digest authentication.
Acquire
▶ OAuth employs this framework by
OAuth
… defining WWW-Authenticate and
credentials 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 OAuth
credentials – URI query parameters
n+1. 200 OK
– POST request bodies

OAuth credential (a posteriori object,
established through OAuth)


Fundamentals
OAuth Credentials Acquisition

Resource Inter-
owner 3. Redirect resource owner to intermediary mediary

4. Obtain credential
(authenticated with )
2. Delegate 0. Access resource
access 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)


Fundamentals
OAuth 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.


Assessing - IAM Practices
Use 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 management


Benchmarking 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.


Authorization Subsystem Integration

Web container Protected
HTTP
PEP resources
Authorization decision
Client: user agent or request/response
composite 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
object


Assessing - IT-Security
Relation 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.


HTTP 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.

Pseudo-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.


Further 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.


Main 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.


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.


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/


Appendix - OAuth 1.0 Details
Tokens 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.


Compass 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 Owns


Service 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/obtainTokenCredential


High-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)


Main 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
credentials


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)

Access 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 resources


Service
Resource Inter- Resource
OAuth
owner mediary endpoints
access
endpoint
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-
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.

Acquire Temporary Credentials

– Intermediaries request temporary credentials by making OAuth-authenticated
POST requests. Required OAuth parameters (in authentication header):
• oauth_callback: URL to which services redirect resource owners after
completing the 3rd-party client entitlement step
– 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.


Entitle 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.

Acquire Token Credentials

– Intermediaries request token credentials by making OAuth-authenticated
POST requests. Required OAuth parameters (in authentication header):
• oauth_verifier: the verification code
– 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.


Progressing Service-Side State
Objects representing Objects representing
intermediaries granted access rights

• Client identifier 3rd-party • User identifier
0. Established • Client key client credential • User shared secret (or means to
a priori validate asymmetric keying)

• Client identifier (in, from authn)
1. Acquire temp • Callback URL (in)
credentials • Creds identifier (out) Temporary
request/response • Creds key (out) credential

• User identifier (in, from authn)
• Creds identifier (in, updated in
token acquisition step)
• Access right details (beyond
2. Entitle 3rd-
OAuth, in)
party clients
• Verification code (out)
request/response

• Creds identifier (in, from authn)
3. Acquire token • Verification code (in)
credentials • Creds identifier (out) Token
request/response • Creds key (out) credential

In: Information provided with requests Out: Information provided with responses


HTTP 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 credentials


HTTP 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)


HTTP 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.


HTTP 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.:
• Note: the oauth_token parameter value is empty (no such value is
available at this point) and may be omitted.


Further 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.:


Overall 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.


Changes 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 level



Service
Resource Inter-
(resource
owner mediary
server)
2. GET/POST...Authorization: MAC Authn inter-
Authz inter-
3. 200 OK (service resource) mediary via
4. 200 OK (3rd-party client resource)
access right
objects

Token credentials (shared secret)


Access Protected Resources

– 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.
– 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 servers


Changes 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 credentials


OOB

Resource Inter- Authz Service
owner mediary server (resource
server)
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-
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 exchange


Entitle 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 above


Acquire Token Credentials
– 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)
– 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)

Progressing Service-Side State
Objects representing Objects representing
intermediaries granted access rights

• Client identifier 3rd-party • User identifier
0. Established • Client key client credential • User shared secret (or means to
a 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

• Authorization code (in)
• Creds identifier (out) Token
• Creds key (out) credential
• MAC algorithm (out)
2. Acquire token
• Further token metadata (out)
credentials
• Refresh token
request/response

In: Information provided with requests Out: Information provided with responses


Degrees 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.


3rd 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 owner's device.
– Native application:
• Public 3rd-party client installed and executed on the resource owner's
device.


Authorization 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).


Access 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-contained


Compass 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 code

Author

▶ Oliver Pfaff
oliver.frank.pfaff@gmail.com


Analyzing OAuth

Recommended

Recommended

More Related Content

What's hot

What's hot (7)

Similar to Analyzing OAuth

Similar to Analyzing OAuth (20)

More from Oliver Pfaff

More from Oliver Pfaff (15)

Recently uploaded

Recently uploaded (20)

Analyzing OAuth