CIS13: Introduction to OAuth 2.0

Copyright ©2013 Ping Identity Corporation. All rights reserved.1
OAuth2
John Bradley, Sr. Technical Architect, Ping Identity

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 2011200920082007
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

OAuth 2.0
Use cases

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

Mobile social collaboration
•  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

Mobile social collaboration
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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a CIS13: Introduction to OAuth 2.0

Similar a CIS13: Introduction to OAuth 2.0 (20)

Más de CloudIDSummit

Más de CloudIDSummit (20)

Último

Último (20)

CIS13: Introduction to OAuth 2.0