Covert Redirect: OAuth and OpenID vulnerability

A new vulnerability has been published which affects OAuth and OpenID protocols, named Covert Redirect. This vulnerability affects all the top major OAuth 2.0 and OpenID providers, including Facebook, Google, Yahoo, LinkedIn, PayPal, Live, Github, and many more. This blog provides a summary of how it works and why it’s going to be difficult to get this patched.

First, most websites out there have a redirect URL, which allows them to send the user to external sites through the redirect so they can capture and track it (presumably). For example.

Now, without going into too much detail about how OpenID and OAuth work, suffice it to say that they both provide a mechanism for the requesting site to provide the url where it should return the request after authentication. For example, you go to and you want to sign in with your Facebook account; CNN sends a request to Facebook in which it also makes a statement akin to, “After you authenticate this user, send him back to” Note that this only one example for the sake of illustrating the flaw and is not intended not to single out CNN in particular.  Hundreds of thousands of sites leverage this method which underscores the threat.

With this vulnerability, an attacker could construct an authorization request where the return URL is still within the requesting partner’s domain, but uses the redirect url to then forward the request elsewhere. For example, a Facebook auth URL to authenticate a user for which returns the user to The user would see the Facebook login screen, there they would see a valid CNN logo indicating this is for the trusted site, but after accepting, they would end up on The end url on would contain some private information, depending on the provider, such as email address. Again, this is purely hypothetical and not intended to imply that CNN has been in anyway impacted.

So why is this hard to fix? Well it’s all in these convenient redirect urls that sites use. The third party sites ( in this example) have to validate the redirects or disallow open redirects.

Interestingly enough, this vulnerability was mentioned in 2011 by Eran Hammer.

Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.