draft-ietf-oauth-jwsreq-10.txt   draft-ietf-oauth-jwsreq-11.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: August 3, 2017 Ping Identity Expires: August 3, 2017 Ping Identity
January 30, 2017 January 30, 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-10 draft-ietf-oauth-jwsreq-11
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 3, line 5 skipping to change at page 3, line 5
10.2. Choice of Parameters to include in the Request Object . 15 10.2. Choice of Parameters to include in the Request Object . 15
10.3. Request Source Authentication . . . . . . . . . . . . . 16 10.3. Request Source Authentication . . . . . . . . . . . . . 16
10.4. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 16 10.4. Explicit Endpoints . . . . . . . . . . . . . . . . . . . 16
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
11.1. Collection limitation . . . . . . . . . . . . . . . . . 17 11.1. Collection limitation . . . . . . . . . . . . . . . . . 17
11.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 18 11.2. Disclosure Limitation . . . . . . . . . . . . . . . . . 18
11.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 18 11.2.1. Request Disclosure . . . . . . . . . . . . . . . . . 18
11.2.2. Tracking using Request Object URI . . . . . . . . . 18 11.2.2. Tracking using Request Object URI . . . . . . . . . 18
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
13. Revision History . . . . . . . . . . . . . . . . . . . . . . 19 13. Revision History . . . . . . . . . . . . . . . . . . . . . . 19
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
14.1. Normative References . . . . . . . . . . . . . . . . . . 21 14.1. Normative References . . . . . . . . . . . . . . . . . . 22
14.2. Informative References . . . . . . . . . . . . . . . . . 23 14.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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 typically sent through user agents such parameter serialization and typically sent through user agents such
as web browsers. 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 9, line 10 skipping to change at page 9, line 10
The client constructs the authorization request URI by adding one of The client constructs the authorization request URI by adding one of
the following parameters but not both to the query component of the the following parameters but not both to the query component of the
authorization endpoint URI using the "application/x-www-form- authorization endpoint URI using the "application/x-www-form-
urlencoded" format: urlencoded" format:
request The Request Object (Section 2.1) that holds authorization request The Request Object (Section 2.1) that holds authorization
request parameters stated in section 4 of OAuth 2.0 [RFC6749]. request parameters stated in section 4 of OAuth 2.0 [RFC6749].
request_uri The absolute URL that points to the Request Object request_uri The absolute URL that points to the Request Object
(Section 2.1) that holds authorization request parameters stated (Section 2.1) that holds authorization request parameters stated
in the section 4 of OAuth 2.0 [RFC6749]. in section 4 of OAuth 2.0 [RFC6749].
The client directs the resource owner to the constructed URI using an The client directs the resource owner to the constructed URI using an
HTTP redirection response, or by other means available to it via the HTTP redirection response, or by other means available to it via the
user-agent. user-agent.
For example, the client directs the end user's user-agent to make the For example, the client directs the end user's user-agent to make the
following HTTPS request: following HTTPS request:
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 either The authorization request object MUST be either
(a) JWS signed; or (a) JWS signed; or
(b) JWE encrypted (when symmetric keys are bing used); or (b) JWE encrypted (when symmetric keys are being used); or
(c) JWS signed and JWE encrypted. (c) JWS signed and JWE encrypted.
When the Request Object is used, the OAuth 2.0 request parameter When the Request Object is used, the OAuth 2.0 request parameter
values contained in the JWS Signed and/or JWE Encrypted JWT supersede values contained in the JWS Signed and/or JWE Encrypted JWT supersede
those passed using the OAuth 2.0 request syntax. Parameters MAY also those passed using the OAuth 2.0 request syntax. Parameters MAY also
be passed using the OAuth 2.0 request syntax even when a Request be passed using the OAuth 2.0 request syntax even when a Request
Object is used in the cases such as (a) to achieve backward Object is used in the cases such as (a) to achieve backward
compatibility with [RFC6749] or (b) to enable a cached, pre-signed compatibility with [RFC6749] or (b) to enable a cached, pre-signed
(and possibly pre-encrypted) Request Object value to be used (and possibly pre-encrypted) Request Object value to be used
skipping to change at page 15, line 48 skipping to change at page 15, line 48
so that the entire request is integrity protected. so that the entire request is integrity protected.
This means that the request object is going to be prepared fresh each This means that the request object is going to be prepared fresh each
time an authorization request is made and caching cannot be used. It time an authorization request is made and caching cannot be used. It
has a performance disadvantage, but where such disadvantage is has a performance disadvantage, but where such disadvantage is
permissible, it should be considered. permissible, it should be considered.
Unless the server and the client have agreed prior to the Unless the server and the client have agreed prior to the
authorization request to use the non-protected parameters, the authorization request to use the non-protected parameters, the
authorization server SHOULD reject a request that is not fully authorization server SHOULD reject a request that is not fully
integrity protected and source authenticated. Note that the such integrity protected and source authenticated. Note that such
agreement needs to be done in a secure fashion. For example, the agreement needs to be done in a secure fashion. For example, the
developers from the server side and the client side can have a face developers from the server side and the client side can have a face
to face meeting to come to such an agreement. to face meeting to come to such an agreement.
10.3. Request Source Authentication 10.3. Request Source Authentication
The source of the Authorization Request MUST always be verified. The source of the Authorization Request MUST always be verified.
There are several ways to do it in this specification. There are several ways to do it in this specification.
(a) Verifying the JWS Signature of the Request Object. (a) Verifying the JWS Signature of the Request Object.
skipping to change at page 17, line 10 skipping to change at page 17, line 10
(b) Authorization Endpoint ("authorization_endpoint"); (b) Authorization Endpoint ("authorization_endpoint");
(c) Redirection URI ("redirect_uri"); and (c) Redirection URI ("redirect_uri"); and
(d) Token Endpoint ("token_endpoint"). (d) Token Endpoint ("token_endpoint").
While Redirection URI is included, others are not included in the While Redirection URI is included, others are not included in the
Authorization Request Object. It is probably a good idea to include Authorization Request Object. It is probably a good idea to include
these in it to reduce the attack surface. An extension specification these in it to reduce the attack surface. An extension specification
should be created as a preventive measure to address potential should be created as a preventive measure to address potential
vulnerabilities that has not yet been identified. vulnerabilities that have not yet been identified.
11. Privacy Considerations 11. 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. ISO/IEC 29100
[ISO29100] is a freely accessible International Standard and its [ISO29100] is a freely accessible International Standard and its
Privacy Principles are good to follow. Privacy Principles are good to follow.
While ISO/IEC 29100 [ISO29100] is a high-level document that gives While ISO/IEC 29100 [ISO29100] is a high-level document that gives
skipping to change at page 18, line 27 skipping to change at page 18, line 27
This specification allows extension parameters. These may include This specification allows extension parameters. These may include
potentially sensitive information. Since URI query parameter may potentially sensitive information. Since URI query parameter may
leak through various means but most notably through referrer and leak through various means but most notably through referrer and
browser history, if the authorization request contains a potentially browser history, if the authorization request contains a potentially
sensitive parameter, the Client SHOULD JWE [RFC7516] encrypt the sensitive parameter, the Client SHOULD JWE [RFC7516] encrypt the
request object. request object.
Where Request Object URI method is being used, if the request object Where Request Object URI method is being used, if the request object
contains personally identifiable or sensitive information, the contains personally identifiable or sensitive information, the
"request_uri" SHOULD be used only once, have short validity period, "request_uri" SHOULD be used only once, have a short validity period,
and MUST have large enough entropy deemed necessary with applicable and MUST have large enough entropy deemed necessary with applicable
security policy unless the Request Object itself is JWE [RFC7516] security policy unless the Request Object itself is JWE [RFC7516]
Encrypted. The adequate shortness of the validity and the entropy of Encrypted. The adequate shortness of the validity and the entropy of
the Request Object URI depends on the risk calculation based on the the Request Object URI depends on the risk calculation based on the
value of the resource being protected. A general guidance for the value of the resource being protected. A general guidance for the
validity time would be less than a minute and the Request Object URI validity time would be less than a minute and the Request Object URI
is to include a cryptographic random value of 128bit or more at the is to include a cryptographic random value of 128bit or more at the
time of the writing of this specification. time of the writing of this specification.
11.2.2. Tracking using Request Object URI 11.2.2. Tracking using Request Object URI
skipping to change at page 19, line 33 skipping to change at page 19, line 33
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).
13. Revision History 13. Revision History
-11
o s/bing/being/
o Added history for -10
-10 -10
o Minor Editorial Nits. o #20: KM1 -- some wording that is awkward in the TLS section.
o Section 10.4 added. o #21: KM2 - the additional attacks against OAuth 2.0 should also
have a pointer
o #22: KM3 -- Nit: in the first line of 10.4:
o #23: KM4 -- Mention RFC6973 in Section 11 in addition to ISO 29100
o #24: SECDIR review: Section 4 -- Confusing requirements for
sign+encrypt
o #25: SECDIR review: Section 6 -- authentication and integrity need
not be provided if the requestor encrypts the token?
o #26: SECDIR Review: Section 10 -- why no reference for JWS
algorithms?
o #27: SECDIR Review: Section 10.2 - how to do the agreement between
client and server "a priori"?
o #28: SECDIR Review: Section 10.3 - Indication on "large entropy"
and "short lifetime" should be indicated
o #29: SECDIR Review: Section 10.3 - Typo
o #30: SECDIR Review: Section 10.4 - typos and missing articles
o #31: SECDIR Review: Section 10.4 - Clearer statement on the lack
of endpoint identifiers needed
o #32: SECDIR Review: Section 11 - ISO29100 needs to be moved to
normative reference
o #33: SECDIR Review: Section 11 - Better English and Entropy
language needed
o #34: Section 4: Typo
o #35: More Acknowledgment
o #36: DP - More precise qualification on Encryption needed.
-09 -09
o Minor Editorial Nits. o Minor Editorial Nits.
o Section 10.4 added. o Section 10.4 added.
o Explicit reference to Security consideration (10.2) added in o Explicit reference to Security consideration (10.2) added in
section 5 and section 5.2. section 5 and section 5.2.
o , (add yourself) removed from the acknowledgement. o , (add yourself) removed from the acknowledgment.
-08 -08
o Applied changes proposed by Hannes on 2016-06-29 on IETF OAuth o Applied changes proposed by Hannes on 2016-06-29 on IETF OAuth
list recorded as https://bitbucket.org/Nat/oauth-jwsreq/ list recorded as https://bitbucket.org/Nat/oauth-jwsreq/
issues/12/. issues/12/.
o TLS requirements added. o TLS requirements added.
o Security Consideration reinforced. o Security Consideration reinforced.
o Privacy Consideration added. o Privacy Consideration added.
skipping to change at page 20, line 30 skipping to change at page 21, line 27
o Clarified sig and enc methods. o Clarified sig and enc methods.
o Better English. o Better English.
o Removed claims from one of the example. o Removed claims from one of the example.
o Re-worded the URI construction. o Re-worded the URI construction.
o Changed the example to use request instead of request_uri. o Changed the example to use request instead of request_uri.
o Clarified that Request Object parameters takes precedence o Clarified that Request Object parameters take precedence
regardless of request or request_uri parameters were used. regardless of request or request_uri parameters were used.
o Generalized the language in 4.2.1 to convey the intent more o Generalized the language in 4.2.1 to convey the intent more
clearly. clearly.
o Changed "Server" to "Authorization Server" as a clarification. o Changed "Server" to "Authorization Server" as a clarification.
o Stopped talking about request_object_signing_alg. o Stopped talking about request_object_signing_alg.
o IANA considerations now reflect the current status. o IANA considerations now reflect the current status.
 End of changes. 13 change blocks. 
14 lines changed or deleted 60 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/