The OAuth 2.0 specification's authorization code mechanism includes redirect URI checking from the site you redirect to. See steps D and E in section 4.1 of the spec. Also, section 4.1.3 describes in detail that the redirected-to client needs to transmit redirect_uri, and that it needs to match that of the initial authorization request.

I can't think of any attack vector that is mitigated by this being a part of the protocol. Why is this redirect_uri check necessary?

4 Answers 4


By not validating the redirect_uri an OAuth provider can be used as an ideal phishing vector. The redirect_uri is an address used by OAuth providers as a location to deliver the access_token by means of a browser redirect. The popular OAuth provider Facebook has run into many vulnerabilities relating to OAuth redirection.

In this attack, the attacker presents the victim with a URL to an authentication portal that the victim trusts (like Facebook), and by using this authentication portal the victim's secret access token is delivered to an HTTP server controlled by the attacker.

Authentication is about intention, tricking a user into allowing access to an unintended resource is a vulnerability.

  • 16
    But the redirection_uri in the Access Token Request (section 4.1.3 in the spec) mentioned by Steven Xu is only checked on the Authorization Server, the access_token is not redirected to this uri. So the code and the redirection_uri is checked before the access_token is returned to the client app... Me too, I can't think of a reason for the additional checking of the redirection_uri...
    – pfust75
    Commented Oct 23, 2013 at 6:02
  • Is it necessary to pass the redirect_uri when being authorized if the client provided it during the registration process?
    – Kyle Hayes
    Commented Jun 30, 2014 at 15:09
  • 1
    @pfust75 The check is only useful if the redirect_uri wasn't checked in the first step. Say Alice clicks a link like https://oauth.example.com/login?client_id=123456&redirect_uri=evilsite.com%2Fpwned. This request will not be rejected unless oauth.example.com requires clients to register a redirect_uri. Let's say that's not the case, then evilsite.com (Mallory) receives the auth code. It can then forge this URL https://client123456.example.com/oauth_redirect?code=987654321, and Mallory will have gained access to Alice's account
    – aross
    Commented May 3, 2019 at 11:02

Edited based on comments. I previously thought the OP was referring to redirect_uri validation during the authorization request, and linked to an example of an attack here. I've updated the answer below.

TL;DR: If a static redirect URL is required to be registered and is strictly matched by the provider, I do not believe that the redirect_uri would be required during the access token request.

The registration requirements ( indicate that the redirect URI should be registered. However, not all providers perform exact matches of the redirect URI, although the spec requires it. The OAuth spec attempts multiple countermeasures to guard against these possibilities, with the redirect_uri <-> authorization code binding requirement described in the Threat Model and Security Considersations RFC (

For example, GitHub matched URL prefixes, which lead to the attack described here by Egor Homakov. In particular, Bugs 1 and 2 allowed an attacker to use a white-listed redirect URI to obtain a code, and then use that code to complete the callback flow and gain access to the victim's account. In this case, the client (Gist), sent the right redirect URI to the provider (GitHub), and GitHub would have not granted the access token if it had checked to ensure the redirect URI was the same one used during the authorization request:

It was flawed: no matter what redirect_uri the Client sent to get a token, the Provider responded with valid access_token.

The attacker could hijack the authorization code issued for a "leaky" redirect_uri, then apply the leaked code on real Client's callback to log in Victim's account.

To summarize, the redirect_uri is required when obtaining an access token to ensure that a leaked code from a redirect to a page the attacker can insert code in doesn't immediately compromise the OAuth flow. A more complete overview of the attack vector is described here by Egor as well:

The attack is straightforward: find a leaking page on the client's domain, insert cross domain image or a link to your website, then use this page as redirect_uri. When your victim will load crafted URL it will send him to leaking_page?code=CODE and victim's user-agent will expose the code in the Referrer header.

Now you can re-use leaked authorization code on the actual redirect_uri to log in the victim account.

Remediation: flexible redirect_uri is a bad practise. But if you need it, store redirect_uri for every code you issue and verify it on access_token creation.

  • 1
    How is this situation possible if the Registration Requirements are followed? Mainly that: "The authorization server SHOULD require all clients to register their redirection endpoint prior to utilizing the authorization endpoint." The victim could never be redirected to the evil site. Commented Sep 9, 2015 at 0:15
  • @SankethKatta whoops, misunderstood the question. I've updated the answer. Thx!
    – vinod
    Commented Sep 9, 2015 at 2:05
  • Been trying to figure this out for hours but honestly I'm stumped. If you can send the victim to an /authorize request with your redirect_uri, you receive the code, you can just call the /token with both the code and the redirect_uri that you gave before. I can't think of a scenario where you can forge a redirect_uri, yet somehow when it's time to call /token you don't know what the redirect_uri is so you can't get the token Commented Dec 21, 2023 at 11:43

As Egor said, link 1:

all oauth exploits are based on tampering with the redirect_uri parameter.

and link 2:

Vector 2. If spec was implemented properly then tampering redirect_uri to other, "leaky", values is pointless. Because to obtain access token you must send redirect_uri value with client creds. If actual redirect_uri was "leaky" and not equal real redirect_uri Client will not be able to obtain access_token for this code.

redirect_uri is the callback for the Client to receive the Authorization Code. The Client treats anyone who brings the code as the Resource Owner.

Attacker may replace the redirect_uri with a malicious one in Step A to get the code. Then he can rebuild and trigger the uri to hijack the session belongs to the Resource Owner.

However, every code have a corresponding redirect_uri it was issued for, i.e., code will be calculated based on the polluted redirect_uri in Step C.

Note that the request in Step D is made by the Client. It will always use the right form of redirect_uri. Finally, Authorization Server turns out the code does not match the uri, therefor no token will be responded back in Step E.

  • Please check my answer. @pfust75
    – Anderson
    Commented Feb 14, 2014 at 2:05
  • Doesn't this just mean that in step D, the client sending the "correct" redirect_uri will not get a token because it doesn't match the one of the attacker, but the attacker does get a token since they're sending the one they used previously? Commented Dec 21, 2023 at 11:51

I emailed the original author of RFC 6749, Dick Hardt, to ask him about this. He responded as follows:

An attacker may have modified the redirect_uri being sent to the AS so that it can get the response and modify it.

As it turns out, there does not seem to be attacks that would be thwarted by passing the redirect_uri to the token endpoint, and we are considering dropping it in OAuth 2.1.

I don't think this additional requirement is justified.

If the attacker already misdirected the client to an adversarial redirect_uri, they will know this redirect_uri when they do a /token request so it won't prevent them from obtaining an access token

If they somehow obtain the authorization code through a leaky callback, they'll get this through a referer header and parse it from the param string, but this means they'll have the entire URL (i.e. the redirect_uri)

I can't think of a scenario where the attacker obtains the authorization code, but not the redirect_uri


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .