How to implement OAuth when the resource and auth servers are same

Question

I have a Django Rest API with JWT authentication which is the backend for a Angular frontend. There are many clients who use the service with our frontend. Now some enterprise clients wanted to integrate the APIs from their system's backend. I don't want to remove JWT from current APIs. I am planning to create new APIs in the same backend with OAuth token for those users.

I wonder what is the best way to implement OAuth for this scenario.

I am thinking Client Credentials grant type is the best way.

Question1: Am I right that client credentials is the right approach ?

For those enterprise users, it is sufficient they get just access token through the UI interface so that they can access all our APIs. But here the problem is one additional step of getting the Client ID and Client Secret first and using that to get Access Token.

Question 2: What is the use of client ID and client secret ?

Question3: Should my backend hide the process of generating Client ID and Client secret and just give Access token (or) give them Client ID and Client Secret and ask then to generate access token ?

Question 4: If I am giving them Access Token without client id and secret, is that fine to have infinite expiry time? and

TLDR; How to implement OAuth when the resource server and auth servers are same ?

Answer 1

There are 4 grant types in oAuth2 which is meant for different scenarios.

client credential : the consumer (app) make calls to back-end using the bearer token created using apikey(or clientId) and secret only. Mostly used for anonymous calls where generic information is retrieved.

Resource owner password credential (ROPC) : the consumer (app) make calls using the bearer token created using apikey, secret, username and password. Mostly used when you(your authorization server) already know the users(user database is handled in your own system).

Authorization code : the consumer (app) make calls using the bearer token created using an authorization code. The authorization code is provided by a 3rd party (which actually has/manages the logged in user data) and the created authorization code linked to the logged in user. Google and Facebook log in for various sites is a typical example. Facebook/Google gives an authorization code for those websites and they exchange that code for a token.

Implicit grant : Mix of password credential and authorization code. Instead of authorization code, you get a bearer token from the 3rd party authorization server.

Question1: Am I right that client credentials is the right approach ? I think you can use CC if there is no user level logics in your backend. If userlevel involved, may be ROPC is a better choice

Question 2: What is the use of client ID and client secret ? Client ID and Client Secret is very similar to username and password in an application level, which is used to obtain bearer token.

Question3: Should my backend hide the process of generating Client ID and Client secret and just give Access token (or) give them Client ID and Client Secret and ask then to generate access token ? If you are implementing oAuth2, your consumer should create the access token. But looking at your use case, may be even a simple hash of userId+timestamp is sufficient. ;)

Answer 2

Question1: Am I right that client credentials is the right approach ?

Yes. Providing the new APIs do not need to be called in the context of an end user.

Question 2: What is the use of client ID and client secret ?

• The client ID allows the auth server to identify the application requesting the token (it's often carried through to the access token too, allowing the API to identify the calling application).
• The client Secret means the auth server can trust that the client is genuinely who he says he is as only he should have the private client secret for his public client ID.

It's effectively a username and password in this scenario.

Question3: Should my backend hide the process of generating Client ID and Client secret and just give Access token (or) give them Client ID and Client Secret and ask then to generate access token ?

Your Auth server should issue the client credentials to the application once and the application should provide those credentials every time they wish to obtain a token via the client credentials grant type.

Answer 3

1. authorization code grant, or implicit grant might be more suitable for this scenario. The first one allows you to add an authentication step before the tokens are returned to the users (might be useful if you want to integrate your JWT authentication to this as well) and the second one is mainly used for single-page applications, and does not include an intermediate authentication step. This one would be useful if you want to improve efficiency.
2. client_id and client_secret are given to you when you register a client application in your identity provider(authorization server). This client application does not mean an application or an API belonging to your clients, but your own application to which you plan to incorporate OAuth(and OIDC). These two parameters are useful when making the requests to authorization in order to obtain tokens. The server uses those values to determine whether the request is made by a valid application. Only you have access to those values as you will be the one who's registering the application with the server.
3. I think this question is answered in the previous section.

I think it would be better if you go through this before doing any implementation. It provides most of the basic knowledge you should have before implementing an OAuth system. I hope this answer was useful to you.