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

OAuth - The good Parts

OAuth - The good Parts

BASTA 2021

Duende Software

September 21, 2021
Tweet

More Decks by Duende Software

Other Decks in Programming

Transcript

  1. 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 [email protected] blog https://blog.duendesoftware.com twitter @leastprivilege slides https://speakerdeck.com/duendesoftware
  2. 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
  3. 7 @duendeidentity Agenda • Why does OAuth exist? • Protocol

    flows • Typical application architectures • "OAuth is not user authentication" – OpenID Connect • Further reading
  4. 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
  5. 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
  6. 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
  7. 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 }
  8. 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
  9. 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
  10. 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
  11. 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.
  12. 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
  13. 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
  14. 26 @duendeidentity Overview Front-Channel • browser redirect • user interaction

    • user authentication • SSO Back-channel • authenticate client • retrieve token 2 1 Client Authorization Server
  15. 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?
  16. 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
  17. 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 }
  18. 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
  19. 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
  20. 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
  21. 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 }
  22. 38 @duendeidentity Token Revocation • Endpoint to programmatically revoke refresh

    tokens (RFC 7009) – e.g. at logout or un-install time /revoke?token=a19..18a
  23. 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
  24. 40 @duendeidentity Browser-based Applications Session Management OpenID Connect / OAuth

    Client Library Token Management UI Assets Application Server
  25. 43 @duendeidentity User Authentication – the Problem Front-Channel • retrieve

    code Back-channel • retrieve access token Client Authorization Server
  26. 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
  27. 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
  28. 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/
  29. 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