1. Introduction

The authorization request in OAuth 2.0 [RFC6749] utilizes query parameter serialization and is 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:

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 it is easy to implement, the encoding in the URI does not allow application-layer security to be used to provide confidentiality and integrity protection. While TLS is used to offer communication security between the client and the user agent as well as 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 a result, the authorization request of [RFC6749] has shortcomings in that:

(a) the communication through the user agents is not integrity protected, and thus, the parameters can be tainted (integrity protection failure);

(b) the source of the communication is not authenticated (source authentication failure);

Due to these inherent weaknesses, several attacks against the protocol, such as redirection URI rewriting, have been identified.

The use of application-layer security mitigates these issues.

The use of application-layer security allows requests to be prepared by a trusted third party so that a client application cannot request more permissions than previously agreed upon.

Furthermore, passing the request by reference allows the reduction of over-the-wire overhead.

The JWT [RFC7519] encoding has been chosen because of:

(1) its close relationship with JSON, which is used as OAuth's response format

(2) its developer friendliness due to its textual nature

(3) its relative compactness compared to XML

(4) its development status as a Proposed Standard, along with the associated signing and encryption methods [RFC7515] [RFC7516]

(5) the 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 [RFC6749] flows. The request parameter is a JSON Web Token (JWT) [RFC7519] whose JWT Claims Set holds the JSON-encoded OAuth 2.0 authorization request parameters. Note that, in contrast to RFC 7519, the elements of the Claims Set are encoded OAuth request parameters [IANA.OAuth.Parameters], supplemented with only a few of the IANA-managed JSON Web Token Claims [IANA.JWT.Claims], in particular, iss and aud. The JWT in the request parameter is integrity protected and source authenticated using JWS.

The JWT [RFC7519] can be passed to the authorization endpoint by reference, in which case the parameter request_uri is used instead of request.

Using JWT [RFC7519] as the request encoding instead of query parameters has several advantages:

(a) Integrity protection. The request can be signed so that the integrity of the request can be checked.

(b) Source authentication. The request can be signed so that the signer can be authenticated.

(c) Confidentiality protection. 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 (including at and before user agents).

(d) Collection minimization. The request can be signed by a trusted third party attesting that the authorization request is compliant with a certain policy. For example, a request can be pre-examined by a trusted third party to confirm that all the personal data requested is strictly necessary to perform the process that the end user asked for; the request would then be signed by that trusted third party. 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 where request by reference is useful, such as:

when it is desirable to reduce the size of a transmitted request. The use of application-layer security increases the size of the request particularly when public-key cryptography is used.
when the client does not want to do the application-level cryptography. The authorization server may provide an endpoint to accept the authorization request through direct communication with the client, so that the client is authenticated and the channel is TLS protected.

This capability is in use by OpenID Connect [OpenID.Core].

See 1.1. Requirements Language.

1. Introduction​

1. Introduction