The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR)
Extracted elements (28)
JWT claims 'iss', 'sub', 'aud', 'exp', 'nbf', 'iat', and 'jti' are registered as OAuth parameters not because JAR uses all of them, but to prevent future OAuth extensions from assigning them different meanings — since the Request Object is a JWT, these claims have fixed JWT semantics.
JWT was chosen as the encoding for authorization requests due to its close relationship with JSON (OAuth's response format), developer friendliness, compactness compared to XML, Proposed Standard status, and relative ease of JWS/JWE compared to XML Signature and Encryption.
Some existing deployments may use the media type 'application/jwt' for Request Objects instead of the registered 'application/oauth-authz-req+jwt'. Similarly, requiring explicit typing ('typ':'oauth-authz-req+jwt') would break most existing deployments using OpenID Connect, as existing clients commonly use untyped Request Objects.
Client implementations supporting the Request Object URI method MUST support TLS per RFC 7525. Confidentiality protection MUST be applied using TLS with a cipher suite providing both confidentiality and integrity. HTTP clients MUST verify the TLS server certificate using DNS-ID to prevent MITM attacks.
If the Request Object is encrypted, the authorization server MUST decrypt it per RFC 7516. If decryption fails, the server MUST return an 'invalid_request_object' error.
If the signed Request Object includes 'iss' and 'aud' claims, SHOULD be present with the 'aud' value set to the authorization server's 'issuer' as defined in RFC 8414. The 'request' and 'request_uri' parameters MUST NOT appear inside a Request Object.
The Authorization Request Object MUST be either JWS-signed or JWS-signed and JWE-encrypted. 'request' and 'request_uri' parameters MUST NOT be included in Request Objects.
The authorization server MUST validate the JWS signature of the Request Object using a key associated with the client. Algorithm verification MUST be performed per Sections 3.1 and 3.2 of RFC 8725. Signature validation failure MUST result in an 'invalid_request_object' error.
The authorization server supporting JAR MUST only use the parameters included in the Request Object, even if the same parameter is duplicated in query parameters. The 'client_id' in the query parameter and in the Request Object claim MUST be identical.
The entire Request Object URI SHOULD NOT exceed 512 ASCII characters to accommodate mobile device URI length restrictions and low-bandwidth connections.
The Request Object MUST contain all parameters used to process the OAuth 2.0 authorization request except 'request' and 'request_uri'. Parameter names and string values MUST be included as JSON strings encoded using UTF-8; numerical values MUST be included as JSON numbers.
The 'request_uri' MUST have appropriate entropy so the URI is not guessable if publicly retrievable. It is RECOMMENDED that the 'request_uri' be removed after a reasonable timeout unless access control measures are taken.
TLS clients MUST support DNS-ID (dNSName in subjectAltName) for server certificate verification. Clients MUST NOT use CN-ID identifiers for authentication. SRV-ID and URI-ID MUST NOT be used for comparison.
Upon receipt of an authorization request with 'request_uri', the authorization server MUST send an HTTP GET to retrieve the referenced Request Object unless it can retrieve it securely through other mechanisms.
When both signature and encryption are applied to a Request Object, the JWT MUST be signed first, then encrypted, producing a Nested JWT as defined in RFC 7519.
If the authorization request contains potentially sensitive parameters, the client SHOULD encrypt the Request Object using JWE, since URI query parameters can leak through referrer headers and browser history.
Per-user persistent Request Object URIs should be avoided as they can enable user tracking through browser history correlation. Single-use Request Object URIs are recommended as an alternative.
A Request Object is a JWT whose Claims Set holds JSON-encoded OAuth 2.0 authorization request parameters. It must be either JWS-signed or JWS-signed then JWE-encrypted, and carries the media type 'application/oauth-authz-req+jwt'.
A Request Object URI is an absolute URI referencing a Request Object resource. When provided by the client (not by the authorization server), it must be an HTTPS URI; when provided by the authorization server, it must be a URN.
JAR defines four new error codes for authorization server responses: 'invalid_request_uri' (request_uri returned error or invalid data), 'invalid_request_object' (invalid Request Object), 'request_not_supported', and 'request_uri_not_supported'.
This specification registers 'request' and 'request_uri' as OAuth authorization request parameters, and also registers JWT claims 'iss', 'sub', 'aud', 'exp', 'nbf', 'iat', and 'jti' in the OAuth Parameters registry to prevent future OAuth extensions from reusing them with different meanings.
This specification registers 'require_signed_request_object' in both the OAuth Authorization Server Metadata registry and the OAuth Dynamic Client Registration Metadata registry, indicating whether authorization requests must be protected as Request Objects.
This specification registers the media type 'application/oauth-authz-req+jwt' in the IANA Media Types registry. The encoding is binary (base64url-encoded values separated by period characters), used to indicate content is a JWT containing Request Object claims.
A set of malicious clients can launch DoS attacks against the authorization server by pointing 'request_uri' to large, slow, or recursive URIs. The server should validate URI destinations, check media types, implement timeouts, and prohibit recursive lookups.
The 'request_uri' parameter is not signed and can be tampered with by a man-in-the-browser attacker, enabling scope elevation or DoS attacks. Mitigations include validating the URI points to an expected location, verifying the 'application/oauth-authz-req+jwt' media type, implementing timeouts, and not performing recursive GET on the URI.
The source of the authorization request MUST always be verified via JWS signature verification, symmetric JWE key verification, TLS server identity verification (with caveats), or client authentication when exchanging Request Objects for URIs. Request Object URIs issued by an AS service MUST have short lifetime (under a minute) and 128-bit minimum entropy.
To prevent cross-JWT confusion attacks (using a Request Object as a client authentication JWT), implementers should never use the client ID as the 'sub' value, use explicit typing with 'typ':'oauth-authz-req+jwt' in the header, or use keys identifiably distinct from keys used for other purposes.
To prevent downgrade attacks where an attacker bypasses JAR protections using plain RFC 6749 requests, the 'require_signed_request_object' metadata value (boolean) can be set to true on the server, causing it to MUST reject non-JAR requests and requests using 'alg':'none'.