Contenu connexe Similaire à CIS13: Introduction to OAuth 2.0 (20) Plus de CloudIDSummit (20) CIS13: Introduction to OAuth 2.01. 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