CIS13: Introduction to OAuth 2.0
-
Upload
cloudidsummit -
Category
Technology
-
view
1.543 -
download
0
description
Transcript of 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
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 ….
Copyright ©2013 Ping Identity Corporation. All rights reserved. 4
On consumer web, once prevalent API authentication model was the so-called ‘password anti-pattern’
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.
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!
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
Copyright ©2013 Ping Identity Corporation. All rights reserved. 8
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
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
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
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/
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
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
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
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
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
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
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
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
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
Copyright ©2013 Ping Identity Corporation. All rights reserved. 21
Code Flow
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
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
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
Copyright ©2013 Ping Identity Corporation. All rights reserved. 25 Copyright ©2013 Ping Identity Corporation. All rights reserved. 25
OAuth 2.0 Use cases
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
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
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
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
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
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
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
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
Copyright ©2013 Ping Identity Corporation. All rights reserved. 34
Questions?
• Related whitepaper at pingidentity.com – ‘Essentials of OAuth’
• John Bradley tweets at @ve7jtb