draft-ietf-oauth-jwsreq-14.txt   draft-ietf-oauth-jwsreq-15.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: January 22, 2018 Yubico Expires: January 22, 2018 Yubico
July 21, 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-14 draft-ietf-oauth-jwsreq-15
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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . 9
5.2.1. URI Referencing the Request Object . . . . . . . . . 11 5.2.1. URI Referencing the Request Object . . . . . . . . . 10
5.2.2. Request using the "request_uri" Request Parameter . . 12 5.2.2. Request using the "request_uri" Request Parameter . . 11
5.2.3. Authorization Server Fetches Request Object . . . . . 12 5.2.3. Authorization Server Fetches Request Object . . . . . 11
6. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 13 6. Validating JWT-Based Requests . . . . . . . . . . . . . . . . 12
6.1. Encrypted Request Object . . . . . . . . . . . . . . . . 13 6.1. Encrypted Request Object . . . . . . . . . . . . . . . . 12
6.2. JWS Signed Request Object . . . . . . . . . . . . . . . . 13 6.2. JWS Signed Request Object . . . . . . . . . . . . . . . . 12
6.3. Request Parameter Assembly and Validation . . . . . . . . 14 6.3. Request Parameter Assembly and Validation . . . . . . . . 13
7. Authorization Server Response . . . . . . . . . . . . . . . . 14 7. Authorization Server Response . . . . . . . . . . . . . . . . 13
8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 14 8. TLS Requirements . . . . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10.1. Choice of Algorithms . . . . . . . . . . . . . . . . . . 15 10.1. Choice of Algorithms . . . . . . . . . . . . . . . . . . 14
10.2. Request Source Authentication . . . . . . . . . . . . . 15 10.2. Request Source Authentication . . . . . . . . . . . . . 14
10.3. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 16 10.3. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 15
10.4. Risks Associated with request_uri . . . . . . . . . . . 17 10.4. Risks Associated with request_uri . . . . . . . . . . . 16
10.4.1. DDoS Attack on the Authorization Server . . . . . . 17 10.4.1. DDoS Attack on the Authorization Server . . . . . . 16
10.4.2. Request URI Rewrite . . . . . . . . . . . . . . . . 17 10.4.2. Request URI Rewrite . . . . . . . . . . . . . . . . 16
11. TLS security considerations . . . . . . . . . . . . . . . . . 18 11. TLS security considerations . . . . . . . . . . . . . . . . . 17
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
12.1. Collection limitation . . . . . . . . . . . . . . . . . 18 12.1. Collection limitation . . . . . . . . . . . . . . . . . 17
12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 19 12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 18
12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 19 12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 18
12.2.2. Tracking using Request Object URI . . . . . . . . . 19 12.2.2. Tracking using Request Object URI . . . . . . . . . 18
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
14. Revision History . . . . . . . . . . . . . . . . . . . . . . 20 14. Revision History . . . . . . . . . . . . . . . . . . . . . . 19
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
15.1. Normative References . . . . . . . . . . . . . . . . . . 25 15.1. Normative References . . . . . . . . . . . . . . . . . . 24
15.2. Informative References . . . . . . . . . . . . . . . . . 26 15.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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",
and "redirect_uri" are encoded in the URI of the request: and "redirect_uri" are encoded in the URI of the request:
skipping to change at page 5, line 23 skipping to change at page 5, line 23
legitimacy of the request when authorizing it. In some cases, legitimacy of the request when authorizing it. In some cases,
it may even be desirable to skip the authorization dialogue it may even be desirable to skip the authorization dialogue
under such circumstances. 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. When the client does not want to do the crypto. The
that 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.
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
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 so that the Client is authenticated and the channel is TLS Client so that the Client is authenticated and the channel is TLS
protected. 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",
skipping to change at page 11, line 6 skipping to change at page 10, line 19
restriction is typically either 512 or 1024 ASCII characters. restriction is typically either 512 or 1024 ASCII characters.
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 "request_uri" value MUST be either URN as defined in
as defined in 2.7.2 of RFC7230 [RFC7230]. The "request_uri" value RFC8141 [RFC8141] or "https" URI, as defined in 2.7.2 of RFC7230
MUST be reachable by the Authorization Server, and SHOULD be [RFC7230] . The "request_uri" value MUST be reachable by the
reachable by the Client. Authorization Server.
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 41 skipping to change at page 11, line 5
0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K 0GxFbuPbj96tVuj11pTnmFCUR6IEOXKYr7iGOCRB3btfJhM0_AKQUfqKnRlrRscc8K
ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG ol-cSLWoYE9l5QqholImzjT_cMnNIznW9E7CDyWXTsO70xnB4SkG6pXfLSjLLlxmPG
iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw iyon_-Te111V8uE83IlzCYIb_NMXvtTIVc1jpspnTSD7xMbpL-2QgwUsAlMGzw
5.2.1. URI 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 URI the Authorization Server can access. Such facility remotely at a URI the Authorization Server can access. Such facility
may be provided by the authorization server or a third party. For may be provided by the authorization server or a third party. For
example, the authorization server may provide a URL to which the example, the authorization server may provide a URL to which the
client POSTs the request object and obtains the Requiest URI. The client POSTs the request object and obtains the Requiest URI. This
URL MUST be a HTTPS URL if it is not under the control of the URI is the Request Object URI, "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.
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):
skipping to change at page 20, line 21 skipping to change at page 19, line 21
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
-15
o Removed further duplication
-14 -14
o #71 Reiterate dynamic params are included. o #71 Reiterate dynamic params are included.
o #70 Made clear that AS must return error. o #70 Made clear that AS must return error.
o #69 Inconsistency of the need to sign. o #69 Inconsistency of the need to sign.
o Fixed Mimetype. o Fixed Mimetype.
skipping to change at page 26, line 41 skipping to change at page 25, line 46
<http://www.rfc-editor.org/info/rfc7516>. <http://www.rfc-editor.org/info/rfc7516>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015, DOI 10.17487/RFC7518, May 2015,
<http://www.rfc-editor.org/info/rfc7518>. <http://www.rfc-editor.org/info/rfc7518>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>. <http://www.rfc-editor.org/info/rfc7519>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<http://www.rfc-editor.org/info/rfc8141>.
15.2. Informative References 15.2. Informative References
[BASIN] Basin, D., Cremers, C., and S. Meier, "Provably Repairing [BASIN] Basin, D., Cremers, C., and S. Meier, "Provably Repairing
the ISO/IEC 9798 Standard for Entity Authentication", the ISO/IEC 9798 Standard for Entity Authentication",
Journal of Computer Security - Security and Trust Journal of Computer Security - Security and Trust
Principles Volume 21 Issue 6, Pages 817-846, November Principles Volume 21 Issue 6, Pages 817-846, November
2013, 2013,
<https://www.cs.ox.ac.uk/people/cas.cremers/downloads/ <https://www.cs.ox.ac.uk/people/cas.cremers/downloads/
papers/BCM2012-iso9798.pdf>. papers/BCM2012-iso9798.pdf>.
 End of changes. 9 change blocks. 
48 lines changed or deleted 46 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/