Django REST Framework - OAuth2 Consumer API from e

Question

I am trying to authorize users to access some resources from my Django REST framework API using Oauth2.

Most answers about Oauth2 and API deal with making the API a provider.

But I plan to share an Oauth2 provider with many REST APIs, and I can't figure out how to consume it (not how to provide Oauth2).

I have no idea how a user can log in on the provider SSO, and then communicate its token to my consuming API, which must authenticate users against my provider (getting back its information, mainly authorizations).

Does anyone have a clue on how to consume Oauth2 from Django REST framework?

Figure:

[User] -> [My API] <-> [Oauth2 provider (with django-oauth-provider)] <-> [Active Directory / anything ]

Answer 1

Looking at the code at https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/authentication.py#L290 it seems just not possible. The django-rest-framework internally accesses provider's database tables to check for tokens and authenticates requests using these data.

Which for me kinda defeats the purpose of OAuth at all, but here we go.

Answer 2

I've found these related questions, which confirms what I thought was an interpretation error from my side:

• How to validate an OAuth 2.0 access token for a resource server?
• https://softwareengineering.stackexchange.com/questions/159119/oauth2-flow-does-the-server-validate-with-the-auth-server

Basically, the standard desn't define such feature... it's amazing, provided a lot of people will hit that point sooner of later.

What's most weird is that I couldn't find any django addon to do this... are we the first two that need to authenticate more than one API using the same Auth Server?

Answer 3

Lately, the OAuth 2.0 Authorization Framework came up with a specification called OAuth 2.0 Token Introspection (RFC 7662) which defines a protocol that allows authorized protected resources to query the authorization server to determine the set of metadata for a given token that was presented to them by an OAuth 2.0 client.

This can solve your problem.

It is implemented by most of the well known OAuth 2.0 providers like:

• Amazon Cognito
• Okta
• Auth0
• Google Cloud Identity

And can easily be integrated with your Django Rest Framework API resources.

In your use case in Django, the open-source library Django OAuth Toolkit can also do the job perfectly. Note that, using an open-source library comes with the hidden costs of maintenance and support, sometimes rarely available.

Token Inspection can be achieved in these simple steps:

1. Setup the Authentication Server and add one extra scope introspection for the Resource Server while creating an OAuth2 access token.

   'SCOPES': {
       'read': 'Read scope',
       'write': 'Write scope',
       'introspection': 'Introspect token scope',
       ...
   }
   

2. The OAuth provider must have one endpoint with path /introspect/ at which it will listen to any introspection request. e.g. URL: https://example.org/o/introspect/

   eg. Request:

   POST /o/introspect/ HTTP/1.1
   Host: www.example.org
   Accept: application/json
   Content-Type: application/x-www-form-urlencoded
   Authorization: Bearer 5HtUoltwKYKHnfmxRcJu
   
   token=pOt6V4KXoMbhAraTIyA4zgyxH
   

   Note: token is access token and Bearer token is Base64($CLIENT_ID:$CLIENT_SECRET)

   And the Response to above example request would look like:

   HTTP/1.1 200 OK
   Content-Type: application/json
   {
     "client_id": "o7dfkjhvHt74F9W20",
     "scope": "read write xyz",
     "username": "john",
     "exp": 1519123438,
     "active": true
   }
   

3. Setup the Resource Server with all other settings same as Auth Server and then add following configurations into your settings:

   a. Resource Server Interospection URL e.g. https://example.org/o/introspect/

   b. Resource Server Auth Token e.g. tBvd837tbdHssyT6bhAr9H

   Or Resource Server Introspection Credentials (i.e. client id & client secret)

The implementation of the above steps might differ for different Auth Providers. But it gives a basic idea of how the whole configurations are done as per the rfc-compliance.