idnits 2.17.1 draft-ietf-oauth-mix-up-mitigation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 18, 2016) is 2961 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3629' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC7662' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'RFC7591' is defined on line 541, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6819 ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) == Outdated reference: A later version (-09) exists of draft-bradley-oauth-jwt-encoded-state-05 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group M. Jones 3 Internet-Draft Microsoft 4 Intended status: Standards Track J. Bradley 5 Expires: September 19, 2016 Ping Identity 6 N. Sakimura 7 NRI 8 March 18, 2016 10 OAuth 2.0 Mix-Up Mitigation 11 draft-ietf-oauth-mix-up-mitigation-00 13 Abstract 15 This specification defines an extension to The OAuth 2.0 16 Authorization Framework that enables the authorization server to 17 dynamically provide the client using it with additional information 18 about the current protocol interaction that can be validated by the 19 client and that enables the client to dynamically provide the 20 authorization server with additional information about the current 21 protocol interaction that can be validated by the authorization 22 server. This additional information can be used by the client and 23 the authorization server to prevent classes of attacks in which the 24 client might otherwise be tricked into using inconsistent sets of 25 metadata from multiple authorization servers, including potentially 26 using a token endpoint that does not belong to the same authorization 27 server as the authorization endpoint used. Recent research 28 publications refer to these as "IdP Mix-Up" and "Malicious Endpoint" 29 attacks. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on September 19, 2016. 48 Copyright Notice 49 Copyright (c) 2016 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Notation and Conventions . . . . . . . . . . 4 66 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. The OAuth Issuer . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Mitigation Data Returned in Authorization Response . . . . . . 5 69 3.1. Mitigation Data Returned in Authorization Response 70 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1.1. Example Authorization Response using Response 72 Parameters . . . . . . . . . . . . . . . . . . . . . . 5 73 3.2. Mitigation Data Returned in JWT . . . . . . . . . . . . . 6 74 3.2.1. Example Authorization Response using JWT . . . . . . . 6 75 4. Validating the Authorization Response . . . . . . . . . . . . 7 76 5. Mitigation Data Sent to the Token Endpoint . . . . . . . . . . 8 77 5.1. Example Token Request . . . . . . . . . . . . . . . . . . 8 78 6. Validating the Token Request . . . . . . . . . . . . . . . . . 9 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 7.1. IdP Mix-Up and Malicious Endpoint Attacks . . . . . . . . 9 81 7.2. Duplicate Information Attacks . . . . . . . . . . . . . . 9 82 7.3. Cut-and-Paste Attacks . . . . . . . . . . . . . . . . . . 10 83 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 84 8.1. OAuth Parameters Registration . . . . . . . . . . . . . . 11 85 8.1.1. Registry Contents . . . . . . . . . . . . . . . . . . 11 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 89 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 13 90 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 13 91 Appendix C. Open Issues . . . . . . . . . . . . . . . . . . . . . 13 92 Appendix D. Document History . . . . . . . . . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 95 1. Introduction 97 OAuth 2.0 [RFC6749] clients use multiple authorization server 98 endpoints when using some OAuth response types. For instance, when 99 using the "code" response type, the client uses both the 100 authorization endpoint and the token endpoint. It is important that 101 endpoints belonging to the same authorization server always be used 102 together. Otherwise, information produced by one authorization 103 server could mistakenly be sent by the client to different 104 authorization server, resulting in some of the attacks described in 105 Section 7. Recent research publications refer to these specific 106 attacks as "IdP Mix-Up" [arXiv.1601.01229v2] and "Malicious Endpoint" 107 [arXiv.1508.04324v2] attacks. 109 The client obviously cannot be confused into using endpoints from 110 multiple authorization servers in an authorization flow if the client 111 is configured to use only a single authorization server. However, 112 the client can potentially be tricked into mixing endpoints if it is 113 configured to use more than one authorization server, whether the 114 configuration is dynamic or static. The client may be confused if it 115 has no way to determine whether the set of endpoints belongs to the 116 same authorization server. Or, a client may be confused simply 117 because it is receiving authorization responses from more than one 118 authorization server at the same redirection endpoint and the client 119 is insufficiently able to determine that the response received is 120 associated with the correct authorization server. 122 This specification enables the authorization server to dynamically 123 provide the client using it with additional information about the 124 current protocol interaction that can be validated by the client and 125 that enables the client to dynamically provide the authorization 126 server with additional information about the current protocol 127 interaction that can be validated by the authorization server. This 128 enables them to abort interactions in which endpoints from multiple 129 authorization servers would otherwise be used. 131 The mitigation data provided by the authorization server to the 132 client is an issuer URL, which is used to identify the authorization 133 server, and a client ID, which is used to verify that the response is 134 from the correct authorization server and is intended for this 135 client. The issuer URL is defined in Section 2 of [OAuth.Discovery]. 136 If supported by the authorization server, the issuer URL can also be 137 used to obtain a consistent set of metadata describing the 138 authorization server configuration, as also described in 139 [OAuth.Discovery]. 141 This mitigation data is returned to the client in the authorization 142 response. The syntax for returning the mitigation data from the 143 authorization server is dependent upon the OAuth response type being 144 used. The syntax used with the existing response types registered in 145 the IANA "OAuth Authorization Endpoint Response Types" registry 146 [IANA.OAuth.Parameters] as of the time of this writing is defined by 147 this specification. Two of these response types are defined by RFC 148 6749 [RFC6749]; the rest are defined by [OAuth.Responses]. 150 The mitigation data provided by the client to the authorization 151 server is the existing "state" value defined by RFC 6749 [RFC6749], 152 but adding also sending it from the client to the token endpoint. 153 This is used by the authorization server to verify that the 154 authorization code and state both belong to the same protocol 155 interaction. 157 1.1. Requirements Notation and Conventions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in RFC 162 2119 [RFC2119]. 164 1.2. Terminology 166 This specification uses the terms "Access Token", "Authorization 167 Code", "Authorization Endpoint", "Authorization Grant", 168 "Authorization Server", "Client", "Client Authentication", "Client 169 Identifier", "Client Secret", "Grant Type", "Protected Resource", 170 "Redirection URI", "Refresh Token", "Resource Owner", "Resource 171 Server", "Response Type", and "Token Endpoint" defined by OAuth 2.0 172 [RFC6749], the terms "Claim Name", "Claim Value", and "JSON Web Token 173 (JWT)" defined by JSON Web Token (JWT) [JWT]. 175 2. The OAuth Issuer 177 The OAuth issuer serves as a concrete identifier for the 178 authorization server. As defined in [OAuth.Discovery], the OAuth 179 issuer is the URL of the authorization server's configuration 180 information location, which uses the "https" scheme and has no query 181 or fragment components. Also as specified there, when discovery is 182 supported, the authorization server's metadata is retrieved as a JSON 183 document [RFC7159] from a path derived from this URL. This metadata 184 document contains a consistent set of metadata describing the 185 authorization server configuration. 187 Implementations supporting this specification MAY also support 188 discovery or they MAY simply use the issuer URL as a concrete 189 identifier for the authorization server. This specification does not 190 rely upon the authorization server publishing or the client 191 retrieving a discovery metadata document. 193 3. Mitigation Data Returned in Authorization Response 195 Mitigating the attacks relies on the authorization server returning 196 additional data about the interaction and the client checking that 197 data. The mitigation data returned is the client ID and the issuer 198 URL. The syntax for returning the mitigation data from the 199 authorization server is dependent upon the OAuth response type being 200 used. 202 3.1. Mitigation Data Returned in Authorization Response Parameters 204 Some OAuth response types do not already return the issuer URL and 205 client ID in the authorization response. When this is the case, the 206 mitigation data is returned as additional OAuth response parameters. 208 These new response parameters are defined for this purpose: 210 client_id 211 Client that this response is intended for. It MUST contain the 212 OAuth 2.0 client ID of the client as its value. 214 iss 215 Issuer URL for the authorization server issuing the response. The 216 "iss" value is a case-sensitive URL using the "https" scheme that 217 contains scheme, host, and optionally, port number and path 218 components and no query or fragment components. 220 As of the time of this writing, these are the existing response types 221 that are registered in the IANA "OAuth Authorization Endpoint 222 Response Types" registry [IANA.OAuth.Parameters] that do not already 223 return the issuer URL and client ID in the authorization response: 224 "code", "code token", "none", and "token". Therefore, the client ID 225 and issuer are returned using the new authorization response 226 parameters when using these response types. To avoid duplication, as 227 discussed in Section 7.2, it is NOT RECOMMENDED to also return them 228 in this manner when the response type already returns these values in 229 the authorization response. 231 3.1.1. Example Authorization Response using Response Parameters 233 The following example authorization response is to a request that 234 used the "code" response type. It uses the "iss" and "client_id" 235 response parameters to return the mitigation information to the 236 client. 238 The example successful authorization response follows (with line 239 breaks within lines for display purposes only): 241 HTTP/1.1 302 Found 242 Location: https://client.example.org/cb? 243 code=Qcb0Orv1zh30vL1MPRsbm-diHiMwcLyZvn1arpZv-Jxf_11jnpEX3Tgfvk 244 &state=nrsz6AnHzPSVVBYRVTXV6ZTXQeg_eih7hdpewHNXmZ8 245 &iss=https://server.example.com 246 &client_id=5d9e8a36-569d-4c40-8d6b-6e279ac1c5f1 248 3.2. Mitigation Data Returned in JWT 250 As of the time of this writing, these are the existing response types 251 that are registered in the IANA "OAuth Authorization Endpoint 252 Response Types" registry [IANA.OAuth.Parameters] that already return 253 the issuer URL and client ID in the authorization response: 254 "code id_token", "code id_token token", "id_token", and 255 "id_token token". All of these return these values as the "iss" 256 (issuer) claim value and as an "aud" (audience) claim value in a 257 signed ID Token, which is a JSON Web Token [JWT], as specified in 258 "OpenID Connect Core 1.0" [OpenID.Core]. When using these response 259 types, the client MUST use the client ID and issuer values returned 260 in the ID Token for validating the mitigation data. 262 3.2.1. Example Authorization Response using JWT 264 The following example authorization response is to a request that 265 used the "id_token token" response type. It uses the "iss" and "aud" 266 claims in the ID Token to return the mitigation information to the 267 client. 269 The example successful authorization response follows (with line 270 breaks within lines for display purposes only): 272 HTTP/1.1 302 Found 273 Location: https://client.example.org/cb# 274 access_token=jHkWEdUXMU1BwAsC4vtUsZwnNvTIxEl0z9K3vx5KF0Y 275 &token_type=Bearer 276 &id_token=eyJraWQiOiIxZTlnZGs3IiwiYWxnIjoiUlMyNTYifQ. 277 ewogImlzcyI6ICJodHRwczovL3NlcnZlci5leGFtcGxlLmNvbSIsCiAic3ViIjog 278 IjI0ODI4OTc2MTAwMSIsCiAiYXVkIjogInM2QmhkUmtxdDMiLAogIm5vbmNlIjog 279 Im4tMFM2X1d6QTJNaiIsCiAiZXhwIjogMTMxMTI4MTk3MCwKICJpYXQiOiAxMzEx 280 MjgwOTcwLAogImF0X2hhc2giOiAiNzdRbVVQdGpQZnpXdEYyQW5wSzlSUSIKfQ. 281 kdqTmftlaXg5WBYBr1wkxhkqCGZPc0k8vTiV5g2jj67jQ7XkrDamYx2bOkZLdZrp 282 MPIzkdYB1nZI_G8vQGQuamRhJcEIt21kblGPZ-yhEhdkAiZIZLu38rChalDS2Mh0 283 glE_rke5XXRhmqqoEFFdziFdnO3p61-7y51co84OEAZvARSINQaOWIzvioRfs4zw 284 IFOaT33Vpxfqr8HDyh31zo9eBW2dSQuCa071z0ENWChWoPliK1JCo_Bk9eDg2uwo 285 2ZwhsvHzj6TMQ0lYOTzufSlSmXIKfjlOsb3nftQeR697_hA-nMZyAdL8_NRfaC37 286 XnAbW8WB9wCfECp7cuNuOg 287 &state=af0ifjsldkj 289 Decoding the ID Token in the response will yield the following 290 claims, which includes the mitigation information in the "iss" and 291 "aud" claims: 293 { 294 "iss": "https://server.example.com", 295 "sub": "248289761001", 296 "aud": "s6BhdRkqt3", 297 "nonce": "n-0S6_WzA2Mj", 298 "exp": 1311281970, 299 "iat": 1311280970, 300 "at_hash": "77QmUPtjPfzWtF2AnpK9RQ" 301 } 303 4. Validating the Authorization Response 305 Upon receiving the mitigation data in an authorization response, the 306 client MUST validate that the response was intended for it and that 307 the authorization server configuration information that it obtained 308 at client registration time is consistent with the authorization 309 server configuration information contained in the metadata referenced 310 by the issuer URL. 312 The client MUST validate the authorization server configuration as 313 follows: 315 1. Compare the issuer URL for the authorization server that the 316 client received when it registered at the authorization server 317 that it made the request to with the issuer value returned in the 318 "iss" response parameter or the "iss" claim in the ID Token, 319 depending upon the response type being used. If they do not 320 exactly match, the client MUST NOT proceed with the 321 authorization. 323 2. Verify that the response is intended for this client by 324 confirming that the client's client identifier for the 325 authorization server the request was made to matches the value of 326 the "client_id" response parameter or that the client's client 327 identifier is an audience value of the ID Token, depending upon 328 the response type being used. If not, the client MUST NOT 329 proceed with the authorization. 331 5. Mitigation Data Sent to the Token Endpoint 333 Mitigating the attacks also relies on the client sending additional 334 data about the interaction to the token endpoint, for response types 335 that use it, and the authorization server checking that data. The 336 mitigation data sent is the same state value that is sent in the 337 authorization request and returned in the authorization response. 338 This specification defines the new "state" token request parameter 339 for passing this additional information. 341 As of the time of this writing, these are the existing response types 342 that are registered in the IANA "OAuth Authorization Endpoint 343 Response Types" registry [IANA.OAuth.Parameters] that use the token 344 endpoint: "code", "code id_token", "code id_token token", and 345 "code token". The state value is to be sent in the "state" token 346 request parameter when using these response types, and any new 347 response types registered that use the token endpoint. 349 5.1. Example Token Request 351 The following example token request is part of a protocol interaction 352 that used the "code" response type. It uses the "state" request 353 parameter to send mitigation information to the authorization server. 355 The example of token request follows (with line breaks within lines 356 for display purposes only): 358 POST /token HTTP/1.1 359 Host: server.example.com 360 Content-Type: application/x-www-form-urlencoded 361 Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW 363 grant_type=authorization_code 364 &code=SplxlOBeZQQYbYS6WxSbIA 365 &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb 366 &state=ZSGXNBavNc-B3kU3DeJnZoWWOzYxsbvj7jp-S0x_z8U 368 6. Validating the Token Request 370 When the authorization server receives a token request at the token 371 endpoint that contains a value in the "state" parameter, it MUST 372 validate that the state value received exactly matches the state 373 value previously received in the corresponding authorization request. 374 If the recorded state value and the state value received do not 375 exactly match, the authorization server MUST NOT proceed with the 376 authorization. 378 7. Security Considerations 380 7.1. IdP Mix-Up and Malicious Endpoint Attacks 382 The attacks mitigated by this extension are described in detail in "A 383 Comprehensive Formal Security Analysis of OAuth 2.0" 384 [arXiv.1601.01229v2] and "On the security of modern Single Sign-On 385 Protocols: Second-Order Vulnerabilities in OpenID Connect" 386 [arXiv.1508.04324v2]. To mitigate these attacks, clients configured 387 to use more than one authorization server should use authorization 388 servers that return issuer and client ID information and should 389 validate that a consistent set of authorization server endpoints are 390 being used when using response types that utilize multiple endpoints. 392 When registering, clients SHOULD NOT allow multiple authorization 393 servers to return the same issuer value, and MUST NOT allow multiple 394 authorization servers to return the same issuer and client ID value 395 pair. 397 7.2. Duplicate Information Attacks 399 If a protocol is defined to return the same information in multiple 400 locations, this can create an additional attack surface. Knowing 401 that the information is supposed to be the same, recipients will 402 often be lazy and use the information from only one of the locations, 403 not validating that all the supposedly duplicate instances are the 404 same. This can enable attackers to create illegal protocol messages 405 that have different values in the multiple locations and those 406 illegal messages will not be detected or rejected by these lazy 407 recipients. 409 For this reason, if an OAuth profile is being used that returns the 410 mitigation information defined by this specification in one location, 411 it SHOULD NOT also be returned in another. In particular, if a JWT 412 containing the client ID and issuer values is being returned in the 413 authorization response, they SHOULD NOT also be returned as 414 individual authorization response parameters. 416 7.3. Cut-and-Paste Attacks 418 OAuth authorization responses are sent as redirects to redirection 419 URIs, with the response parameters typically passed as URI query 420 parameters or fragment values. A "cut-and-paste" attack is performed 421 by the attacker creating what appears to be a legitimate 422 authorization response, but that substitutes some of the response 423 parameter values with values of the attacker's choosing. Sometimes 424 this is done by copying or "cutting" some values out of a legitimate 425 response and replacing or "pasting" some of these values into a 426 different response, the original version of which may have also been 427 legitimate, creating a combination of response values that are not 428 legitimate and that may cause behaviors sought by the attacker. The 429 Code Substitution threat described in Section 4.4.1.13 of [RFC6819] 430 is one example of the use of a cut-and-paste attack. 432 A concern with returning the mitigation information as new individual 433 authorization response parameters whose values are not 434 cryptographically bound together is that cut-and-paste attacks 435 against their values will not be detected. A security analysis has 436 not been done of the effects of the new attacks that the use of cut- 437 and-paste against these new values will enable. 439 To prevent replay of the state in another browser instance by an 440 attacker, the state value MUST be tied to the browser instance in a 441 way that cannot be forged by an attacker. Section 4 of 442 [I-D.bradley-oauth-jwt-encoded-state] provides several examples of 443 how a client can accomplish this. 445 In the replay attack, the attacker can set cookies in the browser. 446 Using an unsigned cookie to bind state to the browser is not 447 sufficient. 449 8. IANA Considerations 451 8.1. OAuth Parameters Registration 453 This specification registers the following parameters in the IANA 454 "OAuth Parameters" registry [IANA.OAuth.Parameters] established by 455 RFC 6749 [RFC6749]. 457 8.1.1. Registry Contents 459 o Parameter name: "client_id" 460 o Parameter usage location: Authorization Response 461 o Change controller: IESG 462 o Specification document(s): Section 3.1 of [[ this specification ]] 463 o Related information: None 465 o Parameter name: "iss" 466 o Parameter usage location: Authorization Response 467 o Change controller: IESG 468 o Specification document(s): Section 3.1 of [[ this specification ]] 469 o Related information: None 471 o Parameter name: "state" 472 o Parameter usage location: Token Request 473 o Change controller: IESG 474 o Specification document(s): Section 5 of [[ this specification ]] 475 o Related information: None 477 9. References 479 9.1. Normative References 481 [IANA.OAuth.Parameters] 482 IANA, "OAuth Parameters", 483 . 485 [JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 486 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 487 . 489 [OAuth.Discovery] 490 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 491 Discovery", draft-ietf-oauth-discovery-01 (work in 492 progress), February 2016, 493 . 496 [OAuth.Responses] 497 de Medeiros, B., Ed., Scurtescu, M., Tarjan, P., and M. 498 Jones, "OAuth 2.0 Multiple Response Type Encoding 499 Practices", February 2014, . 502 [OpenID.Core] 503 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 504 C. Mortimore, "OpenID Connect Core 1.0", November 2014, 505 . 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 509 RFC2119, March 1997, 510 . 512 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 513 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, 514 November 2003, . 516 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 517 RFC 6749, DOI 10.17487/RFC6749, October 2012, 518 . 520 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 521 Threat Model and Security Considerations", RFC 6819, 522 DOI 10.17487/RFC6819, January 2013, 523 . 525 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 526 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, 527 March 2014, . 529 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 530 RFC 7662, DOI 10.17487/RFC7662, October 2015, 531 . 533 9.2. Informative References 535 [I-D.bradley-oauth-jwt-encoded-state] 536 Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding 537 claims in the OAuth 2 state parameter using a JWT", 538 draft-bradley-oauth-jwt-encoded-state-05 (work in 539 progress), December 2015. 541 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 542 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 543 RFC 7591, DOI 10.17487/RFC7591, July 2015, 544 . 546 [arXiv.1508.04324v2] 547 Mladenov, V., Mainka, C., and J. Schwenk, "On the security 548 of modern Single Sign-On Protocols: Second-Order 549 Vulnerabilities in OpenID Connect", arXiv 1508.04324v2, 550 January 2016, . 552 [arXiv.1601.01229v2] 553 Fett, D., Kuesters, R., and G. Schmitz, "A Comprehensive 554 Formal Security Analysis of OAuth 2.0", 555 arXiv 1601.01229v2, January 2016, 556 . 558 Appendix A. Implementation Notes 560 The authorization server can compare the two state values either by 561 recording the complete state value between the authorization request 562 and the token request, possibly in the same data structure in which 563 the authorization code issued was recorded, or by recording only a 564 cryptographic hash of the state value, possibly resulting in 565 substantial size savings. 567 Appendix B. Acknowledgements 569 Alfred Albrecht, John Bradley, Brian Campbell, Joerg Connotte, 570 William Denniss, Sebastian Ebling, Florian Feldmann, Daniel Fett, 571 Roland Hedberg, Phil Hunt, Ralf Kuesters, Torsten Lodderstedt, 572 Christian Mainka, Vladislav Mladenov, Anthony Nadalin, Justin Richer, 573 Nat Sakimura, Antonio Sanso, Guido Schmitz, Joerg Schwenk, Hannes 574 Tschofenig, and Hans Zandbelt all contributed to the discussions that 575 led to the creation of this specification. 577 This specification is partially based on the OpenID Connect Core 1.0 578 specification, which was produced by the OpenID Connect working group 579 of the OpenID Foundation. 581 Appendix C. Open Issues 583 o We need to do a security analysis of the cut-and-paste attacks 584 that may be enabled when mitigation information is returned to the 585 client using individual authorization response parameters. 587 Appendix D. Document History 589 [[ to be removed by the RFC Editor before publication as an RFC ]] 591 -00 593 o Created the initial working group draft from 594 draft-jones-oauth-mix-up-mitigation-01 with no normative changes 595 and adding Nat Sakimura as an editor. 597 Authors' Addresses 599 Michael B. Jones 600 Microsoft 602 Email: mbj@microsoft.com 603 URI: http://self-issued.info/ 605 John Bradley 606 Ping Identity 608 Email: ve7jtb@ve7jtb.com 609 URI: http://www.thread-safe.com/ 611 Nat Sakimura 612 Nomura Research Institute, Ltd. 614 Email: n-sakimura@nri.co.jp 615 URI: http://nat.sakimura.org/