Background
I am building a backend api that will be called by my mobile app. This api will not be made public and will only be used by my mobile application(at least that’s the plan as of now). The users of the mobile app will be able to login using their Facebook/Google details or they can create a local account on the application and log in with that
Question
Is the third case (The local account login) a valid use-case for using the Resource-Owner password flow? I see this flow now has a bad rep but if the API is only used by my mobile app(which is a trusted client), is it okay to use this flow?
2
Answers
For the Resource-Owner password flow as alternative to the Authorize-Flow you intend to do with Facebook/Google as Authorization-Server you will need your own Authorization-Server that is issuing the token.
Do you intend to implement that in your server?
In this case Resource-Owner password flow is perfectly sufficient as you manage the users password anyway on the server side.
Alternatively you could think about having token-based and username-password-based authentication in parallel.
ROPC
is a valid use case if the trust is not a problem. I do think in your case, it can be considered, assuming your users ‘trust you’ with their credentials.If your application is not using browser, probably it is ok to use it (of course considering many other facts like trust, how password is stored etc. )
I think the main reason to avoid ROPC grant is because there are (more) chances for Phishing. A consumer may get fooled easily since you login screen is not ‘that popular’ like google or Facebook and they enter the credentials at wrong place, and your application is at risk.