What happens when you don’t properly validate OAuth access tokens? Account takeovers.

Fundamentally, Salt Security found the same issue across three separate login implementations making use of OAuth2.0 implicit grant flows. These applications would accept the access_token from the Identity Provider and imediately use that to determine the user/email associated with the token, the problem being that the applications would not verify who the token was issues to. By not ensuring that the tokens were issued to their own application an attacker able to obtain access tokens from another application could reuse them on these applications to take over that user’s account on one of the vulnerable applications.

Obtaining those access tokens is a bit of a stretch, but not impossibly so. The post documents the idea of simply using a legitimate website, having users register and then just reusing those tokens. This could also be a route to leverage a compromise of one website into a compromise of accounts on another application.

Of the three applications documented in this post, the first two Vidio and Bukalapak used the implicit grant by default so, but the third application Grammarly used an Authorization Code flow which would not be vulnerable by default as the received code has to be exchanged using the Client ID and Secret. However by bruteforcing the parameters of the page that received the token they found that providing the access_token parameter instead of a code parameter would result in the application using the access_token as if it was an implicit flow.