OAuth - the Good Parts

NDC Oslo 2021

Transcript

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

   View Slide

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
   

   View Slide

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
   

   View Slide

4. 6
   @duendeidentity
   

   View Slide

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

   View Slide

6. 8
   @duendeidentity
   Why does OAuth exist?
   

   View Slide

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

   View Slide

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

   View Slide

9. 11
   @duendeidentity
   "Third Party" Requirement
   

   View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

14. 16
    @duendeidentity
    The two Protocol Flows
    

    View Slide

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
    

    View Slide

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
    }
    

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

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.
    

    View Slide

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
    

    View Slide

22. 24
    @duendeidentity
    Interactive Applications
    

    View Slide

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
    

    View Slide

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

    View Slide

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
    

    View Slide

26. 28
    @duendeidentity
    User Authentication (if required)
    

    View Slide

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?
    

    View Slide

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

    View Slide

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
    

    View Slide

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
    }
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    }
    

    View Slide

35. 37
    @duendeidentity
    Revocation
    

    View Slide

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
    

    View Slide

37. 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
    

    View Slide

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

    View Slide

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

    View Slide

40. 42
    @duendeidentity
    OAuth is not user authentication
    • OpenID Connect
    

    View Slide

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

    View Slide

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
    

    View Slide

43. 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
    

    View Slide

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/
    

    View Slide

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

    View Slide

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
    

    View Slide