When using the OAuth authorization code flow in web applications, after successful authentication of the resource owner, the authorization server usually responds with a browser redirect to pass the authorization code back to the client via the redirect URL's query string.
Now, if the redirect URL is short enough, the whole URL (including the authorization code) fits into the visible space of a browser's address bar. An attacker, who is looking over a victim's shoulder can now see this authorization code. In theory, if the attacker is faster than the victim's browser, he is able to steal this authorization code and pass it to the redirect endpoint of his own client.
Practical Example:
Someone is live-streaming his browser window to a public audience with low latency. An attacker in the audience has fully automated the attack: The video stream is captured, the authorization code is intercepted and then used to steal the victim's login session.
Questions:
- Is there anything the client (or the corresponding back end) can do to prevent this attack?
- Or can only the authorization server make the attack more difficult? One idea would be to hide the authorization code at the end of very long redirect URLs. But what if the user's client is currently unavailable? The timed out redirect request's URL is still visible in the victim's browser history and the attack is working as long as the authorization code has not expired.
