Reputation: 3968
I've been doing some work with OAUTH 2 in the last few years. I have a few authorization servers and several clients using them.
Anyone who has made an app or some client solution that uses OAUTH2 knows that the client secret can be a problem. One can mitigate this somewhat by using access code grant. There has been talk about using a proxy for the secret.
My question is about the redirect URI - this was meant to protect the Access Code grant process. The Auth server will only return the access code to the redirect that is on file (in the database for that client ID). The issue comes into play with mobile apps. They usually depends on https://127.0.0.1 or https://localhost for a redirect URI. Anyone can get a localhost token, right?
With this being the case, what is stopping someone from impersonating a clientID using the localhost redirect URI? Could I not make a copy-cat app, use the same OAUTH2 sign in flow using the real client ID and if I was able to get a user to login, I now have an OAUTH token to access resource servers with. Am I wrong?
If anyone can shed more light on this, I would be greatly appreciative. I want to learn as much as possible, anything helps.
Upvotes: 8
Views: 2475
Reputation: 53928
The attack that you describe is a known weakness when using the Authorization Code grant for native mobile apps. An OAuth 2.0 extension called "Proof Key for Code Exchange" has been developed to mitigate against this threat through the use of a "code verifier" that is dynamically generated and only known by the real Client.
This work was standardized in the IETF as an RFC called Proof Key for Code Exchange by OAuth Public Clients, available at: https://www.rfc-editor.org/rfc/rfc7636
Upvotes: 11