(Added in 7.0)
Pushed Authorization Requests (PAR) is a relatively new OAuth standard that improves the security of OAuth and OIDC flows by moving authorization parameters from the front channel to the back channel (that is, from redirect URLs in the browser to direct machine to machine http calls on the back end).
This prevents an attacker in the browser from
Pushing the authorization parameters also keeps request URLs short. Authorize parameters might get very long when using more complex OAuth and OIDC features, and URLs that are long cause issues in many browsers and networking infrastructure.
The use of PAR is encouraged by the FAPI working group within the OpenID Foundation. For example, the FAPI2.0 Security Profile requires the use of PAR. This security profile is used by many of the groups working on open banking (primarily in Europe), in health care, and in other industries with high security requirements.
Duende.IdentityServer includes support for PAR in the Business Edition or higher license. In the starter edition, PAR requests will not be processed and instead log errors. If you have a starter edition license, you should disable the EnablePushedAuthorizationEndpoint flag so that discovery indicates that your IdentityServer does not support PAR:
builder.Services.AddIdentityServer(options =>
{
options.Endpoints.EnablePushedAuthorizationEndpoint = false;
})
Using PAR is similar to other flows that use the authorization endpoint, but it adds an initial back-channel request to a new protocol endpoint for pushed authorization requests. This endpoint requires client authentication and accepts POSTed form-urlencoded data containing all of the same parameters that are accepted at the authorize endpoint.
The result of the PAR request is JSON containing an identifier (the request_uri property) and expiration information (the expires_in property). Clients then send that identifier to the authorize endpoint instead of the parameters that were just pushed. From there, the OAuth or OIDC flow continues as normal. For example, in the authorization code flow, the user will be redirected to login and other UI pages as necessary before being redirected back to the client with an authorization code which the client subsequently exchanges for tokens.
A sample of how to implement this flow in an ASP.NET application is available here.
Pushed authorization requests are stored in the IPushedAuthorizationRequestStore, which includes methods to store, retrieve, and consume pushed requests. Pushed requests that are not used are removed by the token cleanup job.