idnits 2.17.1 draft-ietf-oauth-security-topics-18.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: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 'not RECOMMENDED' in this paragraph: * Make MTLS a suggestion, not RECOMMENDED. -- The document date (12 April 2021) is 1109 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'OpenID' ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Downref: Normative reference to an Informational RFC: RFC 6819 -- Possible downref: Non-RFC (?) normative reference: ref. 'OpenIDDisc' == Outdated reference: A later version (-05) exists of draft-ietf-oauth-iss-auth-resp-00 == Outdated reference: A later version (-10) exists of draft-ietf-oauth-par-05 == Outdated reference: A later version (-34) exists of draft-ietf-oauth-jwsreq-30 == Outdated reference: A later version (-16) exists of draft-ietf-oauth-dpop-02 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-rar-03 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Web Authorization Protocol T. Lodderstedt 3 Internet-Draft yes.com 4 Intended status: Best Current Practice J. Bradley 5 Expires: 14 October 2021 Yubico 6 A. Labunets 8 D. Fett 9 yes.com 10 12 April 2021 12 OAuth 2.0 Security Best Current Practice 13 draft-ietf-oauth-security-topics-18 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 14 October 2021. 40 Copyright Notice 42 Copyright (c) 2021 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 (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.2. Conventions and Terminology . . . . . . . . . . . . . . . 4 59 2. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.1. Protecting Redirect-Based Flows . . . . . . . . . . . . . 5 61 2.1.1. Authorization Code Grant . . . . . . . . . . . . . . 6 62 2.1.2. Implicit Grant . . . . . . . . . . . . . . . . . . . 7 63 2.2. Token Replay Prevention . . . . . . . . . . . . . . . . . 7 64 2.2.1. Access Tokens . . . . . . . . . . . . . . . . . . . . 7 65 2.2.2. Refresh Tokens . . . . . . . . . . . . . . . . . . . 7 66 2.3. Access Token Privilege Restriction . . . . . . . . . . . 8 67 2.4. Resource Owner Password Credentials Grant . . . . . . . . 8 68 2.5. Client Authentication . . . . . . . . . . . . . . . . . . 9 69 2.6. Other Recommendations . . . . . . . . . . . . . . . . . . 9 70 3. The Updated OAuth 2.0 Attacker Model . . . . . . . . . . . . 10 71 4. Attacks and Mitigations . . . . . . . . . . . . . . . . . . . 12 72 4.1. Insufficient Redirect URI Validation . . . . . . . . . . 12 73 4.1.1. Redirect URI Validation Attacks on Authorization Code 74 Grant . . . . . . . . . . . . . . . . . . . . . . . . 12 75 4.1.2. Redirect URI Validation Attacks on Implicit Grant . . 14 76 4.1.3. Countermeasures . . . . . . . . . . . . . . . . . . . 15 77 4.2. Credential Leakage via Referer Headers . . . . . . . . . 16 78 4.2.1. Leakage from the OAuth Client . . . . . . . . . . . . 16 79 4.2.2. Leakage from the Authorization Server . . . . . . . . 17 80 4.2.3. Consequences . . . . . . . . . . . . . . . . . . . . 17 81 4.2.4. Countermeasures . . . . . . . . . . . . . . . . . . . 17 82 4.3. Credential Leakage via Browser History . . . . . . . . . 18 83 4.3.1. Authorization Code in Browser History . . . . . . . . 18 84 4.3.2. Access Token in Browser History . . . . . . . . . . . 18 85 4.4. Mix-Up Attacks . . . . . . . . . . . . . . . . . . . . . 19 86 4.4.1. Attack Description . . . . . . . . . . . . . . . . . 19 87 4.4.2. Countermeasures . . . . . . . . . . . . . . . . . . . 21 88 4.5. Authorization Code Injection . . . . . . . . . . . . . . 23 89 4.5.1. Attack Description . . . . . . . . . . . . . . . . . 23 90 4.5.2. Discussion . . . . . . . . . . . . . . . . . . . . . 24 91 4.5.3. Countermeasures . . . . . . . . . . . . . . . . . . . 25 92 4.5.4. Limitations . . . . . . . . . . . . . . . . . . . . . 26 93 4.6. Access Token Injection . . . . . . . . . . . . . . . . . 27 94 4.6.1. Countermeasures . . . . . . . . . . . . . . . . . . . 27 95 4.7. Cross Site Request Forgery . . . . . . . . . . . . . . . 27 96 4.7.1. Countermeasures . . . . . . . . . . . . . . . . . . . 28 98 4.8. PKCE Downgrade Attack . . . . . . . . . . . . . . . . . . 28 99 4.8.1. Attack Description . . . . . . . . . . . . . . . . . 29 100 4.8.2. Countermeasures . . . . . . . . . . . . . . . . . . . 29 101 4.9. Access Token Leakage at the Resource Server . . . . . . . 30 102 4.9.1. Access Token Phishing by Counterfeit Resource 103 Server . . . . . . . . . . . . . . . . . . . . . . . 30 104 4.9.2. Compromised Resource Server . . . . . . . . . . . . . 35 105 4.10. Open Redirection . . . . . . . . . . . . . . . . . . . . 36 106 4.10.1. Client as Open Redirector . . . . . . . . . . . . . 36 107 4.10.2. Authorization Server as Open Redirector . . . . . . 37 108 4.11. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 37 109 4.12. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 38 110 4.13. Refresh Token Protection . . . . . . . . . . . . . . . . 39 111 4.13.1. Discussion . . . . . . . . . . . . . . . . . . . . . 39 112 4.13.2. Recommendations . . . . . . . . . . . . . . . . . . 40 113 4.14. Client Impersonating Resource Owner . . . . . . . . . . . 41 114 4.14.1. Countermeasures . . . . . . . . . . . . . . . . . . 41 115 4.15. Clickjacking . . . . . . . . . . . . . . . . . . . . . . 41 116 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42 117 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 118 7. Security Considerations . . . . . . . . . . . . . . . . . . . 43 119 8. Normative References . . . . . . . . . . . . . . . . . . . . 43 120 9. Informative References . . . . . . . . . . . . . . . . . . . 44 121 Appendix A. Document History . . . . . . . . . . . . . . . . . . 48 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52 124 1. Introduction 126 Since its publication in [RFC6749] and [RFC6750], OAuth 2.0 ("OAuth" 127 in the following) has gotten massive traction in the market and 128 became the standard for API protection and the basis for federated 129 login using OpenID Connect [OpenID]. While OAuth is used in a 130 variety of scenarios and different kinds of deployments, the 131 following challenges can be observed: 133 * OAuth implementations are being attacked through known 134 implementation weaknesses and anti-patterns. Although most of 135 these threats are discussed in the OAuth 2.0 Threat Model and 136 Security Considerations [RFC6819], continued exploitation 137 demonstrates a need for more specific recommendations, easier to 138 implement mitigations, and more defense in depth. 140 * OAuth is being used in environments with higher security 141 requirements than considered initially, such as Open Banking, 142 eHealth, eGovernment, and Electronic Signatures. Those use cases 143 call for stricter guidelines and additional protection. 145 * OAuth is being used in much more dynamic setups than originally 146 anticipated, creating new challenges with respect to security. 147 Those challenges go beyond the original scope of [RFC6749], 148 [RFC6750], and [RFC6819]. 150 OAuth initially assumed a static relationship between client, 151 authorization server and resource servers. The URLs of AS and RS 152 were known to the client at deployment time and built an anchor 153 for the trust relationship among those parties. The validation 154 whether the client talks to a legitimate server was based on TLS 155 server authentication (see [RFC6819], Section 4.5.4). With the 156 increasing adoption of OAuth, this simple model dissolved and, in 157 several scenarios, was replaced by a dynamic establishment of the 158 relationship between clients on one side and the authorization and 159 resource servers of a particular deployment on the other side. 160 This way, the same client could be used to access services of 161 different providers (in case of standard APIs, such as e-mail or 162 OpenID Connect) or serve as a frontend to a particular tenant in a 163 multi-tenancy environment. Extensions of OAuth, such as the OAuth 164 2.0 Dynamic Client Registration Protocol [RFC7591] and OAuth 2.0 165 Authorization Server Metadata [RFC8414] were developed in order to 166 support the usage of OAuth in dynamic scenarios. 168 * Technology has changed. For example, the way browsers treat 169 fragments when redirecting requests has changed, and with it, the 170 implicit grant's underlying security model. 172 This document provides updated security recommendations to address 173 these challenges. It does not supplant the security advice given in 174 [RFC6749], [RFC6750], and [RFC6819], but complements those documents. 176 1.1. Structure 178 The remainder of this document is organized as follows: The next 179 section summarizes the most important recommendations of the OAuth 180 working group for every OAuth implementor. Afterwards, the updated 181 the OAuth attacker model is presented. Subsequently, a detailed 182 analysis of the threats and implementation issues that can be found 183 in the wild today is given along with a discussion of potential 184 countermeasures. 186 1.2. Conventions and Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 190 "OPTIONAL" in this document are to be interpreted as described in BCP 191 14 [RFC2119] [RFC8174] when, and only when, they appear in all 192 capitals, as shown here. 194 This specification uses the terms "access token", "authorization 195 endpoint", "authorization grant", "authorization server", "client", 196 "client identifier" (client ID), "protected resource", "refresh 197 token", "resource owner", "resource server", and "token endpoint" 198 defined by OAuth 2.0 [RFC6749]. 200 2. Recommendations 202 This section describes the set of security mechanisms the OAuth 203 working group recommends to OAuth implementers. 205 2.1. Protecting Redirect-Based Flows 207 When comparing client redirect URIs against pre-registered URIs, 208 authorization servers MUST utilize exact string matching except for 209 port numbers in "localhost" redirection URIs of native apps, see 210 Section 4.1.3. This measure contributes to the prevention of leakage 211 of authorization codes and access tokens (see Section 4.1). It can 212 also help to detect mix-up attacks (see Section 4.4). 214 Clients and AS MUST NOT expose URLs that forward the user's browser 215 to arbitrary URIs obtained from a query parameter ("open 216 redirector"). Open redirectors can enable exfiltration of 217 authorization codes and access tokens, see Section 4.10.1. 219 Clients MUST prevent Cross-Site Request Forgery (CSRF). In this 220 context, CSRF refers to requests to the redirection endpoint that do 221 not originate at the authorization server, but a malicious third 222 party (see Section 4.4.1.8. of [RFC6819] for details). Clients that 223 have ensured that the authorization server supports PKCE [RFC7636] 224 MAY rely the CSRF protection provided by PKCE. In OpenID Connect 225 flows, the "nonce" parameter provides CSRF protection. Otherwise, 226 one-time use CSRF tokens carried in the "state" parameter that are 227 securely bound to the user agent MUST be used for CSRF protection 228 (see Section 4.7.1). 230 When an OAuth client can interact with more than one authorization 231 server, a defense against mix-up attacks (see Section 4.4) is 232 REQUIRED. To this end, clients SHOULD 234 * use the "iss" parameter as a countermeasure according to 235 [I-D.ietf-oauth-iss-auth-resp], or 237 * use an alternative countermeasure based on an "iss" value in the 238 authorization response (such as the "iss" Claim in the ID Token in 239 [OpenID] or in [JARM] responses), processing it as described in 240 [I-D.ietf-oauth-iss-auth-resp]. 242 In the absence of these options, clients MAY instead use distinct 243 redirect URIs to identify authorization endpoints and token 244 endpoints, as described in Section 4.4.2. 246 An AS that redirects a request potentially containing user 247 credentials MUST avoid forwarding these user credentials accidentally 248 (see Section 4.11 for details). 250 2.1.1. Authorization Code Grant 252 Clients MUST prevent injection (replay) of authorization codes into 253 the authorization response by attackers. Public clients MUST use 254 PKCE [RFC7636] to this end. For confidential clients, the use of 255 PKCE [RFC7636] is RECOMMENDED. With additional precautions, 256 described in Section 4.5.3.2, confidential clients MAY use the OpenID 257 Connect "nonce" parameter and the respective Claim in the ID Token 258 [OpenID] instead. In any case, the PKCE challenge or OpenID Connect 259 "nonce" MUST be transaction-specific and securely bound to the client 260 and the user agent in which the transaction was started. 262 Note: Although PKCE was designed as a mechanism to protect native 263 apps, this advice applies to all kinds of OAuth clients, including 264 web applications. 266 When using PKCE, clients SHOULD use PKCE code challenge methods that 267 do not expose the PKCE verifier in the authorization request. 268 Otherwise, attackers that can read the authorization request (cf. 269 Attacker A4 in Section 3) can break the security provided by PKCE. 270 Currently, "S256" is the only such method. 272 Authorization servers MUST support PKCE [RFC7636]. 274 Authorization servers MUST provide a way to detect their support for 275 PKCE. It is RECOMMENDED for AS to publish the element 276 "code_challenge_methods_supported" in their AS metadata ([RFC8414]) 277 containing the supported PKCE challenge methods (which can be used by 278 the client to detect PKCE support). AS MAY instead provide a 279 deployment-specific way to ensure or determine PKCE support by the 280 AS. 282 Authorization servers MUST mitigate PKCE Downgrade Attacks by 283 ensuring that a token request containing a "code_verifier" parameter 284 is accepted only if a "code_challenge" parameter was present in the 285 authorization request, see Section 4.8.2 for details. 287 2.1.2. Implicit Grant 289 The implicit grant (response type "token") and other response types 290 causing the authorization server to issue access tokens in the 291 authorization response are vulnerable to access token leakage and 292 access token replay as described in Section 4.1, Section 4.2, 293 Section 4.3, and Section 4.6. 295 Moreover, no viable mechanism exists to cryptographically bind access 296 tokens issued in the authorization response to a certain client as it 297 is recommended in Section 2.2. This makes replay detection for such 298 access tokens at resource servers impossible. 300 In order to avoid these issues, clients SHOULD NOT use the implicit 301 grant (response type "token") or other response types issuing access 302 tokens in the authorization response, unless access token injection 303 in the authorization response is prevented and the aforementioned 304 token leakage vectors are mitigated. 306 Clients SHOULD instead use the response type "code" (aka 307 authorization code grant type) as specified in Section 2.1.1 or any 308 other response type that causes the authorization server to issue 309 access tokens in the token response, such as the "code id_token" 310 response type. This allows the authorization server to detect replay 311 attempts by attackers and generally reduces the attack surface since 312 access tokens are not exposed in URLs. It also allows the 313 authorization server to sender-constrain the issued tokens (see next 314 section). 316 2.2. Token Replay Prevention 318 2.2.1. Access Tokens 320 A sender-constrained access token scopes the applicability of an 321 access token to a certain sender. This sender is obliged to 322 demonstrate knowledge of a certain secret as prerequisite for the 323 acceptance of that token at the recipient (e.g., a resource server). 325 Authorization and resource servers SHOULD use mechanisms for sender- 326 constraining access tokens to prevent token replay, such as Mutual 327 TLS for OAuth 2.0 [RFC8705] (see Section 4.9.1.1.2). 329 2.2.2. Refresh Tokens 331 Refresh tokens MUST be sender-constrained or use refresh token 332 rotation as described in Section 4.13. 334 2.3. Access Token Privilege Restriction 336 The privileges associated with an access token SHOULD be restricted 337 to the minimum required for the particular application or use case. 338 This prevents clients from exceeding the privileges authorized by the 339 resource owner. It also prevents users from exceeding their 340 privileges authorized by the respective security policy. Privilege 341 restrictions also help to reduce the impact of access token leakage. 343 In particular, access tokens SHOULD be restricted to certain resource 344 servers (audience restriction), preferably to a single resource 345 server. To put this into effect, the authorization server associates 346 the access token with certain resource servers and every resource 347 server is obliged to verify, for every request, whether the access 348 token sent with that request was meant to be used for that particular 349 resource server. If not, the resource server MUST refuse to serve 350 the respective request. Clients and authorization servers MAY 351 utilize the parameters "scope" or "resource" as specified in 352 [RFC6749] and [I-D.ietf-oauth-resource-indicators], respectively, to 353 determine the resource server they want to access. 355 Additionally, access tokens SHOULD be restricted to certain resources 356 and actions on resource servers or resources. To put this into 357 effect, the authorization server associates the access token with the 358 respective resource and actions and every resource server is obliged 359 to verify, for every request, whether the access token sent with that 360 request was meant to be used for that particular action on the 361 particular resource. If not, the resource server must refuse to 362 serve the respective request. Clients and authorization servers MAY 363 utilize the parameter "scope" as specified in [RFC6749] and 364 "authorization_details" as specified in [I-D.ietf-oauth-rar] to 365 determine those resources and/or actions. 367 2.4. Resource Owner Password Credentials Grant 369 The resource owner password credentials grant MUST NOT be used. This 370 grant type insecurely exposes the credentials of the resource owner 371 to the client. Even if the client is benign, this results in an 372 increased attack surface (credentials can leak in more places than 373 just the AS) and users are trained to enter their credentials in 374 places other than the AS. 376 Furthermore, adapting the resource owner password credentials grant 377 to two-factor authentication, authentication with cryptographic 378 credentials (cf. WebCrypto [webcrypto], WebAuthn [webauthn]), and 379 authentication processes that require multiple steps can be hard or 380 impossible. 382 2.5. Client Authentication 384 Authorization servers SHOULD use client authentication if possible. 386 It is RECOMMENDED to use asymmetric (public-key based) methods for 387 client authentication such as mTLS [RFC8705] or "private_key_jwt" 388 [OpenID]. When asymmetric methods for client authentication are 389 used, authorization servers do not need to store sensitive symmetric 390 keys, making these methods more robust against a number of attacks. 392 2.6. Other Recommendations 394 The use of OAuth Metadata [RFC8414] can help to improve the security 395 of OAuth deployments: 397 * It ensures that security features and other new OAuth features can 398 be enabled automatically by compliant software libraries. 400 * It reduces chances for misconfigurations, for example 401 misconfigured endpoint URLs (that might belong to an attacker) or 402 misconfigured security features. 404 * It can help to facilitate rotation of cryptographic keys and to 405 ensure cryptographic agility. 407 It is therefore RECOMMENDED that AS publish OAuth metadata according 408 to [RFC8414] and that clients make use of this metadata to configure 409 themselves when available. 411 Authorization servers SHOULD NOT allow clients to influence their 412 "client_id" or "sub" value or any other Claim if that can cause 413 confusion with a genuine resource owner (see Section 4.14). 415 It is RECOMMENDED to use end-to-end TLS. If TLS traffic needs to be 416 terminated at an intermediary, refer to Section 4.12 for further 417 security advice. 419 Authorization responses MUST NOT be transmitted over unencrypted 420 network connections. To this end, AS MUST NOT allow redirect URIs 421 that use the "http" scheme except for native clients that use 422 Loopback Interface Redirection as described in [RFC8252], 423 Section 7.3. 425 3. The Updated OAuth 2.0 Attacker Model 427 In [RFC6819], an attacker model is laid out that describes the 428 capabilities of attackers against which OAuth deployments must be 429 protected. In the following, this attacker model is updated to 430 account for the potentially dynamic relationships involving multiple 431 parties (as described in Section 1), to include new types of 432 attackers and to define the attacker model more clearly. 434 OAuth MUST ensure that the authorization of the resource owner (RO) 435 (with a user agent) at the authorization server (AS) and the 436 subsequent usage of the access token at the resource server (RS) is 437 protected at least against the following attackers: 439 * (A1) Web Attackers that can set up and operate an arbitrary number 440 of network endpoints including browsers and servers (except for 441 the concrete RO, AS, and RS). Web attackers may set up web sites 442 that are visited by the RO, operate their own user agents, and 443 participate in the protocol. 445 Web attackers may, in particular, operate OAuth clients that are 446 registered at AS, and operate their own authorization and resource 447 servers that can be used (in parallel) by the RO and other 448 resource owners. 450 It must also be assumed that web attackers can lure the user to 451 open arbitrary attacker-chosen URIs at any time. In practice, 452 this can be achieved in many ways, for example, by injecting 453 malicious advertisements into advertisement networks, or by 454 sending legit-looking emails. 456 Web attackers can use their own user credentials to create new 457 messages as well as any secrets they learned previously. For 458 example, if a web attacker learns an authorization code of a user 459 through a misconfigured redirect URI, the web attacker can then 460 try to redeem that code for an access token. 462 They cannot, however, read or manipulate messages that are not 463 targeted towards them (e.g., sent to a URL controlled by a non- 464 attacker controlled AS). 466 * (A2) Network Attackers that additionally have full control over 467 the network over which protocol participants communicate. They 468 can eavesdrop on, manipulate, and spoof messages, except when 469 these are properly protected by cryptographic methods (e.g., TLS). 470 Network attackers can also block arbitrary messages. 472 While an example for a web attacker would be a customer of an 473 internet service provider, network attackers could be the internet 474 service provider itself, an attacker in a public (wifi) network using 475 ARP spoofing, or a state-sponsored attacker with access to internet 476 exchange points, for instance. 478 These attackers conform to the attacker model that was used in formal 479 analysis efforts for OAuth [arXiv.1601.01229]. This is a minimal 480 attacker model. Implementers MUST take into account all possible 481 types of attackers in the environment in which their OAuth 482 implementations are expected to run. Previous attacks on OAuth have 483 shown that OAuth deployments SHOULD in particular consider the 484 following, stronger attackers in addition to those listed above: 486 * (A3) Attackers that can read, but not modify, the contents of the 487 authorization response (i.e., the authorization response can leak 488 to an attacker). 490 Examples for such attacks include open redirector attacks, 491 problems existing on mobile operating systems (where different 492 apps can register themselves on the same URI), mix-up attacks (see 493 Section 4.4), where the client is tricked into sending credentials 494 to a attacker-controlled AS, and the fact that URLs are often 495 stored/logged by browsers (history), proxy servers, and operating 496 systems. 498 * (A4) Attackers that can read, but not modify, the contents of the 499 authorization request (i.e., the authorization request can leak, 500 in the same manner as above, to an attacker). 502 * (A5) Attackers that can acquire an access token issued by AS. For 503 example, a resource server can be compromised by an attacker, an 504 access token may be sent to an attacker-controlled resource server 505 due to a misconfiguration, or an RO is social-engineered into 506 using a attacker-controlled RS. See also Section 4.9.2. 508 (A3), (A4) and (A5) typically occur together with either (A1) or 509 (A2). Attackers can collaborate to reach a common goal. 511 Note that in this attacker model, an attacker (see A1) can be a RO or 512 act as one. For example, an attacker can use his own browser to 513 replay tokens or authorization codes obtained by any of the attacks 514 described above at the client or RS. 516 This document focusses on threats resulting from these attackers. 517 Attacks in an even stronger attacker model are discussed, for 518 example, in [arXiv.1901.11520]. 520 4. Attacks and Mitigations 522 This section gives a detailed description of attacks on OAuth 523 implementations, along with potential countermeasures. Attacks and 524 mitigations already covered in [RFC6819] are not listed here, except 525 where new recommendations are made. 527 4.1. Insufficient Redirect URI Validation 529 Some authorization servers allow clients to register redirect URI 530 patterns instead of complete redirect URIs. The authorization 531 servers then match the redirect URI parameter value at the 532 authorization endpoint against the registered patterns at runtime. 533 This approach allows clients to encode transaction state into 534 additional redirect URI parameters or to register a single pattern 535 for multiple redirect URIs. 537 This approach turned out to be more complex to implement and more 538 error prone to manage than exact redirect URI matching. Several 539 successful attacks exploiting flaws in the pattern matching 540 implementation or concrete configurations have been observed in the 541 wild . Insufficient validation of the redirect URI effectively breaks 542 client identification or authentication (depending on grant and 543 client type) and allows the attacker to obtain an authorization code 544 or access token, either 546 * by directly sending the user agent to a URI under the attackers 547 control, or 549 * by exposing the OAuth credentials to an attacker by utilizing an 550 open redirector at the client in conjunction with the way user 551 agents handle URL fragments. 553 These attacks are shown in detail in the following subsections. 555 4.1.1. Redirect URI Validation Attacks on Authorization Code Grant 557 For a client using the grant type code, an attack may work as 558 follows: 560 Assume the redirect URL pattern "https://*.somesite.example/*" is 561 registered for the client with the client ID "s6BhdRkqt3". The 562 intention is to allow any subdomain of "somesite.example" to be a 563 valid redirect URI for the client, for example 564 "https://app1.somesite.example/redirect". A naive implementation on 565 the authorization server, however, might interpret the wildcard "*" 566 as "any character" and not "any character valid for a domain name". 567 The authorization server, therefore, might permit 568 "https://attacker.example/.somesite.example" as a redirect URI, 569 although "attacker.example" is a different domain potentially 570 controlled by a malicious party. 572 The attack can then be conducted as follows: 574 First, the attacker needs to trick the user into opening a tampered 575 URL in his browser that launches a page under the attacker's control, 576 say "https://www.evil.example" (see Attacker A1.) 578 This URL initiates the following authorization request with the 579 client ID of a legitimate client to the authorization endpoint (line 580 breaks for display only): 582 GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=9ad67f13 583 &redirect_uri=https%3A%2F%2Fattacker.example%2F.somesite.example 584 HTTP/1.1 585 Host: server.somesite.example 587 The authorization server validates the redirect URI and compares it 588 to the registered redirect URL patterns for the client "s6BhdRkqt3". 589 The authorization request is processed and presented to the user. 591 If the user does not see the redirect URI or does not recognize the 592 attack, the code is issued and immediately sent to the attacker's 593 domain. If an automatic approval of the authorization is enabled 594 (which is not recommended for public clients according to [RFC6749]), 595 the attack can be performed even without user interaction. 597 If the attacker impersonated a public client, the attacker can 598 exchange the code for tokens at the respective token endpoint. 600 This attack will not work as easily for confidential clients, since 601 the code exchange requires authentication with the legitimate 602 client's secret. The attacker can, however, use the legitimate 603 confidential client to redeem the code by performing an authorization 604 code injection attack, see Section 4.5. 606 Note: Vulnerabilities of this kind can also exist if the 607 authorization server handles wildcards properly. For example, assume 608 that the client registers the redirect URL pattern 609 "https://*.somesite.example/*" and the authorization server 610 interprets this as "allow redirect URIs pointing to any host residing 611 in the domain "somesite.example"". If an attacker manages to 612 establish a host or subdomain in "somesite.example", he can 613 impersonate the legitimate client. This could be caused, for 614 example, by a subdomain takeover attack [subdomaintakeover], where an 615 outdated CNAME record (say, "external-service.somesite.example") 616 points to an external DNS name that does no longer exist (say, 617 "customer-abc.service.example") and can be taken over by an attacker 618 (e.g., by registering as "customer-abc" with the external service). 620 4.1.2. Redirect URI Validation Attacks on Implicit Grant 622 The attack described above works for the implicit grant as well. If 623 the attacker is able to send the authorization response to a URI 624 under his control, he will directly get access to the fragment 625 carrying the access token. 627 Additionally, implicit clients can be subject to a further kind of 628 attack. It utilizes the fact that user agents re-attach fragments to 629 the destination URL of a redirect if the location header does not 630 contain a fragment (see [RFC7231], Section 9.5). The attack 631 described here combines this behavior with the client as an open 632 redirector (see Section 4.10.1) in order to get access to access 633 tokens. This allows circumvention even of very narrow redirect URI 634 patterns, but not strict URL matching. 636 Assume the registered URL pattern for client "s6BhdRkqt3" is 637 "https://client.somesite.example/cb?*", i.e., any parameter is 638 allowed for redirects to "https://client.somesite.example/cb". 639 Unfortunately, the client exposes an open redirector. This endpoint 640 supports a parameter "redirect_to" which takes a target URL and will 641 send the browser to this URL using an HTTP Location header redirect 642 303. 644 The attack can now be conducted as follows: 646 First, and as above, the attacker needs to trick the user into 647 opening a tampered URL in his browser that launches a page under the 648 attacker's control, say "https://www.evil.example". 650 Afterwards, the website initiates an authorization request that is 651 very similar to the one in the attack on the code flow. Different to 652 above, it utilizes the open redirector by encoding 653 "redirect_to=https://attacker.example" into the parameters of the 654 redirect URI and it uses the response type "token" (line breaks for 655 display only): 657 GET /authorize?response_type=token&state=9ad67f13 658 &client_id=s6BhdRkqt3 659 &redirect_uri=https%3A%2F%2Fclient.somesite.example 660 %2Fcb%26redirect_to%253Dhttps%253A%252F 661 %252Fattacker.example%252F HTTP/1.1 662 Host: server.somesite.example 663 Now, since the redirect URI matches the registered pattern, the 664 authorization server permits the request and sends the resulting 665 access token in a 303 redirect (some response parameters omitted for 666 readability): 668 HTTP/1.1 303 See Other 669 Location: https://client.somesite.example/cb? 670 redirect_to%3Dhttps%3A%2F%2Fattacker.example%2Fcb 671 #access_token=2YotnFZFEjr1zCsicMWpAA&... 673 At example.com, the request arrives at the open redirector. The 674 endpoint will read the redirect parameter and will issue an HTTP 303 675 Location header redirect to the URL "https://attacker.example/". 677 HTTP/1.1 303 See Other 678 Location: https://attacker.example/ 680 Since the redirector at client.somesite.example does not include a 681 fragment in the Location header, the user agent will re-attach the 682 original fragment "#access_token=2YotnFZFEjr1zCsicMWpAA&..." to 683 the URL and will navigate to the following URL: 685 https://attacker.example/#access_token=2YotnFZFEjr1z... 687 The attacker's page at "attacker.example" can now access the fragment 688 and obtain the access token. 690 4.1.3. Countermeasures 692 The complexity of implementing and managing pattern matching 693 correctly obviously causes security issues. This document therefore 694 advises to simplify the required logic and configuration by using 695 exact redirect URI matching. This means the authorization server 696 MUST compare the two URIs using simple string comparison as defined 697 in [RFC3986], Section 6.2.1. The only exception are native apps 698 using a "localhost" URI: In this case, the AS MUST allow variable 699 port numbers as described in [RFC8252], Section 7.3. 701 Additional recommendations: 703 * Servers on which callbacks are hosted MUST NOT expose open 704 redirectors (see Section 4.10). 706 * Browsers reattach URL fragments to Location redirection URLs only 707 if the URL in the Location header does not already contain a 708 fragment. Therefore, servers MAY prevent browsers from 709 reattaching fragments to redirection URLs by attaching an 710 arbitrary fragment identifier, for example "#_", to URLs in 711 Location headers. 713 * Clients SHOULD use the authorization code response type instead of 714 response types causing access token issuance at the authorization 715 endpoint. This offers countermeasures against reuse of leaked 716 credentials through the exchange process with the authorization 717 server and token replay through sender-constraining of the access 718 tokens. 720 If the origin and integrity of the authorization request containing 721 the redirect URI can be verified, for example when using 722 [I-D.ietf-oauth-jwsreq] or [I-D.ietf-oauth-par] with client 723 authentication, the authorization server MAY trust the redirect URI 724 without further checks. 726 4.2. Credential Leakage via Referer Headers 728 The contents of the authorization request URI or the authorization 729 response URI can unintentionally be disclosed to attackers through 730 the Referer HTTP header (see [RFC7231], Section 5.5.2), by leaking 731 either from the AS's or the client's web site, respectively. Most 732 importantly, authorization codes or "state" values can be disclosed 733 in this way. Although specified otherwise in [RFC7231], 734 Section 5.5.2, the same may happen to access tokens conveyed in URI 735 fragments due to browser implementation issues as illustrated by 736 Chromium Issue 168213 [bug.chromium]. 738 4.2.1. Leakage from the OAuth Client 740 Leakage from the OAuth client requires that the client, as a result 741 of a successful authorization request, renders a page that 743 * contains links to other pages under the attacker's control and a 744 user clicks on such a link, or 746 * includes third-party content (advertisements in iframes, images, 747 etc.), for example if the page contains user-generated content 748 (blog). 750 As soon as the browser navigates to the attacker's page or loads the 751 third-party content, the attacker receives the authorization response 752 URL and can extract "code" or "state" (and potentially "access 753 token"). 755 4.2.2. Leakage from the Authorization Server 757 In a similar way, an attacker can learn "state" from the 758 authorization request if the authorization endpoint at the 759 authorization server contains links or third-party content as above. 761 4.2.3. Consequences 763 An attacker that learns a valid code or access token through a 764 Referer header can perform the attacks as described in Section 4.1.1, 765 Section 4.5, and Section 4.6. If the attacker learns "state", the 766 CSRF protection achieved by using "state" is lost, resulting in CSRF 767 attacks as described in [RFC6819], Section 4.4.1.8. 769 4.2.4. Countermeasures 771 The page rendered as a result of the OAuth authorization response and 772 the authorization endpoint SHOULD NOT include third-party resources 773 or links to external sites. 775 The following measures further reduce the chances of a successful 776 attack: 778 * Suppress the Referer header by applying an appropriate Referrer 779 Policy [webappsec-referrer-policy] to the document (either as part 780 of the "referrer" meta attribute or by setting a Referrer-Policy 781 header). For example, the header "Referrer-Policy: no-referrer" 782 in the response completely suppresses the Referer header in all 783 requests originating from the resulting document. 785 * Use authorization code instead of response types causing access 786 token issuance from the authorization endpoint. 788 * Bind authorization code to a confidential client or PKCE 789 challenge. In this case, the attacker lacks the secret to request 790 the code exchange. 792 * As described in [RFC6749], Section 4.1.2, authorization codes MUST 793 be invalidated by the AS after their first use at the token 794 endpoint. For example, if an AS invalidated the code after the 795 legitimate client redeemed it, the attacker would fail exchanging 796 this code later. 798 This does not mitigate the attack if the attacker manages to 799 exchange the code for a token before the legitimate client does 800 so. Therefore, [RFC6749] further recommends that, when an attempt 801 is made to redeem a code twice, the AS SHOULD revoke all tokens 802 issued previously based on that code. 804 * The "state" value SHOULD be invalidated by the client after its 805 first use at the redirection endpoint. If this is implemented, 806 and an attacker receives a token through the Referer header from 807 the client's web site, the "state" was already used, invalidated 808 by the client and cannot be used again by the attacker. (This 809 does not help if the "state" leaks from the AS's web site, since 810 then the "state" has not been used at the redirection endpoint at 811 the client yet.) 813 * Use the form post response mode instead of a redirect for the 814 authorization response (see [oauth-v2-form-post-response-mode]). 816 4.3. Credential Leakage via Browser History 818 Authorization codes and access tokens can end up in the browser's 819 history of visited URLs, enabling the attacks described in the 820 following. 822 4.3.1. Authorization Code in Browser History 824 When a browser navigates to "client.example/ 825 redirection_endpoint?code=abcd" as a result of a redirect from a 826 provider's authorization endpoint, the URL including the 827 authorization code may end up in the browser's history. An attacker 828 with access to the device could obtain the code and try to replay it. 830 Countermeasures: 832 * Authorization code replay prevention as described in [RFC6819], 833 Section 4.4.1.1, and Section 4.5. 835 * Use form post response mode instead of redirect for the 836 authorization response (see [oauth-v2-form-post-response-mode]). 838 4.3.2. Access Token in Browser History 840 An access token may end up in the browser history if a client or a 841 web site that already has a token deliberately navigates to a page 842 like "provider.com/get_user_profile?access_token=abcdef". [RFC6750] 843 discourages this practice and advises to transfer tokens via a 844 header, but in practice web sites often pass access tokens in query 845 parameters. 847 In case of the implicit grant, a URL like "client.example/ 848 redirection_endpoint#access_token=abcdef" may also end up in the 849 browser history as a result of a redirect from a provider's 850 authorization endpoint. 852 Countermeasures: 854 * Clients MUST NOT pass access tokens in a URI query parameter in 855 the way described in Section 2.3 of [RFC6750]. The authorization 856 code grant or alternative OAuth response modes like the form post 857 response mode [oauth-v2-form-post-response-mode] can be used to 858 this end. 860 4.4. Mix-Up Attacks 862 Mix-up is an attack on scenarios where an OAuth client interacts with 863 two or more authorization servers and at least one authorization 864 server is under the control of the attacker. This can be the case, 865 for example, if the attacker uses dynamic registration to register 866 the client at his own authorization server or if an authorization 867 server becomes compromised. 869 The goal of the attack is to obtain an authorization code or an 870 access token for an uncompromised authorization server. This is 871 achieved by tricking the client into sending those credentials to the 872 compromised authorization server (the attacker) instead of using them 873 at the respective endpoint of the uncompromised authorization/ 874 resource server. 876 4.4.1. Attack Description 878 The description here follows [arXiv.1601.01229], with variants of the 879 attack outlined below. 881 Preconditions: For this variant of the attack to work, we assume that 883 * the implicit or authorization code grant are used with multiple AS 884 of which one is considered "honest" (H-AS) and one is operated by 885 the attacker (A-AS), and 887 * the client stores the AS chosen by the user in a session bound to 888 the user's browser and uses the same redirection endpoint URI for 889 each AS. 891 In the following, we assume that the client is registered with H-AS 892 (URI: "https://honest.as.example", client ID: "7ZGZldHQ") and with 893 A-AS (URI: "https://attacker.example", client ID: "666RVZJTA"). URLs 894 shown in the following example are shorted for presentation to only 895 include parameters relevant for the attack. 897 Attack on the authorization code grant: 899 1. The user selects to start the grant using A-AS (e.g., by clicking 900 on a button at the client's website). 902 2. The client stores in the user's session that the user selected 903 "A-AS" and redirects the user to A-AS's authorization endpoint 904 with a Location header containing the URL 905 "https://attacker.example/ 906 authorize?response_type=code&client_id=666RVZJTA". 908 3. When the user's browser navigates to the attacker's authorization 909 endpoint, the attacker immediately redirects the browser to the 910 authorization endpoint of H-AS. In the authorization request, 911 the attacker replaces the client ID of the client at A-AS with 912 the client's ID at H-AS. Therefore, the browser receives a 913 redirection ("303 See Other") with a Location header pointing to 914 "https://honest.as.example/ 915 authorize?response_type=code&client_id=7ZGZldHQ" 917 4. The user authorizes the client to access her resources at H-AS. 918 (Note that a vigilant user might at this point detect that she 919 intended to use A-AS instead of H-AS. The first attack variant 920 listed below avoids this.) H-AS issues a code and sends it (via 921 the browser) back to the client. 923 5. Since the client still assumes that the code was issued by A-AS, 924 it will try to redeem the code at A-AS's token endpoint. 926 6. The attacker therefore obtains code and can either exchange the 927 code for an access token (for public clients) or perform an 928 authorization code injection attack as described in Section 4.5. 930 Variants: 932 * *Mix-Up With Interception*: This variant works only if the 933 attacker can intercept and manipulate the first request/response 934 pair from a user's browser to the client (in which the user 935 selects a certain AS and is then redirected by the client to that 936 AS), as in Attacker A2. This capability can, for example, be the 937 result of a man-in-the-middle attack on the user's connection to 938 the client. In the attack, the user starts the flow with H-AS. 939 The attacker intercepts this request and changes the user's 940 selection to A-AS. The rest of the attack proceeds as in Steps 2 941 and following above. 943 * *Implicit Grant*: In the implicit grant, the attacker receives an 944 access token instead of the code; the rest of the attack works as 945 above. 947 * *Per-AS Redirect URIs*: If clients use different redirect URIs for 948 different ASs, do not store the selected AS in the user's session, 949 and ASs do not check the redirect URIs properly, attackers can 950 mount an attack called "Cross-Social Network Request Forgery". 951 These attacks have been observed in practice. Refer to 952 [oauth_security_jcs_14] for details. 954 * *OpenID Connect*: There are variants that can be used to attack 955 OpenID Connect. In these attacks, the attacker misuses features 956 of the OpenID Connect Discovery [OpenIDDisc] mechanism or replays 957 access tokens or ID Tokens to conduct a mix-up attack. The 958 attacks are described in detail in [arXiv.1704.08539], Appendix A, 959 and [arXiv.1508.04324v2], Section 6 ("Malicious Endpoints 960 Attacks"). 962 4.4.2. Countermeasures 964 When an OAuth client can only interact with one authorization server, 965 a mix-up defense is not required. In scenarios where an OAuth client 966 interacts with two or more authorization servers, however, clients 967 MUST prevent mix-up attacks. Two different methods are discussed in 968 the following. 970 For both defenses, clients MUST store, for each authorization 971 request, the issuer they sent the authorization request to and bind 972 this information to the user agent. The issuer serves, via the 973 associated metadata, as an abstract identifier for the combination of 974 the authorization endpoint and token endpoint that are to be used in 975 the flow. If an issuer identifier is not available, for example, if 976 neither OAuth metadata [RFC8414] nor OpenID Connect Discovery 977 [OpenIDDisc] are used, a different unique identifier for this tuple 978 or the tuple itself can be used instead. For brevity of 979 presentation, such a deployment-specific identifier will be subsumed 980 under the issuer (or issuer identifier) in the following. 982 Note: Just storing the authorization server URL is not sufficient to 983 identify mix-up attacks. An attacker might declare an uncompromised 984 AS's authorization endpoint URL as "his" AS URL, but declare a token 985 endpoint under his own control. 987 4.4.2.1. Mix-Up Defense via Issuer Identification 989 This defense requires that the authorization server sends his issuer 990 identifier in the authorization response to the client. When 991 receiving the authorization response, the client MUST compare the 992 received issuer identifier to the stored issuer identifier. If there 993 is a mismatch, the client MUST abort the interaction. 995 There are different ways this issuer identifier can be transported to 996 the client: 998 * The issuer information can be transported, for example, via a 999 separate response parameter "iss", defined in 1000 [I-D.ietf-oauth-iss-auth-resp]. 1002 * When OpenID Connect is used and an ID Token is returned in the 1003 authorization response, the client can evaluate the "iss" Claim in 1004 the ID Token. 1006 In both cases, the "iss" value MUST be evaluated according to 1007 [I-D.ietf-oauth-iss-auth-resp]. 1009 While this defense may require deploying new OAuth features to 1010 transport the issuer information, it is a robust and relatively 1011 simple defense against mix-up. 1013 4.4.2.2. Mix-Up Defense via Distinct Redirect URIs 1015 For this defense, clients MUST use a distinct redirect URI for each 1016 issuer they interact with. 1018 Clients MUST check that the authorization response was received from 1019 the correct issuer by comparing the distinct redirect URI for the 1020 issuer to the URI where the authorization response was received on. 1021 If there is a mismatch, the client MUST abort the flow. 1023 While this defense builds upon existing OAuth functionality, it 1024 cannot be used in scenarios where clients only register once for the 1025 use of many different issuers (as in some open banking schemes) and 1026 due to the tight integration with the client registration, it is 1027 harder to deploy automatically. 1029 Furthermore, an attacker might be able to circumvent the protection 1030 offered by this defense by registering a new client with the "honest" 1031 AS using the redirect URI that the client assigned to the attacker's 1032 AS. The attacker could then run the attack as described above, 1033 replacing the client ID with the client ID of his newly created 1034 client. 1036 This defense SHOULD therefore only be used if other options are not 1037 available. 1039 4.5. Authorization Code Injection 1041 In an authorization code injection attack, the attacker attempts to 1042 inject a stolen authorization code into the attacker's own session 1043 with the client. The aim is to associate the attacker's session at 1044 the client with the victim's resources or identity. 1046 This attack is useful if the attacker cannot exchange the 1047 authorization code for an access token himself. Examples include: 1049 * The code is bound to a particular confidential client and the 1050 attacker is unable to obtain the required client credentials to 1051 redeem the code himself. 1053 * The attacker wants to access certain functions in this particular 1054 client. As an example, the attacker wants to impersonate his 1055 victim in a certain app or on a certain web site. 1057 * The authorization or resource servers are limited to certain 1058 networks that the attacker is unable to access directly. 1060 In the following attack description and discussion, we assume the 1061 presence of a web (A1) or network attacker (A2). 1063 4.5.1. Attack Description 1065 The attack works as follows: 1067 1. The attacker obtains an authorization code by performing any of 1068 the attacks described above. 1070 2. He starts a regular OAuth authorization process with the 1071 legitimate client from his device. 1073 3. The attacker injects the stolen authorization code in the 1074 response of the authorization server to the legitimate client. 1075 Since this response is passing through the attacker's device, the 1076 attacker can use any tool that can intercept and manipulate the 1077 authorization response to this end. The attacker does not need 1078 to control the network. 1080 4. The legitimate client sends the code to the authorization 1081 server's token endpoint, along with the client's client ID, 1082 client secret and actual "redirect_uri". 1084 5. The authorization server checks the client secret, whether the 1085 code was issued to the particular client, and whether the actual 1086 redirect URI matches the "redirect_uri" parameter (see 1087 [RFC6749]). 1089 6. All checks succeed and the authorization server issues access and 1090 other tokens to the client. The attacker has now associated his 1091 session with the legitimate client with the victim's resources 1092 and/or identity. 1094 4.5.2. Discussion 1096 Obviously, the check in step (5.) will fail if the code was issued to 1097 another client ID, e.g., a client set up by the attacker. The check 1098 will also fail if the authorization code was already redeemed by the 1099 legitimate user and was one-time use only. 1101 An attempt to inject a code obtained via a manipulated redirect URI 1102 should also be detected if the authorization server stored the 1103 complete redirect URI used in the authorization request and compares 1104 it with the "redirect_uri" parameter. 1106 [RFC6749], Section 4.1.3, requires the AS to "... ensure that the 1107 "redirect_uri" parameter is present if the "redirect_uri" parameter 1108 was included in the initial authorization request as described in 1109 Section 4.1.1, and if included ensure that their values are 1110 identical.". In the attack scenario described above, the legitimate 1111 client would use the correct redirect URI it always uses for 1112 authorization requests. But this URI would not match the tampered 1113 redirect URI used by the attacker (otherwise, the redirect would not 1114 land at the attackers page). So the authorization server would 1115 detect the attack and refuse to exchange the code. 1117 Note: This check could also detect attempts to inject an 1118 authorization code which had been obtained from another instance of 1119 the same client on another device, if certain conditions are 1120 fulfilled: 1122 * the redirect URI itself needs to contain a nonce or another kind 1123 of one-time use, secret data and 1125 * the client has bound this data to this particular instance of the 1126 client. 1128 But this approach conflicts with the idea to enforce exact redirect 1129 URI matching at the authorization endpoint. Moreover, it has been 1130 observed that providers very often ignore the "redirect_uri" check 1131 requirement at this stage, maybe because it doesn't seem to be 1132 security-critical from reading the specification. 1134 Other providers just pattern match the "redirect_uri" parameter 1135 against the registered redirect URI pattern. This saves the 1136 authorization server from storing the link between the actual 1137 redirect URI and the respective authorization code for every 1138 transaction. But this kind of check obviously does not fulfill the 1139 intent of the specification, since the tampered redirect URI is not 1140 considered. So any attempt to inject an authorization code obtained 1141 using the "client_id" of a legitimate client or by utilizing the 1142 legitimate client on another device will not be detected in the 1143 respective deployments. 1145 It is also assumed that the requirements defined in [RFC6749], 1146 Section 4.1.3, increase client implementation complexity as clients 1147 need to store or re-construct the correct redirect URI for the call 1148 to the token endpoint. 1150 This document therefore recommends to instead bind every 1151 authorization code to a certain client instance on a certain device 1152 (or in a certain user agent) in the context of a certain transaction 1153 using one of the mechanisms described next. 1155 4.5.3. Countermeasures 1157 There are two good technical solutions to achieve this goal, outlined 1158 in the following. 1160 4.5.3.1. PKCE 1162 The PKCE parameter "code_challenge" along with the corresponding 1163 "code_verifier" as specified in [RFC7636] can be used as a 1164 countermeasure. When the attacker attempts to inject an 1165 authorization code, the verifier check fails: the client uses its 1166 correct verifier, but the code is associated with a challenge that 1167 does not match this verifier. PKCE is a deployed OAuth feature, 1168 although its originally intended use was solely focused on securing 1169 native apps, not the broader use recommended by this document. 1171 4.5.3.2. Nonce 1173 OpenID Connect's existing "nonce" parameter can be used for the same 1174 purpose. The "nonce" value is one-time use and created by the 1175 client. The client is supposed to bind it to the user agent session 1176 and sends it with the initial request to the OpenID Provider (OP). 1177 The OP binds "nonce" to the authorization code and attests this 1178 binding in the ID Token, which is issued as part of the code exchange 1179 at the token endpoint. If an attacker injected an authorization code 1180 in the authorization response, the nonce value in the client session 1181 and the nonce value in the ID token will not match and the attack is 1182 detected. The assumption is that an attacker cannot get hold of the 1183 user agent state on the victim's device, where he has stolen the 1184 respective authorization code. 1186 It is important to note that this countermeasure only works if the 1187 client properly checks the "nonce" parameter in the ID Token and does 1188 not use any issued token until this check has succeeded. More 1189 precisely, a client protecting itself against code injection using 1190 the "nonce" parameter, 1192 1. MUST validate the "nonce" in the ID Token obtained from the token 1193 endpoint, even if another ID Token was obtained from the 1194 authorization response (e.g., "response_type=code+id_token"), and 1196 2. MUST ensure that, unless and until that check succeeds, all 1197 tokens (ID Tokens and the access token) are disregarded and not 1198 used for any other purpose. 1200 4.5.3.3. Other Solutions 1202 Other solutions, like binding "state" to the code, using token 1203 binding for the code, or per-instance client credentials are 1204 conceivable, but lack support and bring new security requirements. 1206 PKCE is the most obvious solution for OAuth clients as it is 1207 available today (originally intended for OAuth native apps) whereas 1208 "nonce" is appropriate for OpenID Connect clients. 1210 4.5.4. Limitations 1212 An attacker can circumvent the countermeasures described above if he 1213 can modify the "nonce" or "code_challenge" values that are used in 1214 the victim's authorization request. The attacker can modify these 1215 values to be the same ones as those chosen by the client in his own 1216 session in Step 2 of the attack above. (This requires that the 1217 victim's session with the client begins after the attacker started 1218 his session with the client.) If the attacker is then able to 1219 capture the authorization code from the victim, the attacker will be 1220 able to inject the stolen code in Step 3 even if PKCE or "nonce" are 1221 used. 1223 This attack is complex and requires a close interaction between the 1224 attacker and the victim's session. Nonetheless, measures to prevent 1225 attackers from reading the contents of the authorization response 1226 still need to be taken, as described in Section 4.1, Section 4.2, 1227 Section 4.3, Section 4.4, and Section 4.10. 1229 4.6. Access Token Injection 1231 In an access token injection attack, the attacker attempts to inject 1232 a stolen access token into a legitimate client (that is not under the 1233 attacker's control). This will typically happen if the attacker 1234 wants to utilize a leaked access token to impersonate a user in a 1235 certain client. 1237 To conduct the attack, the attacker starts an OAuth flow with the 1238 client using the implicit grant and modifies the authorization 1239 response by replacing the access token issued by the authorization 1240 server or directly makes up an authorization server response 1241 including the leaked access token. Since the response includes the 1242 "state" value generated by the client for this particular 1243 transaction, the client does not treat the response as a CSRF attack 1244 and uses the access token injected by the attacker. 1246 4.6.1. Countermeasures 1248 There is no way to detect such an injection attack on the OAuth 1249 protocol level, since the token is issued without any binding to the 1250 transaction or the particular user agent. 1252 The recommendation is therefore to use the authorization code grant 1253 type instead of relying on response types issuing acess tokens at the 1254 authorization endpoint. Authorization code injection can be detected 1255 using one of the countermeasures discussed in Section 4.5. 1257 4.7. Cross Site Request Forgery 1259 An attacker might attempt to inject a request to the redirect URI of 1260 the legitimate client on the victim's device, e.g., to cause the 1261 client to access resources under the attacker's control. This is a 1262 variant of an attack known as Cross-Site Request Forgery (CSRF). 1264 4.7.1. Countermeasures 1266 The traditional countermeasure are CSRF tokens that are bound to the 1267 user agent and passed in the "state" parameter to the authorization 1268 server as described in [RFC6819]. The same protection is provided by 1269 PKCE or the OpenID Connect "nonce" value. 1271 When using PKCE instead of "state" or "nonce" for CSRF protection, it 1272 is important to note that: 1274 * Clients MUST ensure that the AS supports PKCE before using PKCE 1275 for CSRF protection. If an authorization server does not support 1276 PKCE, "state" or "nonce" MUST be used for CSRF protection. 1278 * If "state" is used for carrying application state, and integrity 1279 of its contents is a concern, clients MUST protect "state" against 1280 tampering and swapping. This can be achieved by binding the 1281 contents of state to the browser session and/or signed/encrypted 1282 state values [I-D.bradley-oauth-jwt-encoded-state]. 1284 AS therefore MUST provide a way to detect their support for PKCE. 1285 Using AS metadata according to [RFC8414] is RECOMMENDED, but AS MAY 1286 instead provide a deployment-specific way to ensure or determine PKCE 1287 support. 1289 4.8. PKCE Downgrade Attack 1291 An authorization server that supports PKCE but does not make its use 1292 mandatory for all flows can be susceptible to a PKCE downgrade 1293 attack. 1295 The first prerequisite for this attack is that there is an attacker- 1296 controllable flag in the authorization request that enables or 1297 disables PKCE for the particular flow. The presence or absence of 1298 the "code_challenge" parameter lends itself for this purpose, i.e., 1299 the AS enables and enforces PKCE if this parameter is present in the 1300 authorization request, but does not enforce PKCE if the parameter is 1301 missing. 1303 The second prerequisite for this attack is that the client is not 1304 using "state" at all (e.g., because the client relies on PKCE for 1305 CSRF prevention) or that the client is not checking "state" 1306 correctly. 1308 Roughly speaking, this attack is a variant of a CSRF attack. The 1309 attacker achieves the same goal as in the attack described in 1310 Section 4.7: He injects an authorization code (and with that, an 1311 access token) that is bound to his resources into a session between 1312 his victim and the client. 1314 4.8.1. Attack Description 1316 1. The user has started an OAuth session using some client at an AS. 1317 In the authorization request, the client has set the parameter 1318 "code_challenge=sha256(abc)" as the PKCE code challenge. The 1319 client is now waiting to receive the authorization response from 1320 the user's browse. 1322 2. To conduct the attack, the attacker uses his own device to start 1323 an authorization flow with the targeted client. The client now 1324 uses another PKCE code challenge, say 1325 "code_challenge=sha256(xyz)", in the authorization request. The 1326 attacker intercepts the request and removes the entire 1327 "code_challenge" parameter from the request. Since this step is 1328 performed on the attacker's device, the attacker has full access 1329 to the request contents, for example using browser debug tools. 1331 3. If the authorization server allows for flows without PKCE, it 1332 will create a code that is not bound to any PKCE code challenge. 1334 4. The attacker now redirects the user's browser to an authorization 1335 response URL which contains the code for the attacker's session 1336 with the AS. 1338 5. The user's browser sends the authorization code to the client, 1339 which will now try to redeem the code for an access token at the 1340 AS. The client will send "code_verifier=abc" as the PKCE code 1341 verifier in the token request. 1343 6. Since the authorization server sees that this code is not bound 1344 to any PKCE code challenge, it will not check the presence or 1345 contents of the "code_verifier" parameter. It will issue an 1346 access token that belongs to the attacker's resource to the 1347 client under the user's control. 1349 4.8.2. Countermeasures 1351 Using "state" properly would prevent this attack. However, practice 1352 has shown that many OAuth clients do not use or check "state" 1353 properly. 1355 Therefore, AS MUST take precautions against this threat. 1357 Note that from the view of the AS, in the attack described above, a 1358 "code_verifier" parameter is received at the token endpoint although 1359 no "code_challenge" parameter was present in the authorization 1360 request for the OAuth flow in which the authorization code was 1361 issued. 1363 This fact can be used to mitigate this attack. [RFC7636] already 1364 mandates that 1366 * an AS that supports PKCE MUST check whether a code challenge is 1367 contained in the authorization request and bind this information 1368 to the code that is issued; and 1370 * when a code arrives at the token endpoint, and there was a 1371 "code_challenge" in the authorization request for which this code 1372 was issued, there must be a valid "code_verifier" in the token 1373 request. 1375 Beyond this, to prevent PKCE downgrade attacks, the AS MUST ensure 1376 that if there was no "code_challenge" in the authorization request, a 1377 request to the token endpoint containing a "code_verifier" is 1378 rejected. 1380 Note: AS that mandate the use of PKCE in general or for particular 1381 clients implicitly implement this security measure. 1383 4.9. Access Token Leakage at the Resource Server 1385 Access tokens can leak from a resource server under certain 1386 circumstances. 1388 4.9.1. Access Token Phishing by Counterfeit Resource Server 1390 An attacker may setup his own resource server and trick a client into 1391 sending access tokens to it that are valid for other resource servers 1392 (see Attackers A1 and A5). If the client sends a valid access token 1393 to this counterfeit resource server, the attacker in turn may use 1394 that token to access other services on behalf of the resource owner. 1396 This attack assumes the client is not bound to one specific resource 1397 server (and its URL) at development time, but client instances are 1398 provided with the resource server URL at runtime. This kind of late 1399 binding is typical in situations where the client uses a service 1400 implementing a standardized API (e.g., for e-Mail, calendar, health, 1401 or banking) and where the client is configured by a user or 1402 administrator for a service which this user or company uses. 1404 4.9.1.1. Countermeasures 1406 There are several potential mitigation strategies, which will be 1407 discussed in the following sections. 1409 4.9.1.1.1. Metadata 1411 An authorization server could provide the client with additional 1412 information about the location where it is safe to use its access 1413 tokens. 1415 In the simplest form, this would require the AS to publish a list of 1416 its known resource servers, illustrated in the following example 1417 using a non-standard metadata parameter "resource_servers": 1419 HTTP/1.1 200 OK 1420 Content-Type: application/json 1422 { 1423 "issuer":"https://server.somesite.example", 1424 "authorization_endpoint": 1425 "https://server.somesite.example/authorize", 1426 "resource_servers":[ 1427 "email.somesite.example", 1428 "storage.somesite.example", 1429 "video.somesite.example" 1430 ] 1431 ... 1432 } 1434 The AS could also return the URL(s) an access token is good for in 1435 the token response, illustrated by the example and non-standard 1436 return parameter "access_token_resource_server": 1438 HTTP/1.1 200 OK 1439 Content-Type: application/json;charset=UTF-8 1440 Cache-Control: no-store 1441 Pragma: no-cache 1443 { 1444 "access_token":"2YotnFZFEjr1zCsicMWpAA", 1445 "access_token_resource_server": 1446 "https://hostedresource.somesite.example/path1", 1447 ... 1448 } 1449 This mitigation strategy would rely on the client to enforce the 1450 security policy and to only send access tokens to legitimate 1451 destinations. Results of OAuth related security research (see for 1452 example [oauth_security_ubc] and [oauth_security_cmu]) indicate a 1453 large portion of client implementations do not or fail to properly 1454 implement security controls, like "state" checks. So relying on 1455 clients to prevent access token phishing is likely to fail as well. 1456 Moreover given the ratio of clients to authorization and resource 1457 servers, it is considered the more viable approach to move as much as 1458 possible security-related logic to those entities. Clearly, the 1459 client has to contribute to the overall security. But there are 1460 alternative countermeasures, as described in the next sections, which 1461 provide a better balance between the involved parties. 1463 4.9.1.1.2. Sender-Constrained Access Tokens 1465 As the name suggests, sender-constrained access token scope the 1466 applicability of an access token to a certain sender. This sender is 1467 obliged to demonstrate knowledge of a certain secret as prerequisite 1468 for the acceptance of that token at a resource server. 1470 A typical flow looks like this: 1472 1. The authorization server associates data with the access token 1473 that binds this particular token to a certain client. The 1474 binding can utilize the client identity, but in most cases the AS 1475 utilizes key material (or data derived from the key material) 1476 known to the client. 1478 2. This key material must be distributed somehow. Either the key 1479 material already exists before the AS creates the binding or the 1480 AS creates ephemeral keys. The way pre-existing key material is 1481 distributed varies among the different approaches. For example, 1482 X.509 Certificates can be used in which case the distribution 1483 happens explicitly during the enrollment process. Or the key 1484 material is created and distributed at the TLS layer, in which 1485 case it might automatically happen during the setup of a TLS 1486 connection. 1488 3. The RS must implement the actual proof of possession check. This 1489 is typically done on the application level, often tied to 1490 specific material provided by transport layer (e.g., TLS). The 1491 RS must also ensure that replay of the proof of possession is not 1492 possible. 1494 There exist several proposals to demonstrate the proof of possession 1495 in the scope of the OAuth working group: 1497 * *OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound 1498 Access Tokens* ([RFC8705]): The approach as specified in this 1499 document allows the use of mutual TLS (mTLS) for both client 1500 authentication and sender-constrained access tokens. For the 1501 purpose of sender-constrained access tokens, the client is 1502 identified towards the resource server by the fingerprint of its 1503 public key. During processing of an access token request, the 1504 authorization server obtains the client's public key from the TLS 1505 stack and associates its fingerprint with the respective access 1506 tokens. The resource server in the same way obtains the public 1507 key from the TLS stack and compares its fingerprint with the 1508 fingerprint associated with the access token. 1510 * *DPoP* ([I-D.ietf-oauth-dpop]): DPoP (Demonstration of Proof-of- 1511 Possession at the Application Layer) outlines an application-level 1512 sender-constraining for access and refresh tokens that can be used 1513 in cases where neither mTLS nor OAuth Token Binding (see below) 1514 are available. It uses proof-of-possession based on a public/ 1515 private key pair and application-level signing. DPoP can be used 1516 with public clients and, in case of confidential clients, can be 1517 combined with any client authentication method. 1519 * *OAuth Token Binding* ([I-D.ietf-oauth-token-binding]): In this 1520 approach, an access token is, via the token binding ID, bound to 1521 key material representing a long term association between a client 1522 and a certain TLS host. Negotiation of the key material and proof 1523 of possession in the context of a TLS handshake is taken care of 1524 by the TLS stack. The client needs to determine the token binding 1525 ID of the target resource server and pass this data to the access 1526 token request. The authorization server then associates the 1527 access token with this ID. The resource server checks on every 1528 invocation that the token binding ID of the active TLS connection 1529 and the token binding ID of associated with the access token 1530 match. Since all crypto-related functions are covered by the TLS 1531 stack, this approach is very client developer friendly. As a 1532 prerequisite, token binding as described in [RFC8473] (including 1533 federated token bindings) must be supported on all ends (client, 1534 authorization server, resource server). 1536 * *Signed HTTP Requests* ([I-D.ietf-oauth-signed-http-request]): 1537 This approach utilizes [I-D.ietf-oauth-pop-key-distribution] and 1538 represents the elements of the signature in a JSON object. The 1539 signature is built using JWS. The mechanism has built-in support 1540 for signing of HTTP method, query parameters and headers. It also 1541 incorporates a timestamp as basis for replay prevention. 1543 * *JWT Pop Tokens* ([I-D.sakimura-oauth-jpop]): This draft describes 1544 different ways to constrain access token usage, namely TLS or 1545 request signing. Note: Since the authors of this draft 1546 contributed the TLS-related proposal to [RFC8705], this document 1547 only considers the request signing part. For request signing, the 1548 draft utilizes [I-D.ietf-oauth-pop-key-distribution] and 1549 [RFC7800]. The signature data is represented in a JWT and JWS is 1550 used for signing. Replay prevention is provided by building the 1551 signature over a server-provided nonce, client-provided nonce and 1552 a nonce counter. 1554 At the time of writing, OAuth Mutual TLS is the most widely 1555 implemented and the only standardized sender-constraining method. 1556 The use of OAuth Mutual TLS therefore is RECOMMENDED. 1558 Note that the security of sender-constrained tokens is undermined 1559 when an attacker gets access to the token and the key material. This 1560 is in particular the case for corrupted client software and cross- 1561 site scripting attacks (when the client is running in the browser). 1562 If the key material is protected in a hardware or software security 1563 module or only indirectly accessible (like in a TLS stack), sender- 1564 constrained tokens at least protect against a use of the token when 1565 the client is offline, i.e., when the security module or interface is 1566 not available to the attacker. This applies to access tokens as well 1567 as to refresh tokens (see Section 4.13). 1569 4.9.1.1.3. Audience Restricted Access Tokens 1571 Audience restriction essentially restricts access tokens to a 1572 particular resource server. The authorization server associates the 1573 access token with the particular resource server and the resource 1574 server SHOULD verify the intended audience. If the access token 1575 fails the intended audience validation, the resource server must 1576 refuse to serve the respective request. 1578 In general, audience restrictions limit the impact of token leakage. 1579 In the case of a counterfeit resource server, it may (as described 1580 below) also prevent abuse of the phished access token at the 1581 legitimate resource server. 1583 The audience can be expressed using logical names or physical 1584 addresses (like URLs). In order to prevent phishing, it is necessary 1585 to use the actual URL the client will send requests to. In the 1586 phishing case, this URL will point to the counterfeit resource 1587 server. If the attacker tries to use the access token at the 1588 legitimate resource server (which has a different URL), the resource 1589 server will detect the mismatch (wrong audience) and refuse to serve 1590 the request. 1592 In deployments where the authorization server knows the URLs of all 1593 resource servers, the authorization server may just refuse to issue 1594 access tokens for unknown resource server URLs. 1596 The client SHOULD tell the authorization server the intended resource 1597 server. The proposed mechanism [I-D.ietf-oauth-resource-indicators] 1598 could be used or by encoding the information in the scope value. 1600 Instead of the URL, it is also possible to utilize the fingerprint of 1601 the resource server's X.509 certificate as audience value. This 1602 variant would also allow to detect an attempt to spoof the legitimate 1603 resource server's URL by using a valid TLS certificate obtained from 1604 a different CA. It might also be considered a privacy benefit to 1605 hide the resource server URL from the authorization server. 1607 Audience restriction may seem easier to use since it does not require 1608 any crypto on the client-side. Still, since every access token is 1609 bound to a specific resource server, the client also needs to obtain 1610 a single RS-specific access token when accessing several resource 1611 servers. (Resource indicators, as specified in 1612 [I-D.ietf-oauth-resource-indicators], can help to achieve this.) 1613 [I-D.ietf-oauth-token-binding] has the same property since different 1614 token binding ids must be associated with the access token. Using 1615 [RFC8705], on the other hand, allows a client to use the access token 1616 at multiple resource servers. 1618 It shall be noted that audience restrictions, or generally speaking 1619 an indication by the client to the authorization server where it 1620 wants to use the access token, has additional benefits beyond the 1621 scope of token leakage prevention. It allows the authorization 1622 server to create different access token whose format and content is 1623 specifically minted for the respective server. This has huge 1624 functional and privacy advantages in deployments using structured 1625 access tokens. 1627 4.9.2. Compromised Resource Server 1629 An attacker may compromise a resource server to gain access to the 1630 resources of the respective deployment. Such a compromise may range 1631 from partial access to the system, e.g., its log files, to full 1632 control of the respective server. 1634 If the attacker were able to gain full control, including shell 1635 access, all controls can be circumvented and all resources be 1636 accessed. The attacker would also be able to obtain other access 1637 tokens held on the compromised system that would potentially be valid 1638 to access other resource servers. 1640 Preventing server breaches by hardening and monitoring server systems 1641 is considered a standard operational procedure and, therefore, out of 1642 the scope of this document. This section focuses on the impact of 1643 OAuth-related breaches and the replaying of captured access tokens. 1645 The following measures should be taken into account by implementers 1646 in order to cope with access token replay by malicious actors: 1648 * Sender-constrained access tokens as described in Section 4.9.1.1.2 1649 SHOULD be used to prevent the attacker from replaying the access 1650 tokens on other resource servers. Depending on the severity of 1651 the penetration, sender-constrained access tokens will also 1652 prevent replay on the compromised system. 1654 * Audience restriction as described in Section 4.9.1.1.3 SHOULD be 1655 used to prevent replay of captured access tokens on other resource 1656 servers. 1658 * The resource server MUST treat access tokens like any other 1659 credentials. It is considered good practice to not log them and 1660 not store them in plain text. 1662 The first and second recommendation also apply to other scenarios 1663 where access tokens leak (see Attacker A5). 1665 4.10. Open Redirection 1667 The following attacks can occur when an AS or client has an open 1668 redirector. An open redirector is an endpoint that forwards a user's 1669 browser to an arbitrary URI obtained from a query parameter. 1671 4.10.1. Client as Open Redirector 1673 Clients MUST NOT expose open redirectors. Attackers may use open 1674 redirectors to produce URLs pointing to the client and utilize them 1675 to exfiltrate authorization codes and access tokens, as described in 1676 Section 4.1.2. Another abuse case is to produce URLs that appear to 1677 point to the client. This might trick users into trusting the URL 1678 and follow it in their browser. This can be abused for phishing. 1680 In order to prevent open redirection, clients should only redirect if 1681 the target URLs are whitelisted or if the origin and integrity of a 1682 request can be authenticated. Countermeasures against open 1683 redirection are described by OWASP [owasp_redir]. 1685 4.10.2. Authorization Server as Open Redirector 1687 Just as with clients, attackers could try to utilize a user's trust 1688 in the authorization server (and its URL in particular) for 1689 performing phishing attacks. OAuth authorization servers regularly 1690 redirect users to other web sites (the clients), but must do so in a 1691 safe way. 1693 [RFC6749], Section 4.1.2.1, already prevents open redirects by 1694 stating that the AS MUST NOT automatically redirect the user agent in 1695 case of an invalid combination of "client_id" and "redirect_uri". 1697 However, an attacker could also utilize a correctly registered 1698 redirect URI to perform phishing attacks. The attacker could, for 1699 example, register a client via dynamic client registration [RFC7591] 1700 and intentionally send an erroneous authorization request, e.g., by 1701 using an invalid scope value, thus instructing the AS to redirect the 1702 user agent to its phishing site. 1704 The AS MUST take precautions to prevent this threat. Based on its 1705 risk assessment, the AS needs to decide whether it can trust the 1706 redirect URI and SHOULD only automatically redirect the user agent if 1707 it trusts the redirect URI. If the URI is not trusted, the AS MAY 1708 inform the user and rely on the user to make the correct decision. 1710 4.11. 307 Redirect 1712 At the authorization endpoint, a typical protocol flow is that the AS 1713 prompts the user to enter her credentials in a form that is then 1714 submitted (using the HTTP POST method) back to the authorization 1715 server. The AS checks the credentials and, if successful, redirects 1716 the user agent to the client's redirection endpoint. 1718 In [RFC6749], the HTTP status code 302 is used for this purpose, but 1719 "any other method available via the user-agent to accomplish this 1720 redirection is allowed". When the status code 307 is used for 1721 redirection instead, the user agent will send the user credentials 1722 via HTTP POST to the client. 1724 This discloses the sensitive credentials to the client. If the 1725 relying party is malicious, it can use the credentials to impersonate 1726 the user at the AS. 1728 The behavior might be unexpected for developers, but is defined in 1729 [RFC7231], Section 6.4.7. This status code does not require the user 1730 agent to rewrite the POST request to a GET request and thereby drop 1731 the form data in the POST request body. 1733 In the HTTP standard [RFC7231], only the status code 303 1734 unambigiously enforces rewriting the HTTP POST request to an HTTP GET 1735 request. For all other status codes, including the popular 302, user 1736 agents can opt not to rewrite POST to GET requests and therefore to 1737 reveal the user credentials to the client. (In practice, however, 1738 most user agents will only show this behaviour for 307 redirects.) 1740 AS which redirect a request that potentially contains user 1741 credentials therefore MUST NOT use the HTTP 307 status code for 1742 redirection. If an HTTP redirection (and not, for example, 1743 JavaScript) is used for such a request, AS SHOULD use HTTP status 1744 code 303 "See Other". 1746 4.12. TLS Terminating Reverse Proxies 1748 A common deployment architecture for HTTP applications is to hide the 1749 application server behind a reverse proxy that terminates the TLS 1750 connection and dispatches the incoming requests to the respective 1751 application server nodes. 1753 This section highlights some attack angles of this deployment 1754 architecture with relevance to OAuth and gives recommendations for 1755 security controls. 1757 In some situations, the reverse proxy needs to pass security-related 1758 data to the upstream application servers for further processing. 1759 Examples include the IP address of the request originator, token 1760 binding ids, and authenticated TLS client certificates. This data is 1761 usually passed in custom HTTP headers added to the upstream request. 1763 If the reverse proxy would pass through any header sent from the 1764 outside, an attacker could try to directly send the faked header 1765 values through the proxy to the application server in order to 1766 circumvent security controls that way. For example, it is standard 1767 practice of reverse proxies to accept "X-Forwarded-For" headers and 1768 just add the origin of the inbound request (making it a list). 1769 Depending on the logic performed in the application server, the 1770 attacker could simply add a whitelisted IP address to the header and 1771 render a IP whitelist useless. 1773 A reverse proxy must therefore sanitize any inbound requests to 1774 ensure the authenticity and integrity of all header values relevant 1775 for the security of the application servers. 1777 If an attacker was able to get access to the internal network between 1778 proxy and application server, the attacker could also try to 1779 circumvent security controls in place. It is, therefore, essential 1780 to ensure the authenticity of the communicating entities. 1782 Furthermore, the communication link between reverse proxy and 1783 application server must be protected against eavesdropping, 1784 injection, and replay of messages. 1786 4.13. Refresh Token Protection 1788 Refresh tokens are a convenient and user-friendly way to obtain new 1789 access tokens after the expiration of access tokens. Refresh tokens 1790 also add to the security of OAuth since they allow the authorization 1791 server to issue access tokens with a short lifetime and reduced scope 1792 thus reducing the potential impact of access token leakage. 1794 4.13.1. Discussion 1796 Refresh tokens are an attractive target for attackers since they 1797 represent the overall grant a resource owner delegated to a certain 1798 client. If an attacker is able to exfiltrate and successfully replay 1799 a refresh token, the attacker will be able to mint access tokens and 1800 use them to access resource servers on behalf of the resource owner. 1802 [RFC6749] already provides a robust baseline protection by requiring 1804 * confidentiality of the refresh tokens in transit and storage, 1806 * the transmission of refresh tokens over TLS-protected connections 1807 between authorization server and client, 1809 * the authorization server to maintain and check the binding of a 1810 refresh token to a certain client (i.e., "client_id"), 1812 * authentication of this client during token refresh, if possible, 1813 and 1815 * that refresh tokens cannot be generated, modified, or guessed. 1817 [RFC6749] also lays the foundation for further (implementation 1818 specific) security measures, such as refresh token expiration and 1819 revocation as well as refresh token rotation by defining respective 1820 error codes and response behavior. 1822 This specification gives recommendations beyond the scope of 1823 [RFC6749] and clarifications. 1825 4.13.2. Recommendations 1827 Authorization servers SHOULD determine, based on a risk assessment, 1828 whether to issue refresh tokens to a certain client. If the 1829 authorization server decides not to issue refresh tokens, the client 1830 MAY refresh access tokens by utilizing other grant types, such as the 1831 authorization code grant type. In such a case, the authorization 1832 server may utilize cookies and persistent grants to optimize the user 1833 experience. 1835 If refresh tokens are issued, those refresh tokens MUST be bound to 1836 the scope and resource servers as consented by the resource owner. 1837 This is to prevent privilege escalation by the legitimate client and 1838 reduce the impact of refresh token leakage. 1840 For confidential clients, [RFC6749] already requires that refresh 1841 tokens can only be used by the client for which they were issued. 1843 Authorization server MUST utilize one of these methods to detect 1844 refresh token replay by malicious actors for public clients: 1846 * *Sender-constrained refresh tokens:* the authorization server 1847 cryptographically binds the refresh token to a certain client 1848 instance by utilizing [RFC8705] or [I-D.ietf-oauth-token-binding]. 1850 * *Refresh token rotation:* the authorization server issues a new 1851 refresh token with every access token refresh response. The 1852 previous refresh token is invalidated but information about the 1853 relationship is retained by the authorization server. If a 1854 refresh token is compromised and subsequently used by both the 1855 attacker and the legitimate client, one of them will present an 1856 invalidated refresh token, which will inform the authorization 1857 server of the breach. The authorization server cannot determine 1858 which party submitted the invalid refresh token, but it will 1859 revoke the active refresh token. This stops the attack at the 1860 cost of forcing the legitimate client to obtain a fresh 1861 authorization grant. 1863 Implementation note: the grant to which a refresh token belongs 1864 may be encoded into the refresh token itself. This can enable an 1865 authorization server to efficiently determine the grant to which a 1866 refresh token belongs, and by extension, all refresh tokens that 1867 need to be revoked. Authorization servers MUST ensure the 1868 integrity of the refresh token value in this case, for example, 1869 using signatures. 1871 Authorization servers MAY revoke refresh tokens automatically in case 1872 of a security event, such as: 1874 * password change 1876 * logout at the authorization server 1878 Refresh tokens SHOULD expire if the client has been inactive for some 1879 time, i.e., the refresh token has not been used to obtain fresh 1880 access tokens for some time. The expiration time is at the 1881 discretion of the authorization server. It might be a global value 1882 or determined based on the client policy or the grant associated with 1883 the refresh token (and its sensitivity). 1885 4.14. Client Impersonating Resource Owner 1887 Resource servers may make access control decisions based on the 1888 identity of the resource owner as communicated in the "sub" Claim 1889 returned by the authorization server in a token introspection 1890 response [RFC7662] or other mechanisms. If a client is able to 1891 choose its own "client_id" during registration with the authorization 1892 server, then there is a risk that it can register with the same "sub" 1893 value as a privileged user. A subsequent access token obtained under 1894 the client credentials grant may be mistaken for an access token 1895 authorized by the privileged user if the resource server does not 1896 perform additional checks. 1898 4.14.1. Countermeasures 1900 Authorization servers SHOULD NOT allow clients to influence their 1901 "client_id" or "sub" value or any other Claim if that can cause 1902 confusion with a genuine resource owner. Where this cannot be 1903 avoided, authorization servers MUST provide other means for the 1904 resource server to distinguish between access tokens authorized by a 1905 resource owner from access tokens authorized by the client itself. 1907 4.15. Clickjacking 1909 As described in Section 4.4.1.9 of [RFC6819], the authorization 1910 request is susceptible to clickjacking. An attacker can use this 1911 vector to obtain the user's authentication credentials, change the 1912 scope of access granted to the client, and potentially access the 1913 user's resources. 1915 Authorization servers MUST prevent clickjacking attacks. Multiple 1916 countermeasures are described in [RFC6819], including the use of the 1917 X-Frame-Options HTTP response header field and frame-busting 1918 JavaScript. In addition to those, authorization servers SHOULD also 1919 use Content Security Policy (CSP) level 2 [CSP-2] or greater. 1921 To be effective, CSP must be used on the authorization endpoint and, 1922 if applicable, other endpoints used to authenticate the user and 1923 authorize the client (e.g., the device authorization endpoint, login 1924 pages, error pages, etc.). This prevents framing by unauthorized 1925 origins in user agents that support CSP. The client MAY permit being 1926 framed by some other origin than the one used in its redirection 1927 endpoint. For this reason, authorization servers SHOULD allow 1928 administrators to configure allowed origins for particular clients 1929 and/or for clients to register these dynamically. 1931 Using CSP allows authorization servers to specify multiple origins in 1932 a single response header field and to constrain these using flexible 1933 patterns (see [CSP-2] for details). Level 2 of this standard 1934 provides a robust mechanism for protecting against clickjacking by 1935 using policies that restrict the origin of frames (using "frame- 1936 ancestors") together with those that restrict the sources of scripts 1937 allowed to execute on an HTML page (by using "script-src"). A non- 1938 normative example of such a policy is shown in the following listing: 1940 HTTP/1.1 200 OK 1941 Content-Security-Policy: frame-ancestors https://ext.example.org:8000 1942 Content-Security-Policy: script-src 'self' 1943 X-Frame-Options: ALLOW-FROM https://ext.example.org:8000 1944 ... 1946 Because some user agents do not support [CSP-2], this technique 1947 SHOULD be combined with others, including those described in 1948 [RFC6819], unless such legacy user agents are explicitly unsupported 1949 by the authorization server. Even in such cases, additional 1950 countermeasures SHOULD still be employed. 1952 5. Acknowledgements 1954 We would like to thank Jim Manico, Phil Hunt, Nat Sakimura, Christian 1955 Mainka, Doug McDorman, Johan Peeters, Joseph Heenan, Brock Allen, 1956 Vittorio Bertocci, David Waite, Nov Matake, Tomek Stojecki, Dominick 1957 Baier, Neil Madden, William Dennis, Dick Hardt, Petteri Stenius, 1958 Annabelle Richard Backman, Aaron Parecki, George Fletscher, Brian 1959 Campbell, Konstantin Lapine, Tim Würtele, Guido Schmitz, Hans 1960 Zandbelt, Jared Jennings, Michael Peck, Pedram Hosseyni, Michael B. 1961 Jones, Travis Spencer, and Karsten Meyer zu Selhausen for their 1962 valuable feedback. 1964 6. IANA Considerations 1966 This draft includes no request to IANA. 1968 7. Security Considerations 1970 All relevant security considerations have been given in the 1971 functional specification. 1973 8. Normative References 1975 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1976 Framework: Bearer Token Usage", RFC 6750, 1977 DOI 10.17487/RFC6750, October 2012, 1978 . 1980 [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. 1981 Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication 1982 and Certificate-Bound Access Tokens", February 2020, 1983 . 1985 [oauth-v2-form-post-response-mode] 1986 Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response 1987 Mode", 27 April 2015, . 1990 [OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 1991 C. Mortimore, "OpenID Connect Core 1.0 incorporating 1992 errata set 1", 8 November 2014, 1993 . 1995 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1996 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1997 DOI 10.17487/RFC7231, June 2014, 1998 . 2000 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2001 Resource Identifier (URI): Generic Syntax", STD 66, 2002 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2003 . 2005 [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", 2006 BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, 2007 . 2009 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 2010 RFC 6749, DOI 10.17487/RFC6749, October 2012, 2011 . 2013 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 2014 Threat Model and Security Considerations", RFC 6819, 2015 DOI 10.17487/RFC6819, January 2013, 2016 . 2018 [OpenIDDisc] 2019 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 2020 Connect Discovery 1.0 incorporating errata set 1", 8 2021 November 2014, . 2024 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 2025 RFC 7662, DOI 10.17487/RFC7662, October 2015, 2026 . 2028 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 2029 Authorization Server Metadata", RFC 8414, 2030 DOI 10.17487/RFC8414, June 2018, 2031 . 2033 9. Informative References 2035 [webcrypto] 2036 Watson, M., "Web Cryptography API", 26 January 2017, 2037 . 2039 [arXiv.1508.04324v2] 2040 Mladenov, V., Mainka, C., and J. Schwenk, "On the security 2041 of modern Single Sign-On Protocols: Second-Order 2042 Vulnerabilities in OpenID Connect", 7 January 2016, 2043 . 2045 [I-D.ietf-oauth-token-binding] 2046 Jones, M., Campbell, B., Bradley, J., and W. Denniss, 2047 "OAuth 2.0 Token Binding", Work in Progress, Internet- 2048 Draft, draft-ietf-oauth-token-binding-08, 19 October 2018, 2049 . 2052 [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 2053 for Code Exchange by OAuth Public Clients", RFC 7636, 2054 DOI 10.17487/RFC7636, September 2015, 2055 . 2057 [I-D.ietf-oauth-iss-auth-resp] 2058 Selhausen, K. and D. Fett, "OAuth 2.0 Authorization Server 2059 Issuer Identifier in Authorization Response", Work in 2060 Progress, Internet-Draft, draft-ietf-oauth-iss-auth-resp- 2061 00, 6 January 2021, . 2064 [oauth_security_jcs_14] 2065 Bansal, C., Bhargavan, K., Delignat-Lavaud, A., and S. 2066 Maffeis, "Discovering concrete attacks on website 2067 authorization by formal analysis", 23 April 2014, 2068 . 2070 [I-D.sakimura-oauth-jpop] 2071 Sakimura, N., Li, K., and J. Bradley, "The OAuth 2.0 2072 Authorization Framework: JWT Pop Token Usage", Work in 2073 Progress, Internet-Draft, draft-sakimura-oauth-jpop-05, 22 2074 July 2019, . 2077 [oauth_security_ubc] 2078 Sun, S.-T. and K. Beznosov, "The Devil is in the 2079 (Implementation) Details: An Empirical Analysis of OAuth 2080 SSO Systems", October 2012, 2081 . 2083 [CSP-2] West, M., Barth, A., and D. Veditz, "Content Security 2084 Policy Level 2", July 2015, . 2086 [arXiv.1901.11520] 2087 Fett, D., Hosseyni, P., and R. Küsters, "An Extensive 2088 Formal Security Analysis of the OpenID Financial-grade 2089 API", 31 January 2019, . 2091 [I-D.ietf-oauth-par] 2092 Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., 2093 and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", 2094 Work in Progress, Internet-Draft, draft-ietf-oauth-par-05, 2095 14 December 2020, 2096 . 2098 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 2099 Possession Key Semantics for JSON Web Tokens (JWTs)", 2100 RFC 7800, DOI 10.17487/RFC7800, April 2016, 2101 . 2103 [webappsec-referrer-policy] 2104 Eisinger, J. and E. Stark, "Referrer Policy", 20 April 2105 2017, . 2107 [JARM] Lodderstedt, T. and B. Campbell, "Financial-grade API: JWT 2108 Secured Authorization Response Mode for OAuth 2.0 (JARM)", 2109 17 October 2018, 2110 . 2112 [bug.chromium] 2113 "Referer header includes URL fragment when opening link 2114 using New Tab", 2115 . 2118 [I-D.ietf-oauth-signed-http-request] 2119 Richer, J., Bradley, J., and H. Tschofenig, "A Method for 2120 Signing HTTP Requests for OAuth", Work in Progress, 2121 Internet-Draft, draft-ietf-oauth-signed-http-request-03, 8 2122 August 2016, . 2125 [owasp_redir] 2126 "OWASP Cheat Sheet Series - Unvalidated Redirects and 2127 Forwards", 2128 . 2131 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2132 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2133 May 2017, . 2135 [arXiv.1601.01229] 2136 Fett, D., Küsters, R., and G. Schmitz, "A Comprehensive 2137 Formal Security Analysis of OAuth 2.0", 6 January 2016, 2138 . 2140 [webauthn] Balfanz, D., Czeskis, A., Hodges, J., Jones, J.C., Jones, 2141 M.B., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg, 2142 "Web Authentication: An API for accessing Public Key 2143 Credentials Level 1", 4 March 2019, 2144 . 2146 [I-D.ietf-oauth-jwsreq] 2147 Sakimura, N., Bradley, J., and M. Jones, "The OAuth 2.0 2148 Authorization Framework: JWT Secured Authorization Request 2149 (JAR)", Work in Progress, Internet-Draft, draft-ietf- 2150 oauth-jwsreq-30, 10 September 2020, 2151 . 2153 [I-D.ietf-oauth-dpop] 2154 Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., 2155 Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof- 2156 of-Possession at the Application Layer (DPoP)", Work in 2157 Progress, Internet-Draft, draft-ietf-oauth-dpop-02, 18 2158 November 2020, 2159 . 2161 [RFC8473] Popov, A., Nystroem, M., Balfanz, D., Ed., Harper, N., and 2162 J. Hodges, "Token Binding over HTTP", RFC 8473, 2163 DOI 10.17487/RFC8473, October 2018, 2164 . 2166 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2167 Requirement Levels", BCP 14, RFC 2119, 2168 DOI 10.17487/RFC2119, March 1997, 2169 . 2171 [I-D.ietf-oauth-resource-indicators] 2172 Campbell, B., Bradley, J., and H. Tschofenig, "Resource 2173 Indicators for OAuth 2.0", Work in Progress, Internet- 2174 Draft, draft-ietf-oauth-resource-indicators-08, 11 2175 September 2019, . 2178 [arXiv.1704.08539] 2179 Fett, D., Küsters, R., and G. Schmitz, "The Web SSO 2180 Standard OpenID Connect: In-Depth Formal Security Analysis 2181 and Security Guidelines", 27 April 2017, 2182 . 2184 [I-D.bradley-oauth-jwt-encoded-state] 2185 Bradley, J., Lodderstedt, T., and H. Zandbelt, "Encoding 2186 claims in the OAuth 2 state parameter using a JWT", Work 2187 in Progress, Internet-Draft, draft-bradley-oauth-jwt- 2188 encoded-state-09, 4 November 2018, 2189 . 2192 [oauth_security_cmu] 2193 Chen, E., Pei, Y., Chen, S., Tian, Y., Kotcher, R., and P. 2194 Tague, "OAuth Demystified for Mobile Application 2195 Developers", November 2014, 2196 . 2199 [I-D.ietf-oauth-pop-key-distribution] 2200 Bradley, J., Hunt, P., Jones, M., Tschofenig, H., and M. 2201 Meszaros, "OAuth 2.0 Proof-of-Possession: Authorization 2202 Server to Client Key Distribution", Work in Progress, 2203 Internet-Draft, draft-ietf-oauth-pop-key-distribution-07, 2204 27 March 2019, . 2207 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 2208 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 2209 RFC 7591, DOI 10.17487/RFC7591, July 2015, 2210 . 2212 [I-D.ietf-oauth-rar] 2213 Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 2214 Rich Authorization Requests", Work in Progress, Internet- 2215 Draft, draft-ietf-oauth-rar-03, 18 October 2020, 2216 . 2218 [subdomaintakeover] 2219 Liu, D., Hao, S., and H. Wang, "All Your DNS Records Point 2220 to Us: Understanding the Security Threats of Dangling DNS 2221 Records", 24 October 2016, 2222 . 2224 Appendix A. Document History 2226 [[ To be removed from the final specification ]] 2228 -18 2230 * Fix editorial and spelling issues. 2232 * Change wording for disallowing HTTP redirect URIs. 2234 -17 2236 * Make the use of metadata RECOMMENDED for both servers and clients 2238 * Make announcing PKCE support in metadata the RECOMMENDED way 2239 (before: either metadata or deployment-specific way) 2241 * AS also MUST NOT expose open redirectors. 2243 * Mention that attackers can collaborate. 2245 * Update recommendations regarding mix-up defense, building upon 2246 [I-D.ietf-oauth-iss-auth-resp]. 2248 * Improve description of mix-up attack. 2250 * Make HTTPS mandatory for most redirect URIs. 2252 -16 2254 * Make MTLS a suggestion, not RECOMMENDED. 2256 * Add important requirements when using nonce for code injection 2257 protection. 2259 * Highlight requirements for refresh token sender-constraining. 2261 * Make PKCE a MUST for public clients. 2263 * Describe PKCE Downgrade Attacks and countermeasures. 2265 * Allow variable port numbers in localhost redirect URIs as in 2266 RFC8252, Section 7.3. 2268 -15 2270 * Update reference to DPoP 2272 * Fix reference to RFC8414 2274 * Move to xml2rfcv3 2276 -14 2278 * Added info about using CSP to prevent clickjacking 2280 * Changes from WGLC feedback 2282 * Editorial changes 2284 * AS MUST announce PKCE support either in metadata or using 2285 deployment-specific ways (before: SHOULD) 2287 -13 2288 * Discourage use of Resource Owner Password Credentials Grant 2290 * Added text on client impersonating resource owner 2292 * Recommend asymmetric methods for client authentication 2294 * Encourage use of PKCE mode "S256" 2296 * PKCE may replace state for CSRF protection 2298 * AS SHOULD publish PKCE support 2300 * Cleaned up discussion on auth code injection 2302 * AS MUST support PKCE 2304 -12 2306 * Added updated attacker model 2308 -11 2310 * Adapted section 2.1.2 to outcome of consensus call 2312 * more text on refresh token inactivity and implementation note on 2313 refresh token replay detection via refresh token rotation 2315 -10 2317 * incorporated feedback by Joseph Heenan 2319 * changed occurrences of SHALL to MUST 2321 * added text on lack of token/cert binding support tokens issued in 2322 the authorization response as justification to not recommend 2323 issuing tokens there at all 2325 * added requirement to authenticate clients during code exchange 2326 (PKCE or client credential) to 2.1.1. 2328 * added section on refresh tokens 2330 * editorial enhancements to 2.1.2 based on feedback 2332 -09 2334 * changed text to recommend not to use implicit but code 2335 * added section on access token injection 2337 * reworked sections 3.1 through 3.3 to be more specific on implicit 2338 grant issues 2340 -08 2342 * added recommendations re implicit and token injection 2344 * uppercased key words in Section 2 according to RFC 2119 2346 -07 2348 * incorporated findings of Doug McDorman 2350 * added section on HTTP status codes for redirects 2352 * added new section on access token privilege restriction based on 2353 comments from Johan Peeters 2355 -06 2357 * reworked section 3.8.1 2359 * incorporated Phil Hunt's feedback 2361 * reworked section on mix-up 2363 * extended section on code leakage via referrer header to also cover 2364 state leakage 2366 * added Daniel Fett as author 2368 * replaced text intended to inform WG discussion by recommendations 2369 to implementors 2371 * modified example URLs to conform to RFC 2606 2373 -05 2375 * Completed sections on code leakage via referrer header, attacks in 2376 browser, mix-up, and CSRF 2378 * Reworked Code Injection Section 2380 * Added reference to OpenID Connect spec 2381 * removed refresh token leakage as respective considerations have 2382 been given in section 10.4 of RFC 6749 2384 * first version on open redirection 2386 * incorporated Christian Mainka's review feedback 2388 -04 2390 * Restructured document for better readability 2392 * Added best practices on Token Leakage prevention 2394 -03 2396 * Added section on Access Token Leakage at Resource Server 2398 * incorporated Brian Campbell's findings 2400 -02 2402 * Folded Mix up and Access Token leakage through a bad AS into new 2403 section for dynamic OAuth threats 2405 * reworked dynamic OAuth section 2407 -01 2409 * Added references to mitigation methods for token leakage 2411 * Added reference to Token Binding for Authorization Code 2413 * incorporated feedback of Phil Hunt 2415 * fixed numbering issue in attack descriptions in section 2 2417 -00 (WG document) 2419 * turned the ID into a WG document and a BCP 2421 * Added federated app login as topic in Other Topics 2423 Authors' Addresses 2425 Torsten Lodderstedt 2426 yes.com 2428 Email: torsten@lodderstedt.net 2429 John Bradley 2430 Yubico 2432 Email: ve7jtb@ve7jtb.com 2434 Andrey Labunets 2436 Email: isciurus@gmail.com 2438 Daniel Fett 2439 yes.com 2441 Email: mail@danielfett.de