Request by JWS ver.1.0 for OAuth 2.0

The parameters 'request' and 'request_url' are introduced as additional authorization request parameters for the OAuth 2.0 flows. The 'request' parameter is a JSON Web Token (JWT) whose body holds the JSON encoded OAuth 2.0 authorization request parameters. The can be passed to the authorization endpoint by reference, in which case the parameter 'request_uri' is used instead of the 'request'. Using as the request encoding instead of query parameters has several advantages: The request may be signed so that integrity check may be implemented. If a suitable algorithm is used for the signing, then non-repudiation property may be obtained in addition. The request may be encrypted so that end-to-end confidentiality may be obtained even if in the case TLS connection is terminated at a gateway or a similar device. There are a few cases that request by reference is useful such as: When it is detected that the User Agent dose't suport long URLs - It is entirely possible that some extensions may extend the URL. For example, the client might want to send a public key with the request. Static signature: The client may make a signed request file and put it on the client. This may just be done by a client utility or other process, so that the private key does not have to reside on the client, simplifying programming. When the server wants the requests to be cacheable - The request_uri may include a sha256 hash of the file, as defined in FIPS180-2, the server knows if the file has changed without fetching it, so it does not have to re-fetch a same file, which is a win as well. When the client wants to simplify the implementation without compromising the security. If the request parameters go through the Browser, they may be tampered in the browser even if TLS was used. This implies we need to have signature on the request as well. However, if HTTPS request_url was used, it is not going to be tampered, thus we now do not have to sign the request. This simplifies the implementation. This capability is in use by OpenID Connect.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Following parameters are defined as a request and response parameter. A that holds OAuth 2.0 authorization requests as JSON object in its body. It MAY include all the potential variables including extension and non-oauth variables. Request object can optionally be digitally signed or signed and encrypted. To sign, is used. To encrypt, is used. The absolute URL from which the request object is obtained. This is a physical or logical file that the 'request_url' points to.

The Authorization Request object is used to provide authorization request parameters. It contains OAuth 2.0 authorization request parameters including extension parameters. It is a JSON Web Signature (JWS) signed JWT that has the JSON object that holds the OAuth 2.0 authorization request parameters. The parameters are included as the top level members of JSON. Parameter names and string values are included as JSON strings. Numerical values are included as JSON numbers. It MAY include any extension parameters. This JSON constitues the body of the . The Authorization Request Object MAY be signed or unsigned (plaintext). When it is plaintext, this is indicated by use of the none algorithm in the JWS header. If signed, the Authorization Request Object SHOULD contain the Claims iss (issuer) and aud (audience) as members, with their semantics being the same as defined in the JWT specification. The Authorization Request Object MAY also be encrypted using JWE after signing, with nesting performed in the same manner as specified for JWTs . The Authorization Request Object MAY alternatively be sent by reference using request_uri parameter. OAuth 2.0 Authorization Request parameters that are not included in the Authorization Request Object MAY be sent as a query parameter. If the parameter exists both in the query string and the Authorization Request Object, they MUST exactly match. If a required parameter is not present in neither the query parameter or the Authorization Request Object, it forms a malformed request. Following is the example of the JSON which consitutes the body of the .

The following is a non-normative example of a encoded authorization request object. It includes extension variables such as "nonce", "userinfo", and "id_token". Note that the line wraps within the values are for display purpose only:

The client constructs the request URI by adding the following parameters to the query component of the authorization endpoint URI using the "application/x-www-form-urlencoded" format: REQUIRED unless request_uri is specified. The authorization request object that holds authorization request parameters stated in the section 4 of OAuth 2.0. REQUIRED unless request is specified. The absolute URL that points to the authorization request object that holds authorization request parameters stated in the section 4 of OAuth 2.0. When sending the request by request_uri, the client MAY provide the sha256 hash as defined in FIPS180-2of the Request File as the fragment to it to assist the cache utilization decision of the Authorization Server. RECOMMENDED. An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery as described in Section 10.12. of OAuth 2.0 The client directs the resource owner to the constructed URI using an HTTP redirection response, or by other means available to it via the user-agent. For example, the client directs the end-user's user-agent to make the following HTTPS request (line breaks are for display purposes only):

The autorization request object MAY be signed AND/OR encrypted. Upon receipt of request_uri in the request, the authorization server MUST send a GET request to the request_uri to retrieve the authorization request object unless it is already cached at the Authorization Server. If the response was signed AND/OR encrypted, it has to be decoded accordingly before being processed. Then, the Authorization Server MUST reconstruct the complete client request from the original HTTP request and the content of the request object. Then, the process continues as described in Section 3 of OAuth 2.0 .

Authorization Server Response is created and sent to the client as in Section 4 of OAuth 2.0 . In addition, this document defines additional 'error' values as follows: "invalid_request_uri" - The provided request_uri was not available. "invalid_request_format" - The Request Object format was invalid. "invalid_request_params" - The parameter set provided in the Request Object was invalid.

This document registers following error strings to the OAuth Error Registry. "invalid_request_uri" - The provided request_uri was not available. "invalid_request_format" - The Request Object format was invalid. "invalid_request_params" - The parameter set provided in the Request Object was invalid.

In addition to the all the security considerations discussed in OAuth 2.0, the following security considerations SHOULD be taken into account. When sending the authorization request object through request parameter, it SHOULD be signed with . When obtaining the Request FIle, the Authorization Server SHOULD use either HTTP over TLS 1.2 as defined in RFC5246 AND/OR . If the request object contains personally identifiable or sensitive information, the "request_uri" MUST be of one-time use and MUST have large enough entropy deemed necessary with applicable security policy. For higher security requirement, using is strongly recommended. [[ToDo]]

Following people contributed to creating this document through the OpenID Connect 1.0 . Breno de Medeiros (Google), Hideki Nara (TACT), John Bradley (Ping Identity) <author>, Nat Sakimura (NRI) <author/editor>, Ryo Itou (Yahoo! Japan), George Fletcher (AOL), Justin Richer (Mitre), Edmund Jay (MGI1), (add yourself). In addition following people contributed to this and previous versions through The OAuth Working Group. David Recordon (Facebook), Luke Shepard (Facebook), James H. Manger (Telstra), Marius Scurtescu (Google), John Panzer (Google), Dirk Balfanz (Google), (add yourself).