idnits 2.17.1 draft-ietf-oauth-security-topics-09.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 are 2 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 'SHOULD not' in this paragraph: The page rendered as a result of the OAuth authorization response and the authorization endpoint SHOULD not include third-party resources or links to external sites. == 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: AS which redirect a request that potentially contains user credentials therefore MUST not use the HTTP 307 status code for redirection. If an HTTP redirection (and not, for example, JavaScript) is used for such a request, AS SHOULD use HTTP status code 303 "See Other". -- The document date (November 09, 2018) is 1993 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) == Unused Reference: 'RFC2119' is defined on line 1344, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6819 ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) == Outdated reference: A later version (-34) exists of draft-ietf-oauth-jwsreq-17 == Outdated reference: A later version (-17) exists of draft-ietf-oauth-mtls-12 == Outdated reference: A later version (-07) exists of draft-ietf-oauth-pop-key-distribution-04 == Outdated reference: A later version (-08) exists of draft-ietf-oauth-resource-indicators-01 == Outdated reference: A later version (-05) exists of draft-sakimura-oauth-jpop-04 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 3 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 4 Intended status: Best Current Practice J. Bradley 5 Expires: May 13, 2019 Yubico 6 A. Labunets 7 Facebook 8 D. Fett 9 yes.com 10 November 09, 2018 12 OAuth 2.0 Security Best Current Practice 13 draft-ietf-oauth-security-topics-09 15 Abstract 17 This document describes best current security practice for OAuth 2.0. 18 It updates and extends the OAuth 2.0 Security Threat Model to 19 incorporate practical experiences gathered since OAuth 2.0 was 20 published and covers new threats relevant due to the broader 21 application of OAuth 2.0. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 13, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Protecting Redirect-Based Flows . . . . . . . . . . . . . 4 60 2.1.1. Authorization Code Grant . . . . . . . . . . . . . . 5 61 2.1.2. Implicit Grant . . . . . . . . . . . . . . . . . . . 5 62 2.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 5 63 2.3. Access Token Privilege Restriction . . . . . . . . . . . 6 64 3. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 6 65 3.1. Insufficient Redirect URI Validation . . . . . . . . . . 6 66 3.1.1. Attacks on Authorization Code Grant . . . . . . . . . 7 67 3.1.2. Attacks on Implicit Grant . . . . . . . . . . . . . . 8 68 3.1.3. Proposed Countermeasures . . . . . . . . . . . . . . 9 69 3.2. Credential Leakage via Referrer Headers . . . . . . . . . 10 70 3.2.1. Leakage from the OAuth client . . . . . . . . . . . . 10 71 3.2.2. Leakage from the Authorization Server . . . . . . . . 10 72 3.2.3. Consequences . . . . . . . . . . . . . . . . . . . . 11 73 3.2.4. Proposed Countermeasures . . . . . . . . . . . . . . 11 74 3.3. Attacks through the Browser History . . . . . . . . . . . 12 75 3.3.1. Code in Browser History . . . . . . . . . . . . . . . 12 76 3.3.2. Access Token in Browser History . . . . . . . . . . . 12 77 3.4. Mix-Up . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 3.4.1. Attack Description . . . . . . . . . . . . . . . . . 13 79 3.4.2. Countermeasures . . . . . . . . . . . . . . . . . . . 15 80 3.5. Authorization Code Injection . . . . . . . . . . . . . . 15 81 3.5.1. Proposed Countermeasures . . . . . . . . . . . . . . 17 82 3.6. Access Token Injection . . . . . . . . . . . . . . . . . 19 83 3.6.1. Proposed Countermeasures . . . . . . . . . . . . . . 19 84 3.7. Cross Site Request Forgery . . . . . . . . . . . . . . . 19 85 3.7.1. Proposed Countermeasures . . . . . . . . . . . . . . 20 86 3.8. Access Token Leakage at the Resource Server . . . . . . . 20 87 3.8.1. Access Token Phishing by Counterfeit Resource Server 20 88 3.8.1.1. Metadata . . . . . . . . . . . . . . . . . . . . 20 89 3.8.1.2. Sender Constrained Access Tokens . . . . . . . . 22 90 3.8.1.3. Audience Restricted Access Tokens . . . . . . . . 24 91 3.8.2. Compromised Resource Server . . . . . . . . . . . . . 25 92 3.9. Open Redirection . . . . . . . . . . . . . . . . . . . . 26 93 3.9.1. Authorization Server as Open Redirector . . . . . . . 26 94 3.9.2. Clients as Open Redirector . . . . . . . . . . . . . 27 95 3.10. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 27 96 3.11. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 28 98 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 99 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29 101 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 102 7.1. Normative References . . . . . . . . . . . . . . . . . . 29 103 7.2. Informative References . . . . . . . . . . . . . . . . . 29 104 Appendix A. Document History . . . . . . . . . . . . . . . . . . 33 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 107 1. Introduction 109 It's been a while since OAuth has been published in RFC 6749 110 [RFC6749] and RFC 6750 [RFC6750]. Since publication, OAuth 2.0 has 111 gotten massive traction in the market and became the standard for API 112 protection and, as foundation of OpenID Connect [OpenID], identity 113 providing. While OAuth was used in a variety of scenarios and 114 different kinds of deployments, the following challenges could be 115 observed: 117 o OAuth implementations are being attacked through known 118 implementation weaknesses and anti-patterns (CSRF, referrer 119 header). Although most of these threats are discussed in the 120 OAuth 2.0 Threat Model and Security Considerations [RFC6819], 121 continued exploitation demonstrates there may be a need for more 122 specific recommendations or that the existing mitigations are too 123 difficult to deploy. 125 o Technology has changed, e.g., the way browsers treat fragments in 126 some situations, which may change the implicit grant's underlying 127 security model. 129 o OAuth is used in much more dynamic setups than originally 130 anticipated, creating new challenges with respect to security. 131 Those challenges go beyond the original scope of RFC 6749 132 [RFC6749], RFC 6750 [RFC6749], and RFC 6819 [RFC6819]. 134 OAuth initially assumed a static relationship between client, 135 authorization server and resource servers. The URLs of AS and RS 136 were known to the client at deployment time and built an anchor for 137 the trust relationship among those parties. The validation whether 138 the client talks to a legitimate server was based on TLS server 139 authentication (see [RFC6819], Section 4.5.4). With the increasing 140 adoption of OAuth, this simple model dissolved and, in several 141 scenarios, was replaced by a dynamic establishment of the 142 relationship between clients on one side and the authorization and 143 resource servers of a particular deployment on the other side. This 144 way the same client could be used to access services of different 145 providers (in case of standard APIs, such as e-Mail or OpenID 146 Connect) or serves as a frontend to a particular tenant in a multi- 147 tenancy. Extensions of OAuth, such as [RFC7591] and [RFC8414] were 148 developed in order to support the usage of OAuth in dynamic 149 scenarios. As a challenge to the community, such usage scenarios 150 open up new attack angles, which are discussed in this document. 152 The remainder of the document is organized as follows: The next 153 section summarizes the most important recommendations of the OAuth 154 working group for every OAuth implementor. Afterwards, a detailed 155 analysis of the threats and implementation issues which can be found 156 in the wild today is given along with a discussion of potential 157 countermeasures. 159 2. Recommendations 161 This section describes the set of security mechanisms the OAuth 162 working group recommendeds to OAuth implementers. 164 2.1. Protecting Redirect-Based Flows 166 Authorization servers SHALL utilize exact matching of client redirect 167 URIs against pre-registered URIs. This measure contributes to the 168 prevention of leakage of authorization codes and access tokens 169 (depending on the grant type). It also helps to detect mix-up 170 attacks. 172 Clients SHALL avoid any redirects or forwards which can be 173 parameterized by URI query parameters, in order to provide a further 174 layer of defence against token leakage. If there is a need for this 175 kind of redirects, clients are advised to implement appropriate 176 countermeasures against open redirection, e.g., as described by the 177 OWASP [owasp]. 179 Clients SHALL ensure to only process redirect responses of the OAuth 180 authorization server they send the respective request to and in the 181 same user agent this request was initiated in. In particular, 182 clients SHALL implement appropriate CSRF prevention by utilizing one- 183 time use CSRF tokens carried in the "state" parameter, which are 184 securely bound to the user agent. Moreover, the client SHALL 185 memorize which authorization server it sent an authorization request 186 to and bind this information to the user agent and ensure any sub- 187 sequent messages are sent to the same authorization server. 188 Furthermore, clients SHOULD use AS-specific redirect URIs as a means 189 to identify the AS a particular response came from. Matching this 190 with the before mentioned information regarding the AS the client 191 sent the request to helps to detect mix-up attacks. 193 Note: [I-D.bradley-oauth-jwt-encoded-state] gives advice on how to 194 implement CSRF prevention and AS matching using signed JWTs in the 195 "state" parameter. 197 2.1.1. Authorization Code Grant 199 Clients utilizing the authorization grant type SHALL use PKCE 200 [RFC7636] in order to (with the help of the authorization server) 201 detect and prevent attempts to inject (replay) authorization codes 202 into the authorization response. The PKCE challenges must be 203 transaction-specific and securely bound to the user agent in which 204 the transaction was started. OpenID Connect clients MAY use the 205 "nonce" parameter of the OpenID Connect authentication request as 206 specified in [OpenID] in conjunction with the corresponding ID Token 207 claim for the same purpose. 209 Note: although PKCE so far was recommended as a mechanism to protect 210 native apps, this advice applies to all kinds of OAuth clients, 211 including web applications. 213 Authorization servers SHALL consider the recommendations given in 214 [RFC6819], Section 4.4.1.1, on authorization code replay prevention. 216 2.1.2. Implicit Grant 218 The implicit grant (response type "token") and other response types 219 causing the authorization server to issue access tokens in the 220 authorization response are vulnerable to access token leakage and 221 access token replay as described in Section 3.1, Section 3.2, 222 Section 3.3, and Section 3.6. 224 In order to avoid these issues, Clients SHOULD NOT use the implicit 225 grant and any other response type causing the authorization server to 226 issue an access token in the authorization response. 228 Clients SHOULD instead use the response type "code" (aka 229 authorization code grant type) as specified in Section 2.1.1 or any 230 other response type that does not cause the authorization server to 231 issue access tokens in the authorization response. 233 2.2. Token Replay Prevention 235 Authorization servers SHOULD use TLS-based methods for sender 236 constrained access tokens as described in Section 3.8.1.2, such as 237 token binding [I-D.ietf-oauth-token-binding] or Mutual TLS for OAuth 238 2.0 [I-D.ietf-oauth-mtls] in order to prevent token replay. It is 239 also recommended to use end-to-end TLS whenever possible. 241 2.3. Access Token Privilege Restriction 243 The privileges associated with an access token SHOULD be restricted 244 to the minimum required for the particular application or use case. 245 This prevents clients from exceeding the privileges authorized by the 246 resource owner. It also prevents users from exceeding their 247 privileges authorized by the respective security policy. Privilege 248 restrictions also limit the impact of token leakage although more 249 effective counter-measures are described in Section 2.2. 251 In particular, access tokens SHOULD be restricted to certain resource 252 servers, preferably to a single resource server. To put this into 253 effect, the authorization server associates the access token with 254 certain resource servers and every resource server is obliged to 255 verify for every request, whether the access token sent with that 256 request was meant to be used for that particular resource server. If 257 not, the resource server MUST refuse to serve the respective request. 258 Clients and authorization servers MAY utilize the parameters "scope" 259 or "resource" as specified in [RFC6749] and 260 [I-D.ietf-oauth-resource-indicators], respectively, to determine the 261 resource server they want to access. 263 Additionally, access tokens SHOULD be restricted to certain resources 264 and actions on resource servers or resources. To put this into 265 effect, the authorization server associates the access token with the 266 respective resource and actions and every resource server is obliged 267 to verify for every request, whether the access token sent with that 268 request was meant to be used for that particular action on the 269 particular resource. If not, the resource server must refuse to 270 serve the respective request. Clients and authorization servers MAY 271 utilize the parameter "scope" as specified in [RFC6749] to determine 272 those resources and/or actions. 274 3. Attacks and Mitigations 276 This section gives a detailed description of attacks on OAuth 277 implementations, along with potential countermeasures. This section 278 complements and enhances the description given in [RFC6819]. 280 3.1. Insufficient Redirect URI Validation 282 Some authorization servers allow clients to register redirect URI 283 patterns instead of complete redirect URIs. In those cases, the 284 authorization server, at runtime, matches the actual redirect URI 285 parameter value at the authorization endpoint against this pattern. 286 This approach allows clients to encode transaction state into 287 additional redirect URI parameters or to register just a single 288 pattern for multiple redirect URIs. As a downside, it turned out to 289 be more complex to implement and error prone to manage than exact 290 redirect URI matching. Several successful attacks have been observed 291 in the wild, which utilized flaws in the pattern matching 292 implementation or concrete configurations. Such a flaw effectively 293 breaks client identification or authentication (depending on grant 294 and client type) and allows the attacker to obtain an authorization 295 code or access token, either: 297 o by directly sending the user agent to a URI under the attackers 298 control or 300 o by exposing the OAuth credentials to an attacker by utilizing an 301 open redirector at the client in conjunction with the way user 302 agents handle URL fragments. 304 3.1.1. Attacks on Authorization Code Grant 306 For a public client using the grant type code, an attack would look 307 as follows: 309 Let's assume the redirect URL pattern "https://*.somesite.example/*" 310 had been registered for the client "s6BhdRkqt3". This pattern allows 311 redirect URIs pointing to any host residing in the domain 312 somesite.example. So if an attacker manages to establish a host or 313 subdomain in somesite.example he can impersonate the legitimate 314 client. Assume the attacker sets up the host 315 "evil.somesite.example". 317 (1) The attacker needs to trick the user into opening a tampered URL 318 in his browser, which launches a page under the attacker's 319 control, say "https://www.evil.example". 321 (2) This URL initiates an authorization request with the client id 322 of a legitimate client to the authorization endpoint. This is 323 the example authorization request (line breaks are for display 324 purposes only): 326 GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz 327 &redirect_uri=https%3A%2F%2Fevil.somesite.example%2Fcb HTTP/1.1 328 Host: server.somesite.example 330 (3) The authorization server validates the redirect URI in order to 331 identify the client. Since the pattern allows arbitrary domains 332 host names in "somesite.example", the authorization request is 333 processed under the legitimate client's identity. This includes 334 the way the request for user consent is presented to the user. 335 If auto-approval is allowed (which is not recommended for public 336 clients according to [RFC6749]), the attack can be performed 337 even easier. 339 (4) If the user does not recognize the attack, the code is issued 340 and directly sent to the attacker's client. 342 (5) Since the attacker impersonated a public client, it can directly 343 exchange the code for tokens at the respective token endpoint. 345 Note: This attack will not directly work for confidential clients, 346 since the code exchange requires authentication with the legitimate 347 client's secret. The attacker will need to impersonate or utilize 348 the legitimate client to redeem the code (e.g., by performing a code 349 injection attack). This kind of injections is covered in 350 Section Authorization Code Injection. 352 3.1.2. Attacks on Implicit Grant 354 The attack described above works for the implicit grant as well. If 355 the attacker is able to send the authorization response to a URI 356 under his control, he will directly get access to the fragment 357 carrying the access token. 359 Additionally, implicit clients can be subject to a further kind of 360 attacks. It utilizes the fact that user agents re-attach fragments 361 to the destination URL of a redirect if the location header does not 362 contain a fragment (see [RFC7231], Section 9.5). The attack 363 described here combines this behavior with the client as an open 364 redirector in order to get access to access tokens. This allows 365 circumvention even of strict redirect URI patterns (but not strict 366 URL matching!). 368 Assume the pattern for client "s6BhdRkqt3" is 369 "https://client.somesite.example/cb?*", i.e., any parameter is 370 allowed for redirects to "https://client.somesite.example/cb". 371 Unfortunately, the client exposes an open redirector. This endpoint 372 supports a parameter "redirect_to" which takes a target URL and will 373 send the browser to this URL using an HTTP Location header redirect 374 303. 376 (1) Same as above, the attacker needs to trick the user into opening 377 a tampered URL in his browser, which launches a page under the 378 attacker's control, say "https://www.evil.example". 380 (2) The URL initiates an authorization request, which is very 381 similar to the attack on the code flow. As differences, it 382 utilizes the open redirector by encoding 383 "redirect_to=https://client.evil.example" into the redirect URI 384 and it uses the response type "token" (line breaks are for 385 display purposes only): 387 GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz 388 &redirect_uri=https%3A%2F%2Fclient.somesite.example%2Fcb%26redirect_to 389 %253Dhttps%253A%252F%252Fclient.evil.example%252Fcb HTTP/1.1 390 Host: server.somesite.example 392 (3) Since the redirect URI matches the registered pattern, the 393 authorization server allows the request and sends the resulting 394 access token with a 303 redirect (some response parameters are 395 omitted for better readability) 397 HTTP/1.1 303 See Other 398 Location: https://client.somesite.example/cb? 399 redirect_to%3Dhttps%3A%2F%2Fclient.evil.example%2Fcb 400 #access_token=2YotnFZFEjr1zCsicMWpAA&... 402 (4) At example.com, the request arrives at the open redirector. It 403 will read the redirect parameter and will issue an HTTP 303 404 Location header redirect to the URL 405 "https://client.evil.example/cb". 407 HTTP/1.1 303 See Other 408 Location: https://client.evil.example/cb 410 (5) Since the redirector at client.somesite.example does not include 411 a fragment in the Location header, the user agent will re-attach 412 the original fragment 413 "#access_token=2YotnFZFEjr1zCsicMWpAA&..." to the URL and will 414 navigate to the following URL: 416 https://client.evil.example/cb#access_token=2YotnFZFEjr1zCsicMWpAA&... 418 (6) The attacker's page at client.evil.example can access the 419 fragment and obtain the access token. 421 3.1.3. Proposed Countermeasures 423 The complexity of implementing and managing pattern matching 424 correctly obviously causes security issues. This document therefore 425 proposes to simplify the required logic and configuration by using 426 exact redirect URI matching only. This means the authorization 427 server shall compare the two URIs using simple string comparison as 428 defined in [RFC3986], Section 6.2.1.. 430 Additional recommendations: 432 o Servers on which callbacks are hosted must not expose open 433 redirectors (see Section 3.9). 435 o Clients MAY drop fragments via intermediary URLs with "fix 436 fragments" (see [fb_fragments]) to prevent the user agent from 437 appending any unintended fragments. 439 o Clients SHOULD use the authorization code response type instead of 440 response types causing access token issuance at the authorization 441 endpoint. This offers countermeasures against reuse of leaked 442 credentials through the exchange process with the authorization 443 server and token replay through certificate binding of the access 444 tokens. 446 As an alternative to exact redirect URI matching, the AS could also 447 authenticate clients, e.g., using [I-D.ietf-oauth-jwsreq]. 449 3.2. Credential Leakage via Referrer Headers 451 Authorization codes or values of "state" can unintentionally be 452 disclosed to attackers through the referrer header, by leaking either 453 from a client's web site or from an AS's web site. Note: even if 454 specified otherwise in [RFC2616], section 14.36, the same may happen 455 to access tokens conveyed in URI fragments due to browser 456 implementation issues as illustrated by Chromium Issue 168213 457 [bug.chromium]. 459 3.2.1. Leakage from the OAuth client 461 This requires that the client, as a result of a successful 462 authorization request, renders a page that 464 o contains links to other pages under the attacker's control (ads, 465 faq, ...) and a user clicks on such a link, or 467 o includes third-party content (iframes, images, etc.) for example 468 if the page contains user-generated content (blog). 470 As soon as the browser navigates to the attacker's page or loads the 471 third-party content, the attacker receives the authorization response 472 URL and can extract "code", "access token", or "state". 474 3.2.2. Leakage from the Authorization Server 476 In a similar way, an attacker can learn "state" if the authorization 477 endpoint at the authorization server contains links or third-party 478 content as above. 480 3.2.3. Consequences 482 An attacker that learns a valid code or access token through a 483 referrer header can perform the attacks as described in 484 Section 3.1.1, Section 3.5, and Section 3.6. If the attacker learns 485 "state", the CSRF protection achieved by using "state" is lost, 486 resulting in CSRF attacks as described in [RFC6819], 487 Section 4.4.1.8.. 489 3.2.4. Proposed Countermeasures 491 The page rendered as a result of the OAuth authorization response and 492 the authorization endpoint SHOULD not include third-party resources 493 or links to external sites. 495 The following measures further reduce the chances of a successful 496 attack: 498 o Authorization codes SHOULD be invalidated by the AS after their 499 first use at the token endpoint. For example, if an AS 500 invalidated the code after the legitimate client redeemed it, the 501 attacker would fail exchanging this code later. (This does not 502 mitigate the attack if the attacker manages to exchange the code 503 for a token before the legitimate client does so.) 505 o The "state" value SHOULD be invalidated by the client after its 506 first use at the redirection endpoint. If this is implemented, 507 and an attacker receives a token through the referrer header from 508 the client's web site, the "state" was already used, invalidated 509 by the client and cannot be used again by the attacker. (This 510 does not help if the "state" leaks from the AS's web site, since 511 then the "state" has not been used at the redirection endpoint at 512 the client yet.) 514 o Bind authorization code to a confidential client or PKCE 515 challenge. In this case, the attacker lacks the secret to request 516 the code exchange. 518 o Suppress the referrer header by adding the attribute 519 "rel="noreferrer"" to HTML links or by applying an appropriate 520 Referrer Policy [webappsec-referrer-policy] to the document 521 (either as part of the "referrer" meta attribute or by setting a 522 Referrer-Policy header). 524 o Use authorization code instead of response types causing access 525 token issuance from the authorization endpoint. This provides 526 countermeasures against leakage on the OAuth protocol level 527 through the code exchange process with the authorization server. 529 o Additionally, one might use the form post response mode instead of 530 redirect for authorization response (see 531 [oauth-v2-form-post-response-mode]). 533 3.3. Attacks through the Browser History 535 Authorization codes and access tokens can end up in the browser's 536 history of visited URLs, enabling the attacks described in the 537 following. 539 3.3.1. Code in Browser History 541 When a browser navigates to "client.example/ 542 redirection_endpoint?code=abcd" as a result of a redirect from a 543 provider's authorization endpoint, the URL including the 544 authorization code may end up in the browser's history. An attacker 545 with access to the device could obtain the code and try to replay it. 547 Proposed countermeasures: 549 o Authorization code replay prevention as described in [RFC6819], 550 Section 4.4.1.1, and Section 3.5 552 o Use form post response mode instead of redirect for authorization 553 response (see [oauth-v2-form-post-response-mode]) 555 3.3.2. Access Token in Browser History 557 An access token may end up in the browser history if a a client or 558 just a web site, which already has a token, deliberately navigates to 559 a page like "provider.com/get_user_profile?access_token=abcdef.". 560 Actually [RFC6750] discourages this practice and asks to transfer 561 tokens via a header, but in practice web sites often just pass access 562 token in query parameters. 564 In case of implicit grant, a URL like "client.example/ 565 redirection_endpoint#access_token=abcdef" may also end up in the 566 browser history as a result of a redirect from a provider's 567 authorization endpoint. 569 Proposed countermeasures: 571 o Replace implicit flow with postmessage communication or the 572 authorization code grant 574 o Never pass access tokens in URL query parameters 576 3.4. Mix-Up 578 Mix-up is an attack on scenarios where an OAuth client interacts with 579 multiple authorization servers, as is usually the case when dynamic 580 registration is used. The goal of the attack is to obtain an 581 authorization code or an access token by tricking the client into 582 sending those credentials to the attacker instead of using them at 583 the respective endpoint at the authorization/resource server. 585 3.4.1. Attack Description 587 For a detailed attack description, refer to [arXiv.1601.01229] and 588 [I-D.ietf-oauth-mix-up-mitigation]. The description here closely 589 follows [arXiv.1601.01229], with variants of the attack outlined 590 below. 592 Preconditions: For the attack to work, we assume that 594 (1) the implicit or authorization code grant are used with multiple 595 AS of which one is considered "honest" (H-AS) and one is 596 operated by the attacker (A-AS), 598 (2) the client stores the AS chosen by the user in a session bound 599 to the user's browser and uses the same redirection endpoint URI 600 for each AS, and 602 (3) the attacker can manipulate the first request/response pair from 603 a user's browser to the client (in which the user selects a 604 certain AS and is then redirected by the client to that AS). 606 Some of the attack variants described below require different 607 preconditions. 609 In the following, we assume that the client is registered with H-AS 610 (URI: "https://honest.as.example", client id: 7ZGZldHQ) and with A-AS 611 (URI: "https://attacker.example", client id: 666RVZJTA). 613 Attack on the authorization code grant: 615 (1) The user selects to start the grant using H-AS (e.g., by 616 clicking on a button at the client's website). 618 (2) The attacker intercepts this request and changes the user's 619 selection to "A-AS". 621 (3) The client stores in the user's session that the user selected 622 "A-AS" and redirects the user to A-AS's authorization endpoint 623 by sending the following response: 625 HTTP/1.1 303 See Other 626 Location: https://attacker.example/authorize?response_type=code&client_id=666RVZJTA 628 (4) Now the attacker intercepts this response and changes the 629 redirection such that the user is being redirected to H-AS. The 630 attacker also replaces the client id of the client at A-AS with 631 the client's id at H-AS, resulting in the following response 632 being sent to the browser: 634 HTTP/1.1 303 See Other 635 Location: https://honest.as.example/authorize?response_type=code&client_id=7ZGZldHQ 637 (5) Now, the user authorizes the client to access her resources at 638 H-AS. H-AS issues a code and sends it (via the browser) back to 639 the client. 641 (6) Since the client still assumes that the code was issued by A-AS, 642 it will try to redeem the code at A-AS's token endpoint. 644 (7) The attacker therefore obtains code and can either exchange the 645 code for an access token (for public clients) or perform a code 646 injection attack as described in Section 3.5. 648 Variants: 650 Implicit Grant In the implicit grant, the attacker receives an 651 access token instead of the code; the rest of the attack 652 works as above. 654 Mix-Up Without Interception A variant of the above attack works even 655 if the first request/response pair cannot be intercepted (for 656 example, because TLS is used to protect these messages): 657 Here, we assume that the user wants to start the grant using 658 A-AS (and not H-AS). After the client redirected the user to 659 the authorization endpoint at A-AS, the attacker immediately 660 redirects the user to H-AS (changing the client id 661 "7ZGZldHQ"). (A vigilant user might at this point detect 662 that she intended to use A-AS instead of H-AS.) The attack 663 now proceeds exactly as in step 1 of the attack description 664 above. 666 Per-AS Redirect URIs If clients use different redirect URIs for 667 different ASs, do not store the selected AS in the user's 668 session, and ASs do not check the redirect URIs properly, 669 attackers can mount an attack called "Cross-Social Network 670 Request Forgery". We refer to [oauth_security_jcs_14] for 671 details. 673 OpenID Connect There are several variants that can be used to attack 674 OpenID Connect. They are described in detail in 675 [arXiv.1704.08539], Appendix A, and [arXiv.1508.04324v2], 676 Section 6 ("Malicious Endpoints Attacks"). 678 3.4.2. Countermeasures 680 In scenarios where an OAuth client interacts with multiple 681 authorization servers, clients MUST prevent mix-up attacks. 683 Potential countermeasures: 685 o Configure authorization servers to return an AS identitifier 686 ("iss") and the "client_id" for which a code or token was issued 687 in the authorization response. This enables clients to compare 688 this data to their own client id and the "iss" identifier of the 689 AS it believed it sent the user agent to. This mitigation is 690 discussed in detail in [I-D.ietf-oauth-mix-up-mitigation]. In 691 OpenID Connect, if an ID token is returned in the authorization 692 response, it carries client id and issuer. It can be used for 693 this mitigation. 695 o As it can be seen in the preconditions of the attacks above, 696 clients can prevent mix-up attack by (1) using AS-specific 697 redirect URIs with exact redirect URI matching, (2) storing, for 698 each authorization request, the intended AS, and (3) comparing the 699 intended AS with the actual redirect URI where the authorization 700 response was received. 702 3.5. Authorization Code Injection 704 In such an attack, the adversary attempts to inject a stolen 705 authorization code into a legitimate client on a device under his 706 control. In the simplest case, the attacker would want to use the 707 code in his own client. But there are situations where this might 708 not be possible or intended. Examples are: 710 o The attacker wants to access certain functions in this particular 711 client. As an example, the attacker wants to impersonate his 712 victim in a certain app or on a certain web site. 714 o The code is bound to a particular confidential client and the 715 attacker is unable to obtain the required client credentials to 716 redeem the code himself. 718 o The authorization or resource servers are limited to certain 719 networks, the attackers is unable to access directly. 721 How does an attack look like? 723 (1) The attacker obtains an authorization code by performing any of 724 the attacks described above. 726 (2) It performs a regular OAuth authorization process with the 727 legitimate client on his device. 729 (3) The attacker injects the stolen authorization code in the 730 response of the authorization server to the legitimate client. 732 (4) The client sends the code to the authorization server's token 733 endpoint, along with client id, client secret and actual 734 "redirect_uri". 736 (5) The authorization server checks the client secret, whether the 737 code was issued to the particular client and whether the actual 738 redirect URI matches the "redirect_uri" parameter (see 739 [RFC6749]). 741 (6) If all checks succeed, the authorization server issues access 742 and other tokens to the client, so now the attacker is able to 743 impersonate the legitimate user. 745 Obviously, the check in step (5) will fail, if the code was issued to 746 another client id, e.g., a client set up by the attacker. The check 747 will also fail if the authorization code was already redeemed by the 748 legitimate user and was one-time use only. 750 An attempt to inject a code obtained via a malware pretending to be 751 the legitimate client should also be detected, if the authorization 752 server stored the complete redirect URI used in the authorization 753 request and compares it with the redirect_uri parameter. 755 [RFC6749], Section 4.1.3, requires the AS to "... ensure that the 756 "redirect_uri" parameter is present if the "redirect_uri" parameter 757 was included in the initial authorization request as described in 758 Section 4.1.1, and if included ensure that their values are 759 identical.". In the attack scenario described above, the legitimate 760 client would use the correct redirect URI it always uses for 761 authorization requests. But this URI would not match the tampered 762 redirect URI used by the attacker (otherwise, the redirect would not 763 land at the attackers page). So the authorization server would 764 detect the attack and refuse to exchange the code. 766 Note: this check could also detect attempt to inject a code, which 767 had been obtained from another instance of the same client on another 768 device, if certain conditions are fulfilled: 770 o the redirect URI itself needs to contain a nonce or another kind 771 of one-time use, secret data and 773 o the client has bound this data to this particular instance. 775 But this approach conflicts with the idea to enforce exact redirect 776 URI matching at the authorization endpoint. Moreover, it has been 777 observed that providers very often ignore the redirect_uri check 778 requirement at this stage, maybe because it doesn't seem to be 779 security-critical from reading the spec. 781 Other providers just pattern match the redirect_uri parameter against 782 the registered redirect URI pattern. This saves the authorization 783 server from storing the link between the actual redirect URI and the 784 respective authorization code for every transaction. But this kind 785 of check obviously does not fulfill the intent of the spec, since the 786 tampered redirect URI is not considered. So any attempt to inject a 787 code obtained using the "client_id" of a legitimate client or by 788 utilizing the legitimate client on another device won't be detected 789 in the respective deployments. 791 It is also assumed that the requirements defined in [RFC6749], 792 Section 4.1.3, increase client implementation complexity as clients 793 need to memorize or re-construct the correct redirect URI for the 794 call to the tokens endpoint. 796 This document therefore recommends to instead bind every 797 authorization code to a certain client instance on a certain device 798 (or in a certain user agent) in the context of a certain transaction. 800 3.5.1. Proposed Countermeasures 802 There are multiple technical solutions to achieve this goal: 804 Nonce OpenID Connect's existing "nonce" parameter could be used for 805 this purpose. The nonce value is one-time use and created by 806 the client. The client is supposed to bind it to the user 807 agent session and sends it with the initial request to the 808 OpenId Provider (OP). The OP associates the nonce to the 809 authorization code and attests this binding in the ID token, 810 which is issued as part of the code exchange at the token 811 endpoint. If an attacker injected an authorization code in 812 the authorization response, the nonce value in the client 813 session and the nonce value in the ID token will not match 814 and the attack is detected. The assumption is that an 815 attacker cannot get hold of the user agent state on the 816 victims device, where he has stolen the respective 817 authorization code. The main advantage of this option is 818 that Nonce is an existing feature used in the wild. On the 819 other hand, leveraging Nonce by the broader OAuth community 820 would require AS and client to adopt ID Tokens. 822 Code-bound State The "state" parameter as specified in [RFC6749] 823 could be used similarly to what is described above. This 824 would require to add a further parameter "state" to the code 825 exchange token endpoint request. The authorization server 826 would then compare the "state" value it associated with the 827 code and the "state" value in the parameter. If those values 828 do not match, it is considered an attack and the request 829 fails. The advantage of this approach would be to utilize an 830 existing OAuth parameter. But it would also mean to re- 831 interpret the purpose of "state" and to extend the token 832 endpoint request. 834 PKCE The PKCE parameter "challenge" along with the corresponding 835 "verifier" as specified in [RFC7636] could be used in the 836 same way as "nonce" or "state". In contrast to its original 837 intention, the verifier check would fail although the client 838 uses its correct verifier but the code is associated with a 839 challenge, which does not match. PKCE is a deployed OAuth 840 feature, even though it is used today to secure native apps, 841 only. 843 Token Binding Token binding [I-D.ietf-oauth-token-binding] could 844 also be used. In this case, the code would need to be bound 845 to two legs, between user agent and AS and the user agent and 846 the client. This requires further data (extension to 847 response) to manifest binding id for particular code. Token 848 binding is promising as a secure and convenient mechanism 849 (due to its browser integration). As a challenge, it 850 requires broad browser support and use with native apps is 851 still under discussion. 853 per instance client id/secret One could use per instance "client_id" 854 and secrets and bind the code to the respective "client_id". 855 Unfortunately, this does not fit into the web application 856 programming model (would need to use per user client ids). 858 PKCE seems to be the most obvious solution for OAuth clients as it 859 available and effectively used today for similar purposes for OAuth 860 native apps whereas "nonce" is appropriate for OpenId Connect 861 clients. 863 Note on pre-warmed secrets: An attacker can circumvent the 864 countermeasures described above if he is able to create or capture 865 the respective secret or code_challenge on a device under his 866 control, which is then used in the victim's authorization request. 867 Exact redirect URI matching of authorization requests can prevent the 868 attacker from using the pre-warmed secret in the faked authorization 869 transaction on the victim's device. 870 Unfortunately, it does not work for all kinds of OAuth clients. It 871 is effective for web and JS apps and for native apps with claimed 872 URLs. Attacks on native apps using custom schemes or redirect URIs 873 on localhost cannot be prevented this way, except if the AS enforces 874 one-time use for PKCE verifier or "nonce" values. 876 3.6. Access Token Injection 878 In such an attack, the adversary attempts to inject a stolen access 879 token into a legitimate client on a device under his control. This 880 will typically happen if the attacker wants to utilize a leaked 881 access token to impersonate a user in a certain client. 883 To conduct the attack, the adversary starts an OAuth flow with the 884 client and modifies the authorization response by replacing the 885 access token issued by the authorization server or directly makes up 886 an authorization server response including the leaked access token. 887 Since the response includes the state value generated by the client 888 for this particular transaction, the client does not treat the 889 response as a CSRF and will use the access token injected by the 890 attacker. 892 3.6.1. Proposed Countermeasures 894 There is no way to detect such an injection attack on the OAuth 895 protocol level, since the token is issued without any binding to the 896 transaction or the particular user agent. 898 The recommendation is therefore to use the authorization code grant 899 type instead of relying on response types issuing acess tokens at the 900 authorization endpoint. Code injection can be detected using one of 901 the countermeasures discussed in Section 3.5. 903 3.7. Cross Site Request Forgery 905 An attacker might attempt to inject a request to the redirect URI of 906 the legitimate client on the victim's device, e.g., to cause the 907 client to access resources under the attacker's control. 909 3.7.1. Proposed Countermeasures 911 Standard CSRF defenses should be used to protect the redirection 912 endpoint, for example: 914 CSRF Tokens Use of CSRF tokens which are bound to the user agent 915 and passed in the "state" parameter to the 916 authorization server. 918 Origin Header The Origin header can be used to detect and prevent 919 CSRF attacks. Since this feature, at the time of 920 writing, is not consistently supported by all 921 browsers, CSRF tokens should be used in addition to 922 Origin header checking. 924 For more details see [owasp_csrf]. 926 3.8. Access Token Leakage at the Resource Server 928 Access tokens can leak from a resource server under certain 929 circumstances. 931 3.8.1. Access Token Phishing by Counterfeit Resource Server 933 An attacker may setup his own resource server and trick a client into 934 sending access tokens to it, which are valid for other resource 935 servers. If the client sends a valid access token to this 936 counterfeit resource server, the attacker in turn may use that token 937 to access other services on behalf of the resource owner. 939 This attack assumes the client is not bound to a certain resource 940 server (and the respective URL) at development time, but client 941 instances are configured with an resource server's URL at runtime. 942 This kind of late binding is typical in situations where the client 943 uses a standard API, e.g., for e-Mail, calendar, health, or banking 944 and is configured by an user or administrator for the standard-based 945 service, this particular user or company uses. 947 There are several potential mitigation strategies, which will be 948 discussed in the following sections. 950 3.8.1.1. Metadata 952 An authorization server could provide the client with additional 953 information about the location where it is safe to use its access 954 tokens. 956 In the simplest form, this would require the AS to publish a list of 957 its known resource servers, illustrated in the following example 958 using a metadata parameter "resource_servers": 960 HTTP/1.1 200 OK 961 Content-Type: application/json 963 { 964 "issuer":"https://server.somesite.example", 965 "authorization_endpoint": 966 "https://server.somesite.example/authorize", 967 "resource_servers":[ 968 "email.somesite.example", 969 "storage.somesite.example", 970 "video.somesite.example"] 971 ... 972 } 974 The AS could also return the URL(s) an access token is good for in 975 the token response, illustrated by the example return parameter 976 "access_token_resource_server": 978 HTTP/1.1 200 OK 979 Content-Type: application/json;charset=UTF-8 980 Cache-Control: no-store 981 Pragma: no-cache 983 { 984 "access_token":"2YotnFZFEjr1zCsicMWpAA", 985 "access_token_resource_server": 986 "https://hostedresource.somesite.example/path1", 987 ... 988 } 990 This mitigation strategy would rely on the client to enforce the 991 security policy and to only send access tokens to legitimate 992 destinations. Results of OAuth related security research (see for 993 example [oauth_security_ubc] and [oauth_security_cmu]) indicate a 994 large portion of client implementations do not or fail to properly 995 implement security controls, like "state" checks. So relying on 996 clients to prevent access token phishing is likely to fail as well. 997 Moreover given the ratio of clients to authorization and resource 998 servers, it is considered the more viable approach to move as much as 999 possible security-related logic to those entities. Clearly, the 1000 client has to contribute to the overall security. But there are 1001 alternative countermeasures, as described in the next sections, which 1002 provide a better balance between the involved parties. 1004 3.8.1.2. Sender Constrained Access Tokens 1006 As the name suggests, sender constrained access token scope the 1007 applicability of an access token to a certain sender. This sender is 1008 obliged to demonstrate knowledge of a certain secret as prerequisite 1009 for the acceptance of that token at a resource server. 1011 A typical flow looks like this: 1013 1. The authorization server associates data with the access token 1014 which binds this particular token to a certain client. The 1015 binding can utilize the client identity, but in most cases the AS 1016 utilizes key material (or data derived from the key material) 1017 known to the client. 1019 2. This key material must be distributed somehow. Either the key 1020 material already exists before the AS creates the binding or the 1021 AS creates ephemeral keys. The way pre-existing key material is 1022 distributed varies among the different approaches. For example, 1023 X.509 Certificates can be used in which case the distribution 1024 happens explicitly during the enrollment process. Or the key 1025 material is created and distributed at the TLS layer, in which 1026 case it might automatically happens during the setup of a TLS 1027 connection. 1029 3. The RS must implement the actual proof of possession check. This 1030 is typically done on the application level, it may utilize 1031 capabilities of the transport layer (e.g., TLS). Note: replay 1032 prevention is required as well! 1034 There exists several proposals to demonstrate the proof of possession 1035 in the scope of the OAuth working group: 1037 o [I-D.ietf-oauth-token-binding]: In this approach, an access tokens 1038 is, via the so-called token binding id, bound to key material 1039 representing a long term association between a client and a 1040 certain TLS host. Negotiation of the key material and proof of 1041 possession in the context of a TLS handshake is taken care of by 1042 the TLS stack. The client needs to determine the token binding id 1043 of the target resource server and pass this data to the access 1044 token request. The authorization server than associates the 1045 access token with this id. The resource server checks on every 1046 invocation that the token binding id of the active TLS connection 1047 and the token binding id of associated with the access token 1048 match. Since all crypto-related functions are covered by the TLS 1049 stack, this approach is very client developer friendly. As a 1050 prerequisite, token binding as described in 1051 [I-D.ietf-tokbind-https] (including federated token bindings) must 1052 be supported on all ends (client, authorization server, resource 1053 server). 1055 o [I-D.ietf-oauth-mtls]: The approach as specified in this document 1056 allow use of mutual TLS for both client authentication and sender 1057 constraint access tokens. For the purpose of sender constraint 1058 access tokens, the client is identified towards the resource 1059 server by the fingerprint of its public key. During processing of 1060 an access token request, the authorization server obtains the 1061 client's public key from the TLS stack and associates its 1062 fingerprint with the respective access tokens. The resource 1063 server in the same way obtains the public key from the TLS stack 1064 and compares its fingerprint with the fingerprint associated with 1065 the access token. 1067 o [I-D.ietf-oauth-signed-http-request] specifies an approach to sign 1068 HTTP requests. It utilizes [I-D.ietf-oauth-pop-key-distribution] 1069 and represents the elements of the signature in a JSON object. 1070 The signature is built using JWS. The mechanism has built-in 1071 support for signing of HTTP method, query parameters and headers. 1072 It also incorporates a timestamp as basis for replay prevention. 1074 o [I-D.sakimura-oauth-jpop]: this draft describes different ways to 1075 constrain access token usage, namely TLS or request signing. 1076 Note: Since the authors of this draft contributed the TLS-related 1077 proposal to [I-D.ietf-oauth-mtls], this document only considers 1078 the request signing part. For request signing, the draft utilizes 1079 [I-D.ietf-oauth-pop-key-distribution] and RFC 7800 [RFC7800]. The 1080 signature data is represented in a JWT and JWS is used for 1081 signing. Replay prevention is provided by building the signature 1082 over a server-provided nonce, client-provided nonce and a nonce 1083 counter. 1085 [I-D.ietf-oauth-mtls] and [I-D.ietf-oauth-token-binding] are built on 1086 top of TLS and this way continue the successful OAuth 2.0 philosophy 1087 to leverage TLS to secure OAuth wherever possible. Both mechanisms 1088 allow prevention of access token leakage in a fairly client developer 1089 friendly way. 1091 There are some differences between both approaches: To start with, in 1092 [I-D.ietf-oauth-token-binding] all key material is automatically 1093 managed by the TLS stack whereas [I-D.ietf-oauth-mtls] requires the 1094 developer to create and maintain the key pairs and respective 1095 certificates. Use of self-signed certificates, which is supported by 1096 the draft, significantly reduce the complexity of this task. 1097 Furthermore, [I-D.ietf-oauth-token-binding] allows to use different 1098 key pairs for different resource servers, which is a privacy benefit. 1099 On the other hand, [I-D.ietf-oauth-mtls] only requires widely 1100 deployed TLS features, which means it might be easier to adopt in the 1101 short term. 1103 Application level signing approaches, like 1104 [I-D.ietf-oauth-signed-http-request] and [I-D.sakimura-oauth-jpop] 1105 have been debated for a long time in the OAuth working group without 1106 a clear outcome. 1108 As one advantage, application-level signing allows for end-to-end 1109 protection including non-repudiation even if the TLS connection is 1110 terminated between client and resource server. But deployment 1111 experiences have revealed challenges regarding robustness (e.g., 1112 reproduction of the signature base string including correct URL) as 1113 well as state management (e.g., replay prevention). 1115 This document therefore recommends implementors to consider one of 1116 TLS-based approaches wherever possible. 1118 3.8.1.3. Audience Restricted Access Tokens 1120 An audience restriction essentially restricts the resource server a 1121 particular access token can be used at. The authorization server 1122 associates the access token with a certain resource server and every 1123 resource server is obliged to verify for every request, whether the 1124 access token sent with that request was meant to be used at the 1125 particular resource server. If not, the resource server must refuse 1126 to serve the respective request. In the general case, audience 1127 restrictions limit the impact of a token leakage. In the case of a 1128 counterfeit resource server, it may (as described see below) also 1129 prevent abuse of the phished access token at the legitimate resource 1130 server. 1132 The audience can basically be expressed using logical names or 1133 physical addresses (like URLs). In order to prevent phishing, it is 1134 necessary to use the actual URL the client will send requests to. In 1135 the phishing case, this URL will point to the counterfeit resource 1136 server. If the attacker tries to use the access token at the 1137 legitimate resource server (which has a different URL), the resource 1138 server will detect the mismatch (wrong audience) and refuse to serve 1139 the request. 1141 In deployments where the authorization server knows the URLs of all 1142 resource servers, the authorization server may just refuse to issue 1143 access tokens for unknown resource server URLs. 1145 The client needs to tell the authorization server, at which URL it 1146 will use the access token it is requesting. It could use the 1147 mechanism proposed [I-D.ietf-oauth-resource-indicators] or encode the 1148 information in the scope value. 1150 Instead of the URL, it is also possible to utilize the fingerprint of 1151 the resource server's X.509 certificate as audience value. This 1152 variant would also allow to detect an attempt to spoof the legit 1153 resource server's URL by using a valid TLS certificate obtained from 1154 a different CA. It might also be considered a privacy benefit to 1155 hide the resource server URL from the authorization server. 1157 Audience restriction seems easy to use since it does not require any 1158 crypto on the client side. But since every access token is bound to 1159 a certain resource server, the client also needs to obtain different 1160 RS-specific access tokens, if it wants to access several resource 1161 services. [I-D.ietf-oauth-token-binding] has the same property, 1162 since different token binding ids must be associated with the access 1163 token. [I-D.ietf-oauth-mtls] on the other hand allows a client to 1164 use the access token at multiple resource servers. 1166 It shall be noted that audience restrictions, or generally speaking 1167 an indication by the client to the authorization server where it 1168 wants to use the access token, has additional benefits beyond the 1169 scope of token leakage prevention. It allows the authorization 1170 server to create different access token whose format and content is 1171 specifically minted for the respective server. This has huge 1172 functional and privacy advantages in deployments using structured 1173 access tokens. 1175 3.8.2. Compromised Resource Server 1177 An attacker may compromise a resource server in order to get access 1178 to its resources and other resources of the respective deployment. 1179 Such a compromise may range from partial access to the system, e.g., 1180 its logfiles, to full control of the respective server. 1182 If the attacker was able to take over full control including shell 1183 access it will be able to circumvent all controls in place and access 1184 resources without access control. It will also get access to access 1185 tokens, which are sent to the compromised system and which 1186 potentially are valid for access to other resource servers as well. 1187 Even if the attacker "only" is able to access logfiles or databases 1188 of the server system, it may get access to valid access tokens. 1190 Preventing server breaches by way of hardening and monitoring server 1191 systems is considered a standard operational procedure and therefore 1192 out of scope of this document. This section will focus on the impact 1193 of such breaches on OAuth-related parts of the ecosystem, which is 1194 the replay of captured access tokens on the compromised resource 1195 server and other resource servers of the respective deployment. 1197 The following measures shall be taken into account by implementors in 1198 order to cope with access token replay: 1200 o The resource server must treat access tokens like any other 1201 credentials. It is considered good practice to not log them and 1202 not to store them in plain text. 1204 o Sender constraint access tokens as described in Section 3.8.1.2 1205 will prevent the attacker from replaying the access tokens on 1206 other resource servers. Depending on the severity of the 1207 penetration, it will also prevent replay on the compromised 1208 system. 1210 o Audience restriction as described in Section 3.8.1.3 may be used 1211 to prevent replay of captured access tokens on other resource 1212 servers. 1214 3.9. Open Redirection 1216 The following attacks can occur when an AS or client has an open 1217 redirector, i.e., a URL which causes an HTTP redirect to an attacker- 1218 controlled web site. 1220 3.9.1. Authorization Server as Open Redirector 1222 Attackers could try to utilize a user's trust in the authorization 1223 server (and its URL in particular) for performing phishing attacks. 1225 [RFC6749], Section 4.1.2.1, already prevents open redirects by 1226 stating the AS MUST NOT automatically redirect the user agent in case 1227 of an invalid combination of client_id and redirect_uri. 1229 However, as described in [I-D.ietf-oauth-closing-redirectors], an 1230 attacker could also utilize a correctly registered redirect URI to 1231 perform phishing attacks. It could for example register a client via 1232 dynamic client [RFC7591] registration and intentionally send an 1233 erroneous authorization request, e.g., by using an invalid scope 1234 value, to cause the AS to automatically redirect the user agent to 1235 its phishing site. 1237 The AS MUST take precautions to prevent this threat. Based on its 1238 risk assessment the AS needs to decide whether it can trust the 1239 redirect URI or not and SHOULD only automatically redirect the user 1240 agent, if it trusts the redirect URI. If not, it MAY inform the user 1241 that it is about to redirect her to the another site and rely on the 1242 user to decide or MAY just inform the user about the error. 1244 3.9.2. Clients as Open Redirector 1246 Client MUST NOT expose URLs which could be utilized as open 1247 redirector. Attackers may use an open redirector to produce URLs 1248 which appear to point to the client, which might trick users to trust 1249 the URL and follow it in her browser. Another abuse case is to 1250 produce URLs pointing to the client and utilize them to impersonate a 1251 client with an authorization server. 1253 In order to prevent open redirection, clients should only expose such 1254 a function, if the target URLs are whitelisted or if the origin of a 1255 request can be authenticated. 1257 3.10. 307 Redirect 1259 At the authorization endpoint, a typical protocol flow is that the AS 1260 prompts the user to enter her credentials in a form that is then 1261 submitted (using the HTTP POST method) back to the authorization 1262 server. The AS checks the credentials and, if successful, redirects 1263 the user agent to the client's redirection endpoint. 1265 In [RFC6749], the HTTP status code 302 is used for this purpose, but 1266 "any other method available via the user-agent to accomplish this 1267 redirection is allowed". However, when the status code 307 is used 1268 for redirection, the user agent will send the form data (user 1269 credentials) via HTTP POST to the client since this status code does 1270 not require the user agent to rewrite the POST request to a GET 1271 request (and thereby dropping the form data in the POST request 1272 body). If the relying party is malicious, it can use the credentials 1273 to impersonate the user at the AS. 1275 In the HTTP standard [RFC6749], only the status code 303 1276 unambigiously enforces rewriting the HTTP POST request to an HTTP GET 1277 request. For all other status codes, including the popular 302, user 1278 agents can opt not to rewrite POST to GET requests and therefore to 1279 reveal the user credentials to the client. (In practice, however, 1280 most user agents will only show this behaviour for 307 redirects.) 1282 AS which redirect a request that potentially contains user 1283 credentials therefore MUST not use the HTTP 307 status code for 1284 redirection. If an HTTP redirection (and not, for example, 1285 JavaScript) is used for such a request, AS SHOULD use HTTP status 1286 code 303 "See Other". 1288 3.11. TLS Terminating Reverse Proxies 1290 A common deployment architecture for HTTP applications is to have the 1291 application server sitting behind a reverse proxy, which terminates 1292 the TLS connection and dispatches the incoming requests to the 1293 respective application server nodes. 1295 This section highlights some attack angles of this deployment 1296 architecture, which are relevant to OAuth, and give recommendations 1297 for security controls. 1299 In some situations, the reverse proxy needs to pass security-related 1300 data to the upstream application servers for further processing. 1301 Examples include the IP address of the request originator, token 1302 binding ids and authenticated TLS client certificates. 1304 If the reverse proxy would pass through any header sent from the 1305 outside, an attacker could try to directly send the faked header 1306 values through the proxy to the application server in order to 1307 circumvent security controls that way. For example, it is standard 1308 practice of reverse proxies to accept "forwarded_for" headers and 1309 just add the origin of the inbound request (making it a list). 1310 Depending on the logic performed in the application server, the 1311 attacker could simply add a whitelisted IP address to the header and 1312 render a IP whitelist useless. A reverse proxy must therefore 1313 sanitize any inbound requests to ensure the authenticity and 1314 integrity of all header values relevant for the security of the 1315 application servers. 1317 If an attacker would be able to get access to the internal network 1318 between proxy and application server, it could also try to circumvent 1319 security controls in place. It is therefore important to ensure the 1320 authenticity of the communicating entities. Furthermore, the 1321 communication link between reverse proxy and application server must 1322 therefore be protected against tapping and injection (including 1323 replay prevention). 1325 4. Acknowledgements 1327 We would like to thank Jim Manico, Phil Hunt, Nat Sakimura, Christian 1328 Mainka, Doug McDorman, Johan Peeters, and Brian Campbell for their 1329 valuable feedback. 1331 5. IANA Considerations 1333 This draft includes no request to IANA. 1335 6. Security Considerations 1337 All relevant security considerations have been given in the 1338 functional specification. 1340 7. References 1342 7.1. Normative References 1344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1345 Requirement Levels", BCP 14, RFC 2119, 1346 DOI 10.17487/RFC2119, March 1997, 1347 . 1349 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1350 Resource Identifier (URI): Generic Syntax", STD 66, 1351 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1352 . 1354 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1355 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1356 . 1358 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1359 Framework: Bearer Token Usage", RFC 6750, 1360 DOI 10.17487/RFC6750, October 2012, 1361 . 1363 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 1364 Threat Model and Security Considerations", RFC 6819, 1365 DOI 10.17487/RFC6819, January 2013, 1366 . 1368 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1369 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1370 DOI 10.17487/RFC7231, June 2014, 1371 . 1373 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 1374 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 1375 RFC 7591, DOI 10.17487/RFC7591, July 2015, 1376 . 1378 7.2. Informative References 1380 [arXiv.1508.04324v2] 1381 Mladenov, V., Mainka, C., and J. Schwenk, "On the security 1382 of modern Single Sign-On Protocols: Second-Order 1383 Vulnerabilities in OpenID Connect", arXiv 1508.04324v2, 1384 January 2016, . 1386 [arXiv.1601.01229] 1387 Fett, D., Kuesters, R., and G. Schmitz, "A Comprehensive 1388 Formal Security Analysis of OAuth 2.0", arXiv 1601.01229, 1389 January 2016, . 1391 [arXiv.1704.08539] 1392 Fett, D., Kuesters, R., and G. Schmitz, "The Web SSO 1393 Standard OpenID Connect: In-Depth Formal Security Analysis 1394 and Security Guidelines", arXiv 1704.08539, April 2017, 1395 . 1397 [bug.chromium] 1398 "Referer header includes URL fragment when opening link 1399 using New Tab", 1400 . 1403 [fb_fragments] 1404 "Facebook Developer Blog", 1405 . 1407 [I-D.bradley-oauth-jwt-encoded-state] 1408 Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding 1409 claims in the OAuth 2 state parameter using a JWT", draft- 1410 bradley-oauth-jwt-encoded-state-09 (work in progress), 1411 November 2018. 1413 [I-D.ietf-oauth-closing-redirectors] 1414 Bradley, J., Sanso, A., and H. Tschofenig, "OAuth 2.0 1415 Security: Closing Open Redirectors in OAuth", draft-ietf- 1416 oauth-closing-redirectors-00 (work in progress), February 1417 2016. 1419 [I-D.ietf-oauth-jwsreq] 1420 Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization 1421 Framework: JWT Secured Authorization Request (JAR)", 1422 draft-ietf-oauth-jwsreq-17 (work in progress), October 1423 2018. 1425 [I-D.ietf-oauth-mix-up-mitigation] 1426 Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up 1427 Mitigation", draft-ietf-oauth-mix-up-mitigation-01 (work 1428 in progress), July 2016. 1430 [I-D.ietf-oauth-mtls] 1431 Campbell, B., Bradley, J., Sakimura, N., and T. 1432 Lodderstedt, "OAuth 2.0 Mutual TLS Client Authentication 1433 and Certificate Bound Access Tokens", draft-ietf-oauth- 1434 mtls-12 (work in progress), October 2018. 1436 [I-D.ietf-oauth-pop-key-distribution] 1437 Bradley, J., Hunt, P., Jones, M., Tschofenig, H., and M. 1438 Mihaly, "OAuth 2.0 Proof-of-Possession: Authorization 1439 Server to Client Key Distribution", draft-ietf-oauth-pop- 1440 key-distribution-04 (work in progress), October 2018. 1442 [I-D.ietf-oauth-resource-indicators] 1443 Campbell, B., Bradley, J., and H. Tschofenig, "Resource 1444 Indicators for OAuth 2.0", draft-ietf-oauth-resource- 1445 indicators-01 (work in progress), October 2018. 1447 [I-D.ietf-oauth-signed-http-request] 1448 Richer, J., Bradley, J., and H. Tschofenig, "A Method for 1449 Signing HTTP Requests for OAuth", draft-ietf-oauth-signed- 1450 http-request-03 (work in progress), August 2016. 1452 [I-D.ietf-oauth-token-binding] 1453 Jones, M., Campbell, B., Bradley, J., and W. Denniss, 1454 "OAuth 2.0 Token Binding", draft-ietf-oauth-token- 1455 binding-08 (work in progress), October 2018. 1457 [I-D.ietf-tokbind-https] 1458 Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, 1459 N., and J. Hodges, "Token Binding over HTTP", draft-ietf- 1460 tokbind-https-18 (work in progress), June 2018. 1462 [I-D.sakimura-oauth-jpop] 1463 Sakimura, N., Li, K., and J. Bradley, "The OAuth 2.0 1464 Authorization Framework: JWT Pop Token Usage", draft- 1465 sakimura-oauth-jpop-04 (work in progress), March 2017. 1467 [oauth-v2-form-post-response-mode] 1468 Microsoft and Ping Identity, "OAuth 2.0 Form Post Response 1469 Mode", April 2015, . 1472 [oauth_security_cmu] 1473 Carnegie Mellon University, Carnegie Mellon University, 1474 Microsoft Research, Carnegie Mellon University, Carnegie 1475 Mellon University, and Carnegie Mellon University, "OAuth 1476 Demystified for Mobile Application Developers", November 1477 2014. 1479 [oauth_security_jcs_14] 1480 Bansal, C., Bhargavan, K., Delignat-Lavaud, A., and S. 1481 Maffeis, "Discovering concrete attacks on website 1482 authorization by formal analysis", April 2014. 1484 [oauth_security_ubc] 1485 University of British Columbia and University of British 1486 Columbia, "The Devil is in the (Implementation) Details: 1487 An Empirical Analysis of OAuth SSO Systems", October 2012, 1488 . 1490 [OpenID] NRI, Ping Identity, Microsoft, Google, and Salesforce, 1491 "OpenID Connect Core 1.0 incorporating errata set 1", Nov 1492 2014, 1493 . 1495 [owasp] "Open Web Application Security Project Home Page", 1496 . 1498 [owasp_csrf] 1499 "Cross-Site Request Forgery (CSRF) Prevention Cheat 1500 Sheet", . 1503 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1504 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1505 Transfer Protocol -- HTTP/1.1", RFC 2616, 1506 DOI 10.17487/RFC2616, June 1999, 1507 . 1509 [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 1510 for Code Exchange by OAuth Public Clients", RFC 7636, 1511 DOI 10.17487/RFC7636, September 2015, 1512 . 1514 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 1515 Possession Key Semantics for JSON Web Tokens (JWTs)", 1516 RFC 7800, DOI 10.17487/RFC7800, April 2016, 1517 . 1519 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 1520 Authorization Server Metadata", RFC 8414, 1521 DOI 10.17487/RFC8414, June 2018, 1522 . 1524 [webappsec-referrer-policy] 1525 Google Inc. and Google Inc., "Referrer Policy", April 1526 2017, . 1528 Appendix A. Document History 1530 [[ To be removed from the final specification ]] 1532 -09 1534 o changed text to recommend not to use implicit but code 1536 o added section on access token injection 1538 o reworked sections 3.1 through 3.3 to be more specific on implicit 1539 grant issues 1541 -08 1543 o added recommendations re implicit and token injection 1545 o uppercased key words in Section 2 according to RFC 2119 1547 -07 1549 o incorporated findings of Doug McDorman 1551 o added section on HTTP status codes for redirects 1553 o added new section on access token privilege restriction based on 1554 comments from Johan Peeters 1556 -06 1558 o reworked section 3.8.1 1560 o incorporated Phil Hunt's feedback 1562 o reworked section on mix-up 1564 o extended section on code leakage via referrer header to also cover 1565 state leakage 1567 o added Daniel Fett as author 1569 o replaced text intended to inform WG discussion by recommendations 1570 to implementors 1572 o modified example URLs to conform to RFC 2606 1574 -05 1576 o Completed sections on code leakage via referrer header, attacks in 1577 browser, mix-up, and CSRF 1579 o Reworked Code Injection Section 1581 o Added reference to OpenID Connect spec 1583 o removed refresh token leakage as respective considerations have 1584 been given in section 10.4 of RFC 6749 1586 o first version on open redirection 1588 o incorporated Christian Mainka's review feedback 1590 -04 1592 o Restructured document for better readability 1594 o Added best practices on Token Leakage prevention 1596 -03 1598 o Added section on Access Token Leakage at Resource Server 1600 o incorporated Brian Campbell's findings 1602 -02 1604 o Folded Mix up and Access Token leakage through a bad AS into new 1605 section for dynamic OAuth threats 1607 o reworked dynamic OAuth section 1609 -01 1611 o Added references to mitigation methods for token leakage 1613 o Added reference to Token Binding for Authorization Code 1614 o incorporated feedback of Phil Hunt 1616 o fixed numbering issue in attack descriptions in section 2 1618 -00 (WG document) 1620 o turned the ID into a WG document and a BCP 1622 o Added federated app login as topic in Other Topics 1624 Authors' Addresses 1626 Torsten Lodderstedt (editor) 1627 yes.com 1629 Email: torsten@lodderstedt.net 1631 John Bradley 1632 Yubico 1634 Email: ve7jtb@ve7jtb.com 1636 Andrey Labunets 1637 Facebook 1639 Email: isciurus@fb.com 1641 Daniel Fett 1642 yes.com 1644 Email: mail@danielfett.de