idnits 2.17.1 draft-ietf-oauth-security-topics-07.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 (August 24, 2018) is 2069 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 1267, 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 (-09) exists of draft-bradley-oauth-jwt-encoded-state-08 == Outdated reference: A later version (-34) exists of draft-ietf-oauth-jwsreq-16 == Outdated reference: A later version (-17) exists of draft-ietf-oauth-mtls-10 == 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-resource-indicators-00 == Outdated reference: A later version (-08) exists of draft-ietf-oauth-token-binding-07 == Outdated reference: A later version (-05) exists of draft-sakimura-oauth-jpop-04 Summary: 3 errors (**), 0 flaws (~~), 12 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: February 25, 2019 Yubico 6 A. Labunets 7 Facebook 8 D. Fett 9 YES.com AG 10 August 24, 2018 12 OAuth 2.0 Security Best Current Practice 13 draft-ietf-oauth-security-topics-07 15 Abstract 17 This document describes best current security practices for OAuth 18 2.0. 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 February 25, 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.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 5 61 2.3. Access Token Privilege Restriction . . . . . . . . . . . 5 62 3. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 6 63 3.1. Insufficient redirect URI validation . . . . . . . . . . 6 64 3.1.1. Attacks on Authorization Code Grant . . . . . . . . . 6 65 3.1.2. Attacks on Implicit Grant . . . . . . . . . . . . . . 7 66 3.1.3. Proposed Countermeasures . . . . . . . . . . . . . . 9 67 3.2. Code or State Leakage from Client or AS via Referrer 68 Headers . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.2.1. Proposed Countermeasures . . . . . . . . . . . . . . 10 70 3.3. Attacks through the Browser History . . . . . . . . . . . 11 71 3.3.1. Code in Browser History . . . . . . . . . . . . . . . 11 72 3.3.2. Access Token in Browser History . . . . . . . . . . . 11 73 3.4. Mix-Up . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 3.4.1. Attack Description . . . . . . . . . . . . . . . . . 12 75 3.4.2. Countermeasures . . . . . . . . . . . . . . . . . . . 14 76 3.5. Code Injection . . . . . . . . . . . . . . . . . . . . . 14 77 3.5.1. Proposed Countermeasures . . . . . . . . . . . . . . 16 78 3.6. Cross Site Request Forgery . . . . . . . . . . . . . . . 18 79 3.6.1. Proposed Countermeasures . . . . . . . . . . . . . . 18 80 3.7. Access Token Leakage at the Resource Server . . . . . . . 18 81 3.7.1. Access Token Phishing by Counterfeit Resource Server 18 82 3.7.1.1. Metadata . . . . . . . . . . . . . . . . . . . . 19 83 3.7.1.2. Sender Constrained Access Tokens . . . . . . . . 20 84 3.7.1.3. Audience Restricted Access Tokens . . . . . . . . 23 85 3.7.2. Compromised Resource Server . . . . . . . . . . . . . 24 86 3.8. Open Redirection . . . . . . . . . . . . . . . . . . . . 25 87 3.8.1. Authorization Server as Open Redirector . . . . . . . 25 88 3.8.2. Clients as Open Redirector . . . . . . . . . . . . . 25 89 3.9. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 25 90 3.10. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 26 91 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 92 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 27 94 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 7.1. Normative References . . . . . . . . . . . . . . . . . . 27 96 7.2. Informative References . . . . . . . . . . . . . . . . . 28 98 Appendix A. Document History . . . . . . . . . . . . . . . . . . 31 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 101 1. Introduction 103 It's been a while since OAuth has been published in RFC 6749 104 [RFC6749] and RFC 6750 [RFC6750]. Since publication, OAuth 2.0 has 105 gotten massive traction in the market and became the standard for API 106 protection and, as foundation of OpenID Connect [OpenID], identity 107 providing. While OAuth was used in a variety of scenarios and 108 different kinds of deployments, the following challenges could be 109 observed: 111 o OAuth implementations are being attacked through known 112 implementation weaknesses and anti-patterns (XSRF, referrer 113 header). Although most of these threats are discussed in the 114 OAuth 2.0 Threat Model and Security Considerations [RFC6819], 115 continued exploitation demonstrates there may be a need for more 116 specific recommendations or that the existing mitigations are too 117 difficult to deploy. 119 o Technology has changed, e.g., the way browsers treat fragments in 120 some situations, which may change the implicit grant's underlying 121 security model. 123 o OAuth is used in much more dynamic setups than originally 124 anticipated, creating new challenges with respect to security. 125 Those challenges go beyond the original scope of RFC 6749 126 [RFC6749], RFC 6750 [RFC6749], and RFC 6819 [RFC6819]. 128 OAuth initially assumed a static relationship between client, 129 authorization server and resource servers. The URLs of AS and RS 130 were known to the client at deployment time and built an anchor for 131 the trust relationship among those parties. The validation whether 132 the client talks to a legitimate server was based on TLS server 133 authentication (see [RFC6819], Section 4.5.4). With the increasing 134 adoption of OAuth, this simple model dissolved and, in several 135 scenarios, was replaced by a dynamic establishment of the 136 relationship between clients on one side and the authorization and 137 resource servers of a particular deployment on the other side. This 138 way the same client could be used to access services of different 139 providers (in case of standard APIs, such as e-Mail or OpenID 140 Connect) or serves as a frontend to a particular tenant in a multi- 141 tenancy. Extensions of OAuth, such as [RFC7591] and [RFC8414] were 142 developed in order to support the usage of OAuth in dynamic 143 scenarios. As a challenge to the community, such usage scenarios 144 open up new attack angles, which are discussed in this document. 146 The remainder of the document is organized as follows: The next 147 section summarizes the most important recommendations of the OAuth 148 working group for every OAuth implementor. Afterwards, a detailed 149 analysis of the threats and implementation issues which can be found 150 in the wild today is given along with a discussion of potential 151 countermeasures. 153 2. Recommendations 155 This section describes the set of security mechanisms the OAuth 156 working group recommendeds to OAuth implementers. 158 2.1. Protecting redirect-based flows 160 Authorization servers shall utilize exact matching of client redirect 161 URIs against pre-registered URIs. This measure contributes to the 162 prevention of leakage of authorization codes and access tokens 163 (depending on the grant type). It also helps to detect mix-up 164 attacks. 166 Clients shall avoid any redirects or forwards which can be 167 parameterized by URI query parameters, in order to provide a further 168 layer of defence against token leakage. If there is a need for this 169 kind of redirects, clients are advised to implement appropriate 170 countermeasures against open redirection, e.g., as described by the 171 OWASP [owasp]. 173 Clients shall ensure to only process redirect responses of the OAuth 174 authorization server they send the respective request to and in the 175 same user agent this request was initiated in. In particular, 176 clients shall implement appropriate XSRF prevention by utilizing one- 177 time use XSRF tokens carried in the "state" parameter, which are 178 securely bound to the user agent. Moreover, the client shall 179 memorize which authorization server it sent an authorization request 180 to and bind this information to the user agent and ensure any sub- 181 sequent messages are sent to the same authorization server. 182 Furthermore, clients should use AS-specific redirect URIs as a means 183 to identify the AS a particular response came from. Matching this 184 with the before mentioned information regarding the AS the client 185 sent the request to helps to detect mix-up attacks. 187 Note: [I-D.bradley-oauth-jwt-encoded-state] gives advice on how to 188 implement XSRF prevention and AS matching using signed JWTs in the 189 "state" parameter. 191 Clients shall use PKCE [RFC7636] in order to (with the help of the 192 authorization server) detect and prevent attempts to inject (replay) 193 authorization codes into the authorization response. The PKCE 194 challenges must be transaction-specific and securely bound to the 195 user agent, in which the transaction was started. OpenID Connect 196 clients may use the "nonce" parameter of the OpenID Connect 197 authentication request as specified in [OpenID] in conjunction with 198 the corresponding ID Token claim for the same purpose. 200 Note: although PKCE so far was recommended as mechanism to protect 201 native apps, this advice applies to all kinds of OAuth clients, 202 including web applications. 204 Authorization servers shall consider the recommendations given in 205 [RFC6819], Section 4.4.1.1, on authorization code replay prevention. 207 2.2. Token Replay Prevention 209 Authorization servers SHOULD use TLS-based methods for sender 210 constrained access tokens as described in Section 3.7.1.2, such as 211 token binding [I-D.ietf-oauth-token-binding] or Mutual TLS for OAuth 212 2.0 [I-D.ietf-oauth-mtls] in order to prevent token replay. It is 213 also recommend to use end-to-end TLS whenever possible. 215 2.3. Access Token Privilege Restriction 217 The privileges associated with an access token SHOULD be restricted 218 to the minimum required for the particular application or use case. 219 This prevents clients from exceeding the privileges authorized by the 220 resource owner. It also prevents users from exceeding their 221 privileges authorized by the respective security policy. Privilege 222 restrictions also limit the impact of token leakage although more 223 effective counter-measures are described in Section 2.2. 225 In particular, access tokens SHOULD be restricted to certain resource 226 servers, preferably to a single resource server. To put this into 227 effect, the authorization server associates the access token with 228 certain resource servers and every resource server is obliged to 229 verify for every request, whether the access token sent with that 230 request was meant to be used for that particular resource server. If 231 not, the resource server MUST refuse to serve the respective request. 232 Clients and authorization servers MAY utilize the parameters "scope" 233 or "resource" as specified in [RFC6749] and 234 [I-D.ietf-oauth-resource-indicators], respectively, to determine the 235 resource server they want to access. 237 Additionally, access tokens SHOULD be restricted to certain resources 238 and actions on resource servers or resources. To put this into 239 effect, the authorization server associates the access token with the 240 respective resource and actions and every resource server is obliged 241 to verify for every request, whether the access token sent with that 242 request was meant to be used for that particular action on the 243 particular resource. If not, the resource server must refuse to 244 serve the respective request. Clients and authorization servers MAY 245 utilize the parameter "scope" as specified in [RFC6749] to determine 246 those resources and/or actions. 248 3. Attacks and Mitigations 250 This section gives a detailed description of attacks on OAuth 251 implementations, along with potential countermeasures. This section 252 complements and enhances the description given in [RFC6819]. 254 3.1. Insufficient redirect URI validation 256 Some authorization servers allow clients to register redirect URI 257 patterns instead of complete redirect URIs. In those cases, the 258 authorization server, at runtime, matches the actual redirect URI 259 parameter value at the authorization endpoint against this pattern. 260 This approach allows clients to encode transaction state into 261 additional redirect URI parameters or to register just a single 262 pattern for multiple redirect URIs. As a downside, it turned out to 263 be more complex to implement and error prone to manage than exact 264 redirect URI matching. Several successful attacks have been observed 265 in the wild, which utilized flaws in the pattern matching 266 implementation or concrete configurations. Such a flaw effectively 267 breaks client identification or authentication (depending on grant 268 and client type) and allows the attacker to obtain an authorization 269 code or access token, either: 271 o by directly sending the user agent to a URI under the attackers 272 control or 274 o by exposing the OAuth credentials to an attacker by utilizing an 275 open redirector at the client in conjunction with the way user 276 agents handle URL fragments. 278 3.1.1. Attacks on Authorization Code Grant 280 For a public client using the grant type code, an attack would look 281 as follows: 283 Let's assume the redirect URL pattern "https://*.somesite.example/*" 284 had been registered for the client "s6BhdRkqt3". This pattern allows 285 redirect URIs pointing to any host residing in the domain 286 somesite.example. So if an attacker manages to establish a host or 287 subdomain in somesite.example he can impersonate the legitimate 288 client. Assume the attacker sets up the host 289 "evil.somesite.example". 291 (1) The attacker needs to trick the user into opening a tampered URL 292 in his browser, which launches a page under the attacker's 293 control, say "https://www.evil.example". 295 (2) This URL initiates an authorization request with the client id 296 of a legitimate client to the authorization endpoint. This is 297 the example authorization request (line breaks are for display 298 purposes only): 300 GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz 301 &redirect_uri=https%3A%2F%2Fevil.somesite.example%2Fcb HTTP/1.1 302 Host: server.somesite.example 304 (3) The authorization server validates the redirect URI in order to 305 identify the client. Since the pattern allows arbitrary domains 306 host names in "somesite.example", the authorization request is 307 processed under the legitimate client's identity. This includes 308 the way the request for user consent is presented to the user. 309 If auto-approval is allowed (which is not recommended for public 310 clients according to [RFC6749]), the attack can be performed 311 even easier. 313 (4) If the user does not recognize the attack, the code is issued 314 and directly sent to the attacker's client. 316 (5) Since the attacker impersonated a public client, it can directly 317 exchange the code for tokens at the respective token endpoint. 319 Note: This attack will not directly work for confidential clients, 320 since the code exchange requires authentication with the legitimate 321 client's secret. The attacker will need to impersonate or utilize 322 the legitimate client to redeem the code (e.g., by performing a code 323 injection attack). This kind of injections is covered in 324 Section Code Injection. 326 3.1.2. Attacks on Implicit Grant 328 The attack described above works for the implicit grant as well. If 329 the attacker is able to send the authorization response to a URI 330 under his control, he will directly get access to the fragment 331 carrying the access token. 333 Additionally, implicit clients can be subject to a further kind of 334 attacks. It utilizes the fact that user agents re-attach fragments 335 to the destination URL of a redirect if the location header does not 336 contain a fragment (see [RFC7231], Section 9.5). The attack 337 described here combines this behavior with the client as an open 338 redirector in order to get access to access tokens. This allows 339 circumvention even of strict redirect URI patterns (but not strict 340 URL matching!). 342 Assume the pattern for client "s6BhdRkqt3" is 343 "https://client.somesite.example/cb?*", i.e., any parameter is 344 allowed for redirects to "https://client.somesite.example/cb". 345 Unfortunately, the client exposes an open redirector. This endpoint 346 supports a parameter "redirect_to" which takes a target URL and will 347 send the browser to this URL using an HTTP Location header redirect 348 303. 350 (1) Same as above, the attacker needs to trick the user into opening 351 a tampered URL in his browser, which launches a page under the 352 attacker's control, say "https://www.evil.example". 354 (2) The URL initiates an authorization request, which is very 355 similar to the attack on the code flow. As differences, it 356 utilizes the open redirector by encoding 357 "redirect_to=https://client.evil.example" into the redirect URI 358 and it uses the response type "token" (line breaks are for 359 display purposes only): 361 GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz 362 &redirect_uri=https%3A%2F%2Fclient.somesite.example%2Fcb%26redirect_to 363 %253Dhttps%253A%252F%252Fclient.evil.example%252Fcb HTTP/1.1 364 Host: server.somesite.example 366 (3) Since the redirect URI matches the registered pattern, the 367 authorization server allows the request and sends the resulting 368 access token with a 303 redirect (some response parameters are 369 omitted for better readability) 371 HTTP/1.1 303 See Other 372 Location: https://client.somesite.example/cb? 373 redirect_to%3Dhttps%3A%2F%2Fclient.evil.example%2Fcb 374 #access_token=2YotnFZFEjr1zCsicMWpAA&... 376 (4) At example.com, the request arrives at the open redirector. It 377 will read the redirect parameter and will issue an HTTP 303 378 Location header redirect to the URL 379 "https://client.evil.example/cb". 381 HTTP/1.1 303 See Other 382 Location: https://client.evil.example/cb 384 (5) Since the redirector at client.somesite.example does not include 385 a fragment in the Location header, the user agent will re-attach 386 the original fragment 387 "#access_token=2YotnFZFEjr1zCsicMWpAA&..." to the URL and will 388 navigate to the following URL: 390 https://client.evil.example/cb#access_token=2YotnFZFEjr1zCsicMWpAA&... 392 (6) The attacker's page at client.evil.example can access the 393 fragment and obtain the access token. 395 3.1.3. Proposed Countermeasures 397 The complexity of implementing and managing pattern matching 398 correctly obviously causes security issues. This document therefore 399 proposes to simplify the required logic and configuration by using 400 exact redirect URI matching only. This means the authorization 401 server shall compare the two URIs using simple string comparison as 402 defined in [RFC3986], Section 6.2.1.. 404 Additional recommendations: 406 o Servers on which callbacks are hosted must not expose open 407 redirectors (see Section 3.8). 409 o Clients may drop fragments via intermediary URLs with "fix 410 fragments" (see [fb_fragments]) to prevent the user agent from 411 appending any unintended fragments. 413 As an alternative to exact redirect URI matching, the AS could also 414 authenticate clients, e.g., using [I-D.ietf-oauth-jwsreq]. 416 3.2. Code or State Leakage from Client or AS via Referrer Headers 418 Authorization codes or values of "state" can unintentionally be 419 disclosed to attackers through the referrer header, by leaking either 420 from a client's web site or from an AS's web site. 422 Leakage from OAuth client: This requires that the client, as a result 423 of a successful authorization request, renders a page that 425 o contains links to other pages under the attacker's control (ads, 426 faq, ...) and a user clicks on such a link, or 428 o includes third-party content (iframes, images, etc.) for example 429 if the page contains user-generated content (blog). 431 As soon as the browser navigates to the attacker's page or loads the 432 third-party content, the attacker receives the authorization response 433 URL and can extract "code" or "state". 435 Leakage from AS: In a similar way, an attacker can learn "state" if 436 the authorization endpoint at the authorization server contains links 437 or third-party content as above. 439 Consequences: An attacker that learns a valid code through a referrer 440 header can perform the same attacks as described in 441 Section Section 3.1.1. If the attacker learns "state", the CSRF 442 protection achieved by using "state" is lost, resulting in CSRF 443 attacks as described in [RFC6819], Section 4.4.1.8.. 445 3.2.1. Proposed Countermeasures 447 The page rendered as a result of the OAuth authorization response and 448 the authorization endpoint SHOULD not include third-party resources 449 or links to external sites. 451 The following measures further reduce the chances of a successful 452 attack: 454 o Authorization codes SHOULD be invalidated by the AS after their 455 first use at the token endpoint. For example, if an AS 456 invalidated the code after the legitimate client redeemed it, the 457 attacker would fail exchanging this code later. (This does not 458 mitigate the attack if the attacker manages to exchange the code 459 for a token before the legitimate client does so.) 461 o The "state" value SHOULD be invalidated by the client after its 462 first use at the redirection endpoint. If this is implemented, 463 and an attacker receives a token through the referrer header from 464 the client's web site, the "state" was already used, invalidated 465 by the client and cannot be used again by the attacker. (This 466 does not help if the "state" leaks from the AS's web site, since 467 then the "state" has not been used at the redirection endpoint at 468 the client yet.) 470 o Bind authorization code to a confidential client or PKCE 471 challenge. In this case, the attacker lacks the secret to request 472 the code exchange. 474 o Suppress the referrer header by adding the attribute 475 "rel="noreferrer"" to HTML links or by applying an appropriate 476 Referrer Policy [webappsec-referrer-policy] to the document 477 (either as part of the "referrer" meta attribute or by setting a 478 Referrer-Policy header). 480 o Use form post response mode instead of redirect for authorization 481 response (see [oauth-v2-form-post-response-mode]). 483 3.3. Attacks through the Browser History 485 Authorization codes and access tokens can end up in the browser's 486 history of visited URLs, enabling the attacks described in the 487 following. 489 3.3.1. Code in Browser History 491 When a browser navigates to "client.example/ 492 redirection_endpoint?code=abcd" as a result of a redirect from a 493 provider's authorization endpoint, the URL including the 494 authorization code may end up in the browser's history. An attacker 495 with access to the device could obtain the code and try to replay it. 497 Proposed countermeasures: 499 o Authorization code replay prevention as described in [RFC6819], 500 Section 4.4.1.1, and Section 3.5 502 o Use form post response mode instead of redirect for authorization 503 response (see [oauth-v2-form-post-response-mode]) 505 3.3.2. Access Token in Browser History 507 An access token may end up in the browser history if a a client or 508 just a web site, which already has a token, deliberately navigates to 509 a page like "provider.com/get_user_profile?access_token=abcdef.". 510 Actually [RFC6750] discourages this practice and asks to transfer 511 tokens via a header, but in practice web sites often just pass access 512 token in query parameters. 514 In case of implicit grant, a URL like "client.example/ 515 redirection_endpoint#access_token=abcdef" may also end up in the 516 browser history as a result of a redirect from a provider's 517 authorization endpoint. 519 Proposed countermeasures: 521 o Replace implicit flow with postmessage communication or the 522 authorization code grant 524 o Never pass access tokens in URL query parameters 526 3.4. Mix-Up 528 Mix-up is an attack on scenarios where an OAuth client interacts with 529 multiple authorization servers, as is usually the case when dynamic 530 registration is used. The goal of the attack is to obtain an 531 authorization code or an access token by tricking the client into 532 sending those credentials to the attacker instead of using them at 533 the respective endpoint at the authorization/resource server. 535 3.4.1. Attack Description 537 For a detailed attack description, refer to [arXiv.1601.01229] and 538 [I-D.ietf-oauth-mix-up-mitigation]. The description here closely 539 follows [arXiv.1601.01229], with variants of the attack outlined 540 below. 542 Preconditions: For the attack to work, we assume that 544 (1) the implicit or authorization code grant are used with multiple 545 AS of which one is considered "honest" (H-AS) and one is 546 operated by the attacker (A-AS), 548 (2) the client stores the AS chosen by the user in a session bound 549 to the user's browser and uses the same redirection endpoint URI 550 for each AS, and 552 (3) the attacker can manipulate the first request/response pair from 553 a user's browser to the client (in which the user selects a 554 certain AS and is then redirected by the client to that AS). 556 Some of the attack variants described below require different 557 preconditions. 559 In the following, we assume that the client is registered with H-AS 560 (URI: "https://honest.as.example", client id: 7ZGZldHQ) and with A-AS 561 (URI: "https://attacker.example", client id: 666RVZJTA). 563 Attack on the authorization code grant: 565 (1) The user selects to start the grant using H-AS (e.g., by 566 clicking on a button at the client's website). 568 (2) The attacker intercepts this request and changes the user's 569 selection to "A-AS". 571 (3) The client stores in the user's session that the user selected 572 "A-AS" and redirects the user to A-AS's authorization endpoint 573 by sending the following response: 575 HTTP/1.1 303 See Other 576 Location: https://attacker.example/authorize?response_type=code&client_id=666RVZJTA 577 (4) Now the attacker intercepts this response and changes the 578 redirection such that the user is being redirected to H-AS. The 579 attacker also replaces the client id of the client at A-AS with 580 the client's id at H-AS, resulting in the following response 581 being sent to the browser: 583 HTTP/1.1 303 See Other 584 Location: https://honest.as.example/authorize?response_type=code&client_id=7ZGZldHQ 586 (5) Now, the user authorizes the client to access her resources at 587 H-AS. H-AS issues a code and sends it (via the browser) back to 588 the client. 590 (6) Since the client still assumes that the code was issued by A-AS, 591 it will try to redeem the code at A-AS's token endpoint. 593 (7) The attacker therefore obtains code and can either exchange the 594 code for an access token (for public clients) or perform a code 595 injection attack as described in Section Section 3.5. 597 Variants: 599 Implicit Grant In the implicit grant, the attacker receives an 600 access token instead of the code; the rest of the attack 601 works as above. 603 Mix-Up Without Interception A variant of the above attack works even 604 if the first request/response pair cannot be intercepted (for 605 example, because TLS is used to protect these messages): 606 Here, we assume that the user wants to start the grant using 607 A-AS (and not H-AS). After the client redirected the user to 608 the authorization endpoint at A-AS, the attacker immediately 609 redirects the user to H-AS (changing the client id 610 "7ZGZldHQ"). (A vigilant user might at this point detect 611 that she intended to use A-AS instead of H-AS.) The attack 612 now proceeds exactly as in step 1 of the attack description 613 above. 615 Per-AS Redirect URIs If clients use different redirect URIs for 616 different ASs, do not store the selected AS in the user's 617 session, and ASs do not check the redirect URIs properly, 618 attackers can mount an attack called "Cross-Social Network 619 Request Forgery". We refer to [oauth_security_jcs_14] for 620 details. 622 OpenID Connect There are several variants that can be used to attack 623 OpenID Connect. They are described in detail in 625 [arXiv.1704.08539], Appendix A, and [arXiv.1508.04324v2], 626 Section 6 ("Malicious Endpoints Attacks"). 628 3.4.2. Countermeasures 630 In scenarios where an OAuth client interacts with multiple 631 authorization servers, clients MUST prevent mix-up attacks. 633 Potential countermeasures: 635 o Configure authorization servers to return an AS identitifier 636 ("iss") and the "client_id" for which a code or token was issued 637 in the authorization response. This enables clients to compare 638 this data to their own client id and the "iss" identifier of the 639 AS it believed it sent the user agent to. This mitigation is 640 discussed in detail in [I-D.ietf-oauth-mix-up-mitigation]. In 641 OpenID Connect, if an ID token is returned in the authorization 642 response, it carries client id and issuer. It can be used for 643 this mitigation. 645 o As it can be seen in the preconditions of the attacks above, 646 clients can prevent mix-up attack by (1) using AS-specific 647 redirect URIs with exact redirect URI matching, (2) storing, for 648 each authorization request, the intended AS, and (3) comparing the 649 intended AS with the actual redirect URI where the authorization 650 response was received. 652 3.5. Code Injection 654 In such an attack, the adversary attempts to inject a stolen 655 authorization code into a legitimate client on a device under his 656 control. In the simplest case, the attacker would want to use the 657 code in his own client. But there are situations where this might 658 not be possible or intended. Examples are: 660 o The attacker wants to access certain functions in this particular 661 client. As an example, the attacker wants to impersonate his 662 victim in a certain app or on a certain web site. 664 o The code is bound to a particular confidential client and the 665 attacker is unable to obtain the required client credentials to 666 redeem the code himself. 668 o The authorization or resource servers are limited to certain 669 networks, the attackers is unable to access directly. 671 How does an attack look like? 672 (1) The attacker obtains an authorization code by performing any of 673 the attacks described above. 675 (2) It performs a regular OAuth authorization process with the 676 legitimate client on his device. 678 (3) The attacker injects the stolen authorization code in the 679 response of the authorization server to the legitimate client. 681 (4) The client sends the code to the authorization server's token 682 endpoint, along with client id, client secret and actual 683 "redirect_uri". 685 (5) The authorization server checks the client secret, whether the 686 code was issued to the particular client and whether the actual 687 redirect URI matches the "redirect_uri" parameter (see 688 [RFC6749]). 690 (6) If all checks succeed, the authorization server issues access 691 and other tokens to the client, so now the attacker is able to 692 impersonate the legitimate user. 694 Obviously, the check in step (5) will fail, if the code was issued to 695 another client id, e.g., a client set up by the attacker. The check 696 will also fail if the authorization code was already redeemed by the 697 legitimate user and was one-time use only. 699 An attempt to inject a code obtained via a malware pretending to be 700 the legitimate client should also be detected, if the authorization 701 server stored the complete redirect URI used in the authorization 702 request and compares it with the redirect_uri parameter. 704 [RFC6749], Section 4.1.3, requires the AS to "... ensure that the 705 "redirect_uri" parameter is present if the "redirect_uri" parameter 706 was included in the initial authorization request as described in 707 Section 4.1.1, and if included ensure that their values are 708 identical.". In the attack scenario described above, the legitimate 709 client would use the correct redirect URI it always uses for 710 authorization requests. But this URI would not match the tampered 711 redirect URI used by the attacker (otherwise, the redirect would not 712 land at the attackers page). So the authorization server would 713 detect the attack and refuse to exchange the code. 715 Note: this check could also detect attempt to inject a code, which 716 had been obtained from another instance of the same client on another 717 device, if certain conditions are fulfilled: 719 o the redirect URI itself needs to contain a nonce or another kind 720 of one-time use, secret data and 722 o the client has bound this data to this particular instance. 724 But this approach conflicts with the idea to enforce exact redirect 725 URI matching at the authorization endpoint. Moreover, it has been 726 observed that providers very often ignore the redirect_uri check 727 requirement at this stage, maybe because it doesn't seem to be 728 security-critical from reading the spec. 730 Other providers just pattern match the redirect_uri parameter against 731 the registered redirect URI pattern. This saves the authorization 732 server from storing the link between the actual redirect URI and the 733 respective authorization code for every transaction. But this kind 734 of check obviously does not fulfill the intent of the spec, since the 735 tampered redirect URI is not considered. So any attempt to inject a 736 code obtained using the "client_id" of a legitimate client or by 737 utilizing the legitimate client on another device won't be detected 738 in the respective deployments. 740 It is also assumed that the requirements defined in [RFC6749], 741 Section 4.1.3, increase client implementation complexity as clients 742 need to memorize or re-construct the correct redirect URI for the 743 call to the tokens endpoint. 745 This document therefore recommends to instead bind every 746 authorization code to a certain client instance on a certain device 747 (or in a certain user agent) in the context of a certain transaction. 749 3.5.1. Proposed Countermeasures 751 There are multiple technical solutions to achieve this goal: 753 Nonce OpenID Connect's existing "nonce" parameter could be used for 754 this purpose. The nonce value is one-time use and created by 755 the client. The client is supposed to bind it to the user 756 agent session and sends it with the initial request to the 757 OpenId Provider (OP). The OP associates the nonce to the 758 authorization code and attests this binding in the ID token, 759 which is issued as part of the code exchange at the token 760 endpoint. If an attacker injected an authorization code in 761 the authorization response, the nonce value in the client 762 session and the nonce value in the ID token will not match 763 and the attack is detected. The assumption is that an 764 attacker cannot get hold of the user agent state on the 765 victims device, where he has stolen the respective 766 authorization code. The main advantage of this option is 767 that Nonce is an existing feature used in the wild. On the 768 other hand, leveraging Nonce by the broader OAuth community 769 would require AS and client to adopt ID Tokens. 771 Code-bound State The "state" parameter as specified in [RFC6749] 772 could be used similarly to what is described above. This 773 would require to add a further parameter "state" to the code 774 exchange token endpoint request. The authorization server 775 would then compare the "state" value it associated with the 776 code and the "state" value in the parameter. If those values 777 do not match, it is considered an attack and the request 778 fails. The advantage of this approach would be to utilize an 779 existing OAuth parameter. But it would also mean to re- 780 interpret the purpose of "state" and to extend the token 781 endpoint request. 783 PKCE The PKCE parameter "challenge" along with the corresponding 784 "verifier" as specified in [RFC7636] could be used in the 785 same way as "nonce" or "state". In contrast to its original 786 intention, the verifier check would fail although the client 787 uses its correct verifier but the code is associated with a 788 challenge, which does not match. PKCE is a deployed OAuth 789 feature, even though it is used today to secure native apps, 790 only. 792 Token Binding Token binding [I-D.ietf-oauth-token-binding] could 793 also be used. In this case, the code would need to be bound 794 to two legs, between user agent and AS and the user agent and 795 the client. This requires further data (extension to 796 response) to manifest binding id for particular code. Token 797 binding is promising as a secure and convenient mechanism 798 (due to its browser integration). As a challenge, it 799 requires broad browser support and use with native apps is 800 still under discussion. 802 per instance client id/secret One could use per instance "client_id" 803 and secrets and bind the code to the respective "client_id". 804 Unfortunately, this does not fit into the web application 805 programming model (would need to use per user client ids). 807 PKCE seems to be the most obvious solution for OAuth clients as it 808 available and effectively used today for similar purposes for OAuth 809 native apps whereas "nonce" is appropriate for OpenId Connect 810 clients. 812 Note on pre-warmed secrets: An attacker can circumvent the 813 countermeasures described above if he is able to create or capture 814 the respective secret or code_challenge on a device under his 815 control, which is then used in the victim's authorization request. 816 Exact redirect URI matching of authorization requests can prevent the 817 attacker from using the pre-warmed secret in the faked authorization 818 transaction on the victim's device. 819 Unfortunately, it does not work for all kinds of OAuth clients. It 820 is effective for web and JS apps and for native apps with claimed 821 URLs. Attacks on native apps using custom schemes or redirect URIs 822 on localhost cannot be prevented this way, except if the AS enforces 823 one-time use for PKCE verifier or "nonce" values. 825 3.6. Cross Site Request Forgery 827 An attacker might attempt to inject a request to the redirect URI of 828 the legitimate client on the victim's device, e.g., to cause the 829 client to access resources under the attacker's control. 831 3.6.1. Proposed Countermeasures 833 Standard CSRF defenses should be used to protect the redirection 834 endpoint, for example: 836 CSRF Tokens Use of CSRF tokens which are bound to the user agent 837 and passed in the "state" parameter to the 838 authorization server. 840 Origin Header The Origin header can be used to detect and prevent 841 CSRF attacks. Since this feature, at the time of 842 writing, is not consistently supported by all 843 browsers, CSRF tokens should be used in addition to 844 Origin header checking. 846 For more details see [owasp_csrf]. 848 3.7. Access Token Leakage at the Resource Server 850 Access tokens can leak from a resource server under certain 851 circumstances. 853 3.7.1. Access Token Phishing by Counterfeit Resource Server 855 An attacker may setup his own resource server and trick a client into 856 sending access tokens to it, which are valid for other resource 857 servers. If the client sends a valid access token to this 858 counterfeit resource server, the attacker in turn may use that token 859 to access other services on behalf of the resource owner. 861 This attack assumes the client is not bound to a certain resource 862 server (and the respective URL) at development time, but client 863 instances are configured with an resource server's URL at runtime. 864 This kind of late binding is typical in situations where the client 865 uses a standard API, e.g., for e-Mail, calendar, health, or banking 866 and is configured by an user or administrator for the standard-based 867 service, this particular user or company uses. 869 There are several potential mitigation strategies, which will be 870 discussed in the following sections. 872 3.7.1.1. Metadata 874 An authorization server could provide the client with additional 875 information about the location where it is safe to use its access 876 tokens. 878 In the simplest form, this would require the AS to publish a list of 879 its known resource servers, illustrated in the following example 880 using a metadata parameter "resource_servers": 882 HTTP/1.1 200 OK 883 Content-Type: application/json 885 { 886 "issuer":"https://server.somesite.example", 887 "authorization_endpoint": 888 "https://server.somesite.example/authorize", 889 "resource_servers":[ 890 "email.somesite.example", 891 "storage.somesite.example", 892 "video.somesite.example"] 893 ... 894 } 896 The AS could also return the URL(s) an access token is good for in 897 the token response, illustrated by the example return parameter 898 "access_token_resource_server": 900 HTTP/1.1 200 OK 901 Content-Type: application/json;charset=UTF-8 902 Cache-Control: no-store 903 Pragma: no-cache 905 { 906 "access_token":"2YotnFZFEjr1zCsicMWpAA", 907 "access_token_resource_server": 908 "https://hostedresource.somesite.example/path1", 909 ... 910 } 912 This mitigation strategy would rely on the client to enforce the 913 security policy and to only send access tokens to legitimate 914 destinations. Results of OAuth related security research (see for 915 example [oauth_security_ubc] and [oauth_security_cmu]) indicate a 916 large portion of client implementations do not or fail to properly 917 implement security controls, like "state" checks. So relying on 918 clients to prevent access token phishing is likely to fail as well. 919 Moreover given the ratio of clients to authorization and resource 920 servers, it is considered the more viable approach to move as much as 921 possible security-related logic to those entities. Clearly, the 922 client has to contribute to the overall security. But there are 923 alternative countermeasures, as described in the next sections, which 924 provide a better balance between the involved parties. 926 3.7.1.2. Sender Constrained Access Tokens 928 As the name suggests, sender constrained access token scope the 929 applicability of an access token to a certain sender. This sender is 930 obliged to demonstrate knowledge of a certain secret as prerequisite 931 for the acceptance of that token at a resource server. 933 A typical flow looks like this: 935 1. The authorization server associates data with the access token 936 which binds this particular token to a certain client. The 937 binding can utilize the client identity, but in most cases the AS 938 utilizes key material (or data derived from the key material) 939 known to the client. 941 2. This key material must be distributed somehow. Either the key 942 material already exists before the AS creates the binding or the 943 AS creates ephemeral keys. The way pre-existing key material is 944 distributed varies among the different approaches. For example, 945 X.509 Certificates can be used in which case the distribution 946 happens explicitly during the enrollment process. Or the key 947 material is created and distributed at the TLS layer, in which 948 case it might automatically happens during the setup of a TLS 949 connection. 951 3. The RS must implement the actual proof of possession check. This 952 is typically done on the application level, it may utilize 953 capabilities of the transport layer (e.g., TLS). Note: replay 954 prevention is required as well! 956 There exists several proposals to demonstrate the proof of possession 957 in the scope of the OAuth working group: 959 o [I-D.ietf-oauth-token-binding]: In this approach, an access tokens 960 is, via the so-called token binding id, bound to key material 961 representing a long term association between a client and a 962 certain TLS host. Negotiation of the key material and proof of 963 possession in the context of a TLS handshake is taken care of by 964 the TLS stack. The client needs to determine the token binding id 965 of the target resource server and pass this data to the access 966 token request. The authorization server than associates the 967 access token with this id. The resource server checks on every 968 invocation that the token binding id of the active TLS connection 969 and the token binding id of associated with the access token 970 match. Since all crypto-related functions are covered by the TLS 971 stack, this approach is very client developer friendly. As a 972 prerequisite, token binding as described in 973 [I-D.ietf-tokbind-https] (including federated token bindings) must 974 be supported on all ends (client, authorization server, resource 975 server). 977 o [I-D.ietf-oauth-mtls]: The approach as specified in this document 978 allow use of mutual TLS for both client authentication and sender 979 constraint access tokens. For the purpose of sender constraint 980 access tokens, the client is identified towards the resource 981 server by the fingerprint of its public key. During processing of 982 an access token request, the authorization server obtains the 983 client's public key from the TLS stack and associates its 984 fingerprint with the respective access tokens. The resource 985 server in the same way obtains the public key from the TLS stack 986 and compares its fingerprint with the fingerprint associated with 987 the access token. 989 o [I-D.ietf-oauth-signed-http-request] specifies an approach to sign 990 HTTP requests. It utilizes [I-D.ietf-oauth-pop-key-distribution] 991 and represents the elements of the signature in a JSON object. 992 The signature is built using JWS. The mechanism has built-in 993 support for signing of HTTP method, query parameters and headers. 994 It also incorporates a timestamp as basis for replay prevention. 996 o [I-D.sakimura-oauth-jpop]: this draft describes different ways to 997 constrain access token usage, namely TLS or request signing. 998 Note: Since the authors of this draft contributed the TLS-related 999 proposal to [I-D.ietf-oauth-mtls], this document only considers 1000 the request signing part. For request signing, the draft utilizes 1001 [I-D.ietf-oauth-pop-key-distribution] and RFC 7800 [RFC7800]. The 1002 signature data is represented in a JWT and JWS is used for 1003 signing. Replay prevention is provided by building the signature 1004 over a server-provided nonce, client-provided nonce and a nonce 1005 counter. 1007 [I-D.ietf-oauth-mtls] and [I-D.ietf-oauth-token-binding] are built on 1008 top of TLS and this way continue the successful OAuth 2.0 philosophy 1009 to leverage TLS to secure OAuth wherever possible. Both mechanisms 1010 allow prevention of access token leakage in a fairly client developer 1011 friendly way. 1013 There are some differences between both approaches: To start with, in 1014 [I-D.ietf-oauth-token-binding] all key material is automatically 1015 managed by the TLS stack whereas [I-D.ietf-oauth-mtls] requires the 1016 developer to create and maintain the key pairs and respective 1017 certificates. Use of self-signed certificates, which is supported by 1018 the draft, significantly reduce the complexity of this task. 1019 Furthermore, [I-D.ietf-oauth-token-binding] allows to use different 1020 key pairs for different resource servers, which is a privacy benefit. 1021 On the other hand, [I-D.ietf-oauth-mtls] only requires widely 1022 deployed TLS features, which means it might be easier to adopt in the 1023 short term. 1025 Application level signing approaches, like 1026 [I-D.ietf-oauth-signed-http-request] and [I-D.sakimura-oauth-jpop] 1027 have been debated for a long time in the OAuth working group without 1028 a clear outcome. 1030 As one advantage, application-level signing allows for end-to-end 1031 protection including non-repudiation even if the TLS connection is 1032 terminated between client and resource server. But deployment 1033 experiences have revealed challenges regarding robustness (e.g., 1034 reproduction of the signature base string including correct URL) as 1035 well as state management (e.g., replay prevention). 1037 This document therefore recommends implementors to consider one of 1038 TLS-based approaches wherever possible. 1040 3.7.1.3. Audience Restricted Access Tokens 1042 An audience restriction essentially restricts the resource server a 1043 particular access token can be used at. The authorization server 1044 associates the access token with a certain resource server and every 1045 resource server is obliged to verify for every request, whether the 1046 access token send with that request was meant to be used at the 1047 particular resource server. If not, the resource server must refuse 1048 to serve the respective request. In the general case, audience 1049 restrictions limit the impact of a token leakage. In the case of a 1050 counterfeit resource server, it may (as described see below) also 1051 prevent abuse of the phished access token at the legitimate resource 1052 server. 1054 The audience can basically be expressed using logical names or 1055 physical addresses (like URLs). In order to prevent phishing, it is 1056 necessary to use the actual URL the client will send requests to. In 1057 the phishing case, this URL will point to the counterfeit resource 1058 server. If the attacker tries to use the access token at the 1059 legitimate resource server (which has a different URL), the resource 1060 server will detect the mismatch (wrong audience) and refuse to serve 1061 the request. 1063 In deployments where the authorization server knows the URLs of all 1064 resource servers, the authorization server may just refuse to issue 1065 access tokens for unknown resource server URLs. 1067 The client needs to tell the authorization server, at which URL it 1068 will use the access token it is requesting. It could use the 1069 mechanism proposed [I-D.ietf-oauth-resource-indicators] or encode the 1070 information in the scope value. 1072 Instead of the URL, it is also possible to utilize the fingerprint of 1073 the resource server's X.509 certificate as audience value. This 1074 variant would also allow to detect an attempt to spoof the legit 1075 resource server's URL by using a valid TLS certificate obtained from 1076 a different CA. It might also be considered a privacy benefit to 1077 hide the resource server URL from the authorization server. 1079 Audience restriction seems easy to use since it does not require any 1080 crypto on the client side. But since every access token is bound to 1081 a certain resource server, the client also needs to obtain different 1082 RS-specific access tokens, if it wants to access several resource 1083 services. [I-D.ietf-oauth-token-binding] has the same property, 1084 since different token binding ids must be associated with the access 1085 token. [I-D.ietf-oauth-mtls] on the other hand allows a client to 1086 use the access token at multiple resource servers. 1088 It shall be noted that audience restrictions, or generally speaking 1089 an indication by the client to the authorization server where it 1090 wants to use the access token, has additional benefits beyond the 1091 scope of token leakage prevention. It allows the authorization 1092 server to create different access token whose format and content is 1093 specifically minted for the respective server. This has huge 1094 functional and privacy advantages in deployments using structured 1095 access tokens. 1097 3.7.2. Compromised Resource Server 1099 An attacker may compromise a resource server in order to get access 1100 to its resources and other resources of the respective deployment. 1101 Such a compromise may range from partial access to the system, e.g., 1102 its logfiles, to full control of the respective server. 1104 If the attacker was able to take over full control including shell 1105 access it will be able to circumvent all controls in place and access 1106 resources without access control. It will also get access to access 1107 tokens, which are sent to the compromised system and which 1108 potentially are valid for access to other resource servers as well. 1109 Even if the attacker "only" is able to access logfiles or databases 1110 of the server system, it may get access to valid access tokens. 1112 Preventing server breaches by way of hardening and monitoring server 1113 systems is considered a standard operational procedure and therefore 1114 out of scope of this document. This section will focus on the impact 1115 of such breaches on OAuth-related parts of the ecosystem, which is 1116 the replay of captured access tokens on the compromised resource 1117 server and other resource servers of the respective deployment. 1119 The following measures shall be taken into account by implementors in 1120 order to cope with access token replay: 1122 o The resource server must treat access tokens like any other 1123 credentials. It is considered good practice to not log them and 1124 not to store them in plain text. 1126 o Sender constraint access tokens as described in Section 3.7.1.2 1127 will prevent the attacker from replaying the access tokens on 1128 other resource servers. Depending on the severity of the 1129 penetration, it will also prevent replay on the compromised 1130 system. 1132 o Audience restriction as described in Section 3.7.1.3 may be used 1133 to prevent replay of captured access tokens on other resource 1134 servers. 1136 3.8. Open Redirection 1138 The following attacks can occur when an AS or client has an open 1139 redirector, i.e., a URL which causes an HTTP redirect to an attacker- 1140 controlled web site. 1142 3.8.1. Authorization Server as Open Redirector 1144 Attackers could try to utilize a user's trust in the authorization 1145 server (and its URL in particular) for performing phishing attacks. 1147 [RFC6749], Section 4.1.2.1, already prevents open redirects by 1148 stating the AS MUST NOT automatically redirect the user agent in case 1149 of an invalid combination of client_id and redirect_uri. 1151 However, as described in [I-D.ietf-oauth-closing-redirectors], an 1152 attacker could also utilize a correctly registered redirect URI to 1153 perform phishing attacks. It could for example register a client via 1154 dynamic client [RFC7591] registration and intentionally send an 1155 erroneous authorization request, e.g., by using an invalid scope 1156 value, to cause the AS to automatically redirect the user agent to 1157 its phishing site. 1159 The AS MUST take precautions to prevent this threat. Based on its 1160 risk assessment the AS needs to decide whether it can trust the 1161 redirect URI or not and SHOULD only automatically redirect the user 1162 agent, if it trusts the redirect URI. If not, it MAY inform the user 1163 that it is about to redirect her to the another site and rely on the 1164 user to decide or MAY just inform the user about the error. 1166 3.8.2. Clients as Open Redirector 1168 Client MUST NOT expose URLs which could be utilized as open 1169 redirector. Attackers may use an open redirector to produce URLs 1170 which appear to point to the client, which might trick users to trust 1171 the URL and follow it in her browser. Another abuse case is to 1172 produce URLs pointing to the client and utilize them to impersonate a 1173 client with an authorization server. 1175 In order to prevent open redirection, clients should only expose such 1176 a function, if the target URLs are whitelisted or if the origin of a 1177 request can be authenticated. 1179 3.9. 307 Redirect 1181 At the authorization endpoint, a typical protocol flow is that the AS 1182 prompts the user to enter her credentials in a form that is then 1183 submitted (using the HTTP POST method) back to the authorization 1184 server. The AS checks the credentials and, if successful, redirects 1185 the user agent to the client's redirection endpoint. 1187 In [RFC6749], the HTTP status code 302 is used for this purpose, but 1188 "any other method available via the user-agent to accomplish this 1189 redirection is allowed". However, when the status code 307 is used 1190 for redirection, the user agent will send the form data (user 1191 credentials) via HTTP POST to the client since this status code does 1192 not require the user agent to rewrite the POST request to a GET 1193 request (and thereby dropping the form data in the POST request 1194 body). If the relying party is malicious, it can use the credentials 1195 to impersonate the user at the AS. 1197 In the HTTP standard [RFC6749], only the status code 303 1198 unambigiously enforces rewriting the HTTP POST request to an HTTP GET 1199 request. For all other status codes, including the popular 302, user 1200 agents can opt not to rewrite POST to GET requests and therefore to 1201 reveal the user credentials to the client. (In practice, however, 1202 most user agents will only show this behaviour for 307 redirects.) 1204 AS which redirect a request that potentially contains user 1205 credentials therefore MUST not use the HTTP 307 status code for 1206 redirection. If an HTTP redirection (and not, for example, 1207 JavaScript) is used for such a request, AS SHOULD use HTTP status 1208 code 303 "See Other". 1210 3.10. TLS Terminating Reverse Proxies 1212 A common deployment architecture for HTTP applications is to have the 1213 application server sitting behind a reverse proxy, which terminates 1214 the TLS connection and dispatches the incoming requests to the 1215 respective application server nodes. 1217 This section highlights some attack angles of this deployment 1218 architecture, which are relevant to OAuth, and give recommendations 1219 for security controls. 1221 In some situations, the reverse proxy needs to pass security-related 1222 data to the upstream application servers for further processing. 1223 Examples include the IP address of the request originator, token 1224 binding ids and authenticated TLS client certificates. 1226 If the reverse proxy would pass through any header sent from the 1227 outside, an attacker could try to directly send the faked header 1228 values through the proxy to the application server in order to 1229 circumvent security controls that way. For example, it is standard 1230 practice of reverse proxies to accept "forwarded_for" headers and 1231 just add the origin of the inbound request (making it a list). 1233 Depending on the logic performed in the application server, the 1234 attacker could simply add a whitelisted IP address to the header and 1235 render a IP whitelist useless. A reverse proxy must therefore 1236 sanitize any inbound requests to ensure the authenticity and 1237 integrity of all header values relevant for the security of the 1238 application servers. 1240 If an attacker would be able to get access to the internal network 1241 between proxy and application server, it could also try to circumvent 1242 security controls in place. It is therefore important to ensure the 1243 authenticity of the communicating entities. Furthermore, the 1244 communication link between reverse proxy and application server must 1245 therefore be protected against tapping and injection (including 1246 replay prevention). 1248 4. Acknowledgements 1250 We would like to thank Jim Manico, Phil Hunt, Nat Sakimura, Christian 1251 Mainka, Doug McDorman, Johan Peeters, and Brian Campbell for their 1252 valuable feedback. 1254 5. IANA Considerations 1256 This draft includes no request to IANA. 1258 6. Security Considerations 1260 All relevant security considerations have been given in the 1261 functional specification. 1263 7. References 1265 7.1. Normative References 1267 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1268 Requirement Levels", BCP 14, RFC 2119, 1269 DOI 10.17487/RFC2119, March 1997, 1270 . 1272 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1273 Resource Identifier (URI): Generic Syntax", STD 66, 1274 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1275 . 1277 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1278 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1279 . 1281 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1282 Framework: Bearer Token Usage", RFC 6750, 1283 DOI 10.17487/RFC6750, October 2012, 1284 . 1286 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 1287 Threat Model and Security Considerations", RFC 6819, 1288 DOI 10.17487/RFC6819, January 2013, 1289 . 1291 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1292 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1293 DOI 10.17487/RFC7231, June 2014, 1294 . 1296 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 1297 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 1298 RFC 7591, DOI 10.17487/RFC7591, July 2015, 1299 . 1301 7.2. Informative References 1303 [arXiv.1508.04324v2] 1304 Mladenov, V., Mainka, C., and J. Schwenk, "On the security 1305 of modern Single Sign-On Protocols: Second-Order 1306 Vulnerabilities in OpenID Connect", arXiv 1508.04324v2, 1307 January 2016, . 1309 [arXiv.1601.01229] 1310 Fett, D., Kuesters, R., and G. Schmitz, "A Comprehensive 1311 Formal Security Analysis of OAuth 2.0", arXiv 1601.01229, 1312 January 2016, . 1314 [arXiv.1704.08539] 1315 Fett, D., Kuesters, R., and G. Schmitz, "The Web SSO 1316 Standard OpenID Connect: In-Depth Formal Security Analysis 1317 and Security Guidelines", arXiv 1704.08539, April 2017, 1318 . 1320 [fb_fragments] 1321 "Facebook Developer Blog", 1322 . 1324 [I-D.bradley-oauth-jwt-encoded-state] 1325 Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding 1326 claims in the OAuth 2 state parameter using a JWT", draft- 1327 bradley-oauth-jwt-encoded-state-08 (work in progress), 1328 January 2018. 1330 [I-D.ietf-oauth-closing-redirectors] 1331 Bradley, J., Sanso, A., and H. Tschofenig, "OAuth 2.0 1332 Security: Closing Open Redirectors in OAuth", draft-ietf- 1333 oauth-closing-redirectors-00 (work in progress), February 1334 2016. 1336 [I-D.ietf-oauth-jwsreq] 1337 Sakimura, N. and J. Bradley, "The OAuth 2.0 Authorization 1338 Framework: JWT Secured Authorization Request (JAR)", 1339 draft-ietf-oauth-jwsreq-16 (work in progress), April 2018. 1341 [I-D.ietf-oauth-mix-up-mitigation] 1342 Jones, M., Bradley, J., and N. Sakimura, "OAuth 2.0 Mix-Up 1343 Mitigation", draft-ietf-oauth-mix-up-mitigation-01 (work 1344 in progress), July 2016. 1346 [I-D.ietf-oauth-mtls] 1347 Campbell, B., Bradley, J., Sakimura, N., and T. 1348 Lodderstedt, "OAuth 2.0 Mutual TLS Client Authentication 1349 and Certificate Bound Access Tokens", draft-ietf-oauth- 1350 mtls-10 (work in progress), July 2018. 1352 [I-D.ietf-oauth-pop-key-distribution] 1353 Bradley, J., Hunt, P., Jones, M., and H. Tschofenig, 1354 "OAuth 2.0 Proof-of-Possession: Authorization Server to 1355 Client Key Distribution", draft-ietf-oauth-pop-key- 1356 distribution-03 (work in progress), February 2017. 1358 [I-D.ietf-oauth-resource-indicators] 1359 Campbell, B., Bradley, J., and H. Tschofenig, "Resource 1360 Indicators for OAuth 2.0", draft-ietf-oauth-resource- 1361 indicators-00 (work in progress), August 2018. 1363 [I-D.ietf-oauth-signed-http-request] 1364 Richer, J., Bradley, J., and H. Tschofenig, "A Method for 1365 Signing HTTP Requests for OAuth", draft-ietf-oauth-signed- 1366 http-request-03 (work in progress), August 2016. 1368 [I-D.ietf-oauth-token-binding] 1369 Jones, M., Campbell, B., Bradley, J., and W. Denniss, 1370 "OAuth 2.0 Token Binding", draft-ietf-oauth-token- 1371 binding-07 (work in progress), June 2018. 1373 [I-D.ietf-tokbind-https] 1374 Popov, A., Nystrom, M., Balfanz, D., Langley, A., Harper, 1375 N., and J. Hodges, "Token Binding over HTTP", draft-ietf- 1376 tokbind-https-18 (work in progress), June 2018. 1378 [I-D.sakimura-oauth-jpop] 1379 Sakimura, N., Li, K., and J. Bradley, "The OAuth 2.0 1380 Authorization Framework: JWT Pop Token Usage", draft- 1381 sakimura-oauth-jpop-04 (work in progress), March 2017. 1383 [oauth-v2-form-post-response-mode] 1384 Microsoft and Ping Identity, "OAuth 2.0 Form Post Response 1385 Mode", April 2015, . 1388 [oauth_security_cmu] 1389 Carnegie Mellon University, Carnegie Mellon University, 1390 Microsoft Research, Carnegie Mellon University, Carnegie 1391 Mellon University, and Carnegie Mellon University, "OAuth 1392 Demystified for Mobile Application Developers", November 1393 2014. 1395 [oauth_security_jcs_14] 1396 Bansal, C., Bhargavan, K., Delignat-Lavaud, A., and S. 1397 Maffeis, "Discovering concrete attacks on website 1398 authorization by formal analysis", April 2014. 1400 [oauth_security_ubc] 1401 University of British Columbia and University of British 1402 Columbia, "The Devil is in the (Implementation) Details: 1403 An Empirical Analysis of OAuth SSO Systems", October 2012, 1404 . 1406 [OpenID] NRI, Ping Identity, Microsoft, Google, and Salesforce, 1407 "OpenID Connect Core 1.0 incorporating errata set 1", Nov 1408 2014, 1409 . 1411 [owasp] "Open Web Application Security Project Home Page", 1412 . 1414 [owasp_csrf] 1415 "Cross-Site Request Forgery (CSRF) Prevention Cheat 1416 Sheet", . 1419 [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 1420 for Code Exchange by OAuth Public Clients", RFC 7636, 1421 DOI 10.17487/RFC7636, September 2015, 1422 . 1424 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 1425 Possession Key Semantics for JSON Web Tokens (JWTs)", 1426 RFC 7800, DOI 10.17487/RFC7800, April 2016, 1427 . 1429 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 1430 Authorization Server Metadata", RFC 8414, 1431 DOI 10.17487/RFC8414, June 2018, 1432 . 1434 [webappsec-referrer-policy] 1435 Google Inc. and Google Inc., "Referrer Policy", April 1436 2017, . 1438 Appendix A. Document History 1440 [[ To be removed from the final specification ]] 1442 -07 1444 o incorporated findings of Doug McDorman 1446 o added section on HTTP status codes for redirects 1448 o added new section on access token privilege restriction based on 1449 comments from Johan Peeters 1451 -06 1453 o reworked section 3.8.1 1455 o incorporated Phil Hunt's feedback 1457 o reworked section on mix-up 1459 o extended section on code leakage via referrer header to also cover 1460 state leakage 1462 o added Daniel Fett as author 1464 o replaced text intended to inform WG discussion by recommendations 1465 to implementors 1467 o modified example URLs to conform to RFC 2606 1469 -05 1470 o Completed sections on code leakage via referrer header, attacks in 1471 browser, mix-up, and CSRF 1473 o Reworked Code Injection Section 1475 o Added reference to OpenID Connect spec 1477 o removed refresh token leakage as respective considerations have 1478 been given in section 10.4 of RFC 6749 1480 o first version on open redirection 1482 o incorporated Christian Mainka's review feedback 1484 -04 1486 o Restructured document for better readability 1488 o Added best practices on Token Leakage prevention 1490 -03 1492 o Added section on Access Token Leakage at Resource Server 1494 o incorporated Brian Campbell's findings 1496 -02 1498 o Folded Mix up and Access Token leakage through a bad AS into new 1499 section for dynamic OAuth threats 1501 o reworked dynamic OAuth section 1503 -01 1505 o Added references to mitigation methods for token leakage 1507 o Added reference to Token Binding for Authorization Code 1509 o incorporated feedback of Phil Hunt 1511 o fixed numbering issue in attack descriptions in section 2 1513 -00 (WG document) 1515 o turned the ID into a WG document and a BCP 1517 o Added federated app login as topic in Other Topics 1519 Authors' Addresses 1521 Torsten Lodderstedt (editor) 1522 YES.com AG 1524 Email: torsten@lodderstedt.net 1526 John Bradley 1527 Yubico 1529 Email: ve7jtb@ve7jtb.com 1531 Andrey Labunets 1532 Facebook 1534 Email: isciurus@fb.com 1536 Daniel Fett 1537 YES.com AG 1539 Email: mail@danielfett.de