RFC 9101 — JWT-Secured Authorization Request (JAR) — Versola Docs
VersolaVersola/docs
versola.kzGitHub
RUEN

RFC 9101 — JWT-Secured Authorization Request (JAR)

OAuth 2.0 authorization requests as a signed JWT, via the `request` parameter

Specification: RFC 9101

JAR carries the authorization request parameters as the claims of a JWT the client signs, instead of as plain query parameters a user agent could tamper with. The request object can be sent by value (request) directly to /authorize, or pushed ahead of time via RFC 9126 and redeemed by request_uri.

Request Object

  • request parameter carrying a signed JWT, sent directly to /authorize (§5.1) or pushed via /par (§5.2.1)
  • Signature verified against the client’s registered JWK Set (§10) — the same keys private_key_jwt client authentication checks against
  • Signing algorithm restricted to the deployment’s advertised set (request_object_signing_alg_values_supported, §4); alg: none and HMAC algorithms are never accepted
  • typ: oauth-authz-req+jwt header accepted when present, not required (§9.4.1 / §10.8); any other typ is refused
  • client_id outside the object required to match the client_id claim inside (§6.3)
  • iss claim required to equal client_id — only client-signed request objects are supported; third-party-signed objects (§1(d)) are not
  • aud claim checked against the issuer identifier and the authorization endpoint URL (§4)
  • exp claim required and bounded by a maximum lifetime — the RFC leaves exp optional (§4), but an object with no expiry would be a signed instruction valid for as long as the client’s key is, travelling through browser history and referrers
  • nbf claim honored when present
  • Nested request objects rejected — an object naming its own request/request_uri claim is refused (§4, §10.7)
  • Cross-JWT confusion defense — an object carrying a sub claim, which would make it indistinguishable from an RFC 7523 client assertion signed with the same key, is refused (§10.8)
  • request_uri resolved by fetching an arbitrary client-hosted URL — not implemented; request_uri at /authorize always names a pushed authorization request (RFC 9126) obtained over an authenticated back channel, never a URL fetched over the network (§10.4 flags that fetch itself as a request-forgery and denial-of-service surface)
  • Encrypted request objects (JWE nesting) — not supported; only signed (JWS) request objects are accepted

Client Metadata

  • require_signed_request_object (§10.5) — a client registered with it is refused a plain parameter set at /authorize and an unsigned push at /par; registration rejects the flag without a JWK Set, since a request object is verified against no other keys

Authorization Server Metadata

  • request_object_signing_alg_values_supported (§4)