idnits 2.17.1 draft-ietf-oauth-security-topics-05.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 987: '...ates that the AS MUST NOT automaticall...' RFC 2119 keyword, line 997: '...rization request MUST NOT automaticall...' RFC 2119 keyword, line 1002: '... Client MUST not expose URLs which c...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Client MUST not expose URLs which could be utilized as open redirector. An open redirector is a way to cause the recipient of a HTTP request to issue a redirect to a target URL that is passed as a parameter. Attackers may utilize such a mechanism to produce URLs, which appear to point to the client, which might trick users to trust the URL and follow it in her browser. Another abuse case is to produce URLs pointing to the client and utilize them to impersonate a client with an authorization server. -- The document date (March 18, 2018) is 2230 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 6819 ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-09) exists of draft-bradley-oauth-jwt-encoded-state-08 == Outdated reference: A later version (-34) exists of draft-ietf-oauth-jwsreq-15 == Outdated reference: A later version (-17) exists of draft-ietf-oauth-mtls-07 == Outdated reference: A later version (-07) exists of draft-ietf-oauth-pop-key-distribution-03 == Outdated reference: A later version (-08) exists of draft-ietf-oauth-token-binding-06 == Outdated reference: A later version (-18) exists of draft-ietf-tokbind-https-12 == Outdated reference: A later version (-05) exists of draft-sakimura-oauth-jpop-04 Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Authentication Protocol T. Lodderstedt, Ed. 3 Internet-Draft YES.com AG 4 Intended status: Best Current Practice J. Bradley 5 Expires: September 19, 2018 Yubico 6 A. Labunets 7 Facebook 8 March 18, 2018 10 OAuth 2.0 Security Best Current Practice 11 draft-ietf-oauth-security-topics-05 13 Abstract 15 This document describes best current security practices for OAuth 16 2.0.. It updates and extends the OAuth 2.0 Security Threat Model to 17 incorporate practical experiences gathered since OAuth 2.0 was 18 published and cover new threats relevant due to the broader 19 application of OAuth 2.0. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 19, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Protecting redirect-based flows . . . . . . . . . . . . . 4 58 2.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 5 59 3. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 5 60 3.1. Insufficient redirect URI validation . . . . . . . . . . 5 61 3.1.1. Attacks on Authorization Code Grant . . . . . . . . . 5 62 3.1.2. Attacks on Implicit Grant . . . . . . . . . . . . . . 6 63 3.1.3. Proposed Countermeasures . . . . . . . . . . . . . . 8 64 3.2. Authorization code leakage via referrer headers . . . . . 9 65 3.2.1. Proposed Countermeasures . . . . . . . . . . . . . . 9 66 3.3. Attacks in the Browser . . . . . . . . . . . . . . . . . 10 67 3.3.1. Code in browser history . . . . . . . . . . . . . . . 10 68 3.3.2. Access token in browser history . . . . . . . . . . . 10 69 3.4. Mix-Up . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 3.5. Code Injection . . . . . . . . . . . . . . . . . . . . . 11 71 3.5.1. Proposed Countermeasures . . . . . . . . . . . . . . 13 72 3.6. Cross Site Request Forgery . . . . . . . . . . . . . . . 15 73 3.7. Access Token Leakage at the Resource Server . . . . . . . 15 74 3.7.1. Access Token Phishing by Counterfeit Resource Server 15 75 3.7.1.1. Metadata . . . . . . . . . . . . . . . . . . . . 16 76 3.7.1.2. Sender Constrained Access Tokens . . . . . . . . 17 77 3.7.1.3. Audience Restricted Access Tokens . . . . . . . . 19 78 3.7.2. Compromised Resource Server . . . . . . . . . . . . . 20 79 3.8. Open Redirection . . . . . . . . . . . . . . . . . . . . 21 80 3.8.1. Authorization Server as Open Redirector . . . . . . . 21 81 3.8.2. Clients as Open Redirector . . . . . . . . . . . . . 21 82 3.9. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 22 83 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 87 7.1. Normative References . . . . . . . . . . . . . . . . . . 23 88 7.2. Informative References . . . . . . . . . . . . . . . . . 24 89 Appendix A. Document History . . . . . . . . . . . . . . . . . . 26 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 92 1. Introduction 94 It's been a while since OAuth has been published in RFC 6749 95 [RFC6749] and RFC 6750 [RFC6750]. Since publication, OAuth 2.0 has 96 gotten massive traction in the market and became the standard for API 97 protection and, as foundation of OpenID Connect [OpenID], identity 98 providing. While OAuth was used in a variety of scenarios and 99 different kinds of deployments, the following challenges could be 100 observed: 102 o OAuth implementations are being attacked through known 103 implementation weaknesses and anti-patterns (XSRF, referrer 104 header). Although most of these threats are discussed in the 105 OAuth 2.0 Threat Model and Security Considerations [RFC6819], 106 continued exploitation demonstrates there may be a need for more 107 specific recommendations or that the existing mitigations are too 108 difficult to deploy. 110 o Technology has changed, e.g. the way browsers treat fragments in 111 some situations, which may change the implicit grant's underlying 112 security model. 114 o OAuth is used in much more dynamic setups than originally 115 anticipated, creating new challenges with respect to security. 116 Those challenges go beyond the original scope of RFC 6749 117 [RFC6749], RFC 6750 [RFC6749], and RFC 6819 [RFC6819]. 119 OAuth initially assumed a static relationship between client, 120 authorization server and resource servers. The URLs of AS and RS 121 were known to the client at deployment time and built an anchor for 122 the trust relationsship among those parties. The validation whether 123 the client talks to a legitimate server was based on TLS server 124 authentication (see [RFC6819], Section 4.5.4). With the increasing 125 adoption of OAuth, this simple model dissolved and, in several 126 scenarios, was replaced by a dynamic establishment of the 127 relationship between clients on one side and the authorization and 128 resource servers of a particular deployment on the other side. This 129 way the same client could be used to access services of different 130 providers (in case of standard APIs, such as e-Mail or OpenID 131 Connect) or serves as a frontend to a particular tenant in a multi- 132 tenancy. Extensions of OAuth, such as [RFC7591] and 133 [I-D.ietf-oauth-discovery] were developed in order to support the 134 usage of OAuth in dynamic scenarios. As a challenge to the 135 community, such usage scenarios open up new attack angles, which are 136 discussed in this document. 138 The remainder of the document is organized as follows: The next 139 section summarizes the most important recommendations of the OAuth 140 working group for every OAuth implementor. Afterwards, a detailed 141 analyses of the threats and implementation issues, which can be found 142 in the wild today, is given along with a discussion of potential 143 counter measures. 145 2. Recommendations 147 This section describes the set of security mechanisms the authors 148 believe should be taken into consideration by the OAuth working group 149 to be recommended to OAuth implementers. 151 2.1. Protecting redirect-based flows 153 Authorization servers shall utilize exact matching of client redirect 154 URIs against pre-registered URIs. This measure contributes to the 155 prevention of leakage of authorization codes and access tokens 156 (depending on the grant type). It also helps to detect mix up 157 attacks. 159 Clients shall avoid any redirects or forwards, which can be 160 parameterized by URI query parameters, in order to provide a further 161 layer of defence against token leakage. If there is a need for this 162 kind of redirects, clients are advised to implement appropriate 163 counter measures against open redirection, e.g. as described by the 164 OWASP [owasp]. 166 Clients shall ensure to only process redirect responses of the OAuth 167 authorization server they send the respective request to and in the 168 same user agent this request was initiated in. In particular, 169 clients shall implement appropriate XSRF prevention by utilizing one- 170 time use XSRF tokens carried in the STATE parameter, which are 171 securely bound to the user agent. Moreover, the client shall 172 memorize which authorization server it sent an authorization request 173 to and bind this information to the user agent and ensure any sub- 174 sequent messages are sent to the same authorization server. 175 Furthermore, clients should use AS-specific redirect URIs as a means 176 to identify the AS a particular response came from. Matching this 177 with the before mentioned information regarding the AS the client 178 sent the request to helps to detect mix-up attacks. 180 Note: [I-D.bradley-oauth-jwt-encoded-state] gives advice on how to 181 implement XSRF prevention and AS matching using signed JWTs in the 182 STATE parameter. 184 Clients shall use PKCE [RFC7636] in order to (with the help of the 185 authorization server) detect and prevent attempts to inject (replay) 186 authorization codes into the authorization response. The PKCE 187 challenges must be transaction-specific and securely bound to the 188 user agent, in which the transaction was started. OpenID Connect 189 clients may use the "nonce" parameter of the OpenID Connect 190 authentication request as specified in [OpenID] in conjunction with 191 the corresponding ID Token claim of the for the same purpose. 193 Note: although PKCE so far was recommended as mechanism to protect 194 native apps, this advice applies to all kinds of OAuth clients, 195 including web applications. 197 Authorization servers shall consider the recommendations given in 198 [RFC6819], section 4.4.1.1, on authorization code replay prevention. 200 2.2. Token Replay Prevention 202 Authorization servers shall use TLS-based methods for sender 203 constraint access tokens as described in section Section 3.7.1.2, 204 such as token binding [I-D.ietf-oauth-token-binding] or Mutual TLS 205 for OAuth 2.0 [I-D.ietf-oauth-mtls]. It is also recommend to use 206 end-to-end TLS whenever possible. 208 3. Attacks and Mitigations 210 3.1. Insufficient redirect URI validation 212 Some authorization servers allow clients to register redirect URI 213 patterns instead of complete redirect URIs. In those cases, the 214 authorization server, at runtime, matches the actual redirect URI 215 parameter value at the authorization endpoint against this pattern. 216 This approach allows clients to encode transaction state into 217 additional redirect URI parameters or to register just a single 218 pattern for multiple redirect URIs. As a downside, it turned out to 219 be more complex to implement and error prone to manage than exact 220 redirect URI matching. Several successful attacks have been observed 221 in the wild, which utilized flaws in the pattern matching 222 implementation or concrete configurations. Such a flaw effectively 223 breaks client identification or authentication (depending on grant 224 and client type) and allows the attacker to obtain an authorization 225 code or access token, either: 227 o by directly sending the user agent to a URI under the attackers 228 control or 230 o by exposing the OAuth credentials to an attacker by utilizing an 231 open redirector at the client in conjunction with the way user 232 agents handle URL fragments. 234 3.1.1. Attacks on Authorization Code Grant 236 For a public client using the grant type code, an attack would look 237 as follows: 239 Let's assume the redirect URL pattern "https://*.example.com/*" had 240 been registered for the client "s6BhdRkqt3". This pattern allows 241 redirect URIs from any host residing in the domain example.com. So 242 if an attacker manages to establish a host or subdomain in 243 "example.com" he can impersonate the legitimate client. Assume the 244 attacker sets up the host "evil.example.com". 246 (1) The attacker needs to trick the user into opening a tampered URL 247 in his browser, which launches a page under the attacker's 248 control, say "https://www.evil.com". 250 (2) This URL initiates an authorization request with the client id 251 of a legitimate client to the authorization endpoint. This is 252 the example authorization request (line breaks are for display 253 purposes only): 255 GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz 256 &redirect_uri=https%3A%2F%2Fevil.example.com%2Fcb HTTP/1.1 257 Host: server.example.com 259 (1) The authorization validates the redirect URI in order to 260 identify the client. Since the pattern allows arbitrary domains 261 host names in "example.com", the authorization request is 262 processed under the legitimate client's identity. This includes 263 the way the request for user consent is presented to the user. 264 If auto-approval is allowed (which is not recommended for public 265 clients according to RFC 6749), the attack can be performed even 266 easier. 268 (2) If the user does not recognize the attack, the code is issued 269 and directly sent to the attacker's client. 271 (3) Since the attacker impersonated a public client, it can directly 272 exchange the code for tokens at the respective token endpoint. 274 Note: This attack will not directly work for confidential clients, 275 since the code exchange requires authentication with the legitimate 276 client's secret. The attacker will need to utilize the legitimate 277 client to redeem the code (e.g. by performing a code injection 278 attack). This kind of injections is covered in 279 Section Code Injection. 281 3.1.2. Attacks on Implicit Grant 283 The attack described above works for the implicit grant as well. If 284 the attacker is able to send the authorization response to a URI 285 under his control, he will directly get access to the fragment 286 carrying the access token. 288 Additionally, implicit clients can be subject to a further kind of 289 attacks. It utilizes the fact that user agents re-attach fragments 290 to the destination URL of a redirect if the location header does not 291 contain a fragment (see [RFC7231], section 9.5). The attack 292 described here combines this behavior with the client as an open 293 redirector in order to get access to access tokens. This allows 294 circumvention even of strict redirect URI patterns (but not strict 295 URL matching!). 297 Assume the pattern for client "s6BhdRkqt3" is 298 "https://client.example.com/cb?*", i.e. any parameter is allowed for 299 redirects to "https://client.example.com/cb". Unfortunately, the 300 client exposes an open redirector. This endpoint supports a 301 parameter "redirect_to", which takes a target URL and will send the 302 browser to this URL using a HTTP 302. 304 (1) Same as above, the attacker needs to trick the user into opening 305 a tampered URL in his browser, which launches a page under the 306 attacker's control, say "https://www.evil.com". 308 (2) The URL initiates an authorization request, which is very 309 similar to the attack on the code flow. As differences, it 310 utilizes the open redirector by encoding 311 "redirect_to=https://client.evil.com" into the redirect URI and 312 it uses the response type "token" (line breaks are for display 313 purposes only): 315 GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz 316 &redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb%26redirect_to 317 %253Dhttps%253A%252F%252Fclient.evil.com%252Fcb HTTP/1.1 318 Host: server.example.com 320 (1) Since the redirect URI matches the registered pattern, the 321 authorization server allows the request and sends the resulting 322 access token with a 302 redirect (some response parameters are 323 omitted for better readability) 325 HTTP/1.1 302 Found 326 Location: https://client.example.com/cb? 327 redirect_to%3Dhttps%3A%2F%2Fclient.evil.com%2Fcb 328 #access_token=2YotnFZFEjr1zCsicMWpAA&... 330 (2) At the example.com, the request arrives at the open redirector. 331 It will read the redirect parameter and will issue a HTTP 302 to 332 the URL "https://evil.example.com/cb". 334 HTTP/1.1 302 Found 335 Location: https://client.evil.com/cb 337 (3) Since the redirector at example.com does not include a fragment 338 in the Location header, the user agent will re-attach the 339 original fragment 340 "#access_token=2YotnFZFEjr1zCsicMWpAA&..." to the URL and will 341 navigate to the following URL: 343 https://client.evil.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&... 345 (4) The attacker's page at client.evil.com can access the fragment 346 and obtain the access token. 348 3.1.3. Proposed Countermeasures 350 The complexity of implementing and managing pattern matching 351 correctly obviously causes security issues. This document therefore 352 proposes to simplify the required logic and configuration by using 353 exact redirect URI matching only. This means the authorization 354 server shall compare the two URIs using simple string comparison as 355 defined in [RFC3986], Section 6.2.1.. 357 This would cause the following impacts: 359 o This change will require all OAuth clients to maintain the 360 transaction state (and XSRF tokens) in the "state" parameter. 361 This is a normative change to RFC 6749 since section 3.1.2.2 362 allows for dynamic URI query parameters in the redirect URI. In 363 order to assess the practical impact, the working group needs to 364 collect data on whether this feature is really used in deployments 365 today. 367 o The working group may also consider this change as a step towards 368 improved interoperability for OAuth implementations since RFC 6749 369 is somewhat vague on redirect URI validation. Notably there are 370 no rules for pattern matching. One may therefore assume all 371 clients utilizing pattern matching will do so in a deployment 372 specific way. On the other hand, RFC 6749 already recommends 373 exact matching if the full URL had been registered. 375 o Clients with multiple redirect URIs need to register all of them 376 explicitly. 377 Note: clients with just a single redirect URI would not even need 378 to send a redirect URI with the authorization request. Does it 379 make sense to emphasize this option? Would that further simplify 380 use of the protocol and foster security? 382 o Exact redirect matching does not work for native apps utilizing a 383 local web server due to dynamic port numbers - at least wild cards 384 for port numbers are required. 386 Question: Does redirect uri validation solve any problem for 387 native apps? Effective against impersonation when used in 388 conjunction with claimed HTTPS redirect URIs only. 389 For Windows token broker exact redirect URI matching is important 390 as the redirect URI encodes the app identity. For custom scheme 391 redirects there is a question however it is probably a useful part 392 of defense in depth. 394 Additional recommendations: 396 o Servers on which callbacks are hosted must not expose open 397 redirectors (see Section 3.8). 399 o Clients may drop fragments via intermediary URLs with "fix 400 fragments" (e.g. https://developers.facebook.com/blog/post/552/) 401 to prevent the user agent from appending any unintended fragments. 403 Alternatives to exact redirect URI matching: 405 o Authenticate clients using digital signatures (see 406 [I-D.ietf-oauth-jwsreq]) 408 3.2. Authorization code leakage via referrer headers 410 It is possible authorization codes are unintentionally disclosed to 411 attackers, if a OAuth client renders a page containing links to other 412 pages (ads, faq, ...) as result of a successful authorization 413 request. 415 If the user clicks onto one of those links and the target is under 416 the control of an attacker, it can get access to the response URL in 417 the referrer header. 419 It is also possible that an attacker injects cross-domain content 420 somehow into the page, such as (e.g if this is a blog web 421 site). The implication is obviously the same: loading this content 422 by browser results in leaking referrer with a code. 424 3.2.1. Proposed Countermeasures 426 There are some means to prevent leakage as described above: 428 o Make authorization codes one-time use. For example, if the 429 legitimate client redeemed and invalidated the code in the above 430 scenario, the attacker would fail exchanging this code later. 432 o Bind authorization code to a confidential client or PKCE 433 challenge. In this case, the attacker lacks the secret to request 434 the code exchange. 436 o Don't include links to external sites into the page rendered as 437 result of a OAuth authorization response 439 o Use of the HTML link attribute rel="noreferrer" to suppress 440 referrer header 442 o Use of the "referrer" meta link attribute to suppress referrer 443 header (see [webappsec-referrer-policy]) 445 o Use form post response mode instead of redirect for authorization 446 response (see [oauth-v2-form-post-response-mode]) 448 3.3. Attacks in the Browser 450 3.3.1. Code in browser history 452 When a browser navigates to "client.com/ 453 redirection_endpoint?code=abcd" as a result of a redirect from a 454 provider's authorization endpoint, the URL including the 455 authorization code may end up in the browser's history. An attacker 456 with access to the device could obtain the code and try to replay it. 458 Proposed countermeasures: 460 o Authorization code replay prevention as described in [RFC6819], 461 section 4.4.1.1, and Section 3.5 463 o Use form post response mode instead of redirect for authorization 464 response (see [oauth-v2-form-post-response-mode]) 466 3.3.2. Access token in browser history 468 An access token may end up in the browser history if a a client or 469 just a web site, which already has a token, deliberately navigates to 470 a page like "provider.com/get_user_profile?access_token=abcdef.". 471 Actually [RFC6750]discourages this practice and asks to transfer 472 tokens via a header, but in practice web sites often just pass access 473 token in query parameters. 475 In case of implicit grant, a URL like "client.com/ 476 redirection_endpoint#access_token=abcdef" may also end up in the 477 browser history as a result of a redirect from a provider's 478 authorization endpoint. 480 Proposed countermeasures: 482 o Replace implicit flow with postmessage communication or the 483 authorization code grant 485 o Never pass access tokens in URL query parameters 487 3.4. Mix-Up 489 Mix-up is another kind of attack on more dynamic OAuth scenarios (or 490 at least scenarios where a OAuth client interacts with multiple 491 authorization servers). The goal of the attack is to obtain an 492 authorization code or an access token by tricking the client into 493 sending those credentials to the attacker (which acts as MITM between 494 client and authorization server) 496 A detailed description of the attack and potential countermeasures is 497 given in [I-D.ietf-oauth-mix-up-mitigation]. 499 Potential mitigations: 501 o Clients use AS-specific redirect URIs and, for every authorization 502 request, store intended AS and compare intention with actual 503 redirect URI where the response was received 505 o AS returns client_id and its iss in the response. Client compares 506 this data to AS it believed it sent the user agent to. 508 o ID token carries client id and issuer (OpenID Connect specific) 510 3.5. Code Injection 512 In such an attack, the adversary attempts to inject a stolen 513 authorization code into a legitimate client on a device under his 514 control. In the simplest case, the attacker would want to use the 515 code in his own client. But there are situations where this might 516 not be possible or intended. Examples are: 518 o The attacker wants to access certain functions in this particular 519 client. As an example, the attacker wants to impersonate his 520 victim in a certain app or on a certain web site. 522 o The code is bound to a particular confidential client and the 523 attacker is unable to obtain the required client credentials to 524 redeem the code himself. 526 o The authorization or resource servers are limited to certain 527 networks, the attackers is unable to access directly. 529 How does an attack look like? 531 (1) The attacker obtains an authorization code by performing any of 532 the attacks described above. 534 (2) It performs a regular OAuth authorization process with the 535 legitimate client on his device. 537 (3) The attacker injects the stolen authorization code in the 538 response of the authorization server to the legitimate client. 540 (4) The client sends the code to the authorization server's token 541 endpoint, along with client id, client secret and actual 542 redirect_uri. 544 (5) The authorization server checks the client secret, whether the 545 code was issued to the particular client and whether the actual 546 redirect URI matches the redirect_uri parameter (see [RFC6749]). 548 (6) If all checks succeed, the authorization server issues access 549 and other tokens to the client, so now the attacker is able to 550 impersonate the legitimate user. 552 Obviously, the check in step (5) will fail, if the code was issued to 553 another client id, e.g. a client set up by the attacker. The check 554 will also fail if the authorization code was already redeemed by the 555 legitimate user and was one-time use only. 557 An attempt to inject a code obtained via a malware pretending to be 558 the legitimate client should also be detected, if the authorization 559 server stored the complete redirect URI used in the authorization 560 request and compares it with the redirect_uri parameter. 562 [RFC6749], Section 4.1.3, requires the AS to "... ensure that the 563 "redirect_uri" parameter is present if the "redirect_uri" parameter 564 was included in the initial authorization request as described in 565 Section 4.1.1, and if included ensure that their values are 566 identical.". In the attack scenario described above, the legitimate 567 client would use the correct redirect URI it always uses for 568 authorization requests. But this URI would not match the tampered 569 redirect URI used by the attacker (otherwise, the redirect would not 570 land at the attackers page). So the authorization server would 571 detect the attack and refuse to exchange the code. 573 Note: this check could also detect attempt to inject a code, which 574 had been obtained from another instance of the same client on another 575 device, if certain conditions are fulfilled: 577 o the redirect URI itself needs to contain a nonce or another kind 578 of one-time use, secret data and 580 o the client has bound this data to this particular instance 582 But this approach conflicts with the idea to enforce exact redirect 583 URI matching at the authorization endpoint. Moreover, it has been 584 observed that providers very often ignore the redirect_uri check 585 requirement at this stage, maybe, because it doesn't seem to be 586 security-critical from reading the spec. 588 Other providers just pattern match the redirect_uri parameter against 589 the registered redirect URI pattern. This saves the authorization 590 server from storing the link between the actual redirect URI and the 591 respective authorization code for every transaction. But this kind 592 of check obviously does not fulfill the intent of the spec, since the 593 tampered redirect URI is not considered. So any attempt to inject a 594 code obtained using the client_id of a legitimate client or by 595 utilizing the legitimate client on another device won't be detected 596 in the respective deployments. 598 It is also assumed that the requirements defined in [RFC6749], 599 Section 4.1.3, increase client implementation complexity as clients 600 need to memorize or re-construct the correct redirect URI for the 601 call to the tokens endpoint. 603 The authors therefore propose to the working group to drop this 604 feature in favor of more effective and (hopefully) simpler approaches 605 to code injection prevention as described in the following section. 607 3.5.1. Proposed Countermeasures 609 The general proposal is to bind every authorization code to a certain 610 client instance on a certain device (or in a certain user agent) in 611 the context of a certain transaction. There are multiple technical 612 solutions to achieve this goal: 614 Nonce OpenID Connect's existing "nonce" parameter could be used for 615 this purpose. The nonce value is one-time use and created by 616 the client. The client is supposed to bind it to the user 617 agent session and sends it with the initial request to the 618 OpenId Provider (OP). The OP associates the nonce to the 619 authorization code and attests this binding in the ID token, 620 which is issued as part of the code exchange at the token 621 endpoint. If an attacker injected an authorization code in 622 the authorization response, the nonce value in the client 623 session and the nonce value in the ID token will not match 624 and the attack is detected. assumption: attacker cannot get 625 hold of the user agent state on the victims device, where he 626 has stolen the respective authorization code. The main 627 advantage of this option is that Nonce is an existing feature 628 used in the wild. On the other hand, leveraging Nonce by the 629 broader OAuth community would require AS and client to adopt 630 ID Tokens. 632 Code-bound State The "state" parameter as specified in [RFC6749] 633 could be used similarly to the way as described above. This 634 would require to add a further parameter "state" to the code 635 exchange token endpoint request. The authorization server 636 would then compares the state value it associated with the 637 code and the state value in the parameter. If those values 638 do not match, it is considered an attack and the request 639 fails. The advantage of this approach would be to utilize an 640 existing OAuth parameter. But it would also mean to re- 641 interpret the purpose of state and to extend the token 642 endpoint request. 644 PKCE The PKCE parameter "challenge" along with the corresponding 645 "verifier" as specified in [RFC7636] could be used in the 646 same way as "nonce" or "state". In contrast to its original 647 intention, the verifier check would fail although the client 648 uses its correct verifier but the code is associated with a 649 challenge, which does not match. PKCE is a deployed OAuth 650 feature, even so it is today used to secure native apps, 651 only. 653 Token Binding Token binding [I-D.ietf-oauth-token-binding] could 654 also be used. In this case, the code would need to be bound 655 to two legs, between user agent and AS and the user agent and 656 the client. This requires further data (extension to 657 response) to manifest binding id for particular code. Token 658 binding is promising as a secure and convenient mechanism 659 (due to its browser integration). As a challenge, it 660 requires broad browser support and use with native apps still 661 under discussion. 663 per instance client id/secret One could use per instance client_id 664 and secrets and bind the code to the respective client_id. 665 Unfortunately, this does not fit into the web application 666 programming model (would need to use per user client ids). 668 PKCE seem to be the most obvious solution for OAuth clients as it 669 available and effectively used today for similar purposes for OAuth 670 native apps whereas "nonce" is appropriate for OpenId Connect 671 clients. 673 Note on pre-warmed secrets: An attacker can circumvent the 674 countermeasures described above if he is able to create or capture 675 the respective secret or code_challenge on a device under his 676 control, which is then used in the victim's authorization request. 677 Exact redirect URI matching of authorization requests can prevent the 678 attacker from using the pre-warmed secret in the faked authorization 679 transaction on the victim's device. 680 Unfortunately it does not work for all kinds of OAuth clients. It is 681 effective for web and JS apps and for native apps with claimed URLs. 682 Attacks on native apps using custom schemes or redirect URIs on 683 localhost cannot be prevented this way, except if the AS enforces 684 one-time use for PKCE verifier or Nonce values. 686 3.6. Cross Site Request Forgery 688 An attacker might attempt to inject a request to the redirect URI of 689 the legitimate client on the victim's device, e.g. to cause the 690 client to access resources under the attacker's control. 692 Proposed mitigation: use of XSRF tokens (one-time use), which are 693 bound to the user agent and passed in the state parameter to the 694 authorization server. For more details see [owasp_csrf]. 696 3.7. Access Token Leakage at the Resource Server 698 3.7.1. Access Token Phishing by Counterfeit Resource Server 700 An attacker may setup his own resource server and trick a client into 701 sending access tokens to it, which are valid for other resource 702 servers. If the client sends a valid access token to this 703 counterfeit resource server, the attacker in turn may use that token 704 to access other services on behalf of the resource owner. 706 This attack assumes the client is not bound to a certain resource 707 server (and the respective URL) at development time, but client 708 instances are configured with an resource server's URL at runtime. 709 This kind of late binding is typical in situations, where the client 710 uses a standard API, e.g. for e-Mail, calendar, health, or banking 711 and is configured by an user or administrator for the standard-based 712 service, this particular user or company uses. 714 There are several potential mitigation strategies, which will be 715 discussed in the following sections. 717 3.7.1.1. Metadata 719 An authorization server could provide the client with additional 720 information about the location where it is safe to use its access 721 tokens. 723 In the simplest form, this would require the AS to publish a list of 724 its known resource servers, illustrated in the following example 725 using a metadata parameter "resource_servers": 727 HTTP/1.1 200 OK 728 Content-Type: application/json 730 { 731 "issuer":"https://server.example.com", 732 "authorization_endpoint":"https://server.example.com/authorize", 733 "resource_servers":[ 734 "email.example.com", 735 "storage.example.com", 736 "video.example.com"] 737 ... 738 } 740 The AS could also return the URL(s) an access token is good for in 741 the token response, illustrated by the example return parameter 742 "access_token_resource_server": 744 HTTP/1.1 200 OK 745 Content-Type: application/json;charset=UTF-8 746 Cache-Control: no-store 747 Pragma: no-cache 749 { 750 "access_token":"2YotnFZFEjr1zCsicMWpAA", 751 "access_token_resource_server":"https://hostedresource.example.com/path1", 752 ... 753 } 755 This mitigation strategy would rely on the client to enforce the 756 security policy and to only send access tokens to legitimate 757 destinations. Results of OAuth related security research (see for 758 example [oauth_security_ubc] and [oauth_security_cmu]) indicate a 759 large portion of client implementations do not or fail to properly 760 implement security controls, like state checks. So relying on 761 clients to prevent access token phishing is likely to fail as well. 762 Moreover given the ratio of clients to authorization and resource 763 servers, it is considered the more viable approach to move as much as 764 possible security-related logic to those entities. Clearly, the 765 client has to contribute to the overall security. But there are 766 alternative counter measures, as described in the next sections, 767 which provide a better balance between the involved parties. 769 3.7.1.2. Sender Constrained Access Tokens 771 As the name suggests, sender constraint access token scope the 772 applicability of an access token to a certain sender. This sender is 773 obliged to demonstrate knowledge of a certain secret as prerequisite 774 for the acceptance of that token at a resource server. 776 A typical flow looks like this: 778 1. The authorization server associates data with the access token, 779 which bind this particular token to a certain client. The 780 binding can utilize the client identity, but in most cases the AS 781 utilizes key material (or data derived from the key material) 782 known to the client. 784 2. This key material must be distributed somehow. Either the key 785 material already exists before the AS creates the binding or the 786 AS creates ephemeral keys. The way pre-existing key material is 787 distributed varies among the different approaches. For example, 788 X.509 Certificates can be used in which case the distribution 789 happens explicitly during the enrollment process. Or the key 790 material is created and distributed at the TLS layer, in which 791 case it might automatically happens during the setup of a TLS 792 connection. 794 3. The RS must implement the actual proof of possession check. This 795 is typically done on the application level, it may utilize 796 capabilities of the transport layer (e.g. TLS). Note: replay 797 prevention is required as well! 799 There exists several proposals to demonstrate the proof of possession 800 in the scope of the OAuth working group: 802 o [I-D.ietf-oauth-token-binding]: In this approach, an access tokens 803 is, via the so-called token binding id, bound to key material 804 representing a long term association between a client and a 805 certain TLS host. Negotiation of the key material and proof of 806 possession in the context of a TLS handshake is taken care of by 807 the TLS stack. The client needs to determine the token binding id 808 of the target resource server and pass this data to the access 809 token request. The authorization server than associates the 810 access token with this id. The resource server checks on every 811 invocation that the token binding id of the active TLS connection 812 and the token binding id of associated with the access token 813 match. Since all crypto-related functions are covered by the TLS 814 stack, this approach is very client developer friendly. As a 815 prerequisite, token binding as described in 816 [I-D.ietf-tokbind-https] (including federated token bindings) must 817 be supported on all ends (client, authorization server, resource 818 server). 820 o [I-D.ietf-oauth-mtls]: The approach as specified in this document 821 allow use of mutual TLS for both client authentication and sender 822 constraint access tokens. For the purpose of sender constraint 823 access tokens, the client is identified towards the resource 824 server by the fingerprint of its public key. During processing of 825 an access token request, the authorization server obtains the 826 client's public key from the TLS stack and associates its 827 fingerprint with the respective access tokens. The resource 828 server in the same way obtains the public key from the TLS stack 829 and compares its fingerprint with the fingerprint associated with 830 the access token. 832 o [I-D.ietf-oauth-signed-http-request] specifies an approach to sign 833 HTTP requests. It utilizes [I-D.ietf-oauth-pop-key-distribution] 834 and represents the elements of the signature in a JSON object. 835 The signature is built using JWS. The mechanism has built-in 836 support for signing of HTTP method, query parameters and headers. 837 It also incorporates a timestamp as basis for replay prevention. 839 o [I-D.sakimura-oauth-jpop]: this draft describes different ways to 840 constrain access token usage, namely TLS or request signing. 841 Note: Since the authors of this draft contributed the TLS-related 842 proposal to [I-D.ietf-oauth-mtls], this document only considers 843 the request signing part. For request signing, the draft utilizes 844 [I-D.ietf-oauth-pop-key-distribution] and RFC 7800 [RFC7800]. The 845 signature data is represented in a JWT and JWS is used for 846 signing. Replay prevention is provided by building the signature 847 over a server-provided nonce, client-provided nonce and a nonce 848 counter. 850 [I-D.ietf-oauth-mtls] and [I-D.ietf-oauth-token-binding] are built on 851 top of TLS and this way continue the successful OAuth 2.0 philosophy 852 to leverage TLS to secure OAuth wherever possible. Both mechanisms 853 allow prevention of access token leakage in a fairly client developer 854 friendly way. 856 There are some differences between both approaches: To start with, in 857 [I-D.ietf-oauth-token-binding] all key material is automatically 858 managed by the TLS stack whereas [I-D.ietf-oauth-mtls] requires the 859 developer to create and maintain the key pairs and respective 860 certificates. Use of self-signed certificates, which is supported by 861 the draft, significantly reduce the complexity of this task. 862 Furthermore, [I-D.ietf-oauth-token-binding] allows to use different 863 key pairs for different resource servers, which is a privacy benefit. 864 On the other hand, [I-D.ietf-oauth-mtls] only requires widely 865 deployed TLS features, which means it might be easier to adopt in the 866 short term. 868 Application level signing approaches, like 869 [I-D.ietf-oauth-signed-http-request] and [I-D.sakimura-oauth-jpop] 870 have been debated for a long time in the OAuth working group without 871 a clear outcome. 873 As one advantage, application-level signing allows for end-to-end 874 protection including non-repudiation even if the TLS connection is 875 terminated between client and resource server. But deployment 876 experiences have revealed challenges regarding robustness (e.g. 877 reproduction of the signature base string including correct URL) as 878 well as state management (e.g. replay prevention). 880 This document therefore recommends implementors to consider one of 881 TLS-based approaches wherever possible. 883 3.7.1.3. Audience Restricted Access Tokens 885 An audience restriction essentially restricts the resource server a 886 particular access token can be used at. The authorization server 887 associates the access token with a certain resource server and every 888 resource server is obliged to verify for every request, whether the 889 access token send with that request was meant to be used at the 890 particular resource server. If not, the resource server must refuse 891 to serve the respective request. In the general case, audience 892 restrictions limit the impact of a token leakage. In the case of a 893 counterfeit resource server, it may (as described see below) also 894 prevent abuse of the phished access token at the legitimate resource 895 server. 897 The audience can basically be expressed using logical names or 898 physical addresses (like URLs). In order to prevent phishing, it is 899 necessary to use the actual URL the client will send requests to. In 900 the phishing case, this URL will point to the counterfeit resource 901 server. If the attacker tries to use the access token at the 902 legitimate resource server (which has a different URL), the resource 903 server will detect the mismatch (wrong audience) and refuse to serve 904 the request. 906 In deployments where the authorization server knows the URLs of all 907 resource servers, the authorization server may just refuse to issue 908 access tokens for unknown resource server URLs. 910 The client needs to tell the authorization server, at which URL it 911 will use the access token it is requesting. It could use the 912 mechanism proposed [I-D.campbell-oauth-resource-indicators] or encode 913 the information in the scope value. 915 Instead of the URL, it is also possible to utilize the fingerprint of 916 the resource server's X.509 certificate as audience value. This 917 variant would also allow to detect an attempt to spoof the legit 918 resource server's URL by using a valid TLS certificate obtained from 919 a different CA. It might also be considered a privacy benefit to 920 hide the resource server URL from the authorization server. 922 Audience restriction seems easy to use since it does not require any 923 crypto on the client side. But since every access token is bound to 924 a certain resource server, the client also needs to obtain different 925 RS-specific access tokens, if it wants to access several resource 926 services. [I-D.ietf-oauth-token-binding] has the same property, 927 since different token binding ids must be associated with the access 928 token. [I-D.ietf-oauth-mtls] on the other hand allows a client to 929 use the access token at multiple resource servers. 931 It shall be noted that audience restrictions, or generally speaking 932 an indication by the client to the authorization server where it 933 wants to use the access token, has additional benefits beyond the 934 scope of token leakage prevention. It allows the authorization 935 server to create different access token whose format and content is 936 specifically minted for the respective server. This has huge 937 functional and privacy advantages in deployments using structured 938 access tokens. 940 3.7.2. Compromised Resource Server 942 An attacker may compromise a resource server in order to get access 943 to its resources and other resources of the respective deployment. 944 Such a compromise may range from partial access to the system, e.g. 945 its logfiles, to full control of the respective server. 947 If the attacker was able to take over full control including shell 948 access it will be able to circumvent all controls in place and access 949 resources without access control. It will also get access to access 950 tokens, which are sent to the compromised system and which 951 potentially are valid for access to other resource servers as well. 952 Even if the attacker "only" is able to access logfiles or databases 953 of the server system, it may get access to valid access tokens. 955 Preventing server breaches by way of hardening and monitoring server 956 systems is considered a standard operational procedure and therefore 957 out of scope of this document. This section will focus on the impact 958 of such breaches on OAuth-related parts of the ecosystem, which is 959 the replay of captured access tokens on the compromised resource 960 server and other resource servers of the respective deployment. 962 The following measures shall be taken into account by implementors in 963 order to cope with access token replay: 965 o The resource server must treat access tokens like any other 966 credentials. It is considered good practice to not log them and 967 not to store them in plain text. 969 o Sender constraint access tokens as described in Section 3.7.1.2 970 will prevent the attacker from replaying the access tokens on 971 other resource servers. Depending on the severity of the 972 penetration, it will also prevent replay on the compromised 973 system. 975 o Audience restriction as described in Section 3.7.1.3 may be used 976 to prevent replay of captured access tokens on other resource 977 servers. 979 3.8. Open Redirection 981 3.8.1. Authorization Server as Open Redirector 983 Attackers could try to utilize a user's trust in the authorization 984 server (and its URL in particular) for performing phishing attacks. 985 The attacker could send an authorization request with an invalid 986 combination of client_id and redirect_uri. [RFC6749], section 987 4.1.2.1, already states that the AS MUST NOT automatically redirect 988 the user agent in this case to prevent open redirection. 990 But as described in [I-D.ietf-oauth-closing-redirectors], the 991 attacker could also attempt to register a client and intentionally 992 send an erroneous authorization request, e.g. by using an invalid 993 scope value. According to [RFC6749], the AS would send the user 994 agent to the redirect_uri with an "invalid_request" error response. 995 This is dangerous because the authorization server would serve as an 996 open redirector. Therefore this draft recommends that every invalid 997 authorization request MUST NOT automatically redirect the user agent 998 to the client's redirect URI. 1000 3.8.2. Clients as Open Redirector 1002 Client MUST not expose URLs which could be utilized as open 1003 redirector. An open redirector is a way to cause the recipient of a 1004 HTTP request to issue a redirect to a target URL that is passed as a 1005 parameter. Attackers may utilize such a mechanism to produce URLs, 1006 which appear to point to the client, which might trick users to trust 1007 the URL and follow it in her browser. Another abuse case is to 1008 produce URLs pointing to the client and utilize them to impersonate a 1009 client with an authorization server. 1011 In order to prevent open redirection, clients should only expose such 1012 a function, if the target URLs are whitelisted or if the origin of a 1013 request can be authenticated. 1015 3.9. TLS Terminating Reverse Proxies 1017 A common deployment architecture for HTTP applications is to have the 1018 application server sitting behind a reverse proxy, which terminates 1019 the TLS connection and dispatches the incoming requests to the 1020 respective application server nodes. 1022 This section highlights some attack angles of this deployment 1023 architecture, which are relevant to OAuth, and give recommendations 1024 for security controls. 1026 In some situations, the reverse proxy needs to pass security-related 1027 data to the upstream application servers for further processing. 1028 Examples include the IP address of the request originator, token 1029 binding ids and authenticated TLS client certificates. 1031 If the reverse proxy would pass through any header sent from the 1032 outside, an attacker could try to directly send the faked header 1033 values through the proxy to the application server in order to 1034 circumvent security controls that way. For example, it is standard 1035 practice of reverse proxies to accept "forwarded_for" headers and 1036 just add the origin of the inbound request (making it a list). 1037 Depending on the logic performed in the application server, the 1038 attacker could simply add a whitelisted IP address to the header and 1039 render a IP whitelist useless. A reverse proxy must therefore 1040 sanitize any inbound requests to ensure the authenticity and 1041 integrity of all header values relevant for the security of the 1042 application servers. 1044 If an attacker would be able to get access to the internal network 1045 between proxy and application server, it could also try to circumvent 1046 security controls in place. It is therefore important to ensure the 1047 authenticity of the communicating entities. Furthermore, the 1048 communication link between reverse proxy and application server must 1049 therefore be protected against tapping and injection (including 1050 replay prevention). 1052 4. Acknowledgements 1054 We would like to thank Jim Manico, Phil Hunt, Nat Sakimura, Christian 1055 Mainka, and Brian Campbell for their valuable feedback. 1057 5. IANA Considerations 1059 This draft includes no request to IANA. 1061 6. Security Considerations 1063 All relevant security considerations have been given in the 1064 functional specification. 1066 7. References 1068 7.1. Normative References 1070 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1071 Resource Identifier (URI): Generic Syntax", STD 66, 1072 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1073 . 1075 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1076 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1077 . 1079 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1080 Framework: Bearer Token Usage", RFC 6750, 1081 DOI 10.17487/RFC6750, October 2012, 1082 . 1084 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 1085 Threat Model and Security Considerations", RFC 6819, 1086 DOI 10.17487/RFC6819, January 2013, 1087 . 1089 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1090 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1091 DOI 10.17487/RFC7231, June 2014, 1092 . 1094 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 1095 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 1096 RFC 7591, DOI 10.17487/RFC7591, July 2015, 1097 . 1099 7.2. Informative References 1101 [I-D.bradley-oauth-jwt-encoded-state] 1102 Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding 1103 claims in the OAuth 2 state parameter using a JWT", draft- 1104 bradley-oauth-jwt-encoded-state-08 (work in progress), 1105 January 2018. 1107 [I-D.campbell-oauth-resource-indicators] 1108 Campbell, B., Bradley, J., and H. Tschofenig, "Resource 1109 Indicators for OAuth 2.0", draft-campbell-oauth-resource- 1110 indicators-02 (work in progress), November 2016. 1112 [I-D.ietf-oauth-closing-redirectors] 1113 Bradley, J., Sanso, A., and H. Tschofenig, "OAuth 2.0 1114 Security: Closing Open Redirectors in OAuth", draft-ietf- 1115 oauth-closing-redirectors-00 (work in progress), February 1116 2016. 1118 [I-D.ietf-oauth-discovery] 1119 Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 1120 Authorization Server Metadata", draft-ietf-oauth- 1121 discovery-10 (work in progress), March 2018. 1123 [I-D.ietf-oauth-jwsreq] 1124 Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization 1125 Framework: JWT Secured Authorization Request (JAR)", 1126 draft-ietf-oauth-jwsreq-15 (work in progress), July 2017. 1128 [I-D.ietf-oauth-mix-up-mitigation] 1129 Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up 1130 Mitigation", draft-ietf-oauth-mix-up-mitigation-01 (work 1131 in progress), July 2016. 1133 [I-D.ietf-oauth-mtls] 1134 Campbell, B., Bradley, J., Sakimura, N., and T. 1135 Lodderstedt, "OAuth 2.0 Mutual TLS Client Authentication 1136 and Certificate Bound Access Tokens", draft-ietf-oauth- 1137 mtls-07 (work in progress), January 2018. 1139 [I-D.ietf-oauth-pop-key-distribution] 1140 Bradley, J., Hunt, P., Jones, M., and H. Tschofenig, 1141 "OAuth 2.0 Proof-of-Possession: Authorization Server to 1142 Client Key Distribution", draft-ietf-oauth-pop-key- 1143 distribution-03 (work in progress), February 2017. 1145 [I-D.ietf-oauth-signed-http-request] 1146 Richer, J., Bradley, J., and H. Tschofenig, "A Method for 1147 Signing HTTP Requests for OAuth", draft-ietf-oauth-signed- 1148 http-request-03 (work in progress), August 2016. 1150 [I-D.ietf-oauth-token-binding] 1151 Jones, M., Campbell, B., Bradley, J., and W. Denniss, 1152 "OAuth 2.0 Token Binding", draft-ietf-oauth-token- 1153 binding-06 (work in progress), March 2018. 1155 [I-D.ietf-tokbind-https] 1156 Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, 1157 N., and J. Hodges, "Token Binding over HTTP", draft-ietf- 1158 tokbind-https-12 (work in progress), January 2018. 1160 [I-D.sakimura-oauth-jpop] 1161 Sakimura, N., Li, K., and J. Bradley, "The OAuth 2.0 1162 Authorization Framework: JWT Pop Token Usage", draft- 1163 sakimura-oauth-jpop-04 (work in progress), March 2017. 1165 [oauth-v2-form-post-response-mode] 1166 Microsoft and Ping Identity, "OAuth 2.0 Form Post Response 1167 Mode", April 2015, . 1170 [oauth_security_cmu] 1171 Carnegie Mellon University, Carnegie Mellon University, 1172 Microsoft Research, Carnegie Mellon University, Carnegie 1173 Mellon University, and Carnegie Mellon University, "OAuth 1174 Demystified for Mobile Application Developers", November 1175 2014. 1177 [oauth_security_ubc] 1178 University of British Columbia and University of British 1179 Columbia, "The Devil is in the (Implementation) Details: 1180 An Empirical Analysis of OAuth SSO Systems", October 2012, 1181 . 1183 [OpenID] NRI, Ping Identity, Microsoft, Google, and Salesforce, 1184 "OpenID Connect Core 1.0 incorporating errata set 1", Nov 1185 2014, 1186 . 1188 [owasp] "Open Web Application Security Project Home Page", 1189 . 1191 [owasp_csrf] 1192 "Cross-Site Request Forgery (CSRF) Prevention Cheat 1193 Sheet", . 1196 [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 1197 for Code Exchange by OAuth Public Clients", RFC 7636, 1198 DOI 10.17487/RFC7636, September 2015, 1199 . 1201 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 1202 Possession Key Semantics for JSON Web Tokens (JWTs)", 1203 RFC 7800, DOI 10.17487/RFC7800, April 2016, 1204 . 1206 [webappsec-referrer-policy] 1207 Google Inc. and Google Inc., "Referrer Policy", April 1208 2017, . 1210 Appendix A. Document History 1212 [[ To be removed from the final specification ]] 1214 -05 1216 o Completed sections on code leakage via referrer header, attacks in 1217 browser, mix-up, and CSRF 1219 o Reworked Code Injection Section 1221 o Added reference to OpenID Connect spec 1223 o removed refresh token leakage as respective considerations have 1224 been given in section 10.4 of RFC 6749 1226 o first version on open redirection 1228 o incorporated Christian Mainka's review feedback 1230 -04 1232 o Restructured document for better readability 1234 o Added best practices on Token Leakage prevention 1236 -03 1238 o Added section on Access Token Leakage at Resource Server 1239 o incorporated Brian Campbell's findings 1241 -02 1243 o Folded Mix up and Access Token leakage through a bad AS into new 1244 section for dynamic OAuth threats 1246 o reworked dynamic OAuth section 1248 -01 1250 o Added references to mitigation methods for token leakage 1252 o Added reference to Token Binding for Authorization Code 1254 o incorporated feedback of Phil Hunt 1256 o fixed numbering issue in attack descriptions in section 2 1258 -00 (WG document) 1260 o turned the ID into a WG document and a BCP 1262 o Added federated app login as topic in Other Topics 1264 Authors' Addresses 1266 Torsten Lodderstedt (editor) 1267 YES.com AG 1269 Email: torsten@lodderstedt.net 1271 John Bradley 1272 Yubico 1274 Email: ve7jtb@ve7jtb.com 1276 Andrey Labunets 1277 Facebook 1279 Email: isciurus@fb.com