Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

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?

share|improve this question

3 Answers 3

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.

share|improve this answer
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 Oct 23 '13 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 Jun 30 '14 at 15:09

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.

share|improve this answer
Please check my answer. @pfust75 –  Anderson Feb 14 '14 at 2:05

See http://hueniverse.com/2011/06/21/oauth-2-0-redirection-uri-validation/:

Consider the following scenario:

  • Evil user starts the OAuth flow on a legitimate client using the authorization code grant type flow.
  • Client redirects the evil user to the authorization server, including state information about the evil user account on the client.
  • Evil user takes the authorization endpoint URI and changes the redirection to its evil site.
  • Evil user tricks victim user to click on the link and authorize access (using phishing or other social engineering methods).
  • Victim user thinking this is a valid authorization request (it looks kosher), authorizes access. Access is granted to the right legitimate client. So far nothing is wrong.
  • Authorization server thinks it is sending victim user back to the client, but since the redirection URI was changed, victim user is sent to the evil site.
  • Evil user takes the authorization code and gives it back to the client by constructing the original correct redirection URI.
  • Client exchanges the code for access token, attaching it to the evil user’s account.
  • Evil user can now access victim user data via his client account.

The way this works, the attacker does not get direct access to protected resources, but it tricks the client into attaching the victim’s access token to the attacker’s account.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.