REST API Oauth 2 - Which grant type to use?

Question

I have an application which basically inserts some rows from the current front end web application.

All the calls before the service layer checks/validates if the user is allowed to insert data or not (This is where I am stuck with my current approach outlined below).

I have to create a REST API which will allow other third party users/developers (let's say Developer A) to insert some data automatically via some HTTP calls.

There are two scenarios for above scenario.

1. Insert data on behalf of user - Users on Developer A systems does something. Developer A then makes a HTTP REST endpoint to insert some data into our system.

2. Insert data on behalf of system - Developer A wants to insert some data directly into our system without any user interaction(Like a batch upload data where there will be no user interaction on Developer A site).

Now I have created a REST API which uses Oauth 2.0 and I am allowing Authorisation Code and Client Credentials grant types.

Authorisation Code solves my first scenario, where Developer A redirects user to my site for authentication and authorisation, so when I create the access token, I maintain link between user and the access token (which I use later on to establish which user created the token and then check if the user is allowed to insert data or not).

Now for the second scenario, I am using Client Credentials where Developer A can straight away get the access token without user interaction.

So in this scenario, when my code tries to validate the call from this REST call, it basically fails as the access token is not created for a particular user.

How should I solve this problem? Am I going in some wrong direction?

Should I refactor my validation logic, (to ignore the validation as the access token by Client Credentials can only be obtained by a trusted client)? Or create a dummy/anonymous user to be associated with access token for Client Credentials?

UPDATE:

Just some more clarification and my further approach.

The validation mentioned above is not username/password validation, it's custom business logic which depends on internal user id to check permission for a user.

I get this user id as the one which who authorised using Authorisation Code grant type.

But for Client Credentials, my subject is not a user, it's an application, which is not the same as user id.

I am thinking to associate to tackle this as below:

An admin user let's say User1 will register the application(creating client id/secret) in my system to use API. I will make a note of this user's id in my system along with other Oauth related details (client id/secret/app name, etc.). So when the developer uses Client Credentials, which identifies the application (not a specific user), I will query the database and get the user id of the User1 who registered the application. Then I will use this user id to continue all business logic validation (and it would pass this time, because this user User1 will have access to all resources in the system, since it's an Admin user).

Let me your thoughts/comments with this approach of mine.

Answer 1

Your business logic assumes that an end user is the only type of identity which can perform actions (e.g. Inserting records). It turns out that assumption is false, and you have a second sort of identity - a client application. I can see a couple of options:

Create a fake / pseudo user to represent the client application, i.e. a service account. Give the user whatever settings needed to have the system behave as expected, but make sure that it's not possible for real users to log in as this pseudo-user, and maybe hide the user from management screens. You can then either put this user's details in your access token, or have the api look up this user's details when it gets an access token.

What you probably want though is for your business logic to recognize both users and client applications as valid identity types - if we squint a little and rename the users table to "identities", that's sort of what we did with by creating fake / pseudo users. Depending on your code / database structure however you may find it easier to update your code and leave your users table as-is.

Answer 2

If I understand your flow, you can work only with "authorization code" grant, and to add REST API which would be allowed only for admin user (this is hidden in your configuration data. not exposed to other users). So basically the admin is the only one who can use this new REST API, that will bypass the "validation mechanism" that you describe.