IETF · August 2021
RFC 9101
N. Sakimura, J. Bradley, M. Jones
Useful when a user-agent in the middle of a consent flow should not be able to widen the agent's requested permissions.
At a glance
Actors
01
Front-channel authorization parameters can be modified in transit. JAR wraps them in a signed (optionally encrypted) JWT request object. Useful when a user-agent in the middle of a consent flow should not be able to widen the agent's requested permissions.
FAPI 1.0 used JAR heavily. FAPI 2.0 prefers PAR but still allows signed requests. If you already have PAR and confidential client auth, JAR is optional for many agent deployments.
02
The client's signing key authenticates the request contents. aud must be the AS. The browser still carries the request or request_uri; encryption (JWE) hides contents from the user-agent.
03
RFC 9101: JWT containing authorization parameters, signed with the client key, passed as request or by reference as request_uri. Can combine with PAR (push a JAR).
04
Flow 1
Client builds a JWT with the authorize parameters, aud=AS, signed with its key.
Passes request=JWT or request_uri to a hosted object (or PAR).
AS verifies signature and uses the JWT claims as the request, ignoring unsigned duplicates that would widen it.
05
Integrity and authenticity of the authorization request. Not user identity.
06
PAR hides; JAR signs. Together they cover leakage and tampering.
PAR is the FAPI 2 requirement; JAR is not the headline control.
Same client keys often used for private_key_jwt and JAR.
07
The AS must not let query parameters override signed values to a broader grant.
08
RFC 9101, August 2021. Stable. https://www.rfc-editor.org/rfc/rfc9101.html
If you already have PAR and confidential client auth, JAR is optional for many agent deployments. Keep it when you must prove the request came from a specific client key through an untrusted browser.