Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OAuth - The good Parts

OAuth - The good Parts

BASTA 2021

87ff2948d8e35bec8d7187d73c26a6c9?s=128

Duende Software

September 21, 2021
Tweet

More Decks by Duende Software

Other Decks in Programming

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