CODEWITHSUNDEEP
oauth-2.0
David Carek
David Carek

Reputation: 1113

What if any are the downsides to using the resource owner password credential flow when the app and api are first party?

I'm just starting to learn about Identity Server, OAuth 2, and OpenId Connect. While doing so I've spent some time looking over the different OAuth flows and their applications. I understand the risks of using the Resource Owner Password Credential flow when the client is 3rd party or not trusted. However, I haven't really been able to find much on its use when the client(mobile app) and api are trusted 1st party. What are the potential risks of using this flow in this scenario? If you could point to specific security vulnerabilities that would be very helpful.

Thanks!

Upvotes: 0

Views: 195

Answers (1)

starlight54
starlight54

Reputation: 1091

If you are talking about exactly the following...

  1. Your own Mobile App (using trusted libraries)
  2. Collects User Credentials (as if they were logging on your website, assuming you have one)
  3. Sends them over TLS to your Auth server
  4. Returns the normal token response if correct

Then I would argue there is no security penalty, at least, it is no worse than using username/password auth in the first place.

However, there is a wider problem with mobile authentication of this nature.

There is no way to tell that it's your app sending the requests, this applies to all OAuth2 flows (even if you use a more secure flow, the User can simply pull apart the mobile app and extract the credentials).

There are some features from both Google and Apple that attempt to fix this problem, but I'm not sure how mature or secure they are at the moment, it might be worth looking into.

So you are relying on the User to not get tricked into installing a fake app, however, this lands under social engineering and it does apply to all OAuth 2 flows.

Upvotes: 1

Related Questions