cis13: introduction to oauth 2.0

Copyright ©2013 Ping Identity Corporation. All rights reserved. 1

OAuth2

John Bradley, Sr. Technical Architect, Ping Identity

Copyright ©2013 Ping Identity Corporation. All rights reserved. 2 Copyright ©2013 Ping Identity Corporation. All rights reserved. 2

OAuth 2.0


•  More and more, enterprise data is moving to the cloud –  Email, calendar, documents, contacts, music, photos, tasks,

video, notes, travel details, financials, social graph, location, etc.

•  Traditionally accessible via browser interface •  Increasingly also accessed from

–  Other clouds (websites) –  Mobile apps –  Desktop apps –  Other devices

•  Salesforce.com expects that within the next year - 1/3 of access will be via browser with the ‘rest’ being via API

If you’re API and you know it ….


On consumer web, once prevalent API authentication model was the so-called ‘password anti-pattern’


Password anti-pattern

Site asks YOU for your GOOGLE password so it can access your Google stuff.


•  Teaches users to be indiscriminate with theirs passwords

•  Distributed passwords present breach risk

•  Doesn’t support granular permissions, e.g. X can read but not write

•  The hosting site is not involved in the authorization step

•  Doesn’t support (easy) revocation – to be sure of turning off access users must change password

Tsk tsk!


•  http://oauth.net/

– An open protocol to allow secure API authorization in a simple and standard method from desktop and web applications.

OAuth: Antidote to the Anti-Pattern


OAuth Timeline

Community

IETF

WRAP

2010 2011 2009 2008 2007

OAuth 1.0 OAuth 1.0a

OAuth 2.0 RFC 6749 Info RFC 5849

JWT


•  WG Specification complete, Now named RFC 6749

•  Separates token issuance role from resource server

•  Supports number of different mechanisms by which an access token can be obtained

•  Early versions deprecated Oauth 1.0a’s token and message signing – justification was difficulty developers have with signatures

OAuth 2.0 overview


Actors

•  client: An application obtaining authorization and making protected resource requests.

•  resource server (RS): A server capable of accepting and responding to protected resource requests.

•  authorization server (AS): A server capable of issuing tokens after successfully authenticating the resource owner and obtaining authorization.

Client

Authorization Server

Resource Server

Get a token


•  token: A string/structure (often opaque to the client) representing an access authorization issued to the client. –  access token: A token used by

the client to make authenticated requests on behalf of the resource owner.

–  refresh token: A token used by the client to obtain a new access token without having to involve the resource owner.

Tokens

http://jspinbrain.blogspot.com/


•  May be Opaque or Structured for the RS

•  Opaque to the client – Format can be changed without modifying

clients – Clients can work with multiple AS using

different token formats •  Access tokens expire

Access Token


•  Revocation of Refresh tokens stop expired access tokens from being refreshed.

•  Allow for refresh of Access token without re-prompting the user.

•  The use of short lived access tokens with refresh tokens relieves the RS from needing to share state with the AS via a back channel.

Refresh Token


End to end flow (code flow)

Get authorization grant

Trade grant for access token

Use access token


•  Authorization code one type of ‘authorization grant’ •  OAuth 2.0 defines others

–  Implicit (for clients that can’t keep a secret, e.g. Javascript or embedded apps)

–  Resource owner password credentials (when the Client can be trusted (temporarily) with the user password)

–  Client credentials (when the authorization is determined by the client identity, and not a user’s permissions)

–  Extension point (for whatever else you might think of exchanging for an access token)

•  It’s this flexibility that allows OAuth to support variety of client types

Other ways to get an access token


•  Client specifies desired scope of permissions when requesting authorization

•  AS builds appropriate consent UI (when relevant)

•  ‘Issued’ scope may be less than requested scope

•  OAuth 2.0 does not itself define any scopes

•  Client should resist the urge to ask for authorizations ‘just in case’

Scope


OAuth Identity permutations

Client Resource

Client Resource

Client Resource

Access control to User data – permissions based on Client

Access control to business data – permissions based on Client

Client Resource Access control to Business data – permissions based on both User & Client

Access control to User data – permissions based on both User & Client


•  Growing number of OAuth 2.0 implementations –  Salesforce, for

