PAR, JAR and Hardened Profiles

An ordinary authorization request looks like this — every parameter sitting in a URL the browser will navigate to, log, and potentially truncate if the parameter list gets long (a real constraint once Rich Authorization Requests parameters are added):

Every one of these parameters passes through the user’s browser, unauthenticated as coming from the client (the authorization server has no way to know this GET actually originated from the client rather than from something that merely knows the client’s public client_id), and is fully visible in browser history, in any proxy log along the path, and to any script running on a page that constructs the redirect.

RFC 9126 adds a new endpoint, the pushed authorization request endpoint, where the client sends the entire authorization request as an authenticated, direct, server-to-server POST before the user’s browser is involved at all:

Because this call is direct and authenticated with the client’s own credentials — exactly the same client authentication methods covered on Client Credentials and Client Authentication, including private_key_jwt and mTLS — the authorization server can trust it came from the client, not merely from someone who copied a client_id. The authorization server stores the request and responds with a short-lived, single-use reference:

The browser redirect that follows then carries almost nothing:

The authorization server looks up the stored request by request_uri, applies it as if every parameter had arrived on this GET, and proceeds with the normal consent and redirect flow. Because request_uri values are short-lived (RFC 9126 recommends a lifetime on the order of tens of seconds to a few minutes) and single-use, even if one is captured in a browser history entry or a log, it is worthless shortly afterward and cannot be replayed to start a fresh, differently-scoped flow.

Some deployments (and, as covered below, FAPI 2.0) go further and mandate PAR for every client, making the request_uri indirection the only path to the authorization endpoint at all — a direct front-channel authorization request with inline parameters is then rejected outright.

The pushed authorization request endpoint returns ordinary OAuth error responses (RFC 6749 §5.2) with an HTTP error status, before any browser redirect has happened — itself an improvement over a malformed front-channel request, which historically had to be reported by redirecting the browser to an error page or, worse, silently failing:

The subsequent GET /authorize?client_id=…​&request_uri=…​ call can itself still fail — with invalid_request_uri if the reference has expired, has already been consumed, or does not belong to the client_id presented alongside it. Because a request_uri is deliberately short-lived and single-use, a client must treat invalid_request_uri as "start over from the PAR call," never as something to retry with the same reference.

Where PAR removes the request from the front channel, JAR instead protects the request’s integrity and, optionally, confidentiality wherever it travels, by packaging the whole set of authorization parameters as claims inside a JWT (see JWT and JOSE for the underlying format) — signed with the client’s key, and optionally also encrypted to the authorization server’s public key — and sending that JWT as a single request parameter instead of a flat parameter list:

signed (typically RS256, ES256 or PS256) into a compact JWS, and sent as one opaque parameter:

The authorization server verifies the JWS signature against the client’s registered key (published via its own JWKS, the same mechanism JWT and JOSE describes for resource servers verifying access tokens) before honouring anything inside it. Because the whole parameter set is inside a signed structure, tampering with any single parameter along the way — a scope, the redirect_uri, the PKCE challenge — invalidates the signature and the authorization server rejects the request outright. Where the request also needs confidentiality (parameters the browser or an intermediate party should not be able to read at all, not merely be unable to tamper with), the client additionally encrypts the JWT to the authorization server’s public key, producing a nested JWS-inside-JWE structure.

A request object can also be referenced rather than inlined, via request_uri pointing at a URL the client hosts and the authorization server fetches (its own, separate request_uri mechanism, distinct from — and predating — the one PAR defines) — useful when the signed JWT itself is too large for a comfortable URL, but this variant still leaves the fetch-time metadata (which URL was requested, when) on a channel the PAR request_uri avoids entirely.

PAR and JAR solve different problems and combine cleanly: a client can build a JAR request object (protecting the integrity of every parameter with its own signature) and then push that object through the PAR endpoint (removing it from the front channel and getting it authenticated by the client-authentication credential used on the PAR call itself):

followed by the same short request_uri redirect PAR always produces. The two are complementary defence in depth rather than redundant: PAR protects the transport hop to the authorization server and hides the request shape from the browser; JAR proves the request’s authenticity and integrity end to end, including against a party that might see the pushed request in transit or in a server-side log at the authorization server itself. A deployment can adopt PAR without JAR (removing front-channel exposure, without object-level signing) or JAR without PAR (signed requests still sent inline on the front channel, protecting integrity but not confidentiality of the parameter values) — FAPI 2.0, covered next, is the profile that requires both together.

FAPI 1.0 ships as two related profiles:

FAPI 2.0 is a substantial simplification relative to FAPI 1.0’s two-tier structure: rather than a Baseline/ Advanced split with several optional combinations, it defines one Security Profile with a smaller, more opinionated set of mandatory mechanisms, explicitly designed around the lessons learned deploying FAPI 1.0 at scale. FAPI 2.0 mandates:

FAPI 2.0 treats JAR as a companion message signing profile (FAPI 2.0 Message Signing) rather than a baked-in mandatory requirement of the core Security Profile itself, reflecting that PAR alone — being an authenticated, direct server-to-server call — already removes most of the front-channel exposure JAR exists to prevent; deployments needing end-to-end request-integrity proof beyond the PAR hop still layer JAR on top, exactly as described above.

FAPI is not a suggestion a deployment can partially adopt and still call itself "FAPI-compliant" — conformance is verified against the OpenID Foundation’s published certification programme (https://openid.net/certification/), which runs an automated conformance test suite against a live deployment of the authorization server (and, for some profiles, the client) and checks every mandatory behaviour: PAR and JAR wire format, sender-constraining actually rejecting an unconstrained token, iss present and correct, TLS configuration, and the full set of profile-specific error handling. Passing certification produces a listed, publicly verifiable certification record; regulated deployments in open banking and similar regimes frequently require this certification as a condition of participation, not merely as a best-practice recommendation. A deployment that has "implemented FAPI-like controls" without running the conformance suite has not established FAPI conformance in the sense a regulator or an open-banking scheme operator will accept.