Illustrated PAR: OAuth 2.0 Pushed Authorization Requests
This article explains “OAuth 2.0 Pushed Authorization Requests”, a new specification called “PAR”, step by step with diagrams. (Japanese version is here.)
[Additional note on Sep. 16, 2021]: PAR was promoted to RFC 9126.
1️⃣ There is a client application and an authorization server.
2️⃣ The client application has a complex authorization request.
3️⃣ If the authorization server supports “OAuth 2.0 Pushed Authorization Requests”, a.k.a. “PAR”, the server exposes a “Pushed Authorization Request Endpoint”.
4️⃣ The client application can register the complex authorization request into the authorization server at the pushed authorization request endpoint.
5️⃣ As a response, the endpoint issues a “Request URI” that represents the registered authorization request.
6️⃣ The client application sends an authorization request to the authorization endpoint of the authorization server via a web browser. The client application doesn’t have to send the entire complex authorization request. Instead, it is enough to send the issued request URI as the value of the request_uri request parameter (with other mandatory request parameters such as client_id and response_type if you cherish backward compatibility, which “RFC 9101: JWT-Secured Authorization Request” (JAR) dares to break).
7️⃣ As a response, the endpoint issues required tokens such as an authorization code, an access token and/or an ID token. In the diagram below, an authorization code is issued. This happens when the response_type request parameter of the authorization request includes code. See “Diagrams of All The OpenID Connect Flows” for details about relationship between tokens and flows.
8️⃣ The client application sends a token request with the issued authorization code to the token endpoint of the authorization server as usual.
9️⃣ As a response, the endpoint issues an access token and optionally an ID token.
🔟 A full-color diagram as a summary.
New specifications have been being developed for new use cases and demands. Some of such specifications make authorization requests bigger. For example, “OAuth 2.0 Rich Authorization Requests” (RAR) has added a new request parameter, authorization_details, which has a complex JSON structure, and “OpenID Connect for Identity Assurance 1.0” (IDA) (my article: “Identity Assurance — OpenID Connect in the eKYC era”) has inserted verified_claims which also has a complex JSON structure into the value of the claims request parameter (OIDC Core 1.0, Section 5.5).
“OAuth 2.0 Pushed Authorization Requests” (PAR) illustrated in this article has been developed so that client applications don’t have to send big authorization requests via web browsers. In addition, other benefits are brought by PAR. See the PAR specification itself and articles (e.g. “Pushed Authorization Requests Draft adopted by OAuth Working Group”) by Torsten Lodderstedt, the author of the specification, for more information.
Authlete, my company’s product, supports PAR, RAR and IDA since version 2.2 (Spec Sheet). Please contact us via the contact form or email (sales@authlete.com) if you want to try the new specifications.
