Skip to content

PAR And JAR In Released ProAuth: Protecting The Authorization Request

Configure released PAR and JAR support in ProAuth, distinguish request transport from signatures, and plan the client integration.

Security guide3 min readMarc Müller
Back to blog
On this page

A browser redirect is a convenient way to start a login. It is also a poor place to carry a large authorization request whose parameters matter to security reviewers.

ProAuth shipped Pushed Authorization Requests (PAR) and JWT-Secured Authorization Requests (JAR) in 3.0.0. Both remain part of the released product. This article follows the June preview with guidance for integrating the capabilities shipped in ProAuth 3.0.

Move the request before adding a signature

PAR changes the transport. The client posts its authorization parameters directly to ProAuth, which validates and stores them. The browser then carries the client identifier and a short-lived request_uri instead of the complete request.

sequenceDiagram
    participant Client
    participant ProAuth
    participant Browser
    Client->>ProAuth: Push authorization request
    ProAuth-->>Client: request_uri and expiry
    Client->>Browser: Redirect with client_id and request_uri
    Browser->>ProAuth: Continue authorization
    ProAuth->>ProAuth: Use stored request through login and consent

JAR changes how the request’s contents are protected. The client signs a JWT request object; ProAuth validates its signature and required claims before continuing. PAR and JAR can be used together, but they solve different problems. A signed request sent through the browser has not acquired PAR’s transport properties, and an unsigned pushed request has not acquired a JAR signature.

These distinctions follow RFC 9126 and RFC 9101. The ProAuth PAR/JAR guide documents the supported flows and configuration.

Configure the client contract explicitly

For PAR, discover the pushed authorization request endpoint and register the client’s authentication method. The client-level RequirePushedAuthorizationRequests override can inherit tenant policy, require PAR, or permit direct requests. Review the effective FAPI profile as well: FAPI clients require PAR.

For signed requests, register the public validation keys in a Client App Key Set with usage RequestObjectSigning. Client-authentication keys and request-object signing keys have distinct purposes. Set RequestObjectSigningAlg when the client must use a specific supported asymmetric algorithm.

In the AdminApp, the relevant settings are under Client Apps → Security → Signed and encrypted requests. The encryption selectors record metadata; they do not enforce a per-client request-encryption policy. Check discovery and provider keys before designing an encrypted-request integration.

Remote JAR request objects need an exact registered HTTPS URI. ProAuth’s documented fetch controls include redirect restrictions, time and size limits, and checks against private-network targets. Prefer inline request objects when a separately hosted object adds no useful capability.

Keep authentication, PKCE and request protection separate

Configure the client authentication method independently of request protection. PAR transports the request and JAR signs it; neither substitutes for the proof a confidential client uses to authenticate. Use S256 PKCE to bind authorization-code redemption to the initiating application instance.

The returned PAR URI is short-lived and single-use. The documented default lifetime is 90 seconds, so create requests close to the user interaction and handle expiry by starting a fresh request.

Test those boundaries deliberately: omit required authentication, alter a signed parameter, redeem a consumed URI, and interrupt login before returning. A successful login alone does not exercise the rejection paths.

Put the full journey in the release checklist

Verify the registered authentication method at both PAR and token redemption, the signing-key usage, S256 verifier handling, and the browser’s final request parameters. Include cancellation and expiry in the user experience.

For an existing 2.x installation, the 3.0 release notes identify the database, custom-view and deployment migration work. Review that platform transition separately from enabling PAR or JAR for an individual client. For a new integration, establish the request and client-authentication contracts before the application goes live.

Image detail