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
response_type if you cherish backward compatibility, which “JWT Secured Authorization Request” (JAR) is however trying to dare 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.