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