OAuth The good Parts Dominick Baier @leastprivilege https://duendesoftware.com

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

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

6 @duendeidentity

7 @duendeidentity Agenda • Why does OAuth exist? • Protocol flows • Typical application architectures • "OAuth is not user authentication" – OpenID Connect • Further reading

8 @duendeidentity Why does OAuth exist?

9 @duendeidentity Accessing WebServices HTTP APIs Authorization: GET /foo/bar

10 @duendeidentity Tokens Issuer & Signature Scoping Authentication Claims Time Window

11 @duendeidentity "Third Party" Requirement

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

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

14 @duendeidentity Example: GitHub Scopes https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/

15 @duendeidentity Example: Google Scopes https://developers.google.com/oauthplayground/

16 @duendeidentity The two Protocol Flows

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

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 }

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

20 @duendeidentity Use Token • Token transmitted via Authorization header – form body as alternative Authorization: Bearer GET /service/resource https://tools.ietf.org/html/rfc6750

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

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.

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

24 @duendeidentity Interactive Applications

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

26 @duendeidentity Overview Front-Channel • browser redirect • user interaction • user authentication • SSO Back-channel • authenticate client • retrieve token 2 1 Client Authorization Server

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

28 @duendeidentity User Authentication (if required)

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?

30 @duendeidentity Front-Channel Response /cb? ?code=abc &state=xyz 2 Client Authorization Server

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

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 }

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

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

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

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 }

37 @duendeidentity Revocation

38 @duendeidentity Token Revocation • Endpoint to programmatically revoke refresh tokens (RFC 7009) – e.g. at logout or un-install time /revoke?token=a19..18a

39 @duendeidentity Application Architectures • Machine-to-Machine scenarios • Interactive Applications – Browser-based Applications • server-side web applications • SPAs / WASM – Not browser-based Applications • mobile apps • desktop applications

40 @duendeidentity Browser-based Applications Session Management OpenID Connect / OAuth Client Library Token Management UI Assets Application Server

41 @duendeidentity Not Browser-based Applications authentication request render UI & workflow

42 @duendeidentity OAuth is not user authentication • OpenID Connect

43 @duendeidentity User Authentication – the Problem Front-Channel • retrieve code Back-channel • retrieve access token Client Authorization Server

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

45 @duendeidentity Authentication Response (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

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/

47 @duendeidentity …and more https://openid.net/wg/ https://tools.ietf.org/wg/oauth/

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