Why use a proxy to hide OAuth client credentials in password grant calls?

Question

In a November 2014 article by Alex Bilbie, OAuth users were advised against making the client send its credentials (client_id and client_secret) when performing Resource Owner Password grant calls. The idea as I understand it is that for the client to be able to add its credentials to its requests, those credentials must be written in its source code (often HTML/JS) and therefore accessible to possible attackers, which could then use them to perform calls to the API impersonating the client.

In another blog post's comments, the author added:

If I can view source and copy the client credentials there’s nothing stopping me building my own app that can authenticate against your OAuth service and then call the API.

The proposed workaround is that the client shouldn't call the API directly but instead a thin proxy which would be responsible for appending the client credentials to the request and then forwarding it to the API.

As a naive OAuth newbie, I don't understand why this would keep attackers from performing calls to my API. If the client doesn't have to add its credentials to its requests, nobody does. As the proxy automatically adds the credentials, any request sent to the API is then treated as coming from the authorized client.

Someone asked Alex Bilbie this very question in Twitter. Here is his answer:

how would you secure the proxy? Can't the attacker just send a request to the proxy and have the secret happily filled in?

the point is that you’re hiding implementation details of your backend and therefore retaining more control

I would be grateful if someone could elaborate on this answer, as I cannot see what I could gain (security-wise) from hiding implementation details while at the same time removing the need for a client to authenticate itself.

Answer 1

After reading the linked blog post and after cross referencing his issues with the OAuth 2.0 RFC I have a few issues with his concerns. In the first section of his blog post, he has two major issues with using OAuth within a single page web application using the Resource Owner Password Credentials Grant:

1. The client_id and client_secret are baked into the Javascript.
2. An attacker can also access the access_token and refresh_token from the Javascript.

Addressing the first problem, section 4.3.2 of the RFC lists the requirements for requesting an access_token using the Resource Owner Password Credentials Grant flow. These requirements don't include a client_secret because the provider trusts the client. If this flow was used for untrusted clients, the client wouldn't need a client_secret because the client could just authenticate to the provider using the users username and password. This flow basically replicates traditional password based authentication schemes.

The second problem does exist, however the author doesn't really explain the impact. To gain access to the user's access_token the attacker either needs physical access to the user's computer or to exploit a separate vulnerability like cross-site scripting within the web. An access_token is basically equivalent to a session cookie except the browser doesn't have built-in mechanisms like the secure and http-only cookie flags to protect an access_token.

Together this means that there isn't really a valid reason to send the API requests through a thin proxy because the application shouldn't expose any secret data that a web application wouldn't normally expose.