To quote the OAuth spec:

If the resource owner denies the access request or if the request fails for reasons other than a missing or invalid redirection URI, the authorization server informs the client by adding the following parameters to the fragment component of the redirection URI using the "application/x-www-form-urlencoded" format, per Appendix B:


Let's say I'm trying to phish an Example.com account. What prevents me from doing an attack like this:

  1. Register a similar-looking domain. We'll use https://exámple.com for this example.
  2. Set up exámple.com/login to look like the real Example.com's login so I can steal credentials.
  3. Register an OAuth app with a redirect URI of https://exámple.com/login.
  4. Construct a deliberately-invalid OAuth authorization request and get a user to visit it. It might look like this: https://example.com/oauth/authorize?redirect_uri=https%3A%2F%2Fex%C3%A1mple.com%2Flogin&client_id=MY_CLIENT_ID&scope=bogus
  5. When the user visits it, the real example.com will see that my request is invalid (scope was bogus).
  6. example.com will redirect to https://exámple.com/login?error=invalid_request (or similar), which I've set up to phish Example.com users.

This isn't the biggest vulnerability in the world, but if I can trick you into clicking on a link, I can take over your account. I expect a lot of users would click any URL where the domain was google.com, for example.

What steps can an OAuth provider take against such an attack? In the example above, what could Example.com do?


In this case, it's up to Example.com to decide whether it wants to allow arbitrary users to create applications and use it as an OAuth2 provider.

Typically there is some kind of approval process for your app to go "live", and part of that process should be vetting the legitimacy of the application, and hopefully malicious uses like this would be prevented.

Facebook is an example of a OIDC/OAuth provider that allows anybody to register any application, but requires approval before your application can be accessed by other people. I don't actually know if approval involves manual review for things like the phishing attack you describe, but it probably should.

To directly answer your question,

What steps can an OAuth provider take against such an attack?

Example.com should recognize that allowing users to register arbitrary applications exposes them to this kind of attack, and mitigate it by requiring all applications go through a review process. A portion of that review process could be automated by checking whether there is a high degree of similarity between the registered application's redirect URI, and the provider's own domain.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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