Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Demystifying OAuth 2.0

6,934 views

Published on

It seems that OAuth 2.0 is everywhere these days. Whether you are building a hot new single page web application (SPA), a native mobile experience, or just trying to integrate with the API economy, you can't go far without running into the popular authorization framework for REST/APIs and social authentication.

During Oktane15 (https://www.okta.com/oktane15/), Karl McGuinness, our Senior Director of Identity, demystified the powerful, yet often misunderstood, world of OAuth 2.0 and shared details on Okta’s growing support for OpenID Connect.

Published in: Technology
  • Überprüfen Sie die Quelle ⇒ www.WritersHilfe.com ⇐ . Diese Seite hat mir geholfen, eine Diplomarbeit zu schreiben.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating direct: ❤❤❤ http://bit.ly/36cXjBY ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating for everyone is here: ❶❶❶ http://bit.ly/36cXjBY ❶❶❶
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Demystifying OAuth 2.0

  1. 1. Karl McGuinness Senior Director, Identity @ Okta Demystifying OAuth
  2. 2. Why OAuth? Breaking down OAuth 2.0 Pseudo-Authentication OpenID Connect Agenda Security & The Enterprise
  3. 3. Direct Authentication Password anti-pattern 3 GET /index.html HTTP/1.1 Host: www.example.com Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
  4. 4. Federated Identity 4 Identity Provider (IdP) Service Provider (SP) End User Trust Obtains Assertion Provides Assertion
  5. 5. Identity as Claims A claim is a statement or assertion that a certain fact applies to something or somebody • First Name = ‘Karl’ • Age > 21 • Okta Employee Issued by an Authority for a Subject (e.g. user, device, etc.) • Can self-asserted such as Facebook profile or issuer asserted such as Okta Organization • Explicit trust relationship with an issuer • Are subject to verification 5
  6. 6. SAML 2.0 OASIS Standard, 15 March 2005 6 Authentication Request Protocol Assertion
  7. 7. SAML 2.0 Authentication Request Protocol 7
  8. 8. SAML 2.0 Assertion 8 <Assertion   xmlns="urn:oasis:names:tc:SAML:2.0:assertion"   ID="b07b804c-­‐7c29-­‐ea16-­‐7300-­‐4f3d6f7928ac"   Version="2.0"   IssueInstant="2004-­‐12-­‐05T09:22:05" <Issuer>https://example.okta.com<Issuer> <ds:Signature   xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature> <Subject> <NameID  Format="urn:oasis:names:tc:SAML:2.0:nameid-­‐format:unspecified"> karl@example.com </NameID> <SubjectConfirmation   Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> </SubjectConfirmation> </Subject> <Conditions   NotBefore="2004-­‐12-­‐05T09:17:05"   NotOnOrAfter="2004-­‐12-­‐05T09:27:05"> <AudienceRestriction> <saml:Audience>https://sp.example.com/saml2/sso</saml:Audience> </AudienceRestriction> </Conditions> <AuthnStatement   AuthnInstant="2004-­‐12-­‐05T09:22:00"   SessionIndex="b07b804c-­‐7c29-­‐ea16-­‐7300-­‐4f3d6f7928ac"> <AuthnContext> <AuthnContextClassRef> urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport </AuthnContextClassRef> </AuthnContext> </AuthnStatement> <AttributeStatement> <Attribute   Name=“displayName”> <AttributeValue>Karl   McGuinness</AttributeValue> </Attribute> </AttributeStatement> </Assertion>
  9. 9. SAML = Web SSO 9
  10. 10. What’s Changed since 2005? 10
  11. 11. Modern and Native Applications 11
  12. 12. Connected Experiences across Devices 12
  13. 13. Simple Web APIs GET POST PUT DELETE 13
  14. 14. API Economy 14
  15. 15. Delegated Authorization Problem How can a user authorize an app to access protected data on their behalf? 15
  16. 16. Have you ever seen one of these? 16
  17. 17. 17
  18. 18. OAuth 2.0 Web-scale delegated authorization framework for REST/APIs • Enables apps to obtain limited access (scopes) to a user’s data without giving away a user’s password • Decouples authentication from authorization • Supports multiple use cases addressing different client capabilities and deployment models • Server-to-server apps • Browser-based apps • Mobile/Native apps • Consoles/TVs Protecting APIs Since October 2012
  19. 19. Hotel Key Cards but for Apps 19
  20. 20. OAuth Simplified App requests authorization from User 20 1 User authorizes App and delivers proof2 App presents proof of authorization to server to get a Token3 Token is restricted to only access what the User authorized for the specific App 4
  21. 21. OAuth 2.0 21 • Scopes & Consent • Actors • Clients • Tokens • Authorization Server • Flows
  22. 22. Scopes • Additive bundles of permissions asked by client when requesting a token • Decouples authorization policy decisions from enforcement 22 Scopes to Deny Scopes to Allow
  23. 23. Capturing User Consent Authorization Grant (Trust of First Use) 23
  24. 24. Actors Resource Server (RS) Authorization Server (AS) Resource Owner (RO) Client Delegates Obtains Token Uses Token
  25. 25. Actors Resource Server (RS) Authorization Server (AS) Resource Owner (RO) Client Delegates Obtains Token Uses Token
  26. 26. Clients 26 Public (Client Identification) Confidential (Client Authentication)
  27. 27. Clients Client Registration is the DMV of OAuth
  28. 28. Tokens 28 • Short-lived token used by Client to access Resource Server (API) • No client authentication required (Public Clients) • Optimized for scale and performance • Usually can’t be revoked Access Token (Required) • Long-lived token that is used by Client to obtain new access tokens from Authorization Server • Usually requires Confidential Clients with authentication • Forces client to rotate secrets • Can be revoked Refresh Token (Optional) OAuth doesn’t define the format of a token!
  29. 29. Authorization Server Authorization Grant Types are Extensible 29 Authorize Endpoint (/oauth2/authorize) Token Endpoint (/oauth2/token) Authorization Server Authorization Grant Refresh Token Access Token
  30. 30. Token State Management Developer Friction 30
  31. 31. Flow Channels Resource Server (RS) Authorization Server (AS) Resource Owner (RO) Client Delegates Obtains Token Uses Token Back Channel Front Channel
  32. 32. Front Channel Flow Authorize via User Agent Resource Server (RS) Authorization Server (AS) 4 2 3 1 Resource Owner starts flow to delegate access to protected resource 1 Client 2 Client sends authorization request with desired scopes via browser redirect to Authorize Endpoint on Authorization Server 3 User authenticates and consents to Delegated Access (Grant) 4 Authorization Code Grant or Access Token is returned to Client via browser redirect Resource Owner (RO)
  33. 33. Authorization Request GET  https://accounts.google.com/o/oauth2/auth? Scope=gmail.insert  gmail.send& redirect_uri=https://app.example.com/oauth2/callback& response_type=code& client_id=812741506391& state=af0ifjsldkj HTTP/1.1  302  Found Location: https://app.example.com/oauth2/callback? code=MsCeLvIaQm6bTrgtp7& state=af0ifjsldkj Request Response Note: Parameters are not URL-encoded for example purposes
  34. 34. Back Channel Flow Exchange Grants for Tokens Resource Server (RS) Authorization Server (AS) 1 Client 2 Client accesses protected resource with Access Token Resource Owner (RS) 2 Client sends access token request to Token Endpoint on Authorization Server with confidential client credentials or public client id Exchanges Authorization Code Grant for Access Token and optionally Refresh Token 1
  35. 35. Token Request POST  /oauth2/v3/token  HTTP/1.1   Host:  www.googleapis.com   Content-­‐Type:  application/x-­‐www-­‐form-­‐urlencoded code=MsCeLvIaQm6bTrgtp7& client_id=812741506391&client_secret={client_secret}& redirect_uri=https://app.example.com/oauth2/callback& grant_type=authorization_code { "access_token"  :  "2YotnFZFEjr1zCsicMWpAA", "token_type":  "Bearer", "expires_in":  3600, "refresh_token":  "tGzv3JOkF0XG5Qx2TlKWIA", } Request Response Note: Parameters are not URL-encoded for example purposes
  36. 36. Making Protected Resource Requests curl -H "Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA" https://www.googleapis.com/gmail/v1/users/1444587525/messages 36
  37. 37. OAuth 2.0 Grant Types (Flows) 37 • Optimized for browser-only Public Clients • Access token returned directly from authorization request (Front-channel only) • Does not support refresh tokens • Assumes Resource Owner and Public Client are on the same device • Most vulnerable to security threats Implicit (2 Legged) • Front channel flow used by Client to obtain authorization code grant • Back channel flow used by Client to exchange authorization code grant for access token and optionally refresh token • Assumes Resource Owner and Client are on separate devices • Most secure flow as tokens never passes through user- agent Authorization Code (3 Legged) • Optimized for server-only Confidential Clients acting on behalf of itself or a user • Back-channel only flow to obtain an access token using the Client’s credentials • Supports shared secrets or assertions as Client credentials signed with either symmetric or asymmetric keys Client Credential (2 Legged)
  38. 38. OAuth 2.0 Grant Types (Flows) 38 • Legacy grant type for native username/password apps such as desktop apps • Username/password is authorization grant to obtain access token from Authorization Server • Does not support refresh tokens • Assumes Resource Owner and Public Client or on the same device Resource Owner Password • Allows Authorization Server to trust authorization grants from third party such as SAML IdP (Federation) • Assertion is used to obtain access token with token request • Does not support refresh tokens Assertion (2 Legged) • Optimized for devices that do not have access to web- browsers • User code is returned from authorization request that must be redeemed by visiting a URL on a device with a browser to authorize • Back channel flow used by Client to poll for authorization approval for access token and optionally refresh token Device (Non-Standard)
  39. 39. Common OAuth 2.0 Security Issues • Too many inputs that need validation • Token hijacking with CSRF • Always use CSRF token with state parameter to ensure OAuth flow integrity • Leaking authorization codes or tokens through redirects • Always whitelist redirect URIs and ensure proper URI validations • Token hijacking by switching clients • Bind the same client to authorization grants and token requests • Leaking client secrets • Unbounded & Bearer Tokens • See draft specification of OAuth Proof-of-Possession Token Extension 39
  40. 40. Key Enterprise OAuth 2.0 Use Cases • Decouples authorization policydecisions from enforcement • Enables the right blend of fine & coarse grained authorization • Replaces traditional Web Access management (WAM) Policies • Restrict & revoke which apps can access specific APIs • Ensure only managed and/or complaint devices can access specific APIs • Deep integration with identity deprovisioning workflow to revoke all tokens for a user and device • Federation with an IdP 40
  41. 41. OAuth 2.0 Facts • Not backward compatible with OAuth 1.0 • Replaces signatures with HTTPS for all communication • Interoperability issues exists as its not a protocol but rather an authorization framework • OAuth 2.0 is not an authentication protocol • OAuth 2.0 alone says absolutely nothing about the user 41
  42. 42. 42 Authorization Framework?
  43. 43. Like WS-Security Security 43
  44. 44. Authorization Framework Return of Complexity through Extensions 44 OAuth 2 Framework RFC 6749 Assertion Framework RFC 7521 Token Introspection RFC 7662 Token Revocation RFC 7009 Dynamic Client Registration RFC 7591 JSON RFC 7159 JSON Web Token Bearer Assertion RFC 7523 Proof Key for Code Exchange(PKCE) RFC 7636 Simple Authentication and SecurityLayer (SASL) RFC 7628 Token Exchange Draft SAML 2.0 Bearer Assertion RFC 7522 Proof of Possession Draft JSON Web Token (JWT) RFC 7519 JSON Web Signature (JWS) RFC 7515 JSON Web Encryption (JWE) RFC 7516 JSON Web Key (JWK) RFC 7517 Bearer Token RFC 6750
  45. 45. Why all the complexity again? • Enterprise use cases such as federation • Interoperable tokens that can be signed and encrypted • Proof-of-Possession tokens that can’t be replayed • Embedded user agents with unsecure cross-app communication channels • Intermediates can capture resource owner credentials, grants, and tokens • Bindings for non-HTTP transports and legacy protocols such as LDAP or IMAP as well as constrained devices (IoT) 45
  46. 46. 46 Not an Authentication Protocol?
  47. 47. OAuth 2.0 as Pseudo-Authentication As made famous by Facebook Connect and Twitter Client accessing a https://api.example.com/me resource with an access token is not authenticating the user Access tokens just prove the Client was authorized, are opaque, and intended to only be consumed by the Resource Server • Who is the user (claims)? • When did the user authenticate? • Does the user still have an active or expired session? • How did the user authenticate? • Just password or password + second factor 47
  48. 48. OpenID Connect OAuth 2.0 + Facebook Connect + SAML 2.0 (good parts) • Extends OAuth 2.0 with new signed id_token for the Client and UserInfo endpoint to fetch user attributes • Provides a standard set of scopes and claims for identities • profile • email • address • phone • Built-in registration, discovery & metadata for dynamic federations • Bring Your Own Identity (BYOI) • Supports high assurance levels and key SAML use cases (enterprise) 48
  49. 49. OpenID Connect Authorization Request GET  https://accounts.google.com/o/oauth2/auth? scope=openid  email& redirect_uri=https://app.example.com/oauth2/callback& response_type=code& client_id=812741506391& state=af0ifjsldkj HTTP/1.1  302  Found Location: https://app.example.com/oauth2/callback? code=MsCeLvIaQm6bTrgtp7& state=af0ifjsldkj Request Response Note: Parameters are not URL-encoded for example purposes
  50. 50. OpenID Connect Token Request POST  /oauth2/v3/token  HTTP/1.1   Host:  www.googleapis.com   Content-­‐Type:  application/x-­‐www-­‐form-­‐urlencoded code=MsCeLvIaQm6bTrgtp7& client_id=812741506391&client_secret={client_secret}& redirect_uri=https://app.example.com/oauth2/callback& grant_type=authorization_code { "access_token"  :  "2YotnFZFEjr1zCsicMWpAA", "token_type":  "Bearer", "expires_in":  3600, "refresh_token":  "tGzv3JOkF0XG5Qx2TlKWIA", "id_token":  "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ…", } Request Response Note: Parameters are not URL-encoded for example purposes
  51. 51. JSON Web Token (JWT) base64url(Header) + “.” + base64url(Claims) + “.” + base64url(Signature) eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodH RwczovL2V4YW1wbGUub2t0YS5jb20iLC JzdWIiOiIwMHVncmVuTWVxdllsYTRIVzB nMyIsImF1ZCI6IncyNTVIRVdpU1U0QXVO eEVqZWlqIiwiaWF0IjoxNDQ2MzA1MjgyL CJleHAiOjE0NDYzMDg4ODIsImFtciI6Wy Jwd2QiXSwiYXV0aF90aW1lIjoxNDQ2Mz A1MjgyLCJlbWFpbCI6ImthcmxAZXhhbXB sZS5jb20iLCJlbWFpbF92ZXJpZmllZCI6d HJ1ZX0.XcNXs4C7DqpR22LLti777AMMV CxM7FjEPKZQnd- AS_Cc6R54wuQ5EApuY6GVFCkIlnfbNm YSbHMkO4H- L3uoeXVOPQmcqhNPDLLEChj00jQwZD jhPD9uBoNwGyiZ9_YKwsRpzbg9NEeY8 xEwXJFIdk6SRktTFrVNHAOIhEQsgm8 51 { "alg":  "RS256" } { "iss":  "https://example.okta.com", "sub":  "00ugrenMeqvYla4HW0g3", "aud":  "w255HEWiSU4AuNxEjeij", "iat":  1446305282, "exp":  1446308882, "amr":  [ "pwd" ], "auth_time":  1446305282, "email":  "karl@example.com", "email_verified":  true } Header Claims Signature Header Claims
  52. 52. OpenID Connect is built on OAuth 2.0 Validate   (JWT) ID  Token Token Endpoint Authorization Endpoint /.well-known /webfinger /openid-configuration Client Registration Endpoint JWKS Endpoint Check Session iFrame End Session Endpoint UserInfo Endpoint OAuth 2.0 Authorization Server & OpenID Connect Provider (OP) OAuth 2.0 Resource Server API Endpoints Client (Relying Party) 1 2 3 5 6 4 1 Discover OIDC Metadata 2 Get JWT signature keys and optionally dynamically register Client 3 Perform OAuth flow to obtain id_token and access token 4 Validate JWT id_token 5 Get additional user attributes with access token 6 Validate session and/or logout
  53. 53. Summary • OAuth 2.0 is an authorization framework for delegated access to APIs • Clients request scopes that Resources Owners authorize (consent) • Authorization grants are exchanged for an access token and optionally refresh token • Multiple flows to address varying Client capabilities and authorization scenarios • Use JSON Web Tokens (JWT) for structured tokens between Authorization Server and Resource Server • OAuth 2,0 has a very large security surface area • Use a secure toolkit and remember to validate all inputs! • OAuth 2.0 is not an authentication protocol • OpenID Connect extends OAuth 2.0 for authentication scenarios “SAML with curly-braces” 53
  54. 54. Modern OAuth-based Protocols OAuth 2.0 OpenID Connect UMA NAPPS
  55. 55. Q&A
  56. 56. Rate this session in the mobile app!
  57. 57. Thank You.

×