idnits 2.17.1 draft-ietf-oauth-security-topics-19.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 (16 December 2021) is 861 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) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) -- Possible downref: Non-RFC (?) normative reference: ref. 'OpenIDDisc' ** Downref: Normative reference to an Informational RFC: RFC 6819 -- Possible downref: Non-RFC (?) normative reference: ref. 'OpenID' == Outdated reference: A later version (-16) exists of draft-ietf-oauth-dpop-04 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-rar-08 == Outdated reference: A later version (-05) exists of draft-ietf-oauth-iss-auth-resp-04 Summary: 2 errors (**), 0 flaws (~~), 6 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: 19 June 2022 Yubico 6 A. Labunets 7 Independent Researcher 8 D. Fett 9 yes.com 10 16 December 2021 12 OAuth 2.0 Security Best Current Practice 13 draft-ietf-oauth-security-topics-19 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 19 June 2022. 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 Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . . 27 98 4.8. PKCE Downgrade Attack . . . . . . . . . . . . . . . . . . 28 99 4.8.1. Attack Description . . . . . . . . . . . . . . . . . 28 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 . . . . . . 36 108 4.11. 307 Redirect . . . . . . . . . . . . . . . . . . . . . . 37 109 4.12. TLS Terminating Reverse Proxies . . . . . . . . . . . . . 38 110 4.13. Refresh Token Protection . . . . . . . . . . . . . . . . 38 111 4.13.1. Discussion . . . . . . . . . . . . . . . . . . . . . 39 112 4.13.2. Recommendations . . . . . . . . . . . . . . . . . . 39 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 . . . . . . . . . . . . . . . . . . . 42 119 8. Normative References . . . . . . . . . . . . . . . . . . . . 42 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, one- 226 time use CSRF tokens carried in the state parameter that are securely 227 bound to the user agent MUST be used for CSRF protection (see 228 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 is 284 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 for public clients MUST be sender-constrained or use 332 refresh token rotation as described in Section 4.13. [RFC6749] 333 already mandates that refresh tokens for confidential clients can 334 only be used by the client for which they were issued. 336 2.3. Access Token Privilege Restriction 338 The privileges associated with an access token SHOULD be restricted 339 to the minimum required for the particular application or use case. 340 This prevents clients from exceeding the privileges authorized by the 341 resource owner. It also prevents users from exceeding their 342 privileges authorized by the respective security policy. Privilege 343 restrictions also help to reduce the impact of access token leakage. 345 In particular, access tokens SHOULD be restricted to certain resource 346 servers (audience restriction), preferably to a single resource 347 server. To put this into effect, the authorization server associates 348 the access token with certain resource servers and every resource 349 server is obliged to verify, for every request, whether the access 350 token sent with that request was meant to be used for that particular 351 resource server. If not, the resource server MUST refuse to serve 352 the respective request. Clients and authorization servers MAY 353 utilize the parameters scope or resource as specified in [RFC6749] 354 and [I-D.ietf-oauth-resource-indicators], respectively, to determine 355 the resource server they want to access. 357 Additionally, access tokens SHOULD be restricted to certain resources 358 and actions on resource servers or resources. To put this into 359 effect, the authorization server associates the access token with the 360 respective resource and actions and every resource server is obliged 361 to verify, for every request, whether the access token sent with that 362 request was meant to be used for that particular action on the 363 particular resource. If not, the resource server must refuse to 364 serve the respective request. Clients and authorization servers MAY 365 utilize the parameter scope as specified in [RFC6749] and 366 authorization_details as specified in [I-D.ietf-oauth-rar] to 367 determine those resources and/or actions. 369 2.4. Resource Owner Password Credentials Grant 371 The resource owner password credentials grant MUST NOT be used. This 372 grant type insecurely exposes the credentials of the resource owner 373 to the client. Even if the client is benign, this results in an 374 increased attack surface (credentials can leak in more places than 375 just the AS) and users are trained to enter their credentials in 376 places other than the AS. 378 Furthermore, adapting the resource owner password credentials grant 379 to two-factor authentication, authentication with cryptographic 380 credentials (cf. WebCrypto [webcrypto], WebAuthn [webauthn]), and 381 authentication processes that require multiple steps can be hard or 382 impossible. 384 2.5. Client Authentication 386 Authorization servers SHOULD use client authentication if possible. 388 It is RECOMMENDED to use asymmetric (public-key based) methods for 389 client authentication such as mTLS [RFC8705] or private_key_jwt 390 [OpenID]. When asymmetric methods for client authentication are 391 used, authorization servers do not need to store sensitive symmetric 392 keys, making these methods more robust against a number of attacks. 394 2.6. Other Recommendations 396 The use of OAuth Metadata [RFC8414] can help to improve the security 397 of OAuth deployments: 399 * It ensures that security features and other new OAuth features can 400 be enabled automatically by compliant software libraries. 402 * It reduces chances for misconfigurations, for example 403 misconfigured endpoint URLs (that might belong to an attacker) or 404 misconfigured security features. 406 * It can help to facilitate rotation of cryptographic keys and to 407 ensure cryptographic agility. 409 It is therefore RECOMMENDED that AS publish OAuth metadata according 410 to [RFC8414] and that clients make use of this metadata to configure 411 themselves when available. 413 Authorization servers SHOULD NOT allow clients to influence their 414 client_id or sub value or any other Claim if that can cause confusion 415 with a genuine resource owner (see Section 4.14). 417 It is RECOMMENDED to use end-to-end TLS. If TLS traffic needs to be 418 terminated at an intermediary, refer to Section 4.12 for further 419 security advice. 421 Authorization responses MUST NOT be transmitted over unencrypted 422 network connections. To this end, AS MUST NOT allow redirect URIs 423 that use the http scheme except for native clients that use Loopback 424 Interface Redirection as described in [RFC8252], Section 7.3. 426 3. The Updated OAuth 2.0 Attacker Model 428 In [RFC6819], an attacker model is laid out that describes the 429 capabilities of attackers against which OAuth deployments must be 430 protected. In the following, this attacker model is updated to 431 account for the potentially dynamic relationships involving multiple 432 parties (as described in Section 1), to include new types of 433 attackers and to define the attacker model more clearly. 435 OAuth MUST ensure that the authorization of the resource owner (RO) 436 (with a user agent) at the authorization server (AS) and the 437 subsequent usage of the access token at the resource server (RS) is 438 protected at least against the following attackers: 440 * (A1) Web Attackers that can set up and operate an arbitrary number 441 of network endpoints including browsers and servers (except for 442 the concrete RO, AS, and RS). Web attackers may set up web sites 443 that are visited by the RO, operate their own user agents, and 444 participate in the protocol. 446 Web attackers may, in particular, operate OAuth clients that are 447 registered at AS, and operate their own authorization and resource 448 servers that can be used (in parallel) by the RO and other 449 resource owners. 451 It must also be assumed that web attackers can lure the user to 452 open arbitrary attacker-chosen URIs at any time. In practice, 453 this can be achieved in many ways, for example, by injecting 454 malicious advertisements into advertisement networks, or by 455 sending legit-looking emails. 457 Web attackers can use their own user credentials to create new 458 messages as well as any secrets they learned previously. For 459 example, if a web attacker learns an authorization code of a user 460 through a misconfigured redirect URI, the web attacker can then 461 try to redeem that code for an access token. 463 They cannot, however, read or manipulate messages that are not 464 targeted towards them (e.g., sent to a URL controlled by a non- 465 attacker controlled AS). 467 * (A2) Network Attackers that additionally have full control over 468 the network over which protocol participants communicate. They 469 can eavesdrop on, manipulate, and spoof messages, except when 470 these are properly protected by cryptographic methods (e.g., TLS). 471 Network attackers can also block arbitrary messages. 473 While an example for a web attacker would be a customer of an 474 internet service provider, network attackers could be the internet 475 service provider itself, an attacker in a public (wifi) network using 476 ARP spoofing, or a state-sponsored attacker with access to internet 477 exchange points, for instance. 479 These attackers conform to the attacker model that was used in formal 480 analysis efforts for OAuth [arXiv.1601.01229]. This is a minimal 481 attacker model. Implementers MUST take into account all possible 482 types of attackers in the environment in which their OAuth 483 implementations are expected to run. Previous attacks on OAuth have 484 shown that OAuth deployments SHOULD in particular consider the 485 following, stronger attackers in addition to those listed above: 487 * (A3) Attackers that can read, but not modify, the contents of the 488 authorization response (i.e., the authorization response can leak 489 to an attacker). 491 Examples for such attacks include open redirector attacks, 492 problems existing on mobile operating systems (where different 493 apps can register themselves on the same URI), mix-up attacks (see 494 Section 4.4), where the client is tricked into sending credentials 495 to a attacker-controlled AS, and the fact that URLs are often 496 stored/logged by browsers (history), proxy servers, and operating 497 systems. 499 * (A4) Attackers that can read, but not modify, the contents of the 500 authorization request (i.e., the authorization request can leak, 501 in the same manner as above, to an attacker). 503 * (A5) Attackers that can acquire an access token issued by AS. For 504 example, a resource server can be compromised by an attacker, an 505 access token may be sent to an attacker-controlled resource server 506 due to a misconfiguration, or an RO is social-engineered into 507 using a attacker-controlled RS. See also Section 4.9.2. 509 (A3), (A4) and (A5) typically occur together with either (A1) or 510 (A2). Attackers can collaborate to reach a common goal. 512 Note that in this attacker model, an attacker (see A1) can be a RO or 513 act as one. For example, an attacker can use his own browser to 514 replay tokens or authorization codes obtained by any of the attacks 515 described above at the client or RS. 517 This document focusses on threats resulting from these attackers. 518 Attacks in an even stronger attacker model are discussed, for 519 example, in [arXiv.1901.11520]. 521 4. Attacks and Mitigations 523 This section gives a detailed description of attacks on OAuth 524 implementations, along with potential countermeasures. Attacks and 525 mitigations already covered in [RFC6819] are not listed here, except 526 where new recommendations are made. 528 4.1. Insufficient Redirect URI Validation 530 Some authorization servers allow clients to register redirect URI 531 patterns instead of complete redirect URIs. The authorization 532 servers then match the redirect URI parameter value at the 533 authorization endpoint against the registered patterns at runtime. 534 This approach allows clients to encode transaction state into 535 additional redirect URI parameters or to register a single pattern 536 for multiple redirect URIs. 538 This approach turned out to be more complex to implement and more 539 error prone to manage than exact redirect URI matching. Several 540 successful attacks exploiting flaws in the pattern matching 541 implementation or concrete configurations have been observed in the 542 wild . Insufficient validation of the redirect URI effectively breaks 543 client identification or authentication (depending on grant and 544 client type) and allows the attacker to obtain an authorization code 545 or access token, either 547 * by directly sending the user agent to a URI under the attackers 548 control, or 550 * by exposing the OAuth credentials to an attacker by utilizing an 551 open redirector at the client in conjunction with the way user 552 agents handle URL fragments. 554 These attacks are shown in detail in the following subsections. 556 4.1.1. Redirect URI Validation Attacks on Authorization Code Grant 558 For a client using the grant type code, an attack may work as 559 follows: 561 Assume the redirect URL pattern https://*.somesite.example/* is 562 registered for the client with the client ID s6BhdRkqt3. The 563 intention is to allow any subdomain of somesite.example to be a valid 564 redirect URI for the client, for example 565 https://app1.somesite.example/redirect. A naive implementation on 566 the authorization server, however, might interpret the wildcard * as 567 "any character" and not "any character valid for a domain name". The 568 authorization server, therefore, might permit 569 https://attacker.example/.somesite.example as a redirect URI, 570 although attacker.example is a different domain potentially 571 controlled by a malicious party. 573 The attack can then be conducted as follows: 575 First, the attacker needs to trick the user into opening a tampered 576 URL in his browser that launches a page under the attacker's control, 577 say https://www.evil.example (see Attacker A1.) 579 This URL initiates the following authorization request with the 580 client ID of a legitimate client to the authorization endpoint (line 581 breaks for display only): 583 GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=9ad67f13 584 &redirect_uri=https%3A%2F%2Fattacker.example%2F.somesite.example 585 HTTP/1.1 586 Host: server.somesite.example 588 The authorization server validates the redirect URI and compares it 589 to the registered redirect URL patterns for the client s6BhdRkqt3. 590 The authorization request is processed and presented to the user. 592 If the user does not see the redirect URI or does not recognize the 593 attack, the code is issued and immediately sent to the attacker's 594 domain. If an automatic approval of the authorization is enabled 595 (which is not recommended for public clients according to [RFC6749]), 596 the attack can be performed even without user interaction. 598 If the attacker impersonated a public client, the attacker can 599 exchange the code for tokens at the respective token endpoint. 601 This attack will not work as easily for confidential clients, since 602 the code exchange requires authentication with the legitimate 603 client's secret. The attacker can, however, use the legitimate 604 confidential client to redeem the code by performing an authorization 605 code injection attack, see Section 4.5. 607 Note: Vulnerabilities of this kind can also exist if the 608 authorization server handles wildcards properly. For example, assume 609 that the client registers the redirect URL pattern 610 https://*.somesite.example/* and the authorization server interprets 611 this as "allow redirect URIs pointing to any host residing in the 612 domain somesite.example". If an attacker manages to establish a host 613 or subdomain in somesite.example, he can impersonate the legitimate 614 client. This could be caused, for example, by a subdomain takeover 615 attack [subdomaintakeover], where an outdated CNAME record (say, 616 external-service.somesite.example) points to an external DNS name 617 that does no longer exist (say, customer-abc.service.example) and can 618 be taken over by an attacker (e.g., by registering as customer-abc 619 with the external service). 621 4.1.2. Redirect URI Validation Attacks on Implicit Grant 623 The attack described above works for the implicit grant as well. If 624 the attacker is able to send the authorization response to a URI 625 under his control, he will directly get access to the fragment 626 carrying the access token. 628 Additionally, implicit clients can be subject to a further kind of 629 attack. It utilizes the fact that user agents re-attach fragments to 630 the destination URL of a redirect if the location header does not 631 contain a fragment (see [RFC7231], Section 9.5). The attack 632 described here combines this behavior with the client as an open 633 redirector (see Section 4.10.1) in order to get access to access 634 tokens. This allows circumvention even of very narrow redirect URI 635 patterns, but not strict URL matching. 637 Assume the registered URL pattern for client s6BhdRkqt3 is 638 https://client.somesite.example/cb?*, i.e., any parameter is allowed 639 for redirects to https://client.somesite.example/cb. Unfortunately, 640 the client exposes an open redirector. This endpoint supports a 641 parameter redirect_to which takes a target URL and will send the 642 browser to this URL using an HTTP Location header redirect 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 the 683 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 port 699 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 Location 711 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 in 733 this way. Although specified otherwise in [RFC7231], Section 5.5.2, 734 the same may happen to access tokens conveyed in URI fragments due to 735 browser implementation issues as illustrated by Chromium Issue 168213 736 [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 token). 754 4.2.2. Leakage from the Authorization Server 756 In a similar way, an attacker can learn state from the authorization 757 request if the authorization endpoint at the authorization server 758 contains links or third-party content as above. 760 4.2.3. Consequences 762 An attacker that learns a valid code or access token through a 763 Referer header can perform the attacks as described in Section 4.1.1, 764 Section 4.5, and Section 4.6. If the attacker learns state, the CSRF 765 protection achieved by using state is lost, resulting in CSRF attacks 766 as described in [RFC6819], Section 4.4.1.8. 768 4.2.4. Countermeasures 770 The page rendered as a result of the OAuth authorization response and 771 the authorization endpoint SHOULD NOT include third-party resources 772 or links to external sites. 774 The following measures further reduce the chances of a successful 775 attack: 777 * Suppress the Referer header by applying an appropriate Referrer 778 Policy [webappsec-referrer-policy] to the document (either as part 779 of the "referrer" meta attribute or by setting a Referrer-Policy 780 header). For example, the header Referrer-Policy: no-referrer in 781 the response completely suppresses the Referer header in all 782 requests originating from the resulting document. 784 * Use authorization code instead of response types causing access 785 token issuance from the authorization endpoint. 787 * Bind authorization code to a confidential client or PKCE 788 challenge. In this case, the attacker lacks the secret to request 789 the code exchange. 791 * As described in [RFC6749], Section 4.1.2, authorization codes MUST 792 be invalidated by the AS after their first use at the token 793 endpoint. For example, if an AS invalidated the code after the 794 legitimate client redeemed it, the attacker would fail exchanging 795 this code later. 797 This does not mitigate the attack if the attacker manages to 798 exchange the code for a token before the legitimate client does 799 so. Therefore, [RFC6749] further recommends that, when an attempt 800 is made to redeem a code twice, the AS SHOULD revoke all tokens 801 issued previously based on that code. 803 * The state value SHOULD be invalidated by the client after its 804 first use at the redirection endpoint. If this is implemented, 805 and an attacker receives a token through the Referer header from 806 the client's web site, the state was already used, invalidated by 807 the client and cannot be used again by the attacker. (This does 808 not help if the state leaks from the AS's web site, since then the 809 state has not been used at the redirection endpoint at the client 810 yet.) 812 * Use the form post response mode instead of a redirect for the 813 authorization response (see [oauth-v2-form-post-response-mode]). 815 4.3. Credential Leakage via Browser History 817 Authorization codes and access tokens can end up in the browser's 818 history of visited URLs, enabling the attacks described in the 819 following. 821 4.3.1. Authorization Code in Browser History 823 When a browser navigates to client.example/ 824 redirection_endpoint?code=abcd as a result of a redirect from a 825 provider's authorization endpoint, the URL including the 826 authorization code may end up in the browser's history. An attacker 827 with access to the device could obtain the code and try to replay it. 829 Countermeasures: 831 * Authorization code replay prevention as described in [RFC6819], 832 Section 4.4.1.1, and Section 4.5. 834 * Use form post response mode instead of redirect for the 835 authorization response (see [oauth-v2-form-post-response-mode]). 837 4.3.2. Access Token in Browser History 839 An access token may end up in the browser history if a client or a 840 web site that already has a token deliberately navigates to a page 841 like provider.com/get_user_profile?access_token=abcdef. [RFC6750] 842 discourages this practice and advises to transfer tokens via a 843 header, but in practice web sites often pass access tokens in query 844 parameters. 846 In case of the implicit grant, a URL like client.example/ 847 redirection_endpoint#access_token=abcdef may also end up in the 848 browser history as a result of a redirect from a provider's 849 authorization endpoint. 851 Countermeasures: 853 * Clients MUST NOT pass access tokens in a URI query parameter in 854 the way described in Section 2.3 of [RFC6750]. The authorization 855 code grant or alternative OAuth response modes like the form post 856 response mode [oauth-v2-form-post-response-mode] can be used to 857 this end. 859 4.4. Mix-Up Attacks 861 Mix-up is an attack on scenarios where an OAuth client interacts with 862 two or more authorization servers and at least one authorization 863 server is under the control of the attacker. This can be the case, 864 for example, if the attacker uses dynamic registration to register 865 the client at his own authorization server or if an authorization 866 server becomes compromised. 868 The goal of the attack is to obtain an authorization code or an 869 access token for an uncompromised authorization server. This is 870 achieved by tricking the client into sending those credentials to the 871 compromised authorization server (the attacker) instead of using them 872 at the respective endpoint of the uncompromised authorization/ 873 resource server. 875 4.4.1. Attack Description 877 The description here follows [arXiv.1601.01229], with variants of the 878 attack outlined below. 880 Preconditions: For this variant of the attack to work, we assume that 882 * the implicit or authorization code grant are used with multiple AS 883 of which one is considered "honest" (H-AS) and one is operated by 884 the attacker (A-AS), and 886 * the client stores the AS chosen by the user in a session bound to 887 the user's browser and uses the same redirection endpoint URI for 888 each AS. 890 In the following, we assume that the client is registered with H-AS 891 (URI: https://honest.as.example, client ID: 7ZGZldHQ) and with A-AS 892 (URI: https://attacker.example, client ID: 666RVZJTA). URLs shown in 893 the following example are shorted for presentation to only include 894 parameters relevant for the attack. 896 Attack on the authorization code grant: 898 1. The user selects to start the grant using A-AS (e.g., by clicking 899 on a button at the client's website). 901 2. The client stores in the user's session that the user selected 902 "A-AS" and redirects the user to A-AS's authorization endpoint 903 with a Location header containing the URL 904 https://attacker.example/ 905 authorize?response_type=code&client_id=666RVZJTA. 907 3. When the user's browser navigates to the attacker's authorization 908 endpoint, the attacker immediately redirects the browser to the 909 authorization endpoint of H-AS. In the authorization request, 910 the attacker replaces the client ID of the client at A-AS with 911 the client's ID at H-AS. Therefore, the browser receives a 912 redirection (303 See Other) with a Location header pointing to 913 https://honest.as.example/ 914 authorize?response_type=code&client_id=7ZGZldHQ 916 4. The user authorizes the client to access her resources at H-AS. 917 (Note that a vigilant user might at this point detect that she 918 intended to use A-AS instead of H-AS. The first attack variant 919 listed below avoids this.) H-AS issues a code and sends it (via 920 the browser) back to the client. 922 5. Since the client still assumes that the code was issued by A-AS, 923 it will try to redeem the code at A-AS's token endpoint. 925 6. The attacker therefore obtains code and can either exchange the 926 code for an access token (for public clients) or perform an 927 authorization code injection attack as described in Section 4.5. 929 Variants: 931 * *Mix-Up With Interception*: This variant works only if the 932 attacker can intercept and manipulate the first request/response 933 pair from a user's browser to the client (in which the user 934 selects a certain AS and is then redirected by the client to that 935 AS), as in Attacker A2. This capability can, for example, be the 936 result of a man-in-the-middle attack on the user's connection to 937 the client. In the attack, the user starts the flow with H-AS. 938 The attacker intercepts this request and changes the user's 939 selection to A-AS. The rest of the attack proceeds as in Steps 2 940 and following above. 942 * *Implicit Grant*: In the implicit grant, the attacker receives an 943 access token instead of the code; the rest of the attack works as 944 above. 946 * *Per-AS Redirect URIs*: If clients use different redirect URIs for 947 different ASs, do not store the selected AS in the user's session, 948 and ASs do not check the redirect URIs properly, attackers can 949 mount an attack called "Cross-Social Network Request Forgery". 950 These attacks have been observed in practice. Refer to 951 [oauth_security_jcs_14] for details. 953 * *OpenID Connect*: There are variants that can be used to attack 954 OpenID Connect. In these attacks, the attacker misuses features 955 of the OpenID Connect Discovery [OpenIDDisc] mechanism or replays 956 access tokens or ID Tokens to conduct a mix-up attack. The 957 attacks are described in detail in [arXiv.1704.08539], Appendix A, 958 and [arXiv.1508.04324v2], Section 6 ("Malicious Endpoints 959 Attacks"). 961 4.4.2. Countermeasures 963 When an OAuth client can only interact with one authorization server, 964 a mix-up defense is not required. In scenarios where an OAuth client 965 interacts with two or more authorization servers, however, clients 966 MUST prevent mix-up attacks. Two different methods are discussed in 967 the following. 969 For both defenses, clients MUST store, for each authorization 970 request, the issuer they sent the authorization request to and bind 971 this information to the user agent. The issuer serves, via the 972 associated metadata, as an abstract identifier for the combination of 973 the authorization endpoint and token endpoint that are to be used in 974 the flow. If an issuer identifier is not available, for example, if 975 neither OAuth metadata [RFC8414] nor OpenID Connect Discovery 976 [OpenIDDisc] are used, a different unique identifier for this tuple 977 or the tuple itself can be used instead. For brevity of 978 presentation, such a deployment-specific identifier will be subsumed 979 under the issuer (or issuer identifier) in the following. 981 Note: Just storing the authorization server URL is not sufficient to 982 identify mix-up attacks. An attacker might declare an uncompromised 983 AS's authorization endpoint URL as "his" AS URL, but declare a token 984 endpoint under his own control. 986 4.4.2.1. Mix-Up Defense via Issuer Identification 988 This defense requires that the authorization server sends his issuer 989 identifier in the authorization response to the client. When 990 receiving the authorization response, the client MUST compare the 991 received issuer identifier to the stored issuer identifier. If there 992 is a mismatch, the client MUST abort the interaction. 994 There are different ways this issuer identifier can be transported to 995 the client: 997 * The issuer information can be transported, for example, via a 998 separate response parameter iss, defined in 999 [I-D.ietf-oauth-iss-auth-resp]. 1001 * When OpenID Connect is used and an ID Token is returned in the 1002 authorization response, the client can evaluate the iss Claim in 1003 the ID Token. 1005 In both cases, the iss value MUST be evaluated according to 1006 [I-D.ietf-oauth-iss-auth-resp]. 1008 While this defense may require deploying new OAuth features to 1009 transport the issuer information, it is a robust and relatively 1010 simple defense against mix-up. 1012 4.4.2.2. Mix-Up Defense via Distinct Redirect URIs 1014 For this defense, clients MUST use a distinct redirect URI for each 1015 issuer they interact with. 1017 Clients MUST check that the authorization response was received from 1018 the correct issuer by comparing the distinct redirect URI for the 1019 issuer to the URI where the authorization response was received on. 1020 If there is a mismatch, the client MUST abort the flow. 1022 While this defense builds upon existing OAuth functionality, it 1023 cannot be used in scenarios where clients only register once for the 1024 use of many different issuers (as in some open banking schemes) and 1025 due to the tight integration with the client registration, it is 1026 harder to deploy automatically. 1028 Furthermore, an attacker might be able to circumvent the protection 1029 offered by this defense by registering a new client with the "honest" 1030 AS using the redirect URI that the client assigned to the attacker's 1031 AS. The attacker could then run the attack as described above, 1032 replacing the client ID with the client ID of his newly created 1033 client. 1035 This defense SHOULD therefore only be used if other options are not 1036 available. 1038 4.5. Authorization Code Injection 1040 In an authorization code injection attack, the attacker attempts to 1041 inject a stolen authorization code into the attacker's own session 1042 with the client. The aim is to associate the attacker's session at 1043 the client with the victim's resources or identity. 1045 This attack is useful if the attacker cannot exchange the 1046 authorization code for an access token himself. Examples include: 1048 * The code is bound to a particular confidential client and the 1049 attacker is unable to obtain the required client credentials to 1050 redeem the code himself. 1052 * The attacker wants to access certain functions in this particular 1053 client. As an example, the attacker wants to impersonate his 1054 victim in a certain app or on a certain web site. 1056 * The authorization or resource servers are limited to certain 1057 networks that the attacker is unable to access directly. 1059 In the following attack description and discussion, we assume the 1060 presence of a web (A1) or network attacker (A2). 1062 4.5.1. Attack Description 1064 The attack works as follows: 1066 1. The attacker obtains an authorization code by performing any of 1067 the attacks described above. 1069 2. He starts a regular OAuth authorization process with the 1070 legitimate client from his device. 1072 3. The attacker injects the stolen authorization code in the 1073 response of the authorization server to the legitimate client. 1074 Since this response is passing through the attacker's device, the 1075 attacker can use any tool that can intercept and manipulate the 1076 authorization response to this end. The attacker does not need 1077 to control the network. 1079 4. The legitimate client sends the code to the authorization 1080 server's token endpoint, along with the client's client ID, 1081 client secret and actual redirect_uri. 1083 5. The authorization server checks the client secret, whether the 1084 code was issued to the particular client, and whether the actual 1085 redirect URI matches the redirect_uri parameter (see [RFC6749]). 1087 6. All checks succeed and the authorization server issues access and 1088 other tokens to the client. The attacker has now associated his 1089 session with the legitimate client with the victim's resources 1090 and/or identity. 1092 4.5.2. Discussion 1094 Obviously, the check in step (5.) will fail if the code was issued to 1095 another client ID, e.g., a client set up by the attacker. The check 1096 will also fail if the authorization code was already redeemed by the 1097 legitimate user and was one-time use only. 1099 An attempt to inject a code obtained via a manipulated redirect URI 1100 should also be detected if the authorization server stored the 1101 complete redirect URI used in the authorization request and compares 1102 it with the redirect_uri parameter. 1104 [RFC6749], Section 4.1.3, requires the AS to "... ensure that the 1105 redirect_uri parameter is present if the redirect_uri parameter was 1106 included in the initial authorization request as described in 1107 Section 4.1.1, and if included ensure that their values are 1108 identical.". In the attack scenario described above, the legitimate 1109 client would use the correct redirect URI it always uses for 1110 authorization requests. But this URI would not match the tampered 1111 redirect URI used by the attacker (otherwise, the redirect would not 1112 land at the attackers page). So the authorization server would 1113 detect the attack and refuse to exchange the code. 1115 Note: This check could also detect attempts to inject an 1116 authorization code which had been obtained from another instance of 1117 the same client on another device, if certain conditions are 1118 fulfilled: 1120 * the redirect URI itself needs to contain a nonce or another kind 1121 of one-time use, secret data and 1123 * the client has bound this data to this particular instance of the 1124 client. 1126 But this approach conflicts with the idea to enforce exact redirect 1127 URI matching at the authorization endpoint. Moreover, it has been 1128 observed that providers very often ignore the redirect_uri check 1129 requirement at this stage, maybe because it doesn't seem to be 1130 security-critical from reading the specification. 1132 Other providers just pattern match the redirect_uri parameter against 1133 the registered redirect URI pattern. This saves the authorization 1134 server from storing the link between the actual redirect URI and the 1135 respective authorization code for every transaction. But this kind 1136 of check obviously does not fulfill the intent of the specification, 1137 since the tampered redirect URI is not considered. So any attempt to 1138 inject an authorization code obtained using the client_id of a 1139 legitimate client or by utilizing the legitimate client on another 1140 device will not be detected in the respective deployments. 1142 It is also assumed that the requirements defined in [RFC6749], 1143 Section 4.1.3, increase client implementation complexity as clients 1144 need to store or re-construct the correct redirect URI for the call 1145 to the token endpoint. 1147 This document therefore recommends to instead bind every 1148 authorization code to a certain client instance on a certain device 1149 (or in a certain user agent) in the context of a certain transaction 1150 using one of the mechanisms described next. 1152 4.5.3. Countermeasures 1154 There are two good technical solutions to achieve this goal, outlined 1155 in the following. 1157 4.5.3.1. PKCE 1159 The PKCE parameter code_challenge along with the corresponding 1160 code_verifier as specified in [RFC7636] can be used as a 1161 countermeasure. When the attacker attempts to inject an 1162 authorization code, the verifier check fails: the client uses its 1163 correct verifier, but the code is associated with a challenge that 1164 does not match this verifier. PKCE is a deployed OAuth feature, 1165 although its originally intended use was solely focused on securing 1166 native apps, not the broader use recommended by this document. 1168 4.5.3.2. Nonce 1170 OpenID Connect's existing nonce parameter can be used for the same 1171 purpose. The nonce value is one-time use and created by the client. 1172 The client is supposed to bind it to the user agent session and sends 1173 it with the initial request to the OpenID Provider (OP). The OP 1174 binds nonce to the authorization code and attests this binding in the 1175 ID Token, which is issued as part of the code exchange at the token 1176 endpoint. If an attacker injected an authorization code in the 1177 authorization response, the nonce value in the client session and the 1178 nonce value in the ID token will not match and the attack is 1179 detected. The assumption is that an attacker cannot get hold of the 1180 user agent state on the victim's device, where he has stolen the 1181 respective authorization code. 1183 It is important to note that this countermeasure only works if the 1184 client properly checks the nonce parameter in the ID Token and does 1185 not use any issued token until this check has succeeded. More 1186 precisely, a client protecting itself against code injection using 1187 the nonce parameter, 1189 1. MUST validate the nonce in the ID Token obtained from the token 1190 endpoint, even if another ID Token was obtained from the 1191 authorization response (e.g., response_type=code+id_token), and 1193 2. MUST ensure that, unless and until that check succeeds, all 1194 tokens (ID Tokens and the access token) are disregarded and not 1195 used for any other purpose. 1197 4.5.3.3. Other Solutions 1199 Other solutions, like binding state to the code, using token binding 1200 for the code, or per-instance client credentials are conceivable, but 1201 lack support and bring new security requirements. 1203 PKCE is the most obvious solution for OAuth clients as it is 1204 available today (originally intended for OAuth native apps) whereas 1205 nonce is appropriate for OpenID Connect clients. 1207 4.5.4. Limitations 1209 An attacker can circumvent the countermeasures described above if he 1210 can modify the nonce or code_challenge values that are used in the 1211 victim's authorization request. The attacker can modify these values 1212 to be the same ones as those chosen by the client in his own session 1213 in Step 2 of the attack above. (This requires that the victim's 1214 session with the client begins after the attacker started his session 1215 with the client.) If the attacker is then able to capture the 1216 authorization code from the victim, the attacker will be able to 1217 inject the stolen code in Step 3 even if PKCE or nonce are used. 1219 This attack is complex and requires a close interaction between the 1220 attacker and the victim's session. Nonetheless, measures to prevent 1221 attackers from reading the contents of the authorization response 1222 still need to be taken, as described in Section 4.1, Section 4.2, 1223 Section 4.3, Section 4.4, and Section 4.10. 1225 4.6. Access Token Injection 1227 In an access token injection attack, the attacker attempts to inject 1228 a stolen access token into a legitimate client (that is not under the 1229 attacker's control). This will typically happen if the attacker 1230 wants to utilize a leaked access token to impersonate a user in a 1231 certain client. 1233 To conduct the attack, the attacker starts an OAuth flow with the 1234 client using the implicit grant and modifies the authorization 1235 response by replacing the access token issued by the authorization 1236 server or directly makes up an authorization server response 1237 including the leaked access token. Since the response includes the 1238 state value generated by the client for this particular transaction, 1239 the client does not treat the response as a CSRF attack and uses the 1240 access token injected by the attacker. 1242 4.6.1. Countermeasures 1244 There is no way to detect such an injection attack on the OAuth 1245 protocol level, since the token is issued without any binding to the 1246 transaction or the particular user agent. 1248 The recommendation is therefore to use the authorization code grant 1249 type instead of relying on response types issuing acess tokens at the 1250 authorization endpoint. Authorization code injection can be detected 1251 using one of the countermeasures discussed in Section 4.5. 1253 4.7. Cross Site Request Forgery 1255 An attacker might attempt to inject a request to the redirect URI of 1256 the legitimate client on the victim's device, e.g., to cause the 1257 client to access resources under the attacker's control. This is a 1258 variant of an attack known as Cross-Site Request Forgery (CSRF). 1260 4.7.1. Countermeasures 1262 The traditional countermeasure are CSRF tokens that are bound to the 1263 user agent and passed in the state parameter to the authorization 1264 server as described in [RFC6819]. The same protection is provided by 1265 PKCE or the OpenID Connect nonce value. 1267 When using PKCE instead of state or nonce for CSRF protection, it is 1268 important to note that: 1270 * Clients MUST ensure that the AS supports PKCE before using PKCE 1271 for CSRF protection. If an authorization server does not support 1272 PKCE, state or nonce MUST be used for CSRF protection. 1274 * If state is used for carrying application state, and integrity of 1275 its contents is a concern, clients MUST protect state against 1276 tampering and swapping. This can be achieved by binding the 1277 contents of state to the browser session and/or signed/encrypted 1278 state values [I-D.bradley-oauth-jwt-encoded-state]. 1280 AS therefore MUST provide a way to detect their support for PKCE. 1281 Using AS metadata according to [RFC8414] is RECOMMENDED, but AS MAY 1282 instead provide a deployment-specific way to ensure or determine PKCE 1283 support. 1285 4.8. PKCE Downgrade Attack 1287 An authorization server that supports PKCE but does not make its use 1288 mandatory for all flows can be susceptible to a PKCE downgrade 1289 attack. 1291 The first prerequisite for this attack is that there is an attacker- 1292 controllable flag in the authorization request that enables or 1293 disables PKCE for the particular flow. The presence or absence of 1294 the code_challenge parameter lends itself for this purpose, i.e., the 1295 AS enables and enforces PKCE if this parameter is present in the 1296 authorization request, but does not enforce PKCE if the parameter is 1297 missing. 1299 The second prerequisite for this attack is that the client is not 1300 using state at all (e.g., because the client relies on PKCE for CSRF 1301 prevention) or that the client is not checking state correctly. 1303 Roughly speaking, this attack is a variant of a CSRF attack. The 1304 attacker achieves the same goal as in the attack described in 1305 Section 4.7: He injects an authorization code (and with that, an 1306 access token) that is bound to his resources into a session between 1307 his victim and the client. 1309 4.8.1. Attack Description 1311 1. The user has started an OAuth session using some client at an AS. 1312 In the authorization request, the client has set the parameter 1313 code_challenge=sha256(abc) as the PKCE code challenge. The 1314 client is now waiting to receive the authorization response from 1315 the user's browse. 1317 2. To conduct the attack, the attacker uses his own device to start 1318 an authorization flow with the targeted client. The client now 1319 uses another PKCE code challenge, say code_challenge=sha256(xyz), 1320 in the authorization request. The attacker intercepts the 1321 request and removes the entire code_challenge parameter from the 1322 request. Since this step is performed on the attacker's device, 1323 the attacker has full access to the request contents, for example 1324 using browser debug tools. 1326 3. If the authorization server allows for flows without PKCE, it 1327 will create a code that is not bound to any PKCE code challenge. 1329 4. The attacker now redirects the user's browser to an authorization 1330 response URL which contains the code for the attacker's session 1331 with the AS. 1333 5. The user's browser sends the authorization code to the client, 1334 which will now try to redeem the code for an access token at the 1335 AS. The client will send code_verifier=abc as the PKCE code 1336 verifier in the token request. 1338 6. Since the authorization server sees that this code is not bound 1339 to any PKCE code challenge, it will not check the presence or 1340 contents of the code_verifier parameter. It will issue an access 1341 token that belongs to the attacker's resource to the client under 1342 the user's control. 1344 4.8.2. Countermeasures 1346 Using state properly would prevent this attack. However, practice 1347 has shown that many OAuth clients do not use or check state properly. 1349 Therefore, AS MUST take precautions against this threat. 1351 Note that from the view of the AS, in the attack described above, a 1352 code_verifier parameter is received at the token endpoint although no 1353 code_challenge parameter was present in the authorization request for 1354 the OAuth flow in which the authorization code was issued. 1356 This fact can be used to mitigate this attack. [RFC7636] already 1357 mandates that 1359 * an AS that supports PKCE MUST check whether a code challenge is 1360 contained in the authorization request and bind this information 1361 to the code that is issued; and 1363 * when a code arrives at the token endpoint, and there was a 1364 code_challenge in the authorization request for which this code 1365 was issued, there must be a valid code_verifier in the token 1366 request. 1368 Beyond this, to prevent PKCE downgrade attacks, the AS MUST ensure 1369 that if there was no code_challenge in the authorization request, a 1370 request to the token endpoint containing a code_verifier is rejected. 1372 Note: AS that mandate the use of PKCE in general or for particular 1373 clients implicitly implement this security measure. 1375 4.9. Access Token Leakage at the Resource Server 1377 Access tokens can leak from a resource server under certain 1378 circumstances. 1380 4.9.1. Access Token Phishing by Counterfeit Resource Server 1382 An attacker may setup his own resource server and trick a client into 1383 sending access tokens to it that are valid for other resource servers 1384 (see Attackers A1 and A5). If the client sends a valid access token 1385 to this counterfeit resource server, the attacker in turn may use 1386 that token to access other services on behalf of the resource owner. 1388 This attack assumes the client is not bound to one specific resource 1389 server (and its URL) at development time, but client instances are 1390 provided with the resource server URL at runtime. This kind of late 1391 binding is typical in situations where the client uses a service 1392 implementing a standardized API (e.g., for e-Mail, calendar, health, 1393 or banking) and where the client is configured by a user or 1394 administrator for a service which this user or company uses. 1396 4.9.1.1. Countermeasures 1398 There are several potential mitigation strategies, which will be 1399 discussed in the following sections. 1401 4.9.1.1.1. Metadata 1403 An authorization server could provide the client with additional 1404 information about the location where it is safe to use its access 1405 tokens. 1407 In the simplest form, this would require the AS to publish a list of 1408 its known resource servers, illustrated in the following example 1409 using a non-standard metadata parameter resource_servers: 1411 HTTP/1.1 200 OK 1412 Content-Type: application/json 1414 { 1415 "issuer":"https://server.somesite.example", 1416 "authorization_endpoint": 1417 "https://server.somesite.example/authorize", 1418 "resource_servers":[ 1419 "email.somesite.example", 1420 "storage.somesite.example", 1421 "video.somesite.example" 1422 ] 1423 ... 1424 } 1426 The AS could also return the URL(s) an access token is good for in 1427 the token response, illustrated by the example and non-standard 1428 return parameter access_token_resource_server: 1430 HTTP/1.1 200 OK 1431 Content-Type: application/json;charset=UTF-8 1432 Cache-Control: no-store 1433 Pragma: no-cache 1435 { 1436 "access_token":"2YotnFZFEjr1zCsicMWpAA", 1437 "access_token_resource_server": 1438 "https://hostedresource.somesite.example/path1", 1439 ... 1440 } 1442 This mitigation strategy would rely on the client to enforce the 1443 security policy and to only send access tokens to legitimate 1444 destinations. Results of OAuth related security research (see for 1445 example [oauth_security_ubc] and [oauth_security_cmu]) indicate a 1446 large portion of client implementations do not or fail to properly 1447 implement security controls, like state checks. So relying on 1448 clients to prevent access token phishing is likely to fail as well. 1449 Moreover given the ratio of clients to authorization and resource 1450 servers, it is considered the more viable approach to move as much as 1451 possible security-related logic to those entities. Clearly, the 1452 client has to contribute to the overall security. But there are 1453 alternative countermeasures, as described in the next sections, which 1454 provide a better balance between the involved parties. 1456 4.9.1.1.2. Sender-Constrained Access Tokens 1458 As the name suggests, sender-constrained access token scope the 1459 applicability of an access token to a certain sender. This sender is 1460 obliged to demonstrate knowledge of a certain secret as prerequisite 1461 for the acceptance of that token at a resource server. 1463 A typical flow looks like this: 1465 1. The authorization server associates data with the access token 1466 that binds this particular token to a certain client. The 1467 binding can utilize the client identity, but in most cases the AS 1468 utilizes key material (or data derived from the key material) 1469 known to the client. 1471 2. This key material must be distributed somehow. Either the key 1472 material already exists before the AS creates the binding or the 1473 AS creates ephemeral keys. The way pre-existing key material is 1474 distributed varies among the different approaches. For example, 1475 X.509 Certificates can be used in which case the distribution 1476 happens explicitly during the enrollment process. Or the key 1477 material is created and distributed at the TLS layer, in which 1478 case it might automatically happen during the setup of a TLS 1479 connection. 1481 3. The RS must implement the actual proof of possession check. This 1482 is typically done on the application level, often tied to 1483 specific material provided by transport layer (e.g., TLS). The 1484 RS must also ensure that replay of the proof of possession is not 1485 possible. 1487 There exist several proposals to demonstrate the proof of possession 1488 in the scope of the OAuth working group: 1490 * *OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound 1491 Access Tokens* ([RFC8705]): The approach as specified in this 1492 document allows the use of mutual TLS (mTLS) for both client 1493 authentication and sender-constrained access tokens. For the 1494 purpose of sender-constrained access tokens, the client is 1495 identified towards the resource server by the fingerprint of its 1496 public key. During processing of an access token request, the 1497 authorization server obtains the client's public key from the TLS 1498 stack and associates its fingerprint with the respective access 1499 tokens. The resource server in the same way obtains the public 1500 key from the TLS stack and compares its fingerprint with the 1501 fingerprint associated with the access token. 1503 * *DPoP* ([I-D.ietf-oauth-dpop]): DPoP (Demonstration of Proof-of- 1504 Possession at the Application Layer) outlines an application-level 1505 sender-constraining for access and refresh tokens that can be used 1506 in cases where neither mTLS nor OAuth Token Binding (see below) 1507 are available. It uses proof-of-possession based on a public/ 1508 private key pair and application-level signing. DPoP can be used 1509 with public clients and, in case of confidential clients, can be 1510 combined with any client authentication method. 1512 * *OAuth Token Binding* ([I-D.ietf-oauth-token-binding]): In this 1513 approach, an access token is, via the token binding ID, bound to 1514 key material representing a long term association between a client 1515 and a certain TLS host. Negotiation of the key material and proof 1516 of possession in the context of a TLS handshake is taken care of 1517 by the TLS stack. The client needs to determine the token binding 1518 ID of the target resource server and pass this data to the access 1519 token request. The authorization server then associates the 1520 access token with this ID. The resource server checks on every 1521 invocation that the token binding ID of the active TLS connection 1522 and the token binding ID of associated with the access token 1523 match. Since all crypto-related functions are covered by the TLS 1524 stack, this approach is very client developer friendly. As a 1525 prerequisite, token binding as described in [RFC8473] (including 1526 federated token bindings) must be supported on all ends (client, 1527 authorization server, resource server). 1529 * *Signed HTTP Requests* ([I-D.ietf-oauth-signed-http-request]): 1530 This approach utilizes [I-D.ietf-oauth-pop-key-distribution] and 1531 represents the elements of the signature in a JSON object. The 1532 signature is built using JWS. The mechanism has built-in support 1533 for signing of HTTP method, query parameters and headers. It also 1534 incorporates a timestamp as basis for replay prevention. 1536 * *JWT Pop Tokens* ([I-D.sakimura-oauth-jpop]): This draft describes 1537 different ways to constrain access token usage, namely TLS or 1538 request signing. Note: Since the authors of this draft 1539 contributed the TLS-related proposal to [RFC8705], this document 1540 only considers the request signing part. For request signing, the 1541 draft utilizes [I-D.ietf-oauth-pop-key-distribution] and 1542 [RFC7800]. The signature data is represented in a JWT and JWS is 1543 used for signing. Replay prevention is provided by building the 1544 signature over a server-provided nonce, client-provided nonce and 1545 a nonce counter. 1547 At the time of writing, OAuth Mutual TLS is the most widely 1548 implemented and the only standardized sender-constraining method. 1549 The use of OAuth Mutual TLS therefore is RECOMMENDED. 1551 Note that the security of sender-constrained tokens is undermined 1552 when an attacker gets access to the token and the key material. This 1553 is in particular the case for corrupted client software and cross- 1554 site scripting attacks (when the client is running in the browser). 1555 If the key material is protected in a hardware or software security 1556 module or only indirectly accessible (like in a TLS stack), sender- 1557 constrained tokens at least protect against a use of the token when 1558 the client is offline, i.e., when the security module or interface is 1559 not available to the attacker. This applies to access tokens as well 1560 as to refresh tokens (see Section 4.13). 1562 4.9.1.1.3. Audience Restricted Access Tokens 1564 Audience restriction essentially restricts access tokens to a 1565 particular resource server. The authorization server associates the 1566 access token with the particular resource server and the resource 1567 server SHOULD verify the intended audience. If the access token 1568 fails the intended audience validation, the resource server must 1569 refuse to serve the respective request. 1571 In general, audience restrictions limit the impact of token leakage. 1572 In the case of a counterfeit resource server, it may (as described 1573 below) also prevent abuse of the phished access token at the 1574 legitimate resource server. 1576 The audience can be expressed using logical names or physical 1577 addresses (like URLs). In order to prevent phishing, it is necessary 1578 to use the actual URL the client will send requests to. In the 1579 phishing case, this URL will point to the counterfeit resource 1580 server. If the attacker tries to use the access token at the 1581 legitimate resource server (which has a different URL), the resource 1582 server will detect the mismatch (wrong audience) and refuse to serve 1583 the request. 1585 In deployments where the authorization server knows the URLs of all 1586 resource servers, the authorization server may just refuse to issue 1587 access tokens for unknown resource server URLs. 1589 The client SHOULD tell the authorization server the intended resource 1590 server. The proposed mechanism [I-D.ietf-oauth-resource-indicators] 1591 could be used or by encoding the information in the scope value. 1593 Instead of the URL, it is also possible to utilize the fingerprint of 1594 the resource server's X.509 certificate as audience value. This 1595 variant would also allow to detect an attempt to spoof the legitimate 1596 resource server's URL by using a valid TLS certificate obtained from 1597 a different CA. It might also be considered a privacy benefit to 1598 hide the resource server URL from the authorization server. 1600 Audience restriction may seem easier to use since it does not require 1601 any crypto on the client-side. Still, since every access token is 1602 bound to a specific resource server, the client also needs to obtain 1603 a single RS-specific access token when accessing several resource 1604 servers. (Resource indicators, as specified in 1605 [I-D.ietf-oauth-resource-indicators], can help to achieve this.) 1606 [I-D.ietf-oauth-token-binding] has the same property since different 1607 token binding ids must be associated with the access token. Using 1608 [RFC8705], on the other hand, allows a client to use the access token 1609 at multiple resource servers. 1611 It shall be noted that audience restrictions, or generally speaking 1612 an indication by the client to the authorization server where it 1613 wants to use the access token, has additional benefits beyond the 1614 scope of token leakage prevention. It allows the authorization 1615 server to create different access token whose format and content is 1616 specifically minted for the respective server. This has huge 1617 functional and privacy advantages in deployments using structured 1618 access tokens. 1620 4.9.2. Compromised Resource Server 1622 An attacker may compromise a resource server to gain access to the 1623 resources of the respective deployment. Such a compromise may range 1624 from partial access to the system, e.g., its log files, to full 1625 control of the respective server. 1627 If the attacker were able to gain full control, including shell 1628 access, all controls can be circumvented and all resources be 1629 accessed. The attacker would also be able to obtain other access 1630 tokens held on the compromised system that would potentially be valid 1631 to access other resource servers. 1633 Preventing server breaches by hardening and monitoring server systems 1634 is considered a standard operational procedure and, therefore, out of 1635 the scope of this document. This section focuses on the impact of 1636 OAuth-related breaches and the replaying of captured access tokens. 1638 The following measures should be taken into account by implementers 1639 in order to cope with access token replay by malicious actors: 1641 * Sender-constrained access tokens as described in Section 4.9.1.1.2 1642 SHOULD be used to prevent the attacker from replaying the access 1643 tokens on other resource servers. Depending on the severity of 1644 the penetration, sender-constrained access tokens will also 1645 prevent replay on the compromised system. 1647 * Audience restriction as described in Section 4.9.1.1.3 SHOULD be 1648 used to prevent replay of captured access tokens on other resource 1649 servers. 1651 * The resource server MUST treat access tokens like any other 1652 credentials. It is considered good practice to not log them and 1653 not store them in plain text. 1655 The first and second recommendation also apply to other scenarios 1656 where access tokens leak (see Attacker A5). 1658 4.10. Open Redirection 1660 The following attacks can occur when an AS or client has an open 1661 redirector. An open redirector is an endpoint that forwards a user's 1662 browser to an arbitrary URI obtained from a query parameter. 1664 4.10.1. Client as Open Redirector 1666 Clients MUST NOT expose open redirectors. Attackers may use open 1667 redirectors to produce URLs pointing to the client and utilize them 1668 to exfiltrate authorization codes and access tokens, as described in 1669 Section 4.1.2. Another abuse case is to produce URLs that appear to 1670 point to the client. This might trick users into trusting the URL 1671 and follow it in their browser. This can be abused for phishing. 1673 In order to prevent open redirection, clients should only redirect if 1674 the target URLs are whitelisted or if the origin and integrity of a 1675 request can be authenticated. Countermeasures against open 1676 redirection are described by OWASP [owasp_redir]. 1678 4.10.2. Authorization Server as Open Redirector 1680 Just as with clients, attackers could try to utilize a user's trust 1681 in the authorization server (and its URL in particular) for 1682 performing phishing attacks. OAuth authorization servers regularly 1683 redirect users to other web sites (the clients), but must do so in a 1684 safe way. 1686 [RFC6749], Section 4.1.2.1, already prevents open redirects by 1687 stating that the AS MUST NOT automatically redirect the user agent in 1688 case of an invalid combination of client_id and redirect_uri. 1690 However, an attacker could also utilize a correctly registered 1691 redirect URI to perform phishing attacks. The attacker could, for 1692 example, register a client via dynamic client registration [RFC7591] 1693 and intentionally send an erroneous authorization request, e.g., by 1694 using an invalid scope value, thus instructing the AS to redirect the 1695 user agent to its phishing site. 1697 The AS MUST take precautions to prevent this threat. Based on its 1698 risk assessment, the AS needs to decide whether it can trust the 1699 redirect URI and SHOULD only automatically redirect the user agent if 1700 it trusts the redirect URI. If the URI is not trusted, the AS MAY 1701 inform the user and rely on the user to make the correct decision. 1703 4.11. 307 Redirect 1705 At the authorization endpoint, a typical protocol flow is that the AS 1706 prompts the user to enter her credentials in a form that is then 1707 submitted (using the HTTP POST method) back to the authorization 1708 server. The AS checks the credentials and, if successful, redirects 1709 the user agent to the client's redirection endpoint. 1711 In [RFC6749], the HTTP status code 302 is used for this purpose, but 1712 "any other method available via the user-agent to accomplish this 1713 redirection is allowed". When the status code 307 is used for 1714 redirection instead, the user agent will send the user credentials 1715 via HTTP POST to the client. 1717 This discloses the sensitive credentials to the client. If the 1718 relying party is malicious, it can use the credentials to impersonate 1719 the user at the AS. 1721 The behavior might be unexpected for developers, but is defined in 1722 [RFC7231], Section 6.4.7. This status code does not require the user 1723 agent to rewrite the POST request to a GET request and thereby drop 1724 the form data in the POST request body. 1726 In the HTTP standard [RFC7231], only the status code 303 1727 unambigiously enforces rewriting the HTTP POST request to an HTTP GET 1728 request. For all other status codes, including the popular 302, user 1729 agents can opt not to rewrite POST to GET requests and therefore to 1730 reveal the user credentials to the client. (In practice, however, 1731 most user agents will only show this behaviour for 307 redirects.) 1733 AS which redirect a request that potentially contains user 1734 credentials therefore MUST NOT use the HTTP 307 status code for 1735 redirection. If an HTTP redirection (and not, for example, 1736 JavaScript) is used for such a request, AS SHOULD use HTTP status 1737 code 303 "See Other". 1739 4.12. TLS Terminating Reverse Proxies 1741 A common deployment architecture for HTTP applications is to hide the 1742 application server behind a reverse proxy that terminates the TLS 1743 connection and dispatches the incoming requests to the respective 1744 application server nodes. 1746 This section highlights some attack angles of this deployment 1747 architecture with relevance to OAuth and gives recommendations for 1748 security controls. 1750 In some situations, the reverse proxy needs to pass security-related 1751 data to the upstream application servers for further processing. 1752 Examples include the IP address of the request originator, token 1753 binding ids, and authenticated TLS client certificates. This data is 1754 usually passed in custom HTTP headers added to the upstream request. 1756 If the reverse proxy would pass through any header sent from the 1757 outside, an attacker could try to directly send the faked header 1758 values through the proxy to the application server in order to 1759 circumvent security controls that way. For example, it is standard 1760 practice of reverse proxies to accept X-Forwarded-For headers and 1761 just add the origin of the inbound request (making it a list). 1762 Depending on the logic performed in the application server, the 1763 attacker could simply add a whitelisted IP address to the header and 1764 render a IP whitelist useless. 1766 A reverse proxy must therefore sanitize any inbound requests to 1767 ensure the authenticity and integrity of all header values relevant 1768 for the security of the application servers. 1770 If an attacker was able to get access to the internal network between 1771 proxy and application server, the attacker could also try to 1772 circumvent security controls in place. It is, therefore, essential 1773 to ensure the authenticity of the communicating entities. 1774 Furthermore, the communication link between reverse proxy and 1775 application server must be protected against eavesdropping, 1776 injection, and replay of messages. 1778 4.13. Refresh Token Protection 1780 Refresh tokens are a convenient and user-friendly way to obtain new 1781 access tokens after the expiration of access tokens. Refresh tokens 1782 also add to the security of OAuth since they allow the authorization 1783 server to issue access tokens with a short lifetime and reduced scope 1784 thus reducing the potential impact of access token leakage. 1786 4.13.1. Discussion 1788 Refresh tokens are an attractive target for attackers since they 1789 represent the overall grant a resource owner delegated to a certain 1790 client. If an attacker is able to exfiltrate and successfully replay 1791 a refresh token, the attacker will be able to mint access tokens and 1792 use them to access resource servers on behalf of the resource owner. 1794 [RFC6749] already provides a robust baseline protection by requiring 1796 * confidentiality of the refresh tokens in transit and storage, 1798 * the transmission of refresh tokens over TLS-protected connections 1799 between authorization server and client, 1801 * the authorization server to maintain and check the binding of a 1802 refresh token to a certain client and authentication of this 1803 client during token refresh, if possible, and 1805 * that refresh tokens cannot be generated, modified, or guessed. 1807 [RFC6749] also lays the foundation for further (implementation 1808 specific) security measures, such as refresh token expiration and 1809 revocation as well as refresh token rotation by defining respective 1810 error codes and response behavior. 1812 This specification gives recommendations beyond the scope of 1813 [RFC6749] and clarifications. 1815 4.13.2. Recommendations 1817 Authorization servers SHOULD determine, based on a risk assessment, 1818 whether to issue refresh tokens to a certain client. If the 1819 authorization server decides not to issue refresh tokens, the client 1820 MAY refresh access tokens by utilizing other grant types, such as the 1821 authorization code grant type. In such a case, the authorization 1822 server may utilize cookies and persistent grants to optimize the user 1823 experience. 1825 If refresh tokens are issued, those refresh tokens MUST be bound to 1826 the scope and resource servers as consented by the resource owner. 1827 This is to prevent privilege escalation by the legitimate client and 1828 reduce the impact of refresh token leakage. 1830 For confidential clients, [RFC6749] already requires that refresh 1831 tokens can only be used by the client for which they were issued. 1833 Authorization server MUST utilize one of these methods to detect 1834 refresh token replay by malicious actors for public clients: 1836 * *Sender-constrained refresh tokens:* the authorization server 1837 cryptographically binds the refresh token to a certain client 1838 instance by utilizing [RFC8705] or [I-D.ietf-oauth-token-binding]. 1840 * *Refresh token rotation:* the authorization server issues a new 1841 refresh token with every access token refresh response. The 1842 previous refresh token is invalidated but information about the 1843 relationship is retained by the authorization server. If a 1844 refresh token is compromised and subsequently used by both the 1845 attacker and the legitimate client, one of them will present an 1846 invalidated refresh token, which will inform the authorization 1847 server of the breach. The authorization server cannot determine 1848 which party submitted the invalid refresh token, but it will 1849 revoke the active refresh token. This stops the attack at the 1850 cost of forcing the legitimate client to obtain a fresh 1851 authorization grant. 1853 Implementation note: the grant to which a refresh token belongs 1854 may be encoded into the refresh token itself. This can enable an 1855 authorization server to efficiently determine the grant to which a 1856 refresh token belongs, and by extension, all refresh tokens that 1857 need to be revoked. Authorization servers MUST ensure the 1858 integrity of the refresh token value in this case, for example, 1859 using signatures. 1861 Authorization servers MAY revoke refresh tokens automatically in case 1862 of a security event, such as: 1864 * password change 1866 * logout at the authorization server 1868 Refresh tokens SHOULD expire if the client has been inactive for some 1869 time, i.e., the refresh token has not been used to obtain fresh 1870 access tokens for some time. The expiration time is at the 1871 discretion of the authorization server. It might be a global value 1872 or determined based on the client policy or the grant associated with 1873 the refresh token (and its sensitivity). 1875 4.14. Client Impersonating Resource Owner 1877 Resource servers may make access control decisions based on the 1878 identity of the resource owner as communicated in the sub Claim 1879 returned by the authorization server in a token introspection 1880 response [RFC7662] or other mechanisms. If a client is able to 1881 choose its own client_id during registration with the authorization 1882 server, then there is a risk that it can register with the same sub 1883 value as a privileged user. A subsequent access token obtained under 1884 the client credentials grant may be mistaken for an access token 1885 authorized by the privileged user if the resource server does not 1886 perform additional checks. 1888 4.14.1. Countermeasures 1890 Authorization servers SHOULD NOT allow clients to influence their 1891 client_id or sub value or any other Claim if that can cause confusion 1892 with a genuine resource owner. Where this cannot be avoided, 1893 authorization servers MUST provide other means for the resource 1894 server to distinguish between access tokens authorized by a resource 1895 owner from access tokens authorized by the client itself. 1897 4.15. Clickjacking 1899 As described in Section 4.4.1.9 of [RFC6819], the authorization 1900 request is susceptible to clickjacking. An attacker can use this 1901 vector to obtain the user's authentication credentials, change the 1902 scope of access granted to the client, and potentially access the 1903 user's resources. 1905 Authorization servers MUST prevent clickjacking attacks. Multiple 1906 countermeasures are described in [RFC6819], including the use of the 1907 X-Frame-Options HTTP response header field and frame-busting 1908 JavaScript. In addition to those, authorization servers SHOULD also 1909 use Content Security Policy (CSP) level 2 [CSP-2] or greater. 1911 To be effective, CSP must be used on the authorization endpoint and, 1912 if applicable, other endpoints used to authenticate the user and 1913 authorize the client (e.g., the device authorization endpoint, login 1914 pages, error pages, etc.). This prevents framing by unauthorized 1915 origins in user agents that support CSP. The client MAY permit being 1916 framed by some other origin than the one used in its redirection 1917 endpoint. For this reason, authorization servers SHOULD allow 1918 administrators to configure allowed origins for particular clients 1919 and/or for clients to register these dynamically. 1921 Using CSP allows authorization servers to specify multiple origins in 1922 a single response header field and to constrain these using flexible 1923 patterns (see [CSP-2] for details). Level 2 of this standard 1924 provides a robust mechanism for protecting against clickjacking by 1925 using policies that restrict the origin of frames (using frame- 1926 ancestors) together with those that restrict the sources of scripts 1927 allowed to execute on an HTML page (by using script-src). A non- 1928 normative example of such a policy is shown in the following listing: 1930 HTTP/1.1 200 OK 1931 Content-Security-Policy: frame-ancestors https://ext.example.org:8000 1932 Content-Security-Policy: script-src 'self' 1933 X-Frame-Options: ALLOW-FROM https://ext.example.org:8000 1934 ... 1936 Because some user agents do not support [CSP-2], this technique 1937 SHOULD be combined with others, including those described in 1938 [RFC6819], unless such legacy user agents are explicitly unsupported 1939 by the authorization server. Even in such cases, additional 1940 countermeasures SHOULD still be employed. 1942 5. Acknowledgements 1944 We would like to thank Jim Manico, Phil Hunt, Nat Sakimura, Christian 1945 Mainka, Doug McDorman, Johan Peeters, Joseph Heenan, Brock Allen, 1946 Vittorio Bertocci, David Waite, Nov Matake, Tomek Stojecki, Dominick 1947 Baier, Neil Madden, William Dennis, Dick Hardt, Petteri Stenius, 1948 Annabelle Richard Backman, Aaron Parecki, George Fletscher, Brian 1949 Campbell, Konstantin Lapine, Tim Würtele, Guido Schmitz, Hans 1950 Zandbelt, Jared Jennings, Michael Peck, Pedram Hosseyni, Michael B. 1951 Jones, Travis Spencer, and Karsten Meyer zu Selhausen for their 1952 valuable feedback. 1954 6. IANA Considerations 1956 This draft includes no request to IANA. 1958 7. Security Considerations 1960 All relevant security considerations have been given in the 1961 functional specification. 1963 8. Normative References 1965 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1966 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1967 . 1969 [oauth-v2-form-post-response-mode] 1970 Jones, M. and B. Campbell, "OAuth 2.0 Form Post Response 1971 Mode", 27 April 2015, . 1974 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1975 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 1976 DOI 10.17487/RFC7231, June 2014, 1977 . 1979 [OpenIDDisc] 1980 Sakimura, N., Bradley, J., Jones, M., and E. Jay, "OpenID 1981 Connect Discovery 1.0 incorporating errata set 1", 8 1982 November 2014, . 1985 [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", 1986 RFC 7662, DOI 10.17487/RFC7662, October 2015, 1987 . 1989 [RFC8252] Denniss, W. and J. Bradley, "OAuth 2.0 for Native Apps", 1990 BCP 212, RFC 8252, DOI 10.17487/RFC8252, October 2017, 1991 . 1993 [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization 1994 Framework: Bearer Token Usage", RFC 6750, 1995 DOI 10.17487/RFC6750, October 2012, 1996 . 1998 [RFC6819] Lodderstedt, T., Ed., McGloin, M., and P. Hunt, "OAuth 2.0 1999 Threat Model and Security Considerations", RFC 6819, 2000 DOI 10.17487/RFC6819, January 2013, 2001 . 2003 [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. 2004 Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication 2005 and Certificate-Bound Access Tokens", February 2020, 2006 . 2008 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2009 Resource Identifier (URI): Generic Syntax", STD 66, 2010 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2011 . 2013 [OpenID] Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and 2014 C. Mortimore, "OpenID Connect Core 1.0 incorporating 2015 errata set 1", 8 November 2014, 2016 . 2018 [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 2019 Authorization Server Metadata", RFC 8414, 2020 DOI 10.17487/RFC8414, June 2018, 2021 . 2023 9. Informative References 2025 [arXiv.1601.01229] 2026 Fett, D., Küsters, R., and G. Schmitz, "A Comprehensive 2027 Formal Security Analysis of OAuth 2.0", 6 January 2016, 2028 . 2030 [I-D.ietf-oauth-dpop] 2031 Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., 2032 Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof- 2033 of-Possession at the Application Layer (DPoP)", Work in 2034 Progress, Internet-Draft, draft-ietf-oauth-dpop-04, 4 2035 October 2021, . 2038 [CSP-2] West, M., Barth, A., and D. Veditz, "Content Security 2039 Policy Level 2", July 2015, . 2041 [I-D.ietf-oauth-rar] 2042 Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 2043 Rich Authorization Requests", Work in Progress, Internet- 2044 Draft, draft-ietf-oauth-rar-08, 18 October 2021, 2045 . 2048 [I-D.ietf-oauth-signed-http-request] 2049 Richer, J., Bradley, J., and H. Tschofenig, "A Method for 2050 Signing HTTP Requests for OAuth", Work in Progress, 2051 Internet-Draft, draft-ietf-oauth-signed-http-request-03, 8 2052 August 2016, . 2055 [bug.chromium] 2056 "Referer header includes URL fragment when opening link 2057 using New Tab", 2058 . 2061 [webappsec-referrer-policy] 2062 Eisinger, J. and E. Stark, "Referrer Policy", 20 April 2063 2017, . 2065 [I-D.bradley-oauth-jwt-encoded-state] 2066 Bradley, J., Lodderstedt, D. T., and H. Zandbelt, 2067 "Encoding claims in the OAuth 2 state parameter using a 2068 JWT", Work in Progress, Internet-Draft, draft-bradley- 2069 oauth-jwt-encoded-state-09, 4 November 2018, 2070 . 2073 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2074 Requirement Levels", BCP 14, RFC 2119, 2075 DOI 10.17487/RFC2119, March 1997, 2076 . 2078 [webcrypto] 2079 Watson, M., "Web Cryptography API", 26 January 2017, 2080 . 2082 [oauth_security_jcs_14] 2083 Bansal, C., Bhargavan, K., Delignat-Lavaud, A., and S. 2084 Maffeis, "Discovering concrete attacks on website 2085 authorization by formal analysis", 23 April 2014, 2086 . 2088 [owasp_redir] 2089 "OWASP Cheat Sheet Series - Unvalidated Redirects and 2090 Forwards", 2091 . 2094 [RFC7591] Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and 2095 P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol", 2096 RFC 7591, DOI 10.17487/RFC7591, July 2015, 2097 . 2099 [arXiv.1901.11520] 2100 Fett, D., Hosseyni, P., and R. Küsters, "An Extensive 2101 Formal Security Analysis of the OpenID Financial-grade 2102 API", 31 January 2019, . 2104 [I-D.ietf-oauth-par] 2105 Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D., 2106 and F. Skokan, "OAuth 2.0 Pushed Authorization Requests", 2107 Work in Progress, Internet-Draft, draft-ietf-oauth-par-10, 2108 29 July 2021, . 2111 [arXiv.1704.08539] 2112 Fett, D., Küsters, R., and G. Schmitz, "The Web SSO 2113 Standard OpenID Connect: In-Depth Formal Security Analysis 2114 and Security Guidelines", 27 April 2017, 2115 . 2117 [arXiv.1508.04324v2] 2118 Mladenov, V., Mainka, C., and J. Schwenk, "On the security 2119 of modern Single Sign-On Protocols: Second-Order 2120 Vulnerabilities in OpenID Connect", 7 January 2016, 2121 . 2123 [webauthn] Balfanz, D., Czeskis, A., Hodges, J., Jones, J.C., Jones, 2124 M.B., Kumar, A., Liao, A., Lindemann, R., and E. Lundberg, 2125 "Web Authentication: An API for accessing Public Key 2126 Credentials Level 1", 4 March 2019, 2127 . 2129 [RFC8473] Popov, A., Nystroem, M., Balfanz, D., Ed., Harper, N., and 2130 J. Hodges, "Token Binding over HTTP", RFC 8473, 2131 DOI 10.17487/RFC8473, October 2018, 2132 . 2134 [I-D.ietf-oauth-pop-key-distribution] 2135 Bradley, J., Hunt, P., Jones, M. B., Tschofenig, H., and 2136 M. Meszaros, "OAuth 2.0 Proof-of-Possession: Authorization 2137 Server to Client Key Distribution", Work in Progress, 2138 Internet-Draft, draft-ietf-oauth-pop-key-distribution-07, 2139 27 March 2019, . 2142 [I-D.ietf-oauth-jwsreq] 2143 Sakimura, N., Bradley, J., and M. B. Jones, "The OAuth 2.0 2144 Authorization Framework: JWT-Secured Authorization Request 2145 (JAR)", Work in Progress, Internet-Draft, draft-ietf- 2146 oauth-jwsreq-34, 8 April 2021, 2147 . 2150 [oauth_security_ubc] 2151 Sun, S.-T. and K. Beznosov, "The Devil is in the 2152 (Implementation) Details: An Empirical Analysis of OAuth 2153 SSO Systems", October 2012, 2154 . 2156 [oauth_security_cmu] 2157 Chen, E., Pei, Y., Chen, S., Tian, Y., Kotcher, R., and P. 2158 Tague, "OAuth Demystified for Mobile Application 2159 Developers", November 2014, 2160 . 2163 [RFC7636] Sakimura, N., Ed., Bradley, J., and N. Agarwal, "Proof Key 2164 for Code Exchange by OAuth Public Clients", RFC 7636, 2165 DOI 10.17487/RFC7636, September 2015, 2166 . 2168 [I-D.ietf-oauth-resource-indicators] 2169 Campbell, B., Bradley, J., and H. Tschofenig, "Resource 2170 Indicators for OAuth 2.0", Work in Progress, Internet- 2171 Draft, draft-ietf-oauth-resource-indicators-08, 11 2172 September 2019, . 2175 [I-D.ietf-oauth-token-binding] 2176 Jones, M. B., Campbell, B., Bradley, J., and W. Denniss, 2177 "OAuth 2.0 Token Binding", Work in Progress, Internet- 2178 Draft, draft-ietf-oauth-token-binding-08, 19 October 2018, 2179 . 2182 [I-D.sakimura-oauth-jpop] 2183 Sakimura, N., Li, K., and J. Bradley, "The OAuth 2.0 2184 Authorization Framework: JWT Pop Token Usage", Work in 2185 Progress, Internet-Draft, draft-sakimura-oauth-jpop-05, 22 2186 July 2019, . 2189 [subdomaintakeover] 2190 Liu, D., Hao, S., and H. Wang, "All Your DNS Records Point 2191 to Us: Understanding the Security Threats of Dangling DNS 2192 Records", 24 October 2016, 2193 . 2195 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 2196 Possession Key Semantics for JSON Web Tokens (JWTs)", 2197 RFC 7800, DOI 10.17487/RFC7800, April 2016, 2198 . 2200 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2201 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2202 May 2017, . 2204 [I-D.ietf-oauth-iss-auth-resp] 2205 Selhausen, K. M. Z. and D. Fett, "OAuth 2.0 Authorization 2206 Server Issuer Identification", Work in Progress, Internet- 2207 Draft, draft-ietf-oauth-iss-auth-resp-04, 2 December 2021, 2208 . 2211 [JARM] Lodderstedt, T. and B. Campbell, "Financial-grade API: JWT 2212 Secured Authorization Response Mode for OAuth 2.0 (JARM)", 2213 17 October 2018, 2214 . 2216 Appendix A. Document History 2218 [[ To be removed from the final specification ]] 2220 -19 2222 * Changed affiliation of Andrey Labunets 2224 * Editorial change to clarify the new recommendations for refresh 2225 tokens 2227 -18 2229 * Fix editorial and spelling issues. 2231 * Change wording for disallowing HTTP redirect URIs. 2233 -17 2235 * Make the use of metadata RECOMMENDED for both servers and clients 2237 * Make announcing PKCE support in metadata the RECOMMENDED way 2238 (before: either metadata or deployment-specific way) 2240 * AS also MUST NOT expose open redirectors. 2242 * Mention that attackers can collaborate. 2244 * Update recommendations regarding mix-up defense, building upon 2245 [I-D.ietf-oauth-iss-auth-resp]. 2247 * Improve description of mix-up attack. 2249 * Make HTTPS mandatory for most redirect URIs. 2251 -16 2253 * Make MTLS a suggestion, not RECOMMENDED. 2255 * Add important requirements when using nonce for code injection 2256 protection. 2258 * Highlight requirements for refresh token sender-constraining. 2260 * Make PKCE a MUST for public clients. 2262 * Describe PKCE Downgrade Attacks and countermeasures. 2264 * Allow variable port numbers in localhost redirect URIs as in 2265 RFC8252, Section 7.3. 2267 -15 2269 * Update reference to DPoP 2271 * Fix reference to RFC8414 2273 * Move to xml2rfcv3 2275 -14 2277 * Added info about using CSP to prevent clickjacking 2279 * Changes from WGLC feedback 2281 * Editorial changes 2283 * AS MUST announce PKCE support either in metadata or using 2284 deployment-specific ways (before: SHOULD) 2286 -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 2303 -12 2305 * Added updated attacker model 2307 -11 2309 * Adapted section 2.1.2 to outcome of consensus call 2311 * more text on refresh token inactivity and implementation note on 2312 refresh token replay detection via refresh token rotation 2314 -10 2316 * incorporated feedback by Joseph Heenan 2318 * changed occurrences of SHALL to MUST 2320 * added text on lack of token/cert binding support tokens issued in 2321 the authorization response as justification to not recommend 2322 issuing tokens there at all 2324 * added requirement to authenticate clients during code exchange 2325 (PKCE or client credential) to 2.1.1. 2327 * added section on refresh tokens 2329 * editorial enhancements to 2.1.2 based on feedback 2331 -09 2333 * 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 2351 * added new section on access token privilege restriction based on 2352 comments from Johan Peeters 2354 -06 2356 * reworked section 3.8.1 2358 * incorporated Phil Hunt's feedback 2360 * reworked section on mix-up 2362 * extended section on code leakage via referrer header to also cover 2363 state leakage 2365 * added Daniel Fett as author 2367 * replaced text intended to inform WG discussion by recommendations 2368 to implementors 2370 * modified example URLs to conform to RFC 2606 2372 -05 2374 * Completed sections on code leakage via referrer header, attacks in 2375 browser, mix-up, and CSRF 2377 * Reworked Code Injection Section 2379 * 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 2399 -02 2401 * Folded Mix up and Access Token leakage through a bad AS into new 2402 section for dynamic OAuth threats 2404 * reworked dynamic OAuth section 2406 -01 2408 * Added references to mitigation methods for token leakage 2410 * Added reference to Token Binding for Authorization Code 2412 * incorporated feedback of Phil Hunt 2414 * fixed numbering issue in attack descriptions in section 2 2416 -00 (WG document) 2418 * turned the ID into a WG document and a BCP 2420 * Added federated app login as topic in Other Topics 2422 Authors' Addresses 2424 Torsten Lodderstedt 2425 yes.com 2427 Email: torsten@lodderstedt.net 2429 John Bradley 2430 Yubico 2432 Email: ve7jtb@ve7jtb.com 2434 Andrey Labunets 2435 Independent Researcher 2437 Email: isciurus@gmail.com 2439 Daniel Fett 2440 yes.com 2442 Email: mail@danielfett.de