Confused Deputy Attack in OAuth 2.0

If you were to build an app or a website today for the general public, it's very likely that you'll be implementing an OAuth based login system. If you don't know what OAuth is (It is summarised in this blog), I recommend you to read the original RFC of OAuth 2.0 (RFC 6749). In short, OAuth login systems look like this:

When the user clicks on Login with X or anything similar, this is what happens in the background (According to RFC 6749 but with one tweak being "server calls the user_details API", for our example here.):

As you can see, the only thing that's being checked by the OAuth provider is the token. There are no extra fields that's being used to check things. Let's say that the scope for which the client is registered, is "profile_info" and returns us the email ID of the user.

This is where the confused deputy attack comes into the picture.

Suppose you registered a new client with the name "Normal Client", client_id 1 and client_secret 123, and another client with the name "Attacker Client", client_id 2 and client_secret 456. Let's say that for some reason, alice@x.com logged into Normal Client which generated a token for the Normal Client, and received access to delete something. Let's also say that for some reason, alice@x.com logged into Attacker Client generating a token for the Attacker Client. Let's say that the Normal Client's server is the Normal Server and that the Attacker Client's server is the Attacker Server.

Since there are no additional checks on the token, the Attacker Server could use this token generated for the Attacker Client, which is not identical to the Normal Client's token, to gain access as alice@x.com to Normal Server. This will allow the Attacker Server to gain access they weren't given.

Solution:

Anything that can add additional validation to the token either at the OAuth provider's side or the server's side will make things a lot more secure and prevent Confused Deputy Attacks. Examples of this are:

Generating JWT tokens instead of normal tokens and embed information like client_id within the token. Since nobody can alter the state of the JWT token, the client_id will not be tampered with. This client_id can be checked at the server's end or at the OAuth Provider's end.
Using a flag based scope. Even though scopes are meant to describe the level of information that is given to the authorising server (profile_info, profile_picture, contacts), the RFC doesn't really restrict the usage of scope to this. Therefore scopes can be used to restrict access. Although, this becomes a problem if the OAuth provider is widely used.
Sending client_id in the user_details API or the API that validates the token. This doesn't follow the OAuth RFC but it still can be done.