2.1.1.Authorization Code Grant

Clients MUST prevent injection (replay) of authorization codes intothe authorization response by attackers. The use of PKCE[RFC7636]is RECOMMENDED to this end. The OpenID Connectnonce parameter andID Token Claim[OpenID] MAY be used as well. The PKCE challenge orOpenID Connectnonce MUST be transaction-specific and securely boundto the client and the user agent in which the transaction was started.¶

Note: although PKCE so far was designed as a mechanism to protectnative apps, this advice applies to all kinds of OAuth clients,including web applications.¶

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].¶

Authorization servers MUST provide a way to detect their support forPKCE. To this end, they MUST either (a) publish the elementcode_challenge_methods_supported in their AS metadata ([RFC8414])containing the supported PKCE challenge methods (which can be used bythe client to detect PKCE support) or (b) provide adeployment-specific way to ensure or determine PKCE support by the AS.¶

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 viable mechanism exists to cryptographically bind accesstokens issued in the authorization response to a certain client as itis recommended inSection 2.2. This makes replaydetection for such access tokens at resource servers impossible.¶

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 type "code" (aka 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 the "code 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).¶

4.1.1.Redirect URI Validation Attacks on Authorization Code Grant

For a client using the grant type code, 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:¶

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

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 impersonated 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.¶

Note: Vulnerabilities of this kind 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, he can impersonate the legitimate client. Thiscould be caused, for example, by a subdomain takeover attack[subdomaintakeover], 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 a URI underhis control, he will directly get access to the fragment carrying theaccess token.¶

Additionally, implicit clients 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[RFC7231], Section 9.5). The attackdescribed here combines this behavior with the client as an openredirector (seeSection 4.9.1) in order to get access to 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:¶

First, and as above, the attacker needs to trick the user into openinga tampered URL in his 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 example.com, 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 correctlyobviously causes security issues. This document therefore advises tosimplify the required logic and configuration by using exact redirectURI matching only. This means the authorization server MUST comparethe two URIs using simple string comparison as defined in[RFC3986],Section 6.2.1.¶

Additional recommendations:¶

• Servers on which callbacks are hosted MUST NOT expose openredirectors (seeSection 4.9).¶

• 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 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[I-D.ietf-oauth-jwsreq] or[I-D.ietf-oauth-par] 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[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 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 AS after their first use at the tokenendpoint. For example, if an AS invalidated the code after thelegitimate client redeemed it, the attacker would fail exchangingthis 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 AS 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 web site, thestate was already used, invalidated bythe client and cannot be used again by the attacker. (This doesnot help if thestate leaks from theAS's web site, 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-v2-form-post-response-mode]).¶

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-v2-form-post-response-mode]).¶

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 to transfer tokens via a header,but in practice web sites often pass access tokens in queryparameters.¶

In case of the 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-v2-form-post-response-mode] can be used tothis end.¶

4.4.1.Attack Description

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

Preconditions: For this variant of the attack to work, we assume that¶

• the implicit or authorization code grant are used with multiple ASof which one is considered "honest" (H-AS) and one is operated bythe attacker (A-AS),¶

• the client stores the AS chosen by the user in a session bound tothe user's browser and uses the same redirection endpoint URI foreach AS, and¶

• the attacker can intercept and manipulate the firstrequest/response pair from a user's browser to the client (inwhich the user selects a certain AS and is then redirected by theclient to that AS), as in Attacker A2.¶

The latter ability can, for example, be the result of aman-in-the-middle attack on the user's connection to the client. Notethat an attack variant exists that does not require this ability, seebelow.¶

