RFC 9101 — JWT-Secured Authorization Request (JAR) — Versola Docs
/docs
Pre-1.00.7.5versola.ioGitHub
RUEN

RFC 9101 — JWT-Secured Authorization Request (JAR)

OAuth 2.0 authorization requests as a signed JWT passed by value in the request parameter, and how request objects are validated.

Specification: RFC 9101

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

Status

Partially implemented. Checked claims: 17 of 19.

Request object

  • request parameter carrying a signed JWT, sent to /authorize (§5.1) or pushed through /par (§5.2.1) (JarFlowSpec)
  • Only what the object carries is used; a query parameter cannot repeat or add to it (JarFlowSpec)
  • Signature verified against the client’s registered JWK Set (§10), the same keys private_key_jwt uses (JarFlowSpec)
  • Signing algorithm restricted to request_object_signing_alg_values_supported (§4); alg: none and HMAC algorithms are never accepted
  • typ: oauth-authz-req+jwt accepted when present and not required (§9.4.1, §10.8); other values are refused, except JWT
  • client_id outside the object must match the client_id claim inside (§6.3) (JarFlowSpec)
  • iss must equal client_id — only client-signed request objects are supported; objects signed by a third party (§1(d)) are not
  • aud: on a fapi2 tenant exactly the issuer, as a string; on a standard tenant the issuer or the authorization endpoint URL (§4; JarFlowSpec)
  • exp required and bounded by the tenant’s client-assertion maximum — the RFC leaves it optional (§4)
  • nbf: required on a fapi2 tenant, optional on standard; when present it may be at most 60 minutes old, and exp at most 60 minutes after it (JarFlowSpec)
  • iat and nbf up to 60 s in the future are accepted, further ahead is refused (JarFlowSpec)
  • jti replay guard — a fapi2 tenant requires jti; a standard tenant checks it when the client sends one; a replayed object is refused (#358; JarFlowSpec)
  • Nested request objects are refused — an object naming its own request or request_uri claim (§4, §10.7)
  • Cross-JWT confusion defence — an object carrying sub, which would look like an RFC 7523 client assertion, is refused (§10.8)
  • request_uri resolved by fetching a client-hosted URL (§5.2) — not implemented; a request_uri at /authorize always names a pushed request from /par and is never fetched over the network (§10.4 flags that fetch as a request-forgery surface)
  • Encrypted request objects (JWE) — not supported; only signed 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 when the client has no JWK Set (JarFlowSpec)

Authorization server metadata

  • request_object_signing_alg_values_supported (§4)
  • request_parameter_supported: true and request_uri_parameter_supported: true — the second one means pushed references only

Notes

  • OpenID Connect Core §6 says the same for request; see OpenID Connect Core.
  • On a fapi2 tenant the nbf and jti rules follow FAPI 2.0 Message Signing; see FAPI 2.0.

Where to look

Security profiles lists the nbf, jti and aud rules that differ between profiles.