The Authorization Code Redirect URI Manipulation attack in OAuth 2.0

Changing the authorization code redirect URI is one of the ways by which attackers try to game the OAuth 2.0 authorization framework. This article discusses how this attack works in detail and how this attack can be prevented.

If you are not sure of how OAuth 2.0 works, it is better to get an understanding of it here.

OAuth 2.0 makes use of browser redirection to take a user from the webpage of an authorization provider back to the client that the user is trying to authorize. To begin with, the client sends the redirect URI as a query parameter when redirecting users to the authorization provider’s website.

Once the user authenticates himself and authorizes the client to access his data, the authorization server redirects the user back to the client’s site with the authorization code using this redirect URI. However, this attack works by modifying the redirect URI that the client sends as a query parameter to the authorization provider’s site.

The redirect URI

As you may know, to access a protected resource of a user, client applications should have registered themselves with the authorization server and obtained their client credentials such as a client ID and secret.

Let’s assume that a photo editing web application called Photo Editor that runs on wants to allow its users to access their Facebook photos and edit them on their app. First, Photo Editor would register itself with Facebook and obtain a client ID and client secret.

Then, the client needs to have a button or a link to allow users to authorize the application accessing their Facebook photos. So, Photo Editor would create a link to the authorization provider and append its client ID, the grant type, and the redirect URI as query parameters.

This URI would be the link to which the authorization server redirects the user once authorization is complete. The authorization server would append the authorization code as a query parameter to this URI. Let’s say it is

First, a user would create an account with Photo Editor. Then, he would click on this link to authorize the application accessing their Facebook photos. Then, the user agent takes the user to Facebook where they can log in and authorize access.

This is how this flow would work usually. However, an attacker can modify this link to get access to an unsuspecting user’s Facebook account. Let’s see how this attack works.

How does it work?

Initially, an attacker would create an account for himself at Photo Editor. Then, the attacker would copy the link generated by the app and insert a rogue redirect URI instead of the redirect URI pointing to Photo Editor. Let’s say, it is

Then, the attacker can make a victim click on this link and authorize Photo Editor accessing their Facebook photos. However, this may require social engineering.

Once the victim authorizes Photo Editor, the victim is redirected to the attacker’s URI with the authorization code. Then, the attacker can receive the authorization code at Next, the attacker would append his authorization code to the Photo Editor's redirect URI ( and send a request to Photo Editor. Subsequently, Photo Editor would use this authorization code to request an access token from Facebook to access the victim's Facebook photos.

Once Photo Editor receives the access token, the attacker can, then, access the victim’s Facebook photos through his account at Photo Editor.

It is worth noting that, here, an attacker is hijacking the usual OAuth 2.0 authorization grant flow by redirecting the victim to a rogue endpoint, obtaining his authorization code, and sending the authorization code to the actual endpoint.

How can this attack be prevented?

This attack can be prevented by employing two security checks. First, by requiring a client to specify a redirect URI at the time of registration and ensuring that the redirect URI sent along with a request to obtain the authorization code is same the as the registered redirect URI.

For example, if Photo Editor specifies as the redirect URI when registering their application with Facebook, Facebook will not grant the authorization code if the redirect URI sent with the request is

After that, authorization servers can check if the redirect URI used to obtain the authorization grant is as same as the redirect URI used to obtain the access token. If you take our example, the authorization grant is obtained using, and the access token is obtained by Photo Editor using its own URI. If this check is implemented, then Photo Editor won't be able to obtain the access token, consequently, preventing the attacker from accessing the victim's photos.

Most OAuth providers implement the aforementioned security checks and this form of attack is very rare.

Originally published at on October 13, 2019.




Identity and access management is taking over and is a key enabler to build agile businesses. Open source IAM specifically is becoming a game changer. Learn from IAM experts at WSO2 as to why IAM is all the rage and how it can help empower your enterprise.

Recommended from Medium

GODZ Will be Available on CoinTiger on 5 July.

Distributing DApps in a decentralized future

Financial Crime News

{UPDATE} Emergency Driver: City Hero Hack Free Resources Generator

IAMX x Partnership

Welcome to the future of AMMs: MilkSwap

I spy with my little eye... #hakvision

Ankot of Misteria Airdrop Giveaway 20,800 ANKT Tokens + 1 Ankot NFT

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Theviyanthan Krishnamohan

Theviyanthan Krishnamohan

I am a software engineer who is passionate about frontend development, UX design, machine learning, neural networks, blockchain, robotics and IoT.

More from Medium

5 Tips for Better Caching in a REST API

Send Compressed Data From Spring Boot , Uncompress & read in ReactJS

Implementing Domain-Driven Design

TypeORM Query Builder Wrapper