Skip to content
Version v3.0.0

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:

json
{
  "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:

OptionDefaultDescription
PushedAuthorizationRequestLifetime00:01:30Lifetime of a pushed request URI.
RequirePushedAuthorizationRequestsfalseRequires PAR for clients that inherit tenant policy.
ParRequestFetchTimeoutInSeconds5Timeout when fetching registered remote request_uri request objects.
ParRequestFetchMaxBytes102400Maximum response size when fetching registered remote request_uri request objects.
AllowPrivateNetworkRequestUrisfalseAllows 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:

FieldDescription
RequirePushedAuthorizationRequestsNullable override. null inherits tenant policy, true requires PAR, false allows direct authorization requests.
RequestObjectSigningAlgOptional required JAR signing algorithm for the client.
RequestObjectEncryptionAlgOptional JWE key-management algorithm.
RequestObjectEncryptionEncOptional JWE content-encryption method.
Client App Key SetsOne or more key sets with usage RequestObjectSigning; ProAuth uses these keys to validate signed request objects.
Allowed Request URIsExact 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

  1. The client authenticates to POST /connect/par or POST /{tenantKey}/connect/par using 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-client client_id when public clients are allowed.
  2. The client sends normal authorization request parameters as form fields, for example client_id, response_type, scope, redirect_uri, state, nonce, code_challenge, and code_challenge_method.
  3. ProAuth validates and stores the pushed request and returns 201 Created:
json
{
  "request_uri": "urn:ietf:params:oauth:request_uri:<opaque-reference>",
  "expires_in": 90
}
  1. The client redirects the browser to the authorization endpoint with client_id and the returned request_uri.
  2. 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.