draft-ietf-oauth-mix-up-mitigation-00.txt   draft-ietf-oauth-mix-up-mitigation-01.txt 
OAuth Working Group M. Jones OAuth Working Group M. Jones
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track J. Bradley Intended status: Standards Track J. Bradley
Expires: September 19, 2016 Ping Identity Expires: January 7, 2017 Ping Identity
N. Sakimura N. Sakimura
NRI NRI
March 18, 2016 July 6, 2016
OAuth 2.0 Mix-Up Mitigation OAuth 2.0 Mix-Up Mitigation
draft-ietf-oauth-mix-up-mitigation-00 draft-ietf-oauth-mix-up-mitigation-01
Abstract Abstract
This specification defines an extension to The OAuth 2.0 This specification defines an extension to The OAuth 2.0
Authorization Framework that enables the authorization server to Authorization Framework that enables the authorization server to
dynamically provide the client using it with additional information dynamically provide the client using it with additional information
about the current protocol interaction that can be validated by the about the current protocol interaction that can be validated by the
client and that enables the client to dynamically provide the client and that enables the client to dynamically provide the
authorization server with additional information about the current authorization server with additional information about the current
protocol interaction that can be validated by the authorization protocol interaction that can be validated by the authorization
server. This additional information can be used by the client and server. This additional information can be used by the client and
the authorization server to prevent classes of attacks in which the the authorization server to prevent classes of attacks in which the
client might otherwise be tricked into using inconsistent sets of client might otherwise be tricked into using inconsistent sets of
metadata from multiple authorization servers, including potentially metadata from multiple authorization servers, including potentially
using a token endpoint that does not belong to the same authorization using a token endpoint that does not belong to the same authorization
server as the authorization endpoint used. Recent research server as the authorization endpoint used. Recent research
publications refer to these as "IdP Mix-Up" and "Malicious Endpoint" publications refer to these as "IdP Mix-Up" and "Malicious Endpoint"
attacks. attacks.
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 September 19, 2016. This Internet-Draft will expire on January 7, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 2, line 19 skipping to change at page 2, line 22
(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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 Notation and Conventions . . . . . . . . . . 4 1.1. Requirements Notation and Conventions . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. The OAuth Issuer . . . . . . . . . . . . . . . . . . . . . . . 4 2. The OAuth Issuer Identifier . . . . . . . . . . . . . . . . . 4
3. Mitigation Data Returned in Authorization Response . . . . . . 5 3. Mitigation Data Returned in Authorization Response . . . . . 5
3.1. Mitigation Data Returned in Authorization Response 3.1. Mitigation Data Returned in Authorization Response
Parameters . . . . . . . . . . . . . . . . . . . . . . . . 5 Parameters . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Example Authorization Response using Response 3.1.1. Example Authorization Response using Response
Parameters . . . . . . . . . . . . . . . . . . . . . . 5 Parameters . . . . . . . . . . . . . . . . . . . . . 5
3.2. Mitigation Data Returned in JWT . . . . . . . . . . . . . 6 3.2. Mitigation Data Returned in JWT . . . . . . . . . . . . . 6
3.2.1. Example Authorization Response using JWT . . . . . . . 6 3.2.1. Example Authorization Response using JWT . . . . . . 6
4. Validating the Authorization Response . . . . . . . . . . . . 7 4. Validating the Authorization Response . . . . . . . . . . . . 7
5. Mitigation Data Sent to the Token Endpoint . . . . . . . . . . 8 5. Mitigation Data Sent to the Token Endpoint . . . . . . . . . 8
5.1. Example Token Request . . . . . . . . . . . . . . . . . . 8 5.1. Example Token Request . . . . . . . . . . . . . . . . . . 8
6. Validating the Token Request . . . . . . . . . . . . . . . . . 9 6. Validating the Token Request . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7.1. IdP Mix-Up and Malicious Endpoint Attacks . . . . . . . . 9 7.1. IdP Mix-Up and Malicious Endpoint Attacks . . . . . . . . 9
7.2. Duplicate Information Attacks . . . . . . . . . . . . . . 9 7.2. Duplicate Information Attacks . . . . . . . . . . . . . . 9
7.3. Cut-and-Paste Attacks . . . . . . . . . . . . . . . . . . 10 7.3. Cut-and-Paste Attacks . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. OAuth Parameters Registration . . . . . . . . . . . . . . 11 8.1. OAuth Parameters Registration . . . . . . . . . . . . . . 11
8.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 11 8.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 13 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 13
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 13 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . 14
Appendix D. Document History . . . . . . . . . . . . . . . . . . 14 Appendix D. Document History . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
OAuth 2.0 [RFC6749] clients use multiple authorization server OAuth 2.0 [RFC6749] clients use multiple authorization server
endpoints when using some OAuth response types. For instance, when endpoints when using some OAuth response types. For instance, when
using the "code" response type, the client uses both the using the "code" response type, the client uses both the
authorization endpoint and the token endpoint. It is important that authorization endpoint and the token endpoint. It is important that
endpoints belonging to the same authorization server always be used endpoints belonging to the same authorization server always be used
together. Otherwise, information produced by one authorization together. Otherwise, information produced by one authorization
server could mistakenly be sent by the client to different server could mistakenly be sent by the client to different
skipping to change at page 3, line 42 skipping to change at page 3, line 42
This specification enables the authorization server to dynamically This specification enables the authorization server to dynamically
provide the client using it with additional information about the provide the client using it with additional information about the
current protocol interaction that can be validated by the client and current protocol interaction that can be validated by the client and
that enables the client to dynamically provide the authorization that enables the client to dynamically provide the authorization
server with additional information about the current protocol server with additional information about the current protocol
interaction that can be validated by the authorization server. This interaction that can be validated by the authorization server. This
enables them to abort interactions in which endpoints from multiple enables them to abort interactions in which endpoints from multiple
authorization servers would otherwise be used. authorization servers would otherwise be used.
The mitigation data provided by the authorization server to the The mitigation data provided by the authorization server to the
client is an issuer URL, which is used to identify the authorization client is an issuer identifier, which is used to identify the
server, and a client ID, which is used to verify that the response is authorization server, and a client ID, which is used to verify that
from the correct authorization server and is intended for this the response is from the correct authorization server and is intended
client. The issuer URL is defined in Section 2 of [OAuth.Discovery]. for this client. The issuer identifier is defined in Section 2 of
If supported by the authorization server, the issuer URL can also be [OAuth.Discovery]. If supported by the authorization server, the
used to obtain a consistent set of metadata describing the issuer identifier can also be used to obtain a consistent set of
authorization server configuration, as also described in metadata describing the authorization server configuration, as also
[OAuth.Discovery]. described in [OAuth.Discovery].
This mitigation data is returned to the client in the authorization This mitigation data is returned to the client in the authorization
response. The syntax for returning the mitigation data from the response. The syntax for returning the mitigation data from the
authorization server is dependent upon the OAuth response type being authorization server is dependent upon the OAuth response type being
used. The syntax used with the existing response types registered in used. The syntax used with the existing response types registered in
the IANA "OAuth Authorization Endpoint Response Types" registry the IANA "OAuth Authorization Endpoint Response Types" registry
[IANA.OAuth.Parameters] as of the time of this writing is defined by [IANA.OAuth.Parameters] as of the time of this writing is defined by
this specification. Two of these response types are defined by RFC this specification. Two of these response types are defined by RFC
6749 [RFC6749]; the rest are defined by [OAuth.Responses]. 6749 [RFC6749]; the rest are defined by [OAuth.Responses].
skipping to change at page 4, line 36 skipping to change at page 4, line 36
This specification uses the terms "Access Token", "Authorization This specification uses the terms "Access Token", "Authorization
Code", "Authorization Endpoint", "Authorization Grant", Code", "Authorization Endpoint", "Authorization Grant",
"Authorization Server", "Client", "Client Authentication", "Client "Authorization Server", "Client", "Client Authentication", "Client
Identifier", "Client Secret", "Grant Type", "Protected Resource", Identifier", "Client Secret", "Grant Type", "Protected Resource",
"Redirection URI", "Refresh Token", "Resource Owner", "Resource "Redirection URI", "Refresh Token", "Resource Owner", "Resource
Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0 Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0
[RFC6749], the terms "Claim Name", "Claim Value", and "JSON Web Token [RFC6749], the terms "Claim Name", "Claim Value", and "JSON Web Token
(JWT)" defined by JSON Web Token (JWT) [JWT]. (JWT)" defined by JSON Web Token (JWT) [JWT].
2. The OAuth Issuer 2. The OAuth Issuer Identifier
The OAuth issuer serves as a concrete identifier for the The OAuth issuer identifier serves as a concrete identifier for the
authorization server. As defined in [OAuth.Discovery], the OAuth authorization server. As defined in [OAuth.Discovery], the issuer
issuer is the URL of the authorization server's configuration identifier is a URL that uses the "https" scheme and has no query or
information location, which uses the "https" scheme and has no query fragment components. Also as specified there, this is the location
or fragment components. Also as specified there, when discovery is where ".well-known" RFC 5785 [RFC5785] resources containing
supported, the authorization server's metadata is retrieved as a JSON information about the authorization server are published. In
document [RFC7159] from a path derived from this URL. This metadata particular, when discovery is supported, the authorization server's
document contains a consistent set of metadata describing the metadata is retrieved as a JSON document [RFC7159] from a path
authorization server configuration. derived from this URL. This metadata document contains a consistent
set of metadata describing the authorization server configuration.
Implementations supporting this specification MAY also support Implementations supporting this specification MAY also support
discovery or they MAY simply use the issuer URL as a concrete discovery or they MAY simply use the issuer identifier as a concrete
identifier for the authorization server. This specification does not identifier for the authorization server. This specification does not
rely upon the authorization server publishing or the client rely upon the authorization server publishing or the client
retrieving a discovery metadata document. retrieving a discovery metadata document.
3. Mitigation Data Returned in Authorization Response 3. Mitigation Data Returned in Authorization Response
Mitigating the attacks relies on the authorization server returning Mitigating the attacks relies on the authorization server returning
additional data about the interaction and the client checking that additional data about the interaction and the client checking that
data. The mitigation data returned is the client ID and the issuer data. The mitigation data returned is the client ID and the issuer
URL. The syntax for returning the mitigation data from the identifier. The syntax for returning the mitigation data from the
authorization server is dependent upon the OAuth response type being authorization server is dependent upon the OAuth response type being
used. used.
3.1. Mitigation Data Returned in Authorization Response Parameters 3.1. Mitigation Data Returned in Authorization Response Parameters
Some OAuth response types do not already return the issuer URL and Some OAuth response types do not already return the issuer identifier
client ID in the authorization response. When this is the case, the and client ID in the authorization response. When this is the case,
mitigation data is returned as additional OAuth response parameters. the mitigation data is returned as additional OAuth response
parameters.
These new response parameters are defined for this purpose: These new response parameters are defined for this purpose:
client_id client_id
Client that this response is intended for. It MUST contain the Client that this response is intended for. It MUST contain the
OAuth 2.0 client ID of the client as its value. OAuth 2.0 client ID of the client as its value.
iss iss
Issuer URL for the authorization server issuing the response. The Issuer identifier for the authorization server issuing the
"iss" value is a case-sensitive URL using the "https" scheme that response. The "iss" value is a case-sensitive URL using the
contains scheme, host, and optionally, port number and path "https" scheme that contains scheme, host, and optionally, port
components and no query or fragment components. number and path components and no query or fragment components.
As of the time of this writing, these are the existing response types As of the time of this writing, these are the existing response types
that are registered in the IANA "OAuth Authorization Endpoint that are registered in the IANA "OAuth Authorization Endpoint
Response Types" registry [IANA.OAuth.Parameters] that do not already Response Types" registry [IANA.OAuth.Parameters] that do not already
return the issuer URL and client ID in the authorization response: return the issuer identifier and client ID in the authorization
"code", "code token", "none", and "token". Therefore, the client ID response: "code", "code token", "none", and "token". Therefore, the
and issuer are returned using the new authorization response client ID and issuer are returned using the new authorization
parameters when using these response types. To avoid duplication, as response parameters when using these response types. To avoid
discussed in Section 7.2, it is NOT RECOMMENDED to also return them duplication, as discussed in Section 7.2, it is NOT RECOMMENDED to
in this manner when the response type already returns these values in also return them in this manner when the response type already
the authorization response. returns these values in the authorization response.
3.1.1. Example Authorization Response using Response Parameters 3.1.1. Example Authorization Response using Response Parameters
The following example authorization response is to a request that The following example authorization response is to a request that
used the "code" response type. It uses the "iss" and "client_id" used the "code" response type. It uses the "iss" and "client_id"
response parameters to return the mitigation information to the response parameters to return the mitigation information to the
client. client.
The example successful authorization response follows (with line The example successful authorization response follows (with line
breaks within lines for display purposes only): breaks within lines for display purposes only):
skipping to change at page 6, line 20 skipping to change at page 6, line 20
code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk
&state=nrsz6AnHzPSVVBYRVTXV6ZTXQeg_eih7hdpewHNXmZ8 &state=nrsz6AnHzPSVVBYRVTXV6ZTXQeg_eih7hdpewHNXmZ8
&iss=https://server.example.com &iss=https://server.example.com
&client_id=5d9e8a36-569d-4c40-8d6b-6e279ac1c5f1 &client_id=5d9e8a36-569d-4c40-8d6b-6e279ac1c5f1
3.2. Mitigation Data Returned in JWT 3.2. Mitigation Data Returned in JWT
As of the time of this writing, these are the existing response types As of the time of this writing, these are the existing response types
that are registered in the IANA "OAuth Authorization Endpoint that are registered in the IANA "OAuth Authorization Endpoint
Response Types" registry [IANA.OAuth.Parameters] that already return Response Types" registry [IANA.OAuth.Parameters] that already return
the issuer URL and client ID in the authorization response: the issuer identifier and client ID in the authorization response:
"code id_token", "code id_token token", "id_token", and "code id_token", "code id_token token", "id_token", and
"id_token token". All of these return these values as the "iss" "id_token token". All of these return these values as the "iss"
(issuer) claim value and as an "aud" (audience) claim value in a (issuer) claim value and as an "aud" (audience) claim value in a
signed ID Token, which is a JSON Web Token [JWT], as specified in signed ID Token, which is a JSON Web Token [JWT], as specified in
"OpenID Connect Core 1.0" [OpenID.Core]. When using these response "OpenID Connect Core 1.0" [OpenID.Core]. When using these response
types, the client MUST use the client ID and issuer values returned types, the client MUST use the client ID and issuer values returned
in the ID Token for validating the mitigation data. in the ID Token for validating the mitigation data.
3.2.1. Example Authorization Response using JWT 3.2.1. Example Authorization Response using JWT
skipping to change at page 7, line 43 skipping to change at page 7, line 43
"nonce": "n-0S6_WzA2Mj", "nonce": "n-0S6_WzA2Mj",
"exp": 1311281970, "exp": 1311281970,
"iat": 1311280970, "iat": 1311280970,
"at_hash": "77QmUPtjPfzWtF2AnpK9RQ" "at_hash": "77QmUPtjPfzWtF2AnpK9RQ"
} }
4. Validating the Authorization Response 4. Validating the Authorization Response
Upon receiving the mitigation data in an authorization response, the Upon receiving the mitigation data in an authorization response, the
client MUST validate that the response was intended for it and that client MUST validate that the response was intended for it and that
the authorization server configuration information that it obtained the authorization server metadata that it obtained at client
at client registration time is consistent with the authorization registration time is consistent with the authorization server
server configuration information contained in the metadata referenced metadata contained in the metadata referenced by the issuer
by the issuer URL. identifier.
The client MUST validate the authorization server configuration as The client MUST validate the authorization server configuration as
follows: follows:
1. Compare the issuer URL for the authorization server that the 1. Compare the issuer identifier for the authorization server that
client received when it registered at the authorization server the client received when it registered at the authorization
that it made the request to with the issuer value returned in the server that it made the request to with the issuer value returned
"iss" response parameter or the "iss" claim in the ID Token, in the "iss" response parameter or the "iss" claim in the ID
depending upon the response type being used. If they do not Token, depending upon the response type being used. If they do
exactly match, the client MUST NOT proceed with the not exactly match, the client MUST NOT proceed with the
authorization. authorization.
2. Verify that the response is intended for this client by 2. Verify that the response is intended for this client by
confirming that the client's client identifier for the confirming that the client's client identifier for the
authorization server the request was made to matches the value of authorization server the request was made to matches the value of
the "client_id" response parameter or that the client's client the "client_id" response parameter or that the client's client
identifier is an audience value of the ID Token, depending upon identifier is an audience value of the ID Token, depending upon
the response type being used. If not, the client MUST NOT the response type being used. If not, the client MUST NOT
proceed with the authorization. proceed with the authorization.
skipping to change at page 11, line 47 skipping to change at page 11, line 47
[IANA.OAuth.Parameters] [IANA.OAuth.Parameters]
IANA, "OAuth Parameters", IANA, "OAuth Parameters",
<http://www.iana.org/assignments/oauth-parameters>. <http://www.iana.org/assignments/oauth-parameters>.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [JWT] 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://tools.ietf.org/html/rfc7519>. <http://tools.ietf.org/html/rfc7519>.
[OAuth.Discovery] [OAuth.Discovery]
Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Discovery", draft-ietf-oauth-discovery-01 (work in Discovery", draft-ietf-oauth-discovery-02 (work in
progress), February 2016, progress), March 2016, <http://tools.ietf.org/html/
<http://tools.ietf.org/html/ draft-ietf-oauth-discovery-02>.
draft-ietf-oauth-discovery-01>.
[OAuth.Responses] [OAuth.Responses]
de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M.
Jones, "OAuth 2.0 Multiple Response Type Encoding Jones, "OAuth 2.0 Multiple Response Type Encoding
Practices", February 2014, <http://openid.net/specs/ Practices", February 2014, <http://openid.net/specs/
oauth-v2-multiple-response-types-1_0.html>. oauth-v2-multiple-response-types-1_0.html>.
[OpenID.Core] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and
C. Mortimore, "OpenID Connect Core 1.0", November 2014, C. Mortimore, "OpenID Connect Core 1.0", November 2014,
<http://openid.net/specs/openid-connect-core-1_0.html>. <http://openid.net/specs/openid-connect-core-1_0.html>.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
November 2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010,
<http://www.rfc-editor.org/info/rfc5785>.
[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>.
[RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0
Threat Model and Security Considerations", RFC 6819, Threat Model and Security Considerations", RFC 6819,
DOI 10.17487/RFC6819, January 2013, DOI 10.17487/RFC6819, January 2013,
<http://www.rfc-editor.org/info/rfc6819>. <http://www.rfc-editor.org/info/rfc6819>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
March 2014, <http://www.rfc-editor.org/info/rfc7159>. 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection",
RFC 7662, DOI 10.17487/RFC7662, October 2015, RFC 7662, DOI 10.17487/RFC7662, October 2015,
<http://www.rfc-editor.org/info/rfc7662>. <http://www.rfc-editor.org/info/rfc7662>.
9.2. Informative References 9.2. Informative References
[I-D.bradley-oauth-jwt-encoded-state]
Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding
claims in the OAuth 2 state parameter using a JWT",
draft-bradley-oauth-jwt-encoded-state-05 (work in
progress), December 2015.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<http://www.rfc-editor.org/info/rfc7591>.
[arXiv.1508.04324v2] [arXiv.1508.04324v2]
Mladenov, V., Mainka, C., and J. Schwenk, "On the security Mladenov, V., Mainka, C., and J. Schwenk, "On the security
of modern Single Sign-On Protocols: Second-Order of modern Single Sign-On Protocols: Second-Order
Vulnerabilities in OpenID Connect", arXiv 1508.04324v2, Vulnerabilities in OpenID Connect", arXiv 1508.04324v2,
January 2016, <http://arxiv.org/abs/1508.04324v2/>. January 2016, <http://arxiv.org/abs/1508.04324v2/>.
[arXiv.1601.01229v2] [arXiv.1601.01229v2]
Fett, D., Kuesters, R., and G. Schmitz, "A Comprehensive Fett, D., Kuesters, R., and G. Schmitz, "A Comprehensive
Formal Security Analysis of OAuth 2.0", Formal Security Analysis of OAuth 2.0",
arXiv 1601.01229v2, January 2016, arXiv 1601.01229v2, January 2016,
<http://arxiv.org/abs/1601.01229v2/>. <http://arxiv.org/abs/1601.01229v2/>.
[I-D.bradley-oauth-jwt-encoded-state]
Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding
claims in the OAuth 2 state parameter using a JWT", draft-
bradley-oauth-jwt-encoded-state-05 (work in progress),
December 2015.
[RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
RFC 7591, DOI 10.17487/RFC7591, July 2015,
<http://www.rfc-editor.org/info/rfc7591>.
Appendix A. Implementation Notes Appendix A. Implementation Notes
The authorization server can compare the two state values either by The authorization server can compare the two state values either by
recording the complete state value between the authorization request recording the complete state value between the authorization request
and the token request, possibly in the same data structure in which and the token request, possibly in the same data structure in which
the authorization code issued was recorded, or by recording only a the authorization code issued was recorded, or by recording only a
cryptographic hash of the state value, possibly resulting in cryptographic hash of the state value, possibly resulting in
substantial size savings. substantial size savings.
Appendix B. Acknowledgements Appendix B. Acknowledgements
skipping to change at page 14, line 9 skipping to change at page 14, line 15
Appendix C. Open Issues Appendix C. Open Issues
o We need to do a security analysis of the cut-and-paste attacks o We need to do a security analysis of the cut-and-paste attacks
that may be enabled when mitigation information is returned to the that may be enabled when mitigation information is returned to the
client using individual authorization response parameters. client using individual authorization response parameters.
Appendix D. Document History Appendix D. Document History
[[ to be removed by the RFC Editor before publication as an RFC ]] [[ to be removed by the RFC Editor before publication as an RFC ]]
-01
o Changed terms "issuer URL" and "configuration information
location" to "issuer identifier" so that consistent terminology is
used for this.
-00 -00
o Created the initial working group draft from o Created the initial working group draft from draft-jones-oauth-
draft-jones-oauth-mix-up-mitigation-01 with no normative changes mix-up-mitigation-01 with no normative changes and adding Nat
and adding Nat Sakimura as an editor. Sakimura as an editor.
Authors' Addresses Authors' Addresses
Michael B. Jones Michael B. Jones
Microsoft Microsoft
Email: mbj@microsoft.com Email: mbj@microsoft.com
URI: http://self-issued.info/ URI: http://self-issued.info/
John Bradley John Bradley
 End of changes. 28 change blocks. 
102 lines changed or deleted 115 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/