Request by JWS ver.1.0 for OAuth
2.0Nomura Research Institute1-6-5 Marunouchi, Marunouchi Kitaguchi Bldg.Chiyoda-ku100-0005TokyoJapan+81-3-5533-2111n-sakimura@nri.co.jphttp://nat.sakimura.org/Ping IdentityCasilla 177, Sucursal TalaganteTalaganteRMChile+44 20 8133 3718ve7jtb@ve7jtb.comhttp://www.thread-safe.com/
Security
OAuth Working GroupRFCRequest for CommentsI-DInternet-DraftAssertionClaimSecurity TokenOAuthJavaScript Object NotationJSONJSON Web TokenJWTJSON Web SignatureJWSJSON Web EncryptionJWEThe authorization request in OAuth 2.0 utilizes query parameter
serialization. This specification defines the authorization request
using JWT serialization. The request is sent through request parameter or by reference through request_uri parameter that points to the JWT,
allowing the request to be optionally signed and encrypted.The parameters request and request_uri are introduced as additional
authorization request parameters for the OAuth
2.0 flows. The request parameter is a
JSON Web Token (JWT) whose JWT Claims Set 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 are useful such
as:When it is detected that the User Agent does not support long
URLs: 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 Object and
put it at the place where the Authorization Server can access.
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 cache-able: 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_uri 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.For the purposes of this specification, the following terms and
definitions apply.JWT that holds OAuth 2.0 authorization
requests as JWT Claims SetAbsolute URI from which the Request
Object can be obtainedA Request Object is used to
provide authorization request parameters for OAuth 2.0 authorization
request. It contains OAuth 2.0
authorization request parameters including extension parameters. It is a
JSON Web Signature (JWS) signed JWT . The parameters are included as the top-level
members of JSON. Parameter names and
string values MUST be included as JSON strings. Numerical values MUST be
included as JSON numbers. It MAY include any extension parameters. This
JSON constitutes the JWT Claims Set.The Request Object MAY be signed or unsigned (plaintext). When it is
plaintext, this is indicated by use of the none
algorithm JWA 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 Request Object MAY also be encrypted using JWE after signing, with nesting performed in the
same manner as specified for JWT. The
Authorization Request Object MAY alternatively be sent by reference
using request_uri parameter.REQUIRED OAuth 2.0 Authorization Request parameters that are not
included in the Request Object MUST be sent as a query parameter. If a
required parameter is not present in neither the query parameter nor the
Request Object, it forms a malformed request.If the parameter exists in both the query string and the
Authorization Request Object,
the values in the Request Object takes precedence.
This means that if it intends to use a cached request object,
it cannot include such parameters like
state that is expected to differ
in every request. It is fine to include them in the request object
if it is going to be prepared afresh every time.
Following is the example of the JSON that constitutes the
Claims Set.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:Instead of sending the Request Object in an OAuth 2.0 authorization
request directly, this specification allows it to be obtained from the
Request Object URI. Using this method has an advantage of reducing the
request size, enabling the caching of the Request Object, and generally
not requiring integrity protection through a cryptographic operation on
the Request Object if the channel itself is protected.The Request Object URI is sent as a part of the OAuth Authorization
Request as the value for the parameter called request_uri.
How the Request Object is registered at Request Object URI is out of
scope of this specification, but it MUST be done in a protected
channel.NOTE: the Request Object MAY be registered at the Authorization
Server at the client registration time.When the Authorization Server obtains the Request Object from Request
Object URI, it MUST do so over a protected channel. If it is obtained
from a remote server, it SHOULD use either HTTP over TLS 1.2 as defined
in AND/OR
with the algorithm considered appropriate at the time.When sending the request by request_uri,
the client MAY provide the sha256 hash as defined in FIPS180-2of the Request Object as the fragment
to it to assist the cache utilization decision of the Authorization
Server.The client constructs the authorization 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 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 Request Object that holds authorization request
parameters stated in the section 4 of OAuth
2.0.RECOMMENDED. OAuth
2.0 state.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 authorization 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:The provided request_uri was not
available.The Request Object format was
invalid.The parameter set provided in
the Request Object was invalid.This document registers following error strings to the OAuth Error
Registry.The provided request_uri was not
available.The Request Object format was
invalid.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 then
considered appropriate algorithm using . The alg=none SHOULD NOT be used in such a case.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.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 (Illumila), (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).-03Fixed the non-normative description about the advantage of static signature. Changed the requement for the parameter values in the request iteself and the request object from 'MUST MATCH" to 'Req Obj takes precedence.-02Now that they are RFCs, replaced JWS, JWE, etc. with RFC numbers. -01Copy Edits.Secure Hash Signature StandardU.S. Department of CommerceNational Institute of Standards and
TechnologyDefines Secure Hash Algorithm 256 (SHA256)OpenID Connect Core 1.0Nomura Research Institute, Ltd.Ping IdentityMicrosoftGoogleSalesforce