Overview#

Introduction#

For example, the parameters 'response_type', 'client_id', 'state', and 'redirect_uri' are encoded in the URI of the request:

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1 
Host: server.example.com

While this is easy to implement, the encoding in the URI does not allow Application Layer Security with confidentiality and integrity protection to be used. While TLS is used to offer communication security between the OAuth Client and the user-agent and the user-agent and the Authorization Server, TLS sessions are terminated in the user-agent.

In addition, TLS sessions may be terminated prematurely at some middlebox (such as a load balancer).

As the result, the Authorization Request of RFC 6749 has a property that

• the communication through the user agents are NOT integrity protected and thus the parameters can be tainted (integrity protection failure); (SSL-TLS Interception)
• the source of the communication is NOT authenticated (source authentication failure); and
• the communication through the user-agents can be monitored (containment failure or lack of confidentiality).

Because of these weaknesses, several attacks to the protocol such as Redirection URI rewrite has been put forward by now.

The use of Application Layer security mitigates these issues.

In addition, it allows requests to be prepared by a third party so that a OAuth Client application cannot request more permissions than previously agreed. This offers an additional degree of privacy protection.

Further, the Authorization Request by-reference allows the reduction of over-the-wire overhead.

There are other potential formats that could be used for this purpose instead of JWT RFC 7519. The JWT was chosen because of:

• close relationship with JSON, which is used as OAuth's response format;
• developer friendliness due to its textual nature;
• relative compactness compared to XML;
• development status that it is an RFC and so is its associated signing and encryption methods as RFC 7515 and RFC 7516;
• relative ease of JWS and JWE compared to XML Signature and Encryption.

The parameters "request" and "request_uri" are introduced as additional Authorization Request parameters for the OAuth 2.0 (RFC 6749) flows. The "request" parameter is a JSON Web Token (JWT) RFC 7519 whose JWT Claims Set holds the JSON encoded OAuth 2.0 Authorization Request parameters. This JWT is integrity protected and source authenticated using JWS.

The JWT RFC 7519 can be passed to the authorization_endpoint by-reference, in which case the parameter "request_uri" is used instead of the "request".

Using JWT RFC 7519 as the request encoding instead of query parameters has several advantages:

• (integrity protection) The request can be signed so that the integrity of the request can be checked ;
• (source authentication) The request can be signed so that the signer can be authenticated ;
• (containment) The request can be encrypted so that end-to-end confidentiality can be provided even if the TLS connection is terminated at one point or another ; and
• (collection minimization) The request can be signed by a third party attesting that the Authorization Request is compliant to certain policy. For example, a request can be pre-examined by a third party that all the personal data requested is strictly necessary to perform the process that the end-user asked for, and statically signed by that third party.

The OAuth Client would then send the request along with dynamic parameters such as state. The Authorization Server then examines the signature and shows the conformance status to the end-user, who would have some assurance as to the legitimacy of the request when authorizing it. In some cases, it may even be desirable to skip the authorization dialogue under such circumstances.

There are a few cases that request by reference are useful such as:

• When it is desirable to reduce the size of transmitted request. The use of application layer security increases the size of the request, particularly when Public Key cryptography is used.
• The OAuth Client can make a signed Request Object and put it at a place that the Authorization Server can access. This may just be done by a OAuth Client utility or other process, so that the private key does not have to reside on the client, simplifying programming.
  Downside of it is that the signed portion just become a token.
• When the server wants the requests to be cacheable: The request_uri may include a SHA-256 hash of the contents of the resources referenced by the Request Object URI. With this, the server knows if the resource has changed without fetching it, so it does not have to re-fetch the same content, which is a win as well. This is explained in Section 5.2.
• When the OAuth Client does not want to do the crypto: The Authorization Server may provide an endpoint to accept the Authorization Request through direct communication with the OAuth Client so that the OAuth Client is authenticated and the channel is TLS protected.

This capability is in use by OpenID Connect OpenID Connect Core 1.0.

OAuth 2.0 JWT Secured Authorization Request also discusses Explicit Endpoints

More Information#

• JAR
• OAuth 2.0 Security Considerations
• Pushed Authorization Requests
• RFC 9101