Core Authorization Code Implicit Password Client Credentials Grant Types RFC6750 Bearer Tokens Token Usage Tokens in HTTP Header Tokens in POST Form Body Tokens in GET Query String
Core Authorization Code Implicit Password Client Credentials RFC6750 Bearer Tokens RFC7636 +PKCE Tokens in HTTP Header Tokens in POST Form Body Tokens in GET Query String
Core Authorization Code Implicit Password Client Credentials RFC6750 Bearer Tokens RFC7636 +PKCE RFC8252 PKCE for mobile Tokens in HTTP Header Tokens in POST Form Body Tokens in GET Query String
Core Authorization Code Implicit Password Client Credentials RFC6750 Bearer Tokens RFC7636 +PKCE RFC8252 PKCE for mobile Browser App BCP PKCE for SPAs Tokens in HTTP Header Tokens in POST Form Body Tokens in GET Query String
Core Authorization Code Implicit Password Client Credentials RFC6750 Bearer Tokens RFC7636 +PKCE RFC8252 PKCE for mobile Browser App BCP PKCE for SPAs Tokens in HTTP Header Tokens in POST Form Body Tokens in GET Query String
Core Authorization Code Implicit Password Client Credentials RFC6750 Bearer Tokens RFC7636 +PKCE RFC8252 PKCE for mobile Browser App BCP PKCE for SPAs Tokens in HTTP Header Tokens in POST Form Body Tokens in GET Query String
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
to the application • Even for first-party / trusted clients, this increases the attack surface • Trains users that it's okay to enter their password in more than one place • Difficult or impossible to extend to support multifactor or passwordless authentication (WebCrypto, WebAuthn)
clients MUST use PKCE with the authorization code flow • Password grant MUST NOT be used • Use exact string matching for redirect URIs • No access tokens in query strings • Refresh tokens for public clients must be sender-constrained or one-time use oauth.net/2/oauth-best-practice
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
authorization request is sent in the front-channel • Front-channel is susceptible to inspection and modification • PAR initiates the OAuth flow from the back-channel oauth.net/2/pushed-authorization-requests
"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
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
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
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
adding best practices, removing deprecated features Capture current best practices in OAuth 2.0 under a single name Add references to extensions that didn't exist when OAuth 2.0 was published
RFC6750 - Bearer Token Usage RFC7636 - PKCE Native App & Browser-Based App BCPs Security BCP • MUST support PKCE for all OAuth clients • 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
new IETF working group (GNAP) • Re-thinking OAuth from the ground up • Not backwards compatible • Consolidate all the various use cases in OAuth into a new framework