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

OAuth - the Good Parts

OAuth - the Good Parts

NDC Oslo 2021

Dominick Baier

December 01, 2021
Tweet

More Decks by Dominick Baier

Other Decks in Programming

Transcript

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

    View full-size 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 [email protected]
    blog https://blog.duendesoftware.com
    twitter @leastprivilege
    slides https://speakerdeck.com/duendesoftware

    View full-size 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 full-size slide

  4. 6
    @duendeidentity

    View full-size slide

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

    View full-size slide

  6. 8
    @duendeidentity
    Why does OAuth exist?

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  9. 11
    @duendeidentity
    "Third Party" Requirement

    View full-size 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 full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

  14. 16
    @duendeidentity
    The two Protocol Flows

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

  22. 24
    @duendeidentity
    Interactive Applications

    View full-size 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 full-size 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 full-size 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 full-size slide

  26. 28
    @duendeidentity
    User Authentication (if required)

    View full-size 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 full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

  35. 37
    @duendeidentity
    Revocation

    View full-size 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 full-size 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 full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size 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 full-size 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 full-size 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 full-size slide

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

    View full-size 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 full-size slide