Django-OAuth-ToolKit : Generating access token's for multiple resources/services using client credentials grant type of OAuth2.0

Question

I have a couple of backend API\'s which are Django projects. They have a UI ( single page app) to it and a user name password based login.

My clients are usually dev

Answer 1

question 1. I am planning to use django-oauth-tool kit , it seems to me that the client credentials grant type would be suitable for this use case . Am I right ?

Yes, You're right.

Question 2 : Is this process of registering multiple resource server's correct ? Have I set up the introspection correctly ?

Yes, you're doing it the right way.

Question 3 : How would I register different micro services running on the same resource server ?

Do you mean running different micro-services ON DIFFERENT PORTS on the same resource server? If yes, then you have to configure your resource server in the same way as you did for your R1 and R2.

Question 3 : Why is the access token I generated using R1's client id and client secret working even for R2. Am I doing something wrong here ? Basically , I want to be able to produce access tokens for developer's specifically for a resource. I know there are scope and permissions but can I generate access token for a specific resource only ? what do I need to do to achieve this , do I need extend or add some logic ?

Access tokens are confidential. If shared with anyone, either of resources will be able to access it. For eg:- If I've your FB auth token, you and I can do the same thing with it, irrespective to whom does this token belong.

Question 4 : Is my thought on using client credentials grant type correct and are the steps that I have done to register resources server's and the client app's which are going to use resource server's correct ?

1. Yes, using client_credentials is the right way to approach your problem statement.
2. Yes, you're setting it up the right way. However, do look into JWT for an alternative and advanced approach. Using JWT avoids the introspection call made to OAuth Server, thereby saving a network call.

Answer 2

To simply secure the backend you can use the builtin Token Authentication.

It's perfectly secure to get started. It limits you to a single token per user/account which may impact the "user experience" when it comes time to rotate/revoke a token. There are also some downsides when it comes to scaling up to support large transactional volumes. Otherwise it's really fine.

Once you better understand your needs you can consider moving toward JWT, OAuth or other more advanced/complex token based authentication approaches.