As Egor said, link 1:
all oauth exploits are based on tampering with the redirect_uri
and link 2:
Vector 2. If spec was implemented properly then tampering redirect_uri
to other, "leaky", values is pointless. Because to obtain access token
you must send redirect_uri value with client creds. If actual
redirect_uri was "leaky" and not equal real redirect_uri Client will
not be able to obtain access_token for this code.
redirect_uri is the callback for the Client to receive the
The Client treats anyone who brings the code as the Resource Owner.
Attacker may replace the
redirect_uri with a malicious one in Step A to get the code.
Then he can rebuild and trigger the uri to hijack the session belongs to the Resource Owner.
However, every code have a corresponding
redirect_uri it was issued for,
i.e., code will be calculated based on the polluted
redirect_uri in Step C.
Note that the request in Step D is made by the Client. It will always use the right form of
redirect_uri. Finally, Authorization Server turns out the code does not match the uri, therefor no token will be responded back in Step E.