!!! Overview
[{$pagename}] ([JAR]) [RFC 9101]

!! Introduction
The [Authorization Request] in OAuth 2.0 [RFC 6749] utilizes query parameter serialization and typically sent through [user-agents] such as web [browsers].

For example, the parameters '[response_type]', '[client_id]', '[state]', and '[redirect_uri]' are encoded in the [URI] of the request: 
%%prettify 
{{{
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|Authentication] (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|Vulnerability] to the [protocol] such as [Redirection URI rewrite|Malicious Endpoint] 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|Encryption] 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|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].

[{$pagename}] also discusses [Explicit Endpoints]

!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]