1

Specifically, do I have to worry about the confused deputy problem if I'm just trying to authorize a user against a single API?

For example: a basic messaging service will want to authenticate and then authorize a user to send a message.

Using a mobile application, is it safe/smart to use Resource Owner Password Credentials Grant in OAuth2 as a form of authentication and authorization for a user to send a message through this API?

schroeder
  • 123,438
  • 55
  • 284
  • 319
d1str0
  • 2,348
  • 14
  • 24

2 Answers2

2

The biggest security issue associated with Resource Owner Password Credentials Grant is that the application/client is privy to the user's password.

For instance, if the application/client was from a company AwesomeACME, and the Identity Provider was Google, I certainly wouldn't want AwesomeACME application/client to know my Google password.

However, if AwesomeACME also happens to be the IdP, I would be less concerned but would still question why they didn't use Authorization Code Grant instead.

HTLee
  • 1,772
  • 15
  • 30
0

The problem with the Password Credentials Grant is the credentials are relayed in plaintext. Not a problem per se, if the backend is closed (serverside), but that defeats the purpose of your client authentication method.

OAuth can be used to prove object authentication, but you may not use OAuth for that. The better way would be to use Authentication Code Grant, and send the user to a login page on the OAuth provider via a webview. First time the user can decide to accept or decline the OAuth client. After that the client (your app) can talk to the API using the bearer access token. If the OAuth provider associates the access token with the authentication object (I recommend this) the API is always capable of checking the authentication state.

For more fancy authentication you should really consider JWT. JWT and OAuth play nice together and take the best of both.

Yorick de Wid
  • 3,346
  • 14
  • 22
  • I think that you also need to take into account token interception and MiTM token attacks. Many OAuth/JWT systems I've looked at don't secure sufficiently against this. If the token can be intercepted, it can be replayed by a third party. – Julian Knight Sep 09 '16 at 11:28
  • @JulianKnight Jup, true. OpenID Connect tries to prevent this, but both JWT and OAuth have had some criticism about token interception. – Yorick de Wid Sep 09 '16 at 12:17
  • Yes, it is really annoying to see so many tutorials about using JWT that fail to fix this. – Julian Knight Sep 09 '16 at 12:55
  • @JulianKnight JWT is misunderstood by the general public anyway (OAuth as well) . I've seen too many articles, tutorials and posts that use the hash's hexadecimal representation over which the signature is wrongly calculated. – Yorick de Wid Sep 09 '16 at 13:03
  • It would be great to get a definitive, secure, tested example configuration. – Julian Knight Sep 09 '16 at 13:04
  • "send the user to a login page on the OAuth provider via a webview." Security theater at its best. – GnP Sep 17 '16 at 14:47