draft-ietf-oauth-jwsreq-13.txt   draft-ietf-oauth-jwsreq-14.txt 
OAuth Working Group N. Sakimura OAuth Working Group N. Sakimura
Internet-Draft Nomura Research Institute Internet-Draft Nomura Research Institute
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: October 1, 2017 Ping Identity Expires: January 22, 2018 Yubico
March 30, 2017 July 21, 2017
The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request
(JAR) (JAR)
draft-ietf-oauth-jwsreq-13 draft-ietf-oauth-jwsreq-14
Abstract Abstract
The authorization request in OAuth 2.0 described in RFC 6749 utilizes The authorization request in OAuth 2.0 described in RFC 6749 utilizes
query parameter serialization, which means that Authorization Request query parameter serialization, which means that Authorization Request
parameters are encoded in the URI of the request and sent through parameters are encoded in the URI of the request and sent through
user agents such as web browsers. While it is easy to implement, it user agents such as web browsers. While it is easy to implement, it
means that (a) the communication through the user agents are not means that (a) the communication through the user agents are not
integrity protected and thus the parameters can be tainted, and (b) integrity protected and thus the parameters can be tainted, and (b)
the source of the communication is not authenticated. Because of the source of the communication is not authenticated. Because of
these weaknesses, several attacks to the protocol have now been put these weaknesses, several attacks to the protocol have now been put
forward. forward.
This document introduces the ability to send request parameters in a This document introduces the ability to send request parameters in a
JSON Web Token (JWT) instead, which allows the request to be signed JSON Web Token (JWT) instead, which allows the request to be signed
with JSON Web Signature (JWS) and/or encrypted with JSON Web with JSON Web Signature (JWS) and encrypted with JSON Web Encryption
Encryption (JWE) so that the integrity, source authentication and (JWE) so that the integrity, source authentication and
confidentiality property of the Authorization Request is attained. confidentiality property of the Authorization Request is attained.
The request can be sent by value or by reference. The request can be sent by value or by reference.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 1, 2017. This Internet-Draft will expire on January 22, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 6 2.1. Request Object . . . . . . . . . . . . . . . . . . . . . 6
2.2. Request Object URI . . . . . . . . . . . . . . . . . . . 6 2.2. Request Object URI . . . . . . . . . . . . . . . . . . . 6
3. Symbols and abbreviated terms . . . . . . . . . . . . . . . . 6 3. Symbols and abbreviated terms . . . . . . . . . . . . . . . . 6
4. Request Object . . . . . . . . . . . . . . . . . . . . . . . 6 4. Request Object . . . . . . . . . . . . . . . . . . . . . . . 6
5. Authorization Request . . . . . . . . . . . . . . . . . . . . 8 5. Authorization Request . . . . . . . . . . . . . . . . . . . . 8
5.1. Passing a Request Object by Value . . . . . . . . . . . . 9 5.1. Passing a Request Object by Value . . . . . . . . . . . . 9
5.2. Passing a Request Object by Reference . . . . . . . . . . 10 5.2. Passing a Request Object by Reference . . . . . . . . . . 10
5.2.1. URL Referencing the Request Object . . . . . . . . . 11 5.2.1. URI Referencing the Request Object . . . . . . . . . 11
5.2.2. Request using the "request_uri" Request Parameter . . 12 5.2.2. Request using the "request_uri" Request Parameter . . 12
5.2.3. Authorization Server Fetches Request Object . . . . . 12 5.2.3. Authorization Server Fetches Request Object . . . . . 12
6. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 13 6. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 13
6.1. Encrypted Request Object . . . . . . . . . . . . . . . . 13 6.1. Encrypted Request Object . . . . . . . . . . . . . . . . 13
6.2. JWS Signed Request Object . . . . . . . . . . . . . . . . 13 6.2. JWS Signed Request Object . . . . . . . . . . . . . . . . 13
6.3. Request Parameter Assembly and Validation . . . . . . . . 14 6.3. Request Parameter Assembly and Validation . . . . . . . . 14
7. Authorization Server Response . . . . . . . . . . . . . . . . 14 7. Authorization Server Response . . . . . . . . . . . . . . . . 14
8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 14 8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10.1. Choice of Algorithms . . . . . . . . . . . . . . . . . . 15 10.1. Choice of Algorithms . . . . . . . . . . . . . . . . . . 15
10.2. Request Source Authentication . . . . . . . . . . . . . 15 10.2. Request Source Authentication . . . . . . . . . . . . . 15
10.3. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 16 10.3. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 16
10.4. Risks Associated with request_uri . . . . . . . . . . . 17 10.4. Risks Associated with request_uri . . . . . . . . . . . 17
10.4.1. DDoS Attack on the Authorization Server . . . . . . 17 10.4.1. DDoS Attack on the Authorization Server . . . . . . 17
10.4.2. Request URI Rewrite . . . . . . . . . . . . . . . . 17 10.4.2. Request URI Rewrite . . . . . . . . . . . . . . . . 17
11. TLS security considerations . . . . . . . . . . . . . . . . . 17 11. TLS security considerations . . . . . . . . . . . . . . . . . 18
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
12.1. Collection limitation . . . . . . . . . . . . . . . . . 18 12.1. Collection limitation . . . . . . . . . . . . . . . . . 18
12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 19 12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 19
12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 19 12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 19
12.2.2. Tracking using Request Object URI . . . . . . . . . 19 12.2.2. Tracking using Request Object URI . . . . . . . . . 19
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
14. Revision History . . . . . . . . . . . . . . . . . . . . . . 20 14. Revision History . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
15.1. Normative References . . . . . . . . . . . . . . . . . . 24 15.1. Normative References . . . . . . . . . . . . . . . . . . 25
15.2. Informative References . . . . . . . . . . . . . . . . . 26 15.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The Authorization Request in OAuth 2.0 [RFC6749] utilizes query The Authorization Request in OAuth 2.0 [RFC6749] utilizes query
parameter serialization and is typically sent through user agents parameter serialization and is typically sent through user agents
such as web browsers. such as web browsers.
For example, the parameters "response_type", "client_id", "state", For example, the parameters "response_type", "client_id", "state",
skipping to change at page 5, line 10 skipping to change at page 5, line 10
(c) (confidentiality protection) The request can be encrypted so (c) (confidentiality protection) The request can be encrypted so
that end-to-end confidentiality can be provided even if the TLS that end-to-end confidentiality can be provided even if the TLS
connection is terminated at one point or another. connection is terminated at one point or another.
(d) (collection minimization) The request can be signed by a third (d) (collection minimization) The request can be signed by a third
party attesting that the authorization request is compliant with party attesting that the authorization request is compliant with
a certain policy. For example, a request can be pre-examined by a certain policy. For example, a request can be pre-examined by
a third party that all the personal data requested is strictly a third party that all the personal data requested is strictly
necessary to perform the process that the end-user asked for, necessary to perform the process that the end-user asked for,
and statically signed by that third party. The client would and statically signed by that third party. The authorization
then send the request along with dynamic parameters such as server then examines the signature and shows the conformance
"state". The authorization server then examines the signature status to the end-user, who would have some assurance as to the
and shows the conformance status to the end-user, who would have legitimacy of the request when authorizing it. In some cases,
some assurance as to the legitimacy of the request when it may even be desirable to skip the authorization dialogue
authorizing it. In some cases, it may even be desirable to skip under such circumstances.
the authorization dialogue under such circumstances.
There are a few cases that request by reference is useful such as: There are a few cases that request by reference is useful such as:
1. When it is desirable to reduce the size of transmitted request. 1. When it is desirable to reduce the size of transmitted request.
The use of application layer security increases the size of the The use of application layer security increases the size of the
request, particularly when public key cryptography is used. request, particularly when public key cryptography is used.
2. The client can make a signed Request Object and put it in a place 2. The client can make a signed Request Object and put it in a place
that the Authorization Server can access. If thie location is that the Authorization Server can access. This may just be done
secure and only available to the Authorization server, the client by a client utility or other process, so that the private key
may accheve confidentiality without encrypting the Request does not have to reside on the client, simplifying programming.
Object. The downside of it is that the signed portion just become a
token.
3. When the client does not want to do the crypto. The 3. When the client does not want to do the crypto. The
Authorization Server may provide an endpoint to accept the Authorization Server may provide an endpoint to accept the
Authorization Request through direct communication with the Authorization Request through direct communication with the
Client and return a prrivate "request_uri" to the client. Client so that the Client is authenticated and the channel is TLS
protected.
This capability is in use by OpenID Connect [OpenID.Core]. This capability is in use by OpenID Connect [OpenID.Core].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Terminology 2. Terminology
skipping to change at page 6, line 36 skipping to change at page 6, line 36
URI Uniform Resource Identifier URI Uniform Resource Identifier
URL Uniform Resource Locator URL Uniform Resource Locator
WAP Wireless Application Protocol WAP Wireless Application Protocol
4. Request Object 4. Request Object
A Request Object (Section 2.1) is used to provide authorization A Request Object (Section 2.1) is used to provide authorization
request parameters for an OAuth 2.0 authorization request. It request parameters for an OAuth 2.0 authorization request. It MUST
contains OAuth 2.0 [RFC6749] authorization request parameters contains all the OAuth 2.0 [RFC6749] authorization request parameters
including extension parameters. The parameters are represented as including extension parameters. The parameters are represented as
the JWT claims. Parameter names and string values MUST be included the JWT claims. Parameter names and string values MUST be included
as JSON strings. Since it is a JWT, JSON strings MUST be represented as JSON strings. Since it is a JWT, JSON strings MUST be represented
in UTF-8. Numerical values MUST be included as JSON numbers. It MAY in UTF-8. Numerical values MUST be included as JSON numbers. It MAY
include any extension parameters. This JSON [RFC7159] constitutes include any extension parameters. This JSON [RFC7159] constitutes
the JWT Claims Set defined in JWT [RFC7519]. The JWT Claims Set is the JWT Claims Set defined in JWT [RFC7519]. The JWT Claims Set is
then signed or encrypted or both. then signed or signed and encrypted.
To sign, JSON Web Signature (JWS) [RFC7515] is used. The result is a To sign, JSON Web Signature (JWS) [RFC7515] is used. The result is a
JWS signed JWT [RFC7519]. If signed, the Authorization Request JWS signed JWT [RFC7519]. If signed, the Authorization Request
Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience) Object SHOULD contain the Claims "iss" (issuer) and "aud" (audience)
as members, with their semantics being the same as defined in the JWT as members, with their semantics being the same as defined in the JWT
[RFC7519] specification. [RFC7519] specification.
To encrypt, JWE [RFC7516] is used. Unless the algorithm used in JWE To encrypt, JWE [RFC7516] is used. When both signature and
allows for the source to be authenticated, JWS signature SHOULD also encryption are being applied, the JWT MUST be signed then encrypted
be applied so that the source authentication can be done. When both as advised in the section 11.2 of [RFC7519]. The result is a Nested
signature and encryption are being applied, the JWT MUST be signed JWT, as defined in [RFC7519].
then encrypted as advised in the section 11.2 of [RFC7519]. The
result is a Nested JWT, as defined in [RFC7519].
The Authorization Request Object MAY be sent by value as described in The Authorization Request Object MAY be sent by value as described in
Section 5.1 or by reference as described in Section 5.2. Section 5.1 or by reference as described in Section 5.2.
"request" and "request_uri" parameters MUST NOT be included in "request" and "request_uri" parameters MUST NOT be included in
Request Objects. Request Objects.
The following is an example of the Claims in a Request Object before The following is an example of the Claims in a Request Object before
base64url encoding and signing. Note that it includes extension base64url encoding and signing. Note that it includes extension
variables such as "nonce" and "max_age". variables such as "nonce" and "max_age".
skipping to change at page 9, line 29 skipping to change at page 9, line 29
GET /authz?request=eyJhbG..AlMGzw HTTP/1.1 GET /authz?request=eyJhbG..AlMGzw HTTP/1.1
Host: server.example.com Host: server.example.com
The value for the request parameter is abbreviated for brevity. The value for the request parameter is abbreviated for brevity.
The authorization request object MUST be one of the following: The authorization request object MUST be one of the following:
(a) JWS signed (a) JWS signed
(b) JWE encrypted (when symmetric keys are being used) (b) JWS signed and JWE encrypted
(c) JWS signed and JWE encrypted The client MAY send the parameters included in the request object
duplicated in the query parameters as well for the backward
compatibility etc. However, the authorization server supporting this
specification MUST only use the parameters included in the request
object.
5.1. Passing a Request Object by Value 5.1. Passing a Request Object by Value
The Client sends the Authorization Request as a Request Object to the The Client sends the Authorization Request as a Request Object to the
Authorization Endpoint as the "request" parameter value. Authorization Endpoint as the "request" parameter value.
The following is an example of an Authorization Request using the The following is an example of an Authorization Request using the
"request" parameter (with line wraps within values for display "request" parameter (with line wraps within values for display
purposes only): purposes only):
skipping to change at page 11, line 7 skipping to change at page 11, line 7
2. The maximum URL length supported by older versions of Internet 2. The maximum URL length supported by older versions of Internet
Explorer is 2083 ASCII characters. Explorer is 2083 ASCII characters.
3. On a slow connection such as 2G mobile connection, a large URL 3. On a slow connection such as 2G mobile connection, a large URL
would cause the slow response and therefore the use of such is would cause the slow response and therefore the use of such is
not advisable from the user experience point of view. not advisable from the user experience point of view.
The contents of the resource referenced by the URI MUST be a Request The contents of the resource referenced by the URI MUST be a Request
Object. The scheme used in the "request_uri" value MUST be "https", Object. The scheme used in the "request_uri" value MUST be "https",
as defined in 2.7.2 of RFC7230 [RFC7230], unless the target Request as defined in 2.7.2 of RFC7230 [RFC7230]. The "request_uri" value
Object is signed in a way that is verifiable by the Authorization MUST be reachable by the Authorization Server, and SHOULD be
Server. The "request_uri" value MUST be reachable by the reachable by the Client.
Authorization Server, and SHOULD be reachable by the Client.
The following is an example of the contents of a Request Object The following is an example of the contents of a Request Object
resource that can be referenced by a "request_uri" (with line wraps resource that can be referenced by a "request_uri" (with line wraps
within values for display purposes only): within values for display purposes only):
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
skipping to change at page 11, line 36 skipping to change at page 11, line 35
ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH ICAgInBpY3R1cmUiOiBudWxsDQogICAgfSwNCiAgICJpZF90b2tlbiI6IA0KICAgIH
sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu sNCiAgICAgImdlbmRlciI6IG51bGwsDQogICAgICJiaXJ0aGRhdGUiOiB7ImVzc2Vu
dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm dGlhbCI6IHRydWV9LA0KICAgICAiYWNyIjogeyJ2YWx1ZXMiOiBbInVybjptYWNlOm
luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs luY29tbW9uOmlhcDpzaWx2ZXIiXX0NCiAgICB9DQogIH0NCn0.nwwnNsk1-Zkbmnvs
F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
5.2.1. URL Referencing the Request Object 5.2.1. URI Referencing the Request Object
The Client stores the Request Object resource either locally or The Client stores the Request Object resource either locally or
remotely at a URL the Authorization Server can access. Such facility remotely at a URI the Authorization Server can access. Such facility
may be provided by the client or the authorization server or a third may be provided by the authorization server or a third party. For
party. For example, the authorization server may provide a URL to example, the authorization server may provide a URL to which the
which the client POSTs the request object and obtains the Requiest client POSTs the request object and obtains the Requiest URI. The
URI. The URL MUST be HTTPS URL. This URL is the Request Object URI, URL MUST be a HTTPS URL if it is not under the control of the
"request_uri". Authorization Server. When it is stored under the control of the
Authorization Server, it may be a URN. This URI is the Request
Object URI, "request_uri".
It is possible for the Request Object to include values that are to It is possible for the Request Object to include values that are to
be revealed only to the Authorization Server. As such, the be revealed only to the Authorization Server. As such, the
"request_uri" MUST have appropriate entropy for its lifetime. It is "request_uri" MUST have appropriate entropy for its lifetime. It is
RECOMMENDED that it be removed after a reasonable timeout unless RECOMMENDED that it be removed after a reasonable timeout unless
access control measures are taken. access control measures are taken.
Unless the access to the "request_uri" over TLS provides adequate
authentication of the source of the Request Object, the Request
Object MUST be JWS Signed.
The following is an example of a Request Object URI value (with line The following is an example of a Request Object URI value (with line
wraps within values for display purposes only): wraps within values for display purposes only):
https://client.example.org/request.jwt# https://tfp.example.org/request.jwt#
GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
5.2.2. Request using the "request_uri" Request Parameter 5.2.2. Request using the "request_uri" Request Parameter
The Client sends the Authorization Request to the Authorization The Client sends the Authorization Request to the Authorization
Endpoint. Endpoint.
The following is an example of an Authorization Request using the The following is an example of an Authorization Request using the
"request_uri" parameter (with line wraps within values for display "request_uri" parameter (with line wraps within values for display
purposes only): purposes only):
https://server.example.com/authorize? https://server.example.com/authorize?
response_type=code%20id_token response_type=code%20id_token
&client_id=s6BhdRkqt3 &client_id=s6BhdRkqt3
&request_uri=https%3A%2F%2Fclient.example.org%2Frequest.jwt &request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
%23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM %23GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM
&state=af0ifjsldkj &state=af0ifjsldkj
5.2.3. Authorization Server Fetches Request Object 5.2.3. Authorization Server Fetches Request Object
Upon receipt of the Request, the Authorization Server MUST send an Upon receipt of the Request, the Authorization Server MUST send an
HTTP "GET" request to the "request_uri" to retrieve the referenced HTTP "GET" request to the "request_uri" to retrieve the referenced
Request Object, The Authorization Server may also use other Request Object, unless it is stored in a way so that it can retrieve
equivelently secure mechinisims to retreve the refrenced Request it through other mechanism securely, and parse it to recreate the
Object. A private mechinisim may use URN as the "request_uri" value. Authorization Request parameters.
The Authorization server MUST parse the Request Object to vakidate
and extract the Authorization Request parameters.
The following is an example of this fetch process: The following is an example of this fetch process:
GET /request.jwt HTTP/1.1 GET /request.jwt HTTP/1.1
Host: client.example.org Host: tfp.example.org
The following is an example of the fetch response: The following is an example of the fetch response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Thu, 16 Feb 2017 23:52:39 GMT Date: Thu, 16 Feb 2017 23:52:39 GMT
Server: Apache/2.2.22 (client.example.org) Server: Apache/2.2.22 (tfp.example.org)
Content-type: application/jwt
Content-Length: 1250 Content-Length: 1250
Last-Modified: Wed, 15 Feb 2017 23:52:32 GMT Last-Modified: Wed, 15 Feb 2017 23:52:32 GMT
eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3 eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ew0KICJpc3MiOiAiczZCaGRSa3
F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl F0MyIsDQogImF1ZCI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsDQogInJl
c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk c3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsDQogImNsaWVudF9pZCI6ICJzNk
JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w JoZFJrcXQzIiwNCiAicmVkaXJlY3RfdXJpIjogImh0dHBzOi8vY2xpZW50LmV4YW1w
bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW bGUub3JnL2NiIiwNCiAic2NvcGUiOiAib3BlbmlkIiwNCiAic3RhdGUiOiAiYWYwaW
Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog Zqc2xka2oiLA0KICJub25jZSI6ICJuLTBTNl9XekEyTWoiLA0KICJtYXhfYWdlIjog
ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ ODY0MDAsDQogImNsYWltcyI6IA0KICB7DQogICAidXNlcmluZm8iOiANCiAgICB7DQ
skipping to change at page 13, line 37 skipping to change at page 13, line 38
F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF F6zTHm8CHERFMGQPhos-EJcaH4Hh-sMgk8ePrGhw_trPYs8KQxsn6R9Emo_wHwajyF
KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx KzuMXZFSZ3p6Mb8dkxtVyjoy2GIzvuJT_u7PkY2t8QU9hjBcHs68PkgjDVTrG1uRTx
0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
6. Validating JWT-Based Requests 6. Validating JWT-Based Requests
6.1. Encrypted Request Object 6.1. Encrypted Request Object
The Authorization Server MUST decrypt the JWT in accordance with the If the request object is encrypted, the Authorization Server MUST
JSON Web Encryption [RFC7516] specification. If the result is a decrypt the JWT in accordance with the JSON Web Encryption [RFC7516]
signed request object, signature validation MUST be performed as specification.
defined in Section 6.2 as well.
The result is a signed request object and the signature validation
MUST be performed as defined in Section 6.2 as well.
If decryption fails, the Authorization Server MUST return an If decryption fails, the Authorization Server MUST return an
"invalid_request_object" error. "invalid_request_object" error.
6.2. JWS Signed Request Object 6.2. JWS Signed Request Object
To perform signature validation of a JSON Web Signature [RFC7515] To perform signature validation of a JSON Web Signature [RFC7515]
signed request object, the "alg" Header Parameter in its JOSE Header signed request object, the "alg" Header Parameter in its JOSE Header
MUST match the value of the pre-registered algorithm. The signature MUST match the value of the pre-registered algorithm. The signature
MUST be validated against the appropriate key for that "client_id" MUST be validated against the appropriate key for that "client_id"
and algorithm. and algorithm.
If signature validation fails, the Authorization Server MUST return If signature validation fails, the Authorization Server MUST return
an "invalid_request_object" error. an "invalid_request_object" error.
6.3. Request Parameter Assembly and Validation 6.3. Request Parameter Assembly and Validation
The Authorization Server MUST extract the set of Authorization The Authorization Server MUST extract the set of Authorization
Request parameters from the Request Object value. The Authorization Request parameters from the Request Object value. The Authorization
Server MUST only use the parameters in the Request Object even if the
same parameter is provided in the query parameter. The Authorization
Server then validates the request as specified in OAuth 2.0 Server then validates the request as specified in OAuth 2.0
[RFC6749]. [RFC6749].
If the validation fails, then the Authorization Server MUST return an
error as specified in OAuth 2.0 [RFC6749].
7. Authorization Server Response 7. Authorization Server Response
Authorization Server Response is created and sent to the client as in Authorization Server Response is created and sent to the client as in
Section 4 of OAuth 2.0 [RFC6749] . Section 4 of OAuth 2.0 [RFC6749] .
In addition, this document uses these additional error values: In addition, this document uses these additional error values:
invalid_request_uri The "request_uri" in the Authorization Request invalid_request_uri The "request_uri" in the Authorization Request
returns an error or contains invalid data. returns an error or contains invalid data.
skipping to change at page 17, line 21 skipping to change at page 17, line 27
The introdcution of "redirect_uri" introduces several attack The introdcution of "redirect_uri" introduces several attack
possibilities. possibilities.
10.4.1. DDoS Attack on the Authorization Server 10.4.1. DDoS Attack on the Authorization Server
A set of malicious client can launch a DoS attack to the A set of malicious client can launch a DoS attack to the
authorization server by pointing the "request_uri" to a uri that authorization server by pointing the "request_uri" to a uri that
returns extremely large content or extremely slow to respond. Under returns extremely large content or extremely slow to respond. Under
such an attack, the server may use up its resource and start failing. such an attack, the server may use up its resource and start failing.
Similarly, a malicious client can specify the "request_uri" value
that itself points to an authorization request URI that uses
"request_uri" to cause the recursive lookup.
To prevent such attack to succeed, the server should (a) check that To prevent such attack to succeed, the server should (a) check that
the value of "request_uri" parameter does not point to an unexpected the value of "request_uri" parameter does not point to an unexpected
location, (b) check the content type of the response is "application/ location, (b) check the content type of the response is "application/
json" (c) implement a time-out for obtaining the content of jose" (c) implement a time-out for obtaining the content of
"request_uri", and (d) do not perform recursive GET on the
"request_uri". "request_uri".
10.4.2. Request URI Rewrite 10.4.2. Request URI Rewrite
The value of "request_uri" is not signed thus it can be tampered by The value of "request_uri" is not signed thus it can be tampered by
Man-in-the-browser attacker. Several attack possibilities rise Man-in-the-browser attacker. Several attack possibilities rise
because of this, e.g., (a) attacker may create another file that the because of this, e.g., (a) attacker may create another file that the
rewritten URI points to making it possible to request extra scope (b) rewritten URI points to making it possible to request extra scope (b)
attacker launches a DoS attack to a victim site by setting the value attacker launches a DoS attack to a victim site by setting the value
of "request_uri" to be that of the victim. of "request_uri" to be that of the victim.
skipping to change at page 17, line 52 skipping to change at page 18, line 15
11. TLS security considerations 11. TLS security considerations
Curent security considerations can be found in Recommendations for Curent security considerations can be found in Recommendations for
Secure Use of TLS and DTLS [BCP195]. This supersedes the TLS version Secure Use of TLS and DTLS [BCP195]. This supersedes the TLS version
recommendations in OAuth 2.0 [RFC6749]. recommendations in OAuth 2.0 [RFC6749].
12. Privacy Considerations 12. Privacy Considerations
When the Client is being granted access to a protected resource When the Client is being granted access to a protected resource
containing personal data, both the Client and the Authorization containing personal data, both the Client and the Authorization
Server need to adhere to Privacy Principles. ISO/IEC 29100 Server need to adhere to Privacy Principles. RFC 6973 Privacy
Considerations for Internet Protocols [RFC6973] gives excellent
[ISO29100] is an International Standard and its Privacy Principles guidance on the enhancement of protocol design and implementation.
are good to follow. The provision listed in it should be followed.
While ISO/IEC 29100 [ISO29100] is a high-level document that gives
general guidance, RFC 6973 Privacy Considerations for Internet
Protocols [RFC6973] gives more specific guidance on the privacy
consideration for Internet Protocols. It gives excellent guidance on
the enhancement of protocol design and implementation. The provision
listed in it should be followed.
Most of the provision would apply to The OAuth 2.0 Authorization Most of the provision would apply to The OAuth 2.0 Authorization
Framework [RFC6749] and The OAuth 2.0 Authorization Framework: Bearer Framework [RFC6749] and The OAuth 2.0 Authorization Framework: Bearer
Token Usage [RFC6750] and are not specific to this specification. In Token Usage [RFC6750] and are not specific to this specification. In
what follows, only the specific provisions to this specification are what follows, only the specific provisions to this specification are
noted. noted.
12.1. Collection limitation 12.1. Collection limitation
When the Client is being granted access to a protected resource When the Client is being granted access to a protected resource
skipping to change at page 19, line 47 skipping to change at page 19, line 51
Therefore, per-user Request Object URI should be avoided. Therefore, per-user Request Object URI should be avoided.
13. Acknowledgements 13. Acknowledgements
The following people contributed to the creation of this document in The following people contributed to the creation of this document in
the OAuth WG. (Affiliations at the time of the contribution are the OAuth WG. (Affiliations at the time of the contribution are
used.) used.)
Sergey Beryozkin, Brian Campbell (Ping Identity), Vladimir Dzhuvinov Sergey Beryozkin, Brian Campbell (Ping Identity), Vladimir Dzhuvinov
(Connect2id), Michael B. Jones (Microsoft), Torsten Lodderstedt (Connect2id), Michael B. Jones (Microsoft), Torsten Lodderstedt
(Deutsche Telecom) Jim Manico, Axel Nenker(Deutsche Telecom), Hannes (YES) Jim Manico, Axel Nenker(Deutsche Telecom), Hannes Tschofenig
Tschofenig (ARM), Kathleen Moriarty (as AD), and Steve Kent (as (ARM), Kathleen Moriarty (as AD), and Steve Kent (as SECDIR).
SECDIR).
The following people contributed to creating this document through The following people contributed to creating this document through
the OpenID Connect Core 1.0 [OpenID.Core]. the OpenID Connect Core 1.0 [OpenID.Core].
Brian Campbell (Ping Identity), George Fletcher (AOL), Ryo Itou Brian Campbell (Ping Identity), George Fletcher (AOL), Ryo Itou
(Mixi), Edmund Jay (Illumila), Michael B. Jones (Microsoft), Breno (Mixi), Edmund Jay (Illumila), Michael B. Jones (Microsoft), Breno
de Medeiros (Google), Hideki Nara (TACT), Justin Richer (MITRE). de Medeiros (Google), Hideki Nara (TACT), Justin Richer (MITRE).
In addition, the following people contributed to this and previous In addition, the following people contributed to this and previous
versions through the OAuth Working Group. versions through the OAuth Working Group.
Dirk Balfanz (Google), James H. Manger (Telstra), John Panzer Dirk Balfanz (Google), James H. Manger (Telstra), John Panzer
(Google), David Recordon (Facebook), Marius Scurtescu (Google), Luke (Google), David Recordon (Facebook), Marius Scurtescu (Google), Luke
Shepard (Facebook). Shepard (Facebook).
14. Revision History 14. Revision History
-14
o #71 Reiterate dynamic params are included.
o #70 Made clear that AS must return error.
o #69 Inconsistency of the need to sign.
o Fixed Mimetype.
o #67 Incosistence in requiring HTTPS in request uri.
o #66 Dropped ISO 29100 reference.
o #25 Removed Encrypt only option.
o #59 Same with #25.
-13 -13
o add TLS Security Consideration section o add TLS Security Consideration section
o replace RFC7525 reference with BCP195 o replace RFC7525 reference with BCP195
o moved front tag in FETT reference to fix XML structure o moved front tag in FETT reference to fix XML structure
o changes reference from SoK to FETT o changes reference from SoK to FETT
skipping to change at page 25, line 5 skipping to change at page 25, line 26
15. References 15. References
15.1. Normative References 15.1. Normative References
[BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre, [BCP195] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015. (DTLS)", BCP 195, RFC 7525, May 2015.
[ISO29100]
"ISO/IEC 29100 Information technology - Security
techniques - Privacy framework", December 2011,
<http://standards.iso.org/ittf/PubliclyAvailableStandards/
c045123_ISO_IEC_29100_2011.zip>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <http://www.rfc-editor.org/info/rfc6125>. 2011, <http://www.rfc-editor.org/info/rfc6125>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<http://www.rfc-editor.org/info/rfc6234>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012, RFC 6749, DOI 10.17487/RFC6749, October 2012,
<http://www.rfc-editor.org/info/rfc6749>. <http://www.rfc-editor.org/info/rfc6749>.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, Framework: Bearer Token Usage", RFC 6750,
DOI 10.17487/RFC6750, October 2012, DOI 10.17487/RFC6750, October 2012,
<http://www.rfc-editor.org/info/rfc6750>. <http://www.rfc-editor.org/info/rfc6750>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
skipping to change at page 27, line 18 skipping to change at page 27, line 32
Nomura Research Institute Nomura Research Institute
Otemachi Financial City Grand Cube, 1-9-2 Otemachi Otemachi Financial City Grand Cube, 1-9-2 Otemachi
Chiyoda-ku, Tokyo 100-0004 Chiyoda-ku, Tokyo 100-0004
Japan Japan
Phone: +81-3-5533-2111 Phone: +81-3-5533-2111
Email: n-sakimura@nri.co.jp Email: n-sakimura@nri.co.jp
URI: http://nat.sakimura.org/ URI: http://nat.sakimura.org/
John Bradley John Bradley
Ping Identity Yubico
Casilla 177, Sucursal Talagante Casilla 177, Sucursal Talagante
Talagante, RM Talagante, RM
Chile Chile
Phone: +1.202.630.5272 Phone: +1.202.630.5272
Email: ve7jtb@ve7jtb.com Email: ve7jtb@ve7jtb.com
URI: http://www.thread-safe.com/ URI: http://www.thread-safe.com/
 End of changes. 35 change blocks. 
89 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/