In the following, we assume that the client is registered with H-AS(URI:https://honest.as.example, client ID:7ZGZldHQ) and withA-AS (URI:https://attacker.example, client ID:666RVZJTA).¶

Attack on the authorization code grant:¶

1. The user selects to start the grant using H-AS (e.g., by clicking on a button at theclient's website).¶

2. The attacker intercepts this request and changes the user'sselection to "A-AS" (see preconditions).¶

3. 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.¶

4. Now the attacker intercepts this response and changes theredirection such that the user is being redirected to H-AS. Theattacker also replaces the client ID of the client at A-AS withthe client's ID at H-AS. Therefore, the browser receives aredirection (303 See Other) with a Location header pointing tohttps://honest.as.example/authorize?response_type=code&client_id=7ZGZldHQ¶

5. The user authorizes the client to access her resources atH-AS. H-AS issues a code and sends it (via the browser) back tothe client.¶

6. 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.¶

7. 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 Without Interception: A variant of the above attackworks even if the first request/response pair cannot beintercepted, for example, because TLS is used to protect thesemessages: Here, it is assumed that the user wants to start thegrant using A-AS (and not H-AS, see Attacker A1). After the clientredirected the user to the authorization endpoint at A-AS, theattacker immediately redirects the user to H-AS (changing theclient ID to7ZGZldHQ). Note that a vigilant user might at thispoint detect that she intended to use A-AS instead of H-AS. Theattack now proceeds exactly as in Steps 3ff. of the attackdescription above.¶

• Implicit Grant: In the implicit grant, the attacker receivesan access token instead of the code; the rest of the attack worksas above.¶

• Per-AS Redirect URIs: If clients use different redirect URIsfor different ASs, do not store the selected AS in the user'ssession, and ASs do not check the redirect URIs properly,attackers can mount an attack called "Cross-Social Network RequestForgery". These attacks have been observed in practice. Refer to[oauth_security_jcs_14] for details.¶

• OpenID Connect: There are variants that can be used to attackOpenID Connect. In these attacks, the attacker misuses features ofthe OpenID Connect Discovery mechanism or replays access tokens orID Tokens to conduct a Mix-Up Attack. The attacks are described indetail in[arXiv.1704.08539], Appendix A, and[arXiv.1508.04324v2], Section 6 ("Malicious Endpoints Attacks").¶

4.4.2.Countermeasures

In scenarios where an OAuth client interacts with multipleauthorization servers, clients MUST prevent mix-up attacks.¶

To this end, clients SHOULD use distinct redirect URIs for each AS(with alternatives listed below). Clients MUST store, for eachauthorization request, the AS they sent the authorization request toand bind this information to the user agent. Clients MUST check thatthe authorization request was received from the correct authorizationserver and ensure that the subsequent token request, if applicable, issent to the same authorization server.¶

Unfortunately, distinct redirect URIs per AS do not work for all kindsof OAuth clients. They are effective for web and JavaScript apps andfor native apps with claimed URLs. Attacks on native apps using customschemes or redirect URIs on localhost cannot be prevented this way.¶

If clients cannot use distinct redirect URIs for each AS, the following options exist:¶

• Authorization servers can be configured to return an ASidentitifier (iss) as a non-standard parameter in theauthorization response. This enables complying clients to comparethis data to theiss identifier of the AS it believed it sentthe user agent to.¶

• In OpenID Connect, if an ID Token is returned in the authorizationresponse, it carries client ID and issuer. It can be used in thesame way as theiss parameter.¶

4.5.1.Attack Description

The attack works as follows:¶

1. The attacker obtains an authorization code by performing any ofthe attacks described above.¶

2. He performs a regular OAuth authorization process with thelegitimate client on his device.¶

3. The attacker injects the stolen authorization code in the responseof the authorization server to the legitimate client. Since thisresponse is passing through the attacker's device, the attackercan use any tool that can intercept and manipulate theauthorization response to this end. The attacker does not need tocontrol the network.¶

4. The legitimate client sends the code to the authorization server'stoken endpoint, along with the client's client ID, client secretand actualredirect_uri.¶

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 hissession 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 AS 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 attackers page). So the authorization server would detectthe attack and refuse to exchange the code.¶

Note: this check could also detect attempts to inject an authorizationcode which 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 to enforce 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.¶

This document therefore recommends to instead bind 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 achieve this goal:¶

• PKCE: The PKCE parametercode_challenge along with thecorrespondingcode_verifier as specified in[RFC7636] can beused as a countermeasure. In contrast to its original intention,the verifier check fails although the client uses its correctverifier but the code is associated with a challenge that does notmatch. PKCE is a deployed OAuth feature, although its originalintended use was solely focused on securing native apps, not thebroader use recommended by this document.¶

• Nonce: OpenID Connect's existingnonce parameter can be usedfor the same purpose. Thenonce value is one-time use andcreated by the client. The client is supposed to bind it to theuser agent session and sends it with the initial request to theOpenID Provider (OP). The OP bindsnonce to the authorizationcode and attests this binding in the ID Token, which is issued aspart of the code exchange at the token endpoint. If an attackerinjected an authorization code in the authorization response, thenonce value in the client session and the nonce value in the IDtoken will not match and the attack is detected. The assumption isthat an attacker cannot get hold of the user agent state on thevictim's device, where he has stolen the respective authorizationcode.¶

Other solutions, like bindingstate to the code, using token bindingfor the code, or per-instance client credentials are conceivable, butlack support and bring new security requirements.¶

PKCE is the most obvious solution for OAuth clients as it is availabletoday (originally intended for OAuth native apps) whereasnonce isappropriate for OpenID Connect clients.¶

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 his own sessionin Step 2 of the attack above. (This requires that the victim'ssession with the client begins after the attacker started his 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.9.¶

4.6.1.Countermeasures

There is no way to detect such an injection attack on the OAuthprotocol level, since the token is issued without any binding to thetransaction or the particular user agent.¶

The recommendation is therefore to use the authorization code granttype instead of relying on response types issuing acess tokens at theauthorization endpoint. Authorization code injection can be detectedusing one of the countermeasures discussed inSection 4.5.¶

4.7.1.Countermeasures

The traditional countermeasure are CSRF tokens that are bound to theuser agent and passed in thestate parameter to the authorizationserver as described in[RFC6819]. The same protection is provided byPKCE or the OpenID Connectnonce value.¶

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

• Clients MUST ensure that the AS 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 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[I-D.bradley-oauth-jwt-encoded-state].¶

AS therefore MUST provide a way to detect their support for PKCEeither via AS metadata according to[RFC8414] or provide adeployment-specific way to ensure or determine PKCE support.¶

4.8.1.Access Token Phishing by Counterfeit Resource Server

An attacker may setup his own resource server and trick a client intosending access tokens to it that are valid for other resource servers(see Attackers A1 and A5). 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 which this user or company uses.¶

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"  ]  ...}

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",...}

4.8.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 of the respective server.¶

If the attacker were able to gain full control, including shellaccess, all controls can be circumvented and all resources 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.¶

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.8.1.1.2SHOULD be used to prevent the attacker from replaying the accesstokens on other resource servers. Depending on the severity of thepenetration, sender-constrained access tokens will also preventreplay on the compromised system.¶

• Audience restriction as described inSection 4.8.1.1.3 SHOULD beused to prevent replay of captured access tokens on other resourceservers.¶

• The resource server MUST treat access tokens like any othercredentials. It is considered good practice to not log them andnot store them in plain text.¶

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

4.9.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 follow it in their browser. This can be abused for phishing.¶

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

4.9.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 web sites (the clients), but must do so in a safe way.¶

[RFC6749], Section 4.1.2.1, already prevents open redirects bystating that the AS 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 intentionally send an erroneous authorization request, e.g., byusing an invalid scope value, thus instructing the AS to redirect theuser agent to its phishing site.¶

The AS MUST take precautions to prevent this threat. Based on its riskassessment, the AS needs to decide whether it can trust the redirectURI and SHOULD only automatically redirect the user agent if it truststhe redirect URI. If the URI is not trusted, the AS MAY inform theuser and rely on the user to make the correct decision.¶

4.12.1.Discussion

Refresh tokens are an attractive target for attackers since theyrepresent the overall grant a resource owner delegated to a certainclient. 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 a 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 (i.e.,client_id),¶

• 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 (implementationspecific) security measures, such as refresh token expiration andrevocation as well as refresh token rotation by defining respectiveerror codes and response behavior.¶

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

4.12.2.Recommendations

Authorization servers SHOULD 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 refresh access tokens 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.¶

Authorization server 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 by utilizing[I-D.ietf-oauth-token-binding] or[RFC8705].¶

• 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.13.1.Countermeasures

Authorization servers SHOULD NOT allow clients to influence theirclient_id orsub value or any other claim if that can causeconfusion with a genuine resource owner. Where this cannot be avoided,authorization servers MUST provide other means for the resource serverto distinguish between access tokens authorized by a resource ownerfrom access tokens authorized by the client itself.¶