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

IIW 39 - OAuth 101

IIW 39 - OAuth 101

Aaron Parecki

October 29, 2024
Tweet

More Decks by Aaron Parecki

Other Decks in Technology

Transcript

  1. RFC6749 RFC6750 CLIENT TYPE AUTH METHOD GRANT TYPE RFC6819 RFC7009

    RFC7592 RFC7662 RFC7636 RFC7591 RFC7519 RFC8252 OIDC RFC8414 STATE PARAM TLS CSRF UMA 2 FAPI RFC7515 RFC7516 RFC7517 RFC7518 TOKEN BINDING POP SECURITY BCP CIBA HTTP SIGNING MUTUAL TLS SPA BCP JARM JAR TOKEN EXCHANGE DPOP
  2. The Password Anti-Pattern • How do you revoke this app’s

    access? • Do you trust the app to not store your password? • Do you trust the app to access only the things it says it needs? • Do you trust the app to not do things like change your password or delete your account?
  3. Tells the application about the user authenticating Gives the application

    a way to make API requests ID Token Access Token
  4. Authorization Code OAuth Flows Device Flow Client Credentials Implicit Password

    web mobile SPA browserless devices server-to-server CLI CLI >_ >_
  5. User Agent App OAuth Server API ? Authorization Request Authorization

    Code Response Token Request Token Response "Log In"
  6. User Agent App OAuth Server API ? Authorization Request Authorization

    Code Response Token Request Token Response "Log In" Front Channel Back Channel
  7. Front Channel Back Channel https://accounts.google.com/?... Passing data via the browser's

    address bar The user, or malicious software, can modify the requests and responses Sent from client to server HTTPS request from client to server, so requests cannot be tampered with
  8. PKCE Ensures the app that receives the authorization code is

    the same one that started the exchange
  9. OAuth 2.1 Consolidate the OAuth 2.0 specs,
 adding best practices,

    
 removing deprecated features Capture current best practices in OAuth 2.0 under a single name
  10. OAuth 2.0 RFC6749 OAuth Core Authorization Code Implicit Password Client

    Credentials RFC6750 Bearer Tokens Tokens in HTTP Header Tokens in POST Form Body Tokens in GET Query String RFC7636 +PKCE RFC8252 PKCE for mobile Browser App BCP PKCE for SPAs PKCE for con fi dential clients Security BCP
  11. oauth.net/2/pushed-authorization-requests PUSHED AUTHORIZATION REQUESTS (PAR) Typically, the authorization request is

    sent in the front channel Front channel is susceptible to inspection and modi f ication PAR initiates the OAuth f low from the back channel RFC9126
  12. oauth.net/2/rich-authorization-requests RICH AUTHORIZATION REQUESTS OAuth “scope” is limited to strings

    Need a way to authorize f ine-grained transactions or resources And present that to the user in the authorization interface RFC 9396
  13. https://datatracker.ietf.org/doc/html/draft-ietf-oauth-step-up-authn-challenge STEP-UP AUTHENTICATION CHALLENGE A Resource Server can respond with

    an error telling the client to re-authenticate the user or get a higher level authentication The client sends the user through the OAuth f low again to get a new access token RFC 9470
  14. User Agent (Browser) Authorization Server Resource Server (API) Client (App)

    OAuth for Browser-Based Applications (Best Current Practice) https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
  15. authorization token Pure SPA Access token is obtained by JS

    in the browser. No backend, browser JS makes API requests directly.
  16. TMI-BFF Token Mediating Backend Access token is obtained by the

    backend, but then retrieved by the frontend. Browser JS makes API calls directly.
  17. BFF Backend-for-Frontend Access token is never sent to the browser.

    All API requests are proxied through the BFF. XSS is limited to the attacker telling your app server to make requests.
  18. Specs Built on OAuth • OpenID Connect (openid.net) • FAPI

    (High-Security OAuth Pro fi le) • UMA (User-Managed Access) • IndieAuth (indieauth.net)