•  authenticating REST API calls •  Web server redirect flow •  Trading SAML assertion for OAuth access token

–  Microsoft –Azure ACS •  Evolution of OAuth WRAP support

–  Facebook – authentication & authorization for Graph API

–  Google OpenID Connect & most API –  PayPal OpenID Connect & X.commerce API

OAuth 2.0 adoption


OAuth 2.0 Security Model

•  Following WRAP, early versions of OAuth 2.0 deprecated signatures/HMACs and relied on transport layer protections

•  SSL –  SHOULD for Client

accessing resource –  MUST for Client obtaining

access token •  Much ‘discussion’ in

community as to the appropriateness of a bearer token model


Security Model cont’d

•  Compromise is for OAuth 2.0 to support both a bearer token model as well as (optional) client signatures

•  Monolithic spec is broken into – ‘How to get a token’ spec RFC 6749 – ‘How to use’ a token specs

• Bearer RFC 6750 • Proof of Possession


Code Flow


•  A client is tricked by a resource into presenting a access token via a http 403 error response indicating insufficient_scope

•  The client can replay a bearer token at a real resource that accepts the token.

Confused Deputy


•  JWT defines a token format that can encode claims transferred between two parties. The claims are encoded as a JSON object , this bae64urlencoded, then digitally signed or encrypted using JOSE.

•  Logically similar to SAML assertion

•  Advantages –  simple to construct (form encoded

key value pairs) –  compact on the wire

•  Not specific to OAuth, will need to be profiled for access tokens

JSON Web Token


OAuth relationship to SAML

•  SAML SSO can provide user authentication mechanism for obtaining consent – OAuth is orthogonal to how the user

authenticates to the AS •  SAML’s SSO flow can be used to distribute

OAuth access tokens – As an optimization of doing a SAML-based

SSO sequence followed by OAuth sequence •  SAML assertion can be traded for access

token – more on this later in use case discussion


Use cases

Use case API User Client AS RS Notes

Consumer IDP

Profile & activity stream

Consumer Enterprise Social IdP Social IdP Authz step required

Cloud API Enterprise data & services

Employee Enterprise SaaS SaaS Leverages SSO & trust

Mobile social collaboration

Work-related updates

Employee Phone app Enterprise Enterprise Options for authentication


Consumer IDPs

•  Enterprise has a consumer-facing aspect, e.g. retail, customer service, etc •  Wants to accept identity from 3rd party consumer IdPs, e.g. Facebook, Twitter,

etc •  For user

–  No new account to create/manage •  For enterprise

–  Smaller registration hurdle for customers –  No pwd to manage/support –  Access to rich profile & activity data –  Option for social publishing back to Consumer IdP


Consumer IDPs

Enterprise Consumer IdP

AS

RS API call (token)

Authz code ?

Facebook et al

Browser

token

code

1

2

3

4

Rich profile data 5


Cloud APIs

•  Enterprise has existing SAML-based SSO set-up with cloud provider

•  Wants to use OAuth-protected REST APIs offered by Salesforce to retrieve data from Database.com for local analysis

•  Uses OAuth assertion flow to trade SAML assertion (normally sent to SaaS by SAML SSO) for OAuth access token

•  Subsequently uses access token on calls to Database.com API

http://www.database.com/what


Cloud APIs

Enterprise Salesforce

AS

Database.com

SAML assertion

token

API call (token)

1

2

3

Client



•  Enterprise is customer of Salesforce, encourages employees to use Chatter for work-related collaboration

•  Seesmic for Android is Chatter client (also Twitter etc) •  Seesmic retrieves access token from Salesforce hosted

AS •  Relies on browser-based authentication & authorization

for access token retrieval •  In this scenario, employee presents corporate

credentials to Salesforce, which then verifies them with enterprise. SSO also possible

•  Seesmic uses access tokens to call Chatter API



Enterprise

SaaS provider AS RS

API call (token) Browser

Social collaboration app token

Authn & consent

1

2

3

tokens

validation

4

5


Seesmic as Salesforce Chatter Client

Seesmic pops a browser window to AS, within which user authenticates and grants authorizations


Questions?

•  Related whitepaper at pingidentity.com – ‘Essentials of OAuth’

•  John Bradley tweets at @ve7jtb

cis13: introduction to oauth 2.0

Technology