OAuth 2.0 authorization code flow vulnerable to "shoulder surfing"?

Question

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.

Answer 1

Is there anything the client (or the corresponding back end) can do to prevent this attack?

It seems that the OAuth 2.0 PKCE extension is what I was looking for. As explained within this thread, the PKCE extension prevents a leaked authorization code from being useful to an attacker.

This is achieved by exchanging a (e.g. user session specific) secret with the authorization server, not only when redeeming the authorization code (similar to the default client secret), but also when creating the authorization request, so that the authorization server can verify that during the whole process the secret (and therefore session) stays the same.