OAuth - The good Parts

BASTA 2021

Transcript

1. OAuth The good Parts Dominick Baier @leastprivilege https://duendesoftware.com
2. 2 @duendeidentity Me • 15+ years consulting and project work in the identity space – co-creator of IdentityServer & IdentityModel OSS Project – certified OpenID Connect & OAuth 2.0 Engine for ASP.NET Core • Co-Founder of Duende Software – the new home of IdentityServer – https://duendesoftware.com email dominick@duendesoftware.com blog https://blog.duendesoftware.com twitter @leastprivilege slides https://speakerdeck.com/duendesoftware
3. 5 @duendeidentity Some History… 2005 SAML 2.0p WS-Federation WS-Trust 2007 2012 2014 2015 2017 Soon OAuth 2.0 Token Exchange OAuth 2.0 Mutual TLS OAuth 2.0 Resource Indicators JSON Web Token BCP OAuth 1.0 OAuth 2.0 Bearer Tokens OpenID Connect Core OpenID Connect Discovery OAuth 2.0 Assertion Framework OAuth 2.0 Dynamic Client Registration OAuth 2.0 Token Introspection JSON Web Token (JWT) OAuth 2.0 JSON Web Token (JWT) Profile OAuth 2.0 PKCE JAR, RAR, PAR JWT Access Token Profile OAuth 2.1 OAuth 2.0 Security Topics BCP OAuth 2.0 for Browser-based Applications BCP OAuth 2.0 Threat Model & Security Considerations OAuth 2.0 for Native Apps BCP 2019/20
4. 6 @duendeidentity
5. 7 @duendeidentity Agenda • Why does OAuth exist? • Protocol flows • Typical application architectures • "OAuth is not user authentication" – OpenID Connect • Further reading
6. 8 @duendeidentity Why does OAuth exist?
7. 9 @duendeidentity Accessing WebServices HTTP APIs Authorization: <token> GET /foo/bar
8. 10 @duendeidentity Tokens Issuer & Signature Scoping Authentication Claims Time Window
9. 11 @duendeidentity "Third Party" Requirement
10. 12 @duendeidentity OAuth Architecture and Terminology Clients Authorization Server Resource Server Browser Mobile Server Resource Owner User authorize/token request 1 return access token 2 access resource using access token 3 public vs confidential clients
11. 13 @duendeidentity Specifying the Resource to Access • scope parameter The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. The value of the scope parameter is expressed as a list of space-delimited, case-sensitive strings. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. RFC6749
12. 14 @duendeidentity Example: GitHub Scopes https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/
13. 15 @duendeidentity Example: Google Scopes https://developers.google.com/oauthplayground/
14. 16 @duendeidentity The two Protocol Flows
15. 17 @duendeidentity Client Credentials Flow • Machine to machine communication – no "interactive" user present – authenticates the client only (hence the name) • Sometimes called "two-legged" flow
16. 18 @duendeidentity Protocol Flow Resources Authorization Server Scopes: api1, api2 api3… POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF Content-Type: application/x-www-form-urlencoded grant_type=client_credentials& scope=api1 HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token": "2YotnFZFEjr1zCsicMWpAA", "scope": "api1", "token_type": "Bearer", "expires_in": 3600 }
17. 19 @duendeidentity JWT Access Tokens { "typ": "at+jwt", "alg": "RS256" "kid": "1" } { "iss": "https://my_issuer", "iat": 1340819180, "exp": 1340819380, "scope": "api1", "client_id": "client1", } Header Payload eyJhbGciOiJub25lIn0.eyJpc3MiOiJqb2UiLA0KICJleHAiOjEzMD.4MTkzODAsDQogImh0dHA6Ly9leGFt Header Payload Signature Issuer & Signature Scoping Claims Time Window
18. 20 @duendeidentity Use Token • Token transmitted via Authorization header – form body as alternative Authorization: Bearer <token> GET /service/resource https://tools.ietf.org/html/rfc6750
19. 21 @duendeidentity Access Token Processing Rules • Token format and content is a private implementation detail between Authorization Server and Resource – client is simply a forwarder – client must not try to ”consume” token • JWT validation rules – signature must be valid and signature algorithm must be allowed – typ must be at+jwt – iss must be an expected value – current time must be before exp and after iat – scope must contain an expected value
20. 22 @duendeidentity 401 vs 403 RFC 7235: HTTP 1.1 Authentication A server that receives valid credentials that are not adequate to gain access ought to respond with the 403 (Forbidden) status code The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.
21. 23 @duendeidentity Token Management • Store tokens server-side – in-memory, distributed cache, cookie, session storage, database… • Pro-active – keep track of expiration and renew token ahead of time • Re-active – wait for 401, renew, re-send
22. 24 @duendeidentity Interactive Applications
23. 25 @duendeidentity Authorization Code Flow • Designed to incorporate a user – suitable for any type of interactive client application – allows for UI during protocol flow (login, consent, etc.) – dependent on browser • Support for refresh tokens for UX-friendly token management • Always used in conjunction with PKCE extension – https://tools.ietf.org/html/rfc7636
24. 26 @duendeidentity Overview Front-Channel • browser redirect • user interaction • user authentication • SSO Back-channel • authenticate client • retrieve token 2 1 Client Authorization Server
25. 27 @duendeidentity Front-Channel Request /authorize? ?client_id=client &redirect_uri=https://client.com/cb &response_type=code &scope=api1 &state=id &code_challenge=hash(verifier) 1 Client Authorization Server
26. 28 @duendeidentity User Authentication (if required)
27. 29 @duendeidentity Consent (if required) Who is the Authorization Server? Who is the user? Who is the client? What is the client asking for? Do you want to allow that?
28. 30 @duendeidentity Front-Channel Response /cb? ?code=abc &state=xyz 2 Client Authorization Server
29. 31 @duendeidentity Back-Channel Request 3 Client Authorization Server POST /token Authorization: Basic czZCaGRS0M2JW grant_type=authorization_code& code=abc& redirect_uri=https://client.com/cb& code_verifier=verifier
30. 32 @duendeidentity Back-Channel Response 4 Client Authorization Server HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "refresh_token": "9u3djij099jmjipom9", "token_type":"Bearer", "expires_in":3600 }
31. 33 @duendeidentity User-Centric Access Tokens { "typ": "at+jwt", "alg": "RS256" "kid": "1" } { "iss": "https://my_issuer", "iat": 1340819180, "exp": 1340819380, "scope": "api1", "client_id": "client1", "sub": "123" "amr" : [ "pwd" ] } Header Payload
32. 34 @duendeidentity Token Management • Access tokens are typically short-lived • Clients need to manage and re-new their tokens if longer access is required – should not need to involve user – UX friendly • Refresh token allows for manual lifetime management – similar to sliding expiration cookies
33. 35 @duendeidentity Refreshing an Access Token (1) POST /token HTTP/1.1 Host: server.example.com Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF Content-Type: application/x-www-form-urlencoded grant_type=refresh_token& refresh_token=xyz
34. 36 @duendeidentity Refreshing an Access Token (2) HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "refresh_token": "9u3djij099jmjipom9", "token_type":"Bearer", "expires_in":3600 }
35. 37 @duendeidentity Revocation
36. 38 @duendeidentity Token Revocation • Endpoint to programmatically revoke refresh tokens (RFC 7009) – e.g. at logout or un-install time /revoke?token=a19..18a
37. 39 @duendeidentity Application Architectures • Machine-to-Machine scenarios • Browser-based Applications – server-side web applications – SPAs / WASM • Not browser-based Applications – mobile apps – desktop applications
38. 40 @duendeidentity Browser-based Applications Session Management OpenID Connect / OAuth Client Library Token Management UI Assets Application Server
39. 41 @duendeidentity Not Browser-based Applications authentication request render UI & workflow
40. 42 @duendeidentity Beyond OAuth • User authentication – OpenID Connect
41. 43 @duendeidentity User Authentication – the Problem Front-Channel • retrieve code Back-channel • retrieve access token Client Authorization Server
42. 44 @duendeidentity OpenID Connect • Introduction of additional response data for client to consume – "authentication response" aka id_token • Contains description of the "authentication event" – user id – authentication time – authentication method – additional user claims
43. 45 @duendeidentity id_token • Returned on back-channel when redeeming code { "typ": "JWT", "alg": "RS256", "kid": "mj399j…" } { "iss": "https://issuer", "exp": 1340819380, "iat": 1340818761, "aud": "client", "amr": [ "pwd" ], "auth_time": 12340819300 "sub": "182jmm199", "name": "Alice", } Header Payload
44. 46 @duendeidentity Further Reading • OAuth 2.1 – https://tools.ietf.org/wg/oauth/draft-ietf-oauth-v2-1/ • OpenID Connect – https://openid.net/specs/openid-connect-core-1_0.html • Two is the magic number – https://leastprivilege.com/2019/09/09/two-is-the-magic-number/ • Securing SPAs using the BFF pattern – https://blog.duendesoftware.com/posts/20210326_bff/
45. 47 @duendeidentity …and more https://openid.net/wg/ https://tools.ietf.org/wg/oauth/
46. 48 @duendeidentity Summary • OAuth is a token request/response framework – designed to allow 3rd party access – built with user interaction in mind • Authorization Server – knows all resources – knows all clients – provides protocol and UI endpoints – authenticates clients and users – issues tokens • OpenID Connect is an authentication protocol – implementation of OAuth