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

OAuth 2.1

OAuth 2.1

The web's most widely used open auth standard is getting an update. What's changing, how you can prepare your apps, and why.

Talk given on 20 May 2024 to the OWASP meetup in Ōtautahi Christchurch.

Pete Nicholls

May 20, 2024
Tweet

More Decks by Pete Nicholls

Other Decks in Technology

Transcript

  1. OWASP Juice Shop owasp-juice.shop An intentionally broken web application aimed

    to help learn about vulnerabilities, with hacking challenges of varying difficulty and a leaderboard. Great for teams and individuals.
  2. Application Verification Security Standard (ASVS) owasp.org How do you know

    whether you’re doing the right thing when it comes to security? Have you got any blindspots? What’s the right minimum length for passwords?
  3. OWASP NZ Day 2024 appsec.org.nz Auckland • AUT City Campus

    Thu 5-Fri 6 Sept $30 or free for students
  4. Top 10 owasp.org Web Application Security Risks The Top 10

    is a great starting point for teams beginning their journey to better security. Targeted by security training platforms. Often referenced in security questionnaires and contractors when vendors and buyers are investigating a product or service.
  5. Before OAuth The bad old days (e.g. 2005) Connect your

    Twitter account to our app! Your Twitter username Your Twitter password Connect
  6. Before OAuth The bad old days (e.g. 2005) Browser Third-

    party app Twitter “Enter your Twitter username and password” 1 Requests data w/ creds 4 Responds w/ data for user 5 User sends credentials 2 3 Stores in plain-text :( Serves tweet timeline (or whatever) 6
  7. OAuth User doesn’t have to share their password Sign in

    with Twitter ✔ You’re signed in! access_token “c4f3…”
  8. OAuth Authorisation Code Grant flow A typical 2.0 example Browser

    App Authorisation Server Serves “sign in” link 1 User clicks “sign in” 2 Sends credentials 4 Sign in with Twitter Prompts user for credentials 3 Sends redirect with one-time code 6 5 Creds OK
  9. OAuth Authorisation Code Grant flow A typical 2.0 example Browser

    App Authorisation Server Follows redirect 7 Sends one- time code + client secret 8 Issues access token 10 Issues session 12 ✔ You’re signed in! 11 Stores access token 9 Checks
  10. OAuth Authorisation Code Grant flow A recap Relying Party a.k.a.

    your app Constructs “sign in” link Handles OAuth redirect callback Exchanges one-time code for access token Issues app-level session
  11. OAuth Authorisation Code Grant flow A recap Authorisation Server Offers

    “sign in” user experience Handles authentication May offer consent screen Redirects to app with one-time code Issues access token in exchange for one-time code
  12. Authorization Code Grant For web and mobile. Lets a user

    authorise directly with the authorisation server. …and the refresh token grant Implicit Grant Used by Single Page Applications (SPAs). Resource Owner Password Credentials Grant Used in cases where the user trusts the application completely (e.g., first-party clients). Client Credentials Grant Used for server-to-server (machine-to-machine) communication where no user is involved. Device Code Grant Used for devices with limited input capabilities (e.g., smart TVs, IoT devices). JWT Bearer Token Grant Used for exchanging a JWT (JSON Web Token) for an access token.
  13. Authorization Code Grant For web and mobile. Lets a user

    authorise directly with the authorisation server. …and the refresh token grant Implicit Grant Used by Single Page Applications (SPAs). Resource Owner Password Credentials Grant Used in cases where the user trusts the application completely (e.g., first-party clients). Client Credentials Grant Used for server-to-server (machine-to-machine) communication where no user is involved. Device Code Grant Used for devices with limited input capabilities (e.g., smart TVs, IoT devices). JWT Bearer Token Grant Used for exchanging a JWT (JSON Web Token) for an access token.
  14. 2012 The OAuth 2.0 Authorization Framework RFC 6749 Today Perception:

    OAuth was settled years ago 2014 OpenID Connect Core 1.0 RFC 6749 “OAuth? We added that ye ar s ago.”
  15. Reality: OAuth continues to evolve 2013 2015 2017 2019 2021

    2021 2023 2012 2014 2016 2018 2020 2022 2024 RFC 6749 - The OAuth 2.0 Authorization Framework RFC 6750 - The OAuth 2.0 Authorization Framework: Bearer Token Usage RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients RFC 8414 - OAuth 2.0 Authorization Server Metadata RFC 8628 - OAuth 2.0 Device Authorization Grant RFC 8705 - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens RFC 8707 - Resource Indicators for OAuth 2.0 RFC 8725 - JSON Web Token Best Current Practices RFC 8898 - Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP) RFC 9068 - JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens RFC 9101 - The OAuth 2.0 Authorization Framework: JWT- Secured Authorization Request (JAR) RFC 9126 - OAuth 2.0 Pushed Authorization Requests RFC 9200 - Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth) RFC 9207 - OAuth 2.0 Authorization Server Issuer Identification RFC 9278 - JWK Thumbprint URI RFC 9207 - OAuth 2.0 Authorization Server Issuer Identification RFC 9396 - OAuth 2.0 Rich Authorization Requests RFC 9449 - OAuth 2.0 Demonstrating Proof of Possession (DPoP) OpenID Connect Core 1.0 OpenID Connect Discovery 1.0 OpenID Connect Dynamic Client Registration 1.0 RFC 8252 - OAuth 2.0 for Native Apps RFC 9470 - OAuth 2.0 Step Up Authentication Challenge Protocol Not a c om plete list…
  16. What’s drafted for 2.1? 🚫 Implicit Grant flow (response_type=token) gone

    🚫 Resource Owner Password Credentials flow (response_type=password) gone 🚫 Bearer tokens are not allowed in URIs 🔒 Redirect URIs must be compared using exact string matches 🔒 Refresh tokens must either be sender-constrained or one-time use 🔒 When implementing the Authorisation Code Grant flow, the PCKE is now required
  17. Authorization Code Grant For web and mobile. Lets a user

    authorise directly with the authorisation server. …and the refresh token grant Implicit Grant Used by Single Page Applications (SPAs). Resource Owner Password Credentials Grant Used in cases where the user trusts the application completely (e.g., first-party clients). Client Credentials Grant Used for server-to-server (machine-to-machine) communication where no user is involved. Device Code Grant Used for devices with limited input capabilities (e.g., smart TVs, IoT devices). JWT Bearer Token Grant Used for exchanging a JWT (JSON Web Token) for an access token. response_type=token response_type=password
  18. 🚫 Bearer tokens are not allowed in URIs GET 200

    /some-service?access_token=abcdef
  19. 🔒 Redirect URIs must be compared using exact string matches

    https://app-42.netlify.app/oauth/callback https://app-53.netlify.app/oauth/callback 🚫 https://*.netlify.app/oauth/callback
  20. 🔒 Refresh tokens must either be sender-constrained or one-time use

    sender- constrained one-time use Expire refresh tokens so they can’t be exchanged for a fresh access token Ensure the request to refresh came from the client that was issued the refresh token e.g. Demonstrating Proof of Possession DPoP header e.g. Mutual TLS
  21. PKCE: Proof Key for Code Exchange Pronounced “pixie” code_verifier Secret

    held by client Secure, random value Must be web-friendly (e.g. Base64 URL-encoded) code_challenge SHA256 of code_verifier, Base64 URL-encoded
  22. Browser App Authorisation Server Follows redirect 7 Sends one-time code

    + client secret + code_verifier 8 Issues access token 10 Issues session 12 11 Stores access token 9 Checks ✔ You’re signed in! PKCE: Proof Key for Code Exchange Pronounced “pixie”
  23. What’s drafted for 2.1? 🚫 Implicit Grant flow (response_type=token) gone

    🚫 Resource Owner Password Credentials flow (response_type=password) gone 🚫 Bearer tokens are not allowed in URIs 🔒 Redirect URIs must be compared using exact string matches 🔒 Refresh tokens must either be sender-constrained or one-time use 🔒 When implementing the Authorisation Code Grant flow, the PCKE is now required