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

7
votes

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.

1
apirestauthenticationoauth
Hi Mark, I'm running into the same problem as you are. The question you linked to concluded "[the] best option to protect the API from abuse is to implement some sort of usage monitoring". You could indeed include a client secret in every response, but unfortunately anyone can take a peek into your app and find it. Did you ever come across a good solution to this? – Rengers
I have the same problem and, in my opinion, oauth2 doesn't provide any solution to this. The oauth2 draft wasn't written thinking at mobile native clients and with resource owner password credentials you have to trust the user not using a 3rd party client. – alex
@Rengers Not really, and I'm inclined to agree with alex that oauth doesn't really provide a solution to this particular scenario. It seems like everyone tends to roll their own solution. – Mark Murphy

1 Answers

0
votes

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.