Pro Yearly is on sale from $80 to $50! »

What's New with OAuth and OpenID Connect?

What's New with OAuth and OpenID Connect?

In this talk you'll learn about the latest developments with the OAuth and OIDC specs directly from the standards group. The latest additions to the specs enable richer experiences and better security for applications using OAuth.

https://www.oktane20.com/agenda#573

11954e59b49809173d48133ec4047fce?s=128

Aaron Parecki

March 31, 2020
Tweet

Transcript

  1. What's New with OAuth and OpenID Connect? Aaron Parecki Oktane20

    • April 2020
  2. Where does this work happen? openid.net/wg ietf.org / oauth.net

  3. Who can participate? The IETF has no formal membership, no

    membership fee, and nothing to sign. You do not need to be a member of the OpenID Foundation to participate in working groups openid.net/wg/about ietf.org/about/participate
  4. so... what's new?

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

    RFC7592 RFC7662 RFC7636 RFC7591 RFC7519 BUILDING YOUR APPLICATION 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
  6. Recently Published RFCs • RFC8705 - Mutual TLS • RFC8707

    - Resource Indicators
  7. RFC8705: Mutual TLS • A form of "Proof of Possession"

    • Associating a TLS certificate with an access token • Prevents access tokens from being used if stolen tools.ietf.org/html/rfc8705
  8. RFC8707: Resource Indicators • Adds a parameter "resource" for the

    client to indicate what server it intends to use the access token at • Improves security when an authorization server issues tokens that are redeemed at multiple resource servers tools.ietf.org/html/rfc8707
  9. In-Progress Work • OAuth 2.0 Security Best Current Practice •

    OAuth 2.0 for Browser-Based Apps
  10. OAuth 2.0 Security BCP • All clients MUST use PKCE

    with the authorization code flow • Password grant MUST NOT be used • Use Authorization Code instead of Implicit flow • Use exact string matching for redirect URIs • No access tokens in query strings • Refresh tokens must be sender-constrained or one-time use oauth.net/2/oauth-best-practice
  11. OAuth 2.0 for Browser-Based Apps • Describes various architectural patterns

    for SPAs • MUST use PKCE with the authorization code flow • Password grant MUST NOT be used • MUST NOT use the Implicit flow • Refresh tokens must be one-time use with a maximum lifetime oauth.net/2/browser-based-apps
  12. OAuth 2.0 for Browser-Based Apps

  13. OAuth 2.0 for Browser-Based Apps

  14. New OAuth Extensions • JWT Profile for Access Tokens •

    Rich Authorization Requests (RAR) • Pushed Authorization Requests (PAR) • JWT Authorization Requests (JAR) • Proof of Possession (DPoP) very much still in progress!
  15. JWT Profile for Access Tokens • Many existing implementations use

    JWTs for access tokens • This standard captures best practices and defines consistent properties oauth.net/2/jwt-access-tokens
  16. Rich Authorization Requests (RAR) • OAuth "scope" is limited to

    fixed lists of scopes • Need a way to authorize fine-grained transactions or resources • and present that to the user in the authorization interface oauth.net/2/rich-authorization-requests
  17. Rich Authorization Requests (RAR) oauth.net/2/rich-authorization-requests

  18. Pushed Authorization Requests (PAR) • Currently, the authorization request is

    sent in the front-channel • Susceptible to inspection and modification • PAR initiates the OAuth flow from the back-channel oauth.net/2/pushed-authorization-requests
  19. Pushed Authorization Requests (PAR) GET /authorize?response_type=code &client_id=s6BhdRkqt3&state=af0ifjsldkj &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb HTTP/1.1 Host:

    as.example.com POST /as/par HTTP/1.1 Host: as.example.com Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3 response_type=code &client_id=s6BhdRkqt3&state=af0ifjsldkj &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb Instead of: Push the request to the AS: oauth.net/2/pushed-authorization-requests
  20. Pushed Authorization Requests (PAR) { "request_uri": "urn:example:bwc4JK-ESC0w8acc191e-Y1LTC2", "expires_in": 90 }

    GET /authorize?request_uri= urn%3Aexample%3Abwc4JK-ESC0w8acc191e-Y1LTC2 HTTP/1.1 AS responds with a URL: User visits that URL, authorization request details are hidden! oauth.net/2/pushed-authorization-requests
  21. JWT Authorization Requests (JAR) • Create a signed JWT with

    the authorization request details • Prevents front-channel tampering with the request, similar to PAR • Authenticates the request so the AS knows the client really did initiate it tools.ietf.org/html/draft-ietf-oauth-jwsreq
  22. JWT Authorization Requests (JAR) { "iss": "s6BhdRkqt3", "aud": "https://server.example.com", "response_type":

    "code id_token", "client_id": "s6BhdRkqt3", "redirect_uri": "https://client.example.org/cb", "scope": "openid", "state": "af0ifjsldkj", "nonce": "n-0S6_WzA2Mj", "max_age": 86400 } eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2 lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2 HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6 JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g tools.ietf.org/html/draft-ietf-oauth-jwsreq
  23. JWT Authorization Requests (JAR) https://server.example.com/authorize?request=eyJhbGciOiJS... Either passed by value in

    the URL: https://server.example.com/authorize?request_uri=https://example.org/r... ...by reference in the URL: POST https://server.example.com/authorize request=eyJhbGciOiJS... ...or pushed using PAR: tools.ietf.org/html/draft-ietf-oauth-jwsreq
  24. OAuth 2.1

  25. Current State of OAuth 2.0 RFC6749 OAuth Core Authorization Code

    Implicit Password Client Credentials RFC6750 Bearer Tokens HTTP Header POST Form Body GET Query String
  26. Current State of OAuth 2.0 RFC6749 OAuth Core Authorization Code

    Implicit Password Client Credentials RFC6750 Bearer Tokens HTTP Header POST Form Body GET Query String RFC7636 PKCE
  27. Current State of OAuth 2.0 RFC6749 OAuth Core Authorization Code

    Implicit Password Client Credentials RFC6750 Bearer Tokens HTTP Header POST Form Body GET Query String RFC7636 PKCE RFC8252 PKCE for mobile
  28. Current State of OAuth 2.0 RFC6749 OAuth Core Authorization Code

    Implicit Password Client Credentials RFC6750 Bearer Tokens HTTP Header POST Form Body GET Query String RFC7636 PKCE RFC8252 PKCE for mobile Browser App BCP PKCE for SPAs
  29. Current State of 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 confidential clients Security BCP
  30. OAuth 2.1 Authorization Code Client Credentials +PKCE Tokens in HTTP

    Header Tokens in POST Form Body
  31. 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
  32. OAuth 2.1 No new behavior defined by OAuth 2.1 Non-Goals:

    Don't include anything experimental, 
 in progress or not widely implemented
  33. OAuth 2.1 RFC6749 - OAuth 2.0 Core RFC6750 - Bearer

    Token Usage RFC7636 - PKCE Native App & Browser-Based App BCPs Security BCP • MUST support PKCE for all client types • No password grant • No implicit flow • Exact string matching for redirect URIs • No access tokens in query strings • Refresh tokens must be sender-constrained or one-time use
  34. OAuth 2.1 oauth.net/2.1 tools.ietf.org/html/draft-parecki-oauth-v2-1

  35. OAuth 3 aka XYZ aka TXAuth aka XAuth

  36. OAuth 3 • In development under a new IETF working

    group • Re-thinking OAuth from the ground up • Not backwards compatible • Consolidate all the various use cases in OAuth into a new framework
  37. OAuth 3 very much in progress!

  38. Thank you! @aaronpk aaronpk.com oauth2simplified.com