Secure a REST API

Question

I want to build a REST API where applications can authenticate using an OAuth2 Bearer Token, so they get access only to resources related to one user or they can access by itself accessing resources for their own application or general resources. Therefore I ask myself how to authenticate these applications when they access on their behalf.

Example

So for example, I have the resources User, Post.

The User resource is only accessible for the user itself or for an application who got a bearer token by the user. Therefore I use the Bearer Tokens.

Then there are many Post resources which belongs to a User resource. An application can access it by having the Bearer Token and get it through the User ID or by accessing it through their own application access and getting it by search or by the post ID.

Now I'm undecided whether to use the client credentials flow or to use the client secret included in the OAuth2 flow as an api key to access this post by its post ID.

Question

Shall I use the client credentials flow of OAuth2 or can I use the Client Secret used for OAuth2 also as a way to access general information. Important to me is that sensitive data, like email addresses, can only be accessed by applications when they have a Bearer Token, while data that might be accessed by applications is just protected behind a suitable authentication for these applications.

Answer 1

I can not help you decide what flow to pick based on the information given, I can point out some things to consider making your choice:

First, to limit acces to a specific resource, use scoping. For example the email could use its own scope, where you need to have a valid token and scope in order to retrieve it.

Secondly I would recommend using an identity layer with your authorization scheme. Something like Open ID Connect (OIDC), this would allow you to select specific scopes while maintaining identity of the requester (user).

Further more I would use a flow where the JWT is encrypted & signed or if you can not avoid it only signed with a shared secret or public / private key. The later require Public Key Infrastructure but is a lot more flexible.

If you are looking for a good start with this take a look at programs like keycloak. They have implemented this well.