Pushed and JWT-Secured Authorization Requests
ProAuth supports Pushed Authorization Requests (PAR, RFC 9126) and JWT-Secured Authorization Requests (JAR, RFC 9101) for clients that need a hardened authorization request flow.
FAPI 2.0 clients must use PAR for every authorization request. See FAPI 2.0 Security Profile.
PAR lets a client POST the authorization request to ProAuth before redirecting the browser. ProAuth returns a one-time request_uri, keeping sensitive request parameters out of the front channel and avoiding URL length limits. JAR lets a client sign the authorization request as a JWT so ProAuth can validate request integrity before continuing the authorization flow.
Discovery Metadata
Tenant discovery advertises the PAR and JAR capabilities:
{
"pushed_authorization_request_endpoint": "https://idp.example.com/{tenant}/connect/par",
"request_parameter_supported": true,
"request_uri_parameter_supported": true,
"require_request_uri_registration": true,
"request_object_signing_alg_values_supported": ["RS256", "PS256", "ES256"],
"request_object_encryption_alg_values_supported": ["RSA-OAEP"],
"request_object_encryption_enc_values_supported": ["A256GCM"]
}require_pushed_authorization_requests is included only when tenant-level PAR enforcement is enabled.
Tenant Configuration
Configure these tenant options:
| Option | Default | Description |
|---|---|---|
PushedAuthorizationRequestLifetime | 00:01:30 | Lifetime of a pushed request URI. |
RequirePushedAuthorizationRequests | false | Requires PAR for clients that inherit tenant policy. |
ParRequestFetchTimeoutInSeconds | 5 | Timeout when fetching registered remote request_uri request objects. |
ParRequestFetchMaxBytes | 102400 | Maximum response size when fetching registered remote request_uri request objects. |
AllowPrivateNetworkRequestUris | false | Allows registered remote request_uri request objects to resolve to private network addresses. Keep disabled unless the tenant explicitly trusts that network and the host is not controlled by untrusted clients. |
Client Configuration
Client applications expose these v2 Management API and AdminApp fields:
| Field | Description |
|---|---|
RequirePushedAuthorizationRequests | Nullable override. null inherits tenant policy, true requires PAR, false allows direct authorization requests. |
RequestObjectSigningAlg | Optional required JAR signing algorithm for the client. |
RequestObjectEncryptionAlg | Optional JWE key-management algorithm. |
RequestObjectEncryptionEnc | Optional JWE content-encryption method. |
| Client App Key Sets | One or more key sets with usage RequestObjectSigning; ProAuth uses these keys to validate signed request objects. |
| Allowed Request URIs | Exact HTTPS allowlist for remote JAR request_uri values. |
Signed request objects must use asymmetric RS*, PS*, or ES* algorithms. none and HMAC signing algorithms are not accepted.
For ProAuth v3 configurations, store request-object signing keys in ClientAppKeySet records with usage RequestObjectSigning. Public request-object keys are no longer configured directly on the client application. See Client App Key Sets.
PAR Flow
- The client authenticates to
POST /connect/parorPOST /{tenantKey}/connect/parusing the same client authentication style as the token endpoint:client_secret_basic,client_secret_post,client_secret_jwt,private_key_jwt,tls_client_auth,self_signed_tls_client_auth, or a registered public-clientclient_idwhen public clients are allowed. - The client sends normal authorization request parameters as form fields, for example
client_id,response_type,scope,redirect_uri,state,nonce,code_challenge, andcode_challenge_method. - ProAuth validates and stores the pushed request and returns
201 Created:
{
"request_uri": "urn:ietf:params:oauth:request_uri:<opaque-reference>",
"expires_in": 90
}- The client redirects the browser to the authorization endpoint with
client_idand the returnedrequest_uri. - ProAuth resolves the pushed request server-side. Expired or replayed PAR URNs fail with
invalid_request_uri. Consumption is protected by optimistic concurrency so concurrent browser retries cannot redeem the same pushed request more than once.
The response includes Cache-Control: no-store and Pragma: no-cache.
ProAuth.Oidc.Client exposes PAR directly through IOidcClient.PushAuthorizationRequestAsync(AuthRequest). The method discovers pushed_authorization_request_endpoint, applies the configured AuthenticationSettings.ClientAuthenticationMethod, posts the authorization request as form fields, and returns the request_uri and expiry from ProAuth.
The ProAuth.Bff package uses ASP.NET Core's built-in PAR support and applies the configured client authentication method during the PAR call. Configure AuthenticationSettings:PushedAuthorizationBehavior with UseIfAvailable, Disable, or Require.
JAR Flow
Inline JAR uses the request authorization parameter. Remote JAR uses request_uri; the URI must be registered exactly for the client.
Request-object claims must not conflict with query or form parameters. Duplicate parameters are accepted only when the values are identical; otherwise ProAuth rejects the request with invalid_request_object. client_id must match the authenticated or outer client. ProAuth validates iss, aud, exp, signature, and the configured client signing metadata before continuing.
Remote request-object fetching uses SSRF controls: HTTPS only, no userinfo, no fragment, exact per-client allowlist, no redirects, short timeout, response-size cap, DNS resolution before fetch, and private or loopback host blocking unless explicit tenant configuration allows it. Remote key sets used to validate request-object signatures are stricter: they are always HTTPS-only, no userinfo, no fragment, and public-address only.
Encrypted request objects are accepted only when they decrypt to a signed JWT using ProAuth encryption keys.
ProAuth.Bff can sign authorization requests as inline request objects. Set AuthenticationSettings:RequestObject:Enabled to true and provide a base64 PFX signing certificate. The corresponding public key must be registered as a client app key set with usage RequestObjectSigning, and RequestObjectSigningAlg must match the configured signing algorithm when set.