Your SlideShare is downloading. ×
CIS13: Introduction to OAuth 2.0
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

CIS13: Introduction to OAuth 2.0

1,402
views

Published on

John Bradley, Senior Technical Architect, Ping Identity …

John Bradley, Senior Technical Architect, Ping Identity
OAuth 2.0 is the future of API Security, allowing software clients to request and use access tokens to access necessary APIs rather than caching and replaying usernames and passwords on every API fetch. John Bradley will explain the OAuth 2.0 protocol from top to bottom. Response types, authorization codes, front-channel vs. back-channel architecture decisions, security considerations and best practices will all be discussed. If you want to really understand OAuth, this session will dig deep.

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,402
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
55
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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
  • 21. Copyright ©2013 Ping Identity Corporation. All rights reserved.21 Code Flow
  • 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