Resource Owner Password Credentials security concern

[mmdumi]

Hello guys,

This is more a discussion radder then an issue. Recently while implementing a webservice using this library, i've come up with this:

• as developer i would like to make available the 'authorization code' and 'implicit' grant types for others to get access tokens into my webservice but i may also develop a mobile app for me that would use the 'password credentials grant'. The reason would be simple: only my first party app could login into the system with a simple form while others would have to use the above 2 methods.
• the way the library works right now, gives others the possibility to create a proxy on their computer, see what api calls my app makes and see that the client id "xxxx" can actually use the password grant type while others can't. Most probably others would use my client to use the simple login method.

I've checked my concern with other webservices like facebook, instagram and what i have seen is that they indeed use the password grant and i can see their client id, but they also use a signature system. Most probably they use a private key (other then the client secret) for which they create a signature for the given params. It's a pretty simple solution that gives the rights to use the grant type only to explicit clients by giving them the signature key.

Would you be interested to have this feature into the library?

[F21]

I think this is a good idea! :smile: Are there any specs so that we can have a implementation that is standard?

Another thought: If I were able to reverse engine/disassemble your app to get the private key, wouldn't I still be able to launch attacks against your server?

[bshaffer]

Yes, very interested! Unless I am mistaken, this is essentially an OAuth 1.0-style signed token, and is what we hope for in the MAC token spec (http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00).

I've created a branch to implement the MAC token type, but have not gotten around to finishing it. I would love to add this feature. Once added, we would then need to add logic to allow for MACs to be specified per grant type, as only the ClientCredentials Grant Type in your example would require signed tokens.