JWT-Secured Authorization Requests Need Their Own Replay Boundary

Authorization requests using JSON Web Tokens (JWT) require a unique replay boundary to prevent unauthorized reuse. Although signing the JWT provides some protection, it does not guarantee a one-time event. Just marking the JWT as signed does not stop replay attacks.

For a JWT-Secured Authorization Request to be secure, the authorization server must perform several checks. Firstly, it must validate the JSON Web Signature (JWS) using the algorithm and key that the client is authorized to use. The "iss" (issuer) claim should identify the client, while the "aud" (audience) claim should identify the authorization server. The client identifier in the outer request should match the claims inside the JWT.

The server must also pay attention to how parameters are assembled. Some OAuth parameters can appear both outside and inside the JWT. The server needs a deterministic rule for dealing with duplicate or conflicting parameters. For signed JWTs, the recommended claims are "iss" (issuer) and "aud" (audience). For encrypted JWTs, the server should decrypt it first and then apply the same validation checks.

The JWT should not be treated as the entire transaction; instead, it should be seen as input to an authorization process that has its own state. The server should record the client, redirect URI, requested scopes, response type, and a transaction identifier before user interaction. If the same JWT is reused with a different browser session or if the authorization flow has expired, the request should be rejected.

Another layer of security comes from using a unique "jti" (JWT identifier) when available. This helps detect duplicates, but it's only useful if the server stores it for at least the replay window. Correlating state remains crucial to match the browser callback with the original authorization attempt.

However, there are challenges beyond JWT signing. The "request_uri" parameter adds a separate issue. The server must fetch the request object from a URI, constraining the scheme, host, redirect behavior, response size, and timeout. The URI should be scoped to the client and expire quickly. A server fetching arbitrary URLs supplied in an authorization request has essentially granted itself the server's privileges.

To test whether a server is properly validating the protocol, one can attempt to send the same signed request twice. If the second attempt is rejected or enters a distinct transaction, the server is likely implementing the necessary replay boundary. Changing the outer client identifier while keeping the signed claims intact can also help expose any weaknesses in parameter handling. Pointing "request_uri" at different endpoints or oversized responses can reveal issues in the server's handling of the request URI.