Demystifying OAuth 2.0
11 likes7,638 views
The document explains OAuth 2.0 as a delegated authorization framework designed for REST and APIs, enabling apps to access user data without sharing passwords. It discusses various OAuth flows, security considerations, and modern use cases, emphasizing the distinction between authorization and authentication. Additionally, it covers the integration of OpenID Connect, extending OAuth 2.0 for user identity and session management.
![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](https://image.slidesharecdn.com/demystifyingoauth-151208063049-lva1-app6891/85/Demystifying-OAuth-2-0-51-320.jpg)
Demystifying OAuth 2.0
- 1. Karl McGuinness Senior Director, Identity @ Okta Demystifying OAuth
- 2. Why OAuth? Breaking down OAuth 2.0 Pseudo-Authentication OpenID Connect Agenda Security & The Enterprise
- 3. Direct Authentication Password anti-pattern 3 GET /index.html HTTP/1.1 Host: www.example.com Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
- 4. Federated Identity 4 Identity Provider (IdP) Service Provider (SP) End User Trust Obtains Assertion Provides Assertion
- 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. SAML 2.0 OASIS Standard, 15 March 2005 6 Authentication Request Protocol Assertion
- 7. SAML 2.0 Authentication Request Protocol 7
- 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"> [email protected] </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. SAML = Web SSO 9
- 10. What’s Changed since 2005? 10
- 11. Modern and Native Applications 11
- 12. Connected Experiences across Devices 12
- 13. Simple Web APIs GET POST PUT DELETE 13
- 14. API Economy 14
- 15. Delegated Authorization Problem How can a user authorize an app to access protected data on their behalf? 15
- 16. Have you ever seen one of these? 16
- 17. 17
- 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. Hotel Key Cards but for Apps 19
- 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. OAuth 2.0 21 • Scopes & Consent • Actors • Clients • Tokens • Authorization Server • Flows
- 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. Capturing User Consent Authorization Grant (Trust of First Use) 23
- 24. Actors Resource Server (RS) Authorization Server (AS) Resource Owner (RO) Client Delegates Obtains Token Uses Token
- 25. Actors Resource Server (RS) Authorization Server (AS) Resource Owner (RO) Client Delegates Obtains Token Uses Token
- 27. Clients Client Registration is the DMV of OAuth
- 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. 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. Token State Management Developer Friction 30
- 31. Flow Channels Resource Server (RS) Authorization Server (AS) Resource Owner (RO) Client Delegates Obtains Token Uses Token Back Channel Front Channel
- 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. 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. 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. 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. Making Protected Resource Requests curl -H "Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA" https://www.googleapis.com/gmail/v1/users/1444587525/messages 36
- 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. 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. 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. 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. 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
- 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. 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
- 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. 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. 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. 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. 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": "[email protected]", "email_verified": true } Header Claims Signature Header Claims
- 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. 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
- 55. Q&A
- 56. Rate this session in the mobile app!
- 57. Thank You.