This document provides an overview of OAuth 2.0 and how it addresses issues with the previous "password anti-pattern" approach to API authentication. It describes the key actors in OAuth - clients, authorization servers, and resource servers. It also summarizes the different flows for obtaining access tokens, common use cases for OAuth, and how OAuth compares to SAML for SSO and authorization.
Introduction to Multilingual Retrieval Augmented Generation (RAG)
Â
CIS13: Introduction to OAuth 2.0
1. Copyright Š2013 Ping Identity Corporation. All rights reserved.1
OAuth2
John Bradley, Sr. Technical Architect, Ping Identity
2. Copyright Š2013 Ping Identity Corporation. All rights reserved.2
Copyright Š2013 Ping Identity Corporation. All rights reserved.2
OAuth 2.0
3. Copyright Š2013 Ping Identity Corporation. All rights reserved.3
â˘âŻ 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 âŚ.
4. Copyright Š2013 Ping Identity Corporation. All rights reserved.4
On consumer web, once
prevalent API authentication
model was the so-called
âpassword anti-patternâ
5. Copyright Š2013 Ping Identity Corporation. All rights reserved.5
Password anti-pattern
Site asks YOU for your GOOGLE password
so it can access your Google stuff.
6. Copyright Š2013 Ping Identity Corporation. All rights reserved.6
â˘âŻ 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!
7. Copyright Š2013 Ping Identity Corporation. All rights reserved.7
â˘âŻ 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
8. Copyright Š2013 Ping Identity Corporation. All rights reserved.8
OAuth Timeline
Community
IETF
WRAP
2010 2011200920082007
OAuth 1.0
OAuth 1.0a
OAuth 2.0 RFC 6749
Info RFC 5849
JWT
9. Copyright Š2013 Ping Identity Corporation. All rights reserved.9
â˘âŻ 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
10. Copyright Š2013 Ping Identity Corporation. All rights reserved.10
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
11. Copyright Š2013 Ping Identity Corporation. All rights reserved.11
â˘âŻ 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/
12. Copyright Š2013 Ping Identity Corporation. All rights reserved.12
â˘âŻ 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
13. Copyright Š2013 Ping Identity Corporation. All rights reserved.13
â˘âŻ 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
14. Copyright Š2013 Ping Identity Corporation. All rights reserved.14
End to end flow (code flow)
Get authorization grant
Trade grant for access token
Use access token
15. Copyright Š2013 Ping Identity Corporation. All rights reserved.15
â˘âŻ 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
16. Copyright Š2013 Ping Identity Corporation. All rights reserved.16
â˘âŻ 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
17. Copyright Š2013 Ping Identity Corporation. All rights reserved.17
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
18. Copyright Š2013 Ping Identity Corporation. All rights reserved.18
â˘âŻ 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
19. Copyright Š2013 Ping Identity Corporation. All rights reserved.19
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
20. Copyright Š2013 Ping Identity Corporation. All rights reserved.20
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
22. Copyright Š2013 Ping Identity Corporation. All rights reserved.22
â˘âŻ 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
23. Copyright Š2013 Ping Identity Corporation. All rights reserved.23
â˘âŻ 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
24. Copyright Š2013 Ping Identity Corporation. All rights reserved.24
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
25. Copyright Š2013 Ping Identity Corporation. All rights reserved.25
Copyright Š2013 Ping Identity Corporation. All rights reserved.25
OAuth 2.0
Use cases
26. Copyright Š2013 Ping Identity Corporation. All rights reserved.26
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
27. Copyright Š2013 Ping Identity Corporation. All rights reserved.27
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
28. Copyright Š2013 Ping Identity Corporation. All rights reserved.28
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
29. Copyright Š2013 Ping Identity Corporation. All rights reserved.29
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
30. Copyright Š2013 Ping Identity Corporation. All rights reserved.30
Cloud APIs
Enterprise Salesforce
AS
Database.com
SAML assertion
token
API call (token)
1
2
3
Client
31. Copyright Š2013 Ping Identity Corporation. All rights reserved.31
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
32. Copyright Š2013 Ping Identity Corporation. All rights reserved.32
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
33. Copyright Š2013 Ping Identity Corporation. All rights reserved.33
Seesmic as Salesforce Chatter Client
Seesmic pops a browser window to
AS, within which user authenticates
and grants authorizations
34. Copyright Š2013 Ping Identity Corporation. All rights reserved.34
Questions?
â˘âŻ Related whitepaper at
pingidentity.com â âEssentials of
OAuthâ
â˘âŻ John Bradley tweets at @ve7jtb