Combine oAuth 2.0 Client Credentials and Resource Owner Password Credentials Grant Types for API?

Question

We are building a REST API that will be consumed by our own mobile app as well as others. We want to secure it from being publicly accessible with an API key which seems to fit within oAuths Client Credentials Grant definition.

Some API endpoints, such as those that would modify a user resource, would require the user to be authenticated which seems to fit within the Resource Owner Password Credentials Grant definition.

This question essentially summarizes the same scenario linked to below but failed to ask for any examples of what the actual implementation might look like:

How to keep the client credentials confidential, while using OAuth2's Resource Owner Password Credentials grant type

This is a difficult question to frame up. I've looked at as many similar questions as I could find and none of them really seem to answer the following:

How would the flow for something like this work? Would the client just pass an API key parameter/header with every request in addition to requesting/passing an access_token for the user on certain endpoints?

Are there any publicly accessible examples out there in the wild of this particular use case in terms of source code (ruby/rails in particular)?

Also, I'm not strictly tied to oAuth, so let me know if there are other secure and proven ways to do the same type of thing.

Answer 1

This is simply not possible, with whatever technology you can come up with, unless you are 100% in control of the device the user is using to connect to your service.

If there's a piece of software that runs on a users' machine and it doesn't need anything else other than the client credentials to do certain privileged actions, then yea, somebody will be able to figure out what those credentials are.

If you are worried about malicious users doing something that they are not allowed to do, you simply must put this behind a username and password(ish) system, implying Resource Owner Password Credentials (or actually preferably Authorization Code Grant).

However, if your mobile app just needs to be able to access apis that pertain to data specifically on the device that created it and don't want the users to authenticate, then you could just 'make up' a random username and password per device and store that.