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.
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
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
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
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
Rich Authorization Requests (RAR) • Pushed Authorization Requests (PAR) • JWT Authorization Requests (JAR) • Proof of Possession (DPoP) very much still in progress!
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
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
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
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
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
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
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
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