draft-ietf-oauth-jwsreq-16.txt   draft-ietf-oauth-jwsreq-17.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 8, 2018 Yubico Expires: April 24, 2019 Yubico
April 6, 2018 October 21, 2018
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-16 draft-ietf-oauth-jwsreq-17
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 1, line 47 skipping to change at page 1, line 47
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 8, 2018. This Internet-Draft will expire on April 24, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 3, line 11 skipping to change at page 3, line 11
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
12.1. Collection limitation . . . . . . . . . . . . . . . . . 17 12.1. Collection limitation . . . . . . . . . . . . . . . . . 17
12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 18 12.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 18
12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 18 12.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 18
12.2.2. Tracking using Request Object URI . . . . . . . . . 18 12.2.2. Tracking using Request Object URI . . . . . . . . . 18
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
14. Revision History . . . . . . . . . . . . . . . . . . . . . . 19 14. Revision History . . . . . . . . . . . . . . . . . . . . . . 19
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
15.1. Normative References . . . . . . . . . . . . . . . . . . 24 15.1. Normative References . . . . . . . . . . . . . . . . . . 24
15.2. Informative References . . . . . . . . . . . . . . . . . 26 15.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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",
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 6, line 26 skipping to change at page 6, line 26
JWT JSON Web Token JWT JSON Web Token
JWS JSON Web Signature JWS JSON Web Signature
JWE JSON Web Encryption JWE JSON Web Encryption
URI Uniform Resource Identifier URI Uniform Resource Identifier
URL Uniform Resource Locator URL Uniform Resource Locator
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 MUST request parameters for an OAuth 2.0 authorization request. It MUST
contains all the 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 Request Objects are handled across domains as JSON strings. Since Request Objects are handled across domains
and potentially outside of a closed ecosystem, per section 8.1 of and potentially outside of a closed ecosystem, per section 8.1 of
[RFC8259], these JSON strings MUST be encoded using UTF-8 [RFC3629]. [RFC8259], these JSON strings MUST be encoded using UTF-8 [RFC3629].
skipping to change at page 16, line 23 skipping to change at page 16, line 23
In [RFC6749], while Redirection URI is included, others are not In [RFC6749], while Redirection URI is included, others are not
included in the Authorization Request. As the result, the same included in the Authorization Request. As the result, the same
applies to Authorization Request Object. applies to Authorization Request Object.
The lack of the link among those endpoints are sited as the cause of The lack of the link among those endpoints are sited as the cause of
Cross-Phase Attacks introduced in [FETT]. An extension specification Cross-Phase Attacks introduced in [FETT]. An extension specification
should be created as a measure to address the risk. should be created as a measure to address the risk.
10.4. Risks Associated with request_uri 10.4. Risks Associated with request_uri
The introdcution of "redirect_uri" introduces several attack The introduction of "request_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 Similarly, a malicious client can specify the "request_uri" value
that itself points to an authorization request URI that uses that itself points to an authorization request URI that uses
"request_uri" to cause the recursive lookup. "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/
jose" (c) implement a time-out for obtaining the content of jwt" (c) implement a time-out for obtaining the content of
"request_uri", and (d) do not perform recursive GET on the "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.
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 jwt" (c) implement a time-out for obtaining the content of
"request_uri". "request_uri".
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
skipping to change at page 19, line 29 skipping to change at page 19, line 29
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
Note to the RFC Editor: Please remove this section from the final Note to the RFC Editor: Please remove this section from the final
RFC. RFC.
-17
o #78 Typos in content-type
-16 -16
o Treated remaining Ben Campbell comments. o Treated remaining Ben Campbell comments.
-15 -15
o Removed further duplication o Removed further duplication
-14 -14
 End of changes. 9 change blocks. 
10 lines changed or deleted 12 lines changed or added

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