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.