2

Confused Deputy Problem (also known as 'The Devil Wears Prada') is an OAuth 2 vulnerability arising when the protocol is used for authentication. Essentially, a malicious client obtains a token for a user, and presents this to a second client. If the second client accepts tokens as proof of authentication, than the malicious client can authenticate himself as the user towards another client.

In most explanations of this vulnerability, such as http://blog.intothesymmetry.com/2013/05/oauth-2-attacks-introducing-devil-wears.html and OAuth implicit flow and confused deputy problem, it is suggested that this only works for the implicit flow.

However, wouldn't the authorization code flow suffer from the same problem? It seems that a malicious client can obtain an authorization code for a user, and then offer that authorization code to a second client. The second client now does a backchannel request to the authorization server, and upon completion the second client believes it is communicating with the user rather than with the malicious client.

Is this analysis correct?

Matthijs Melissen
  • 123
  • 4

1 Answers1

1

In Authentication Code grant flow, the auth server will be able to figure out the auth code was provided to a different client than the second client.

To obtain the auth code, below sample request will be issued from the malicious client:

GET /authorize?response_type=code&client_id=<malicious client ID>&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

Note the auth server keeps a mapping of auth code and client id as a result of a successful auth code request.

Now the malicious client will serve this auth code to the redirect URI for the second client and the second client will in turn request for an auth token. Sample as below:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Note the client ID and secret is encoded in the Authorization header, as a result, when auth server process such information, it is able to tell whether the client id in the request matches to the client id which the auth code was initially assigned to. In this case there isn't a match, as a result the auth server won't grant access token in response to the request.

In other words, the check for client ID performed by auth server in the backend guarantees that all tokens returned in exchange for the authorization code were issued for your application.

Chen Xie
  • 126
  • 1