4👍
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.
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?
- How to check if a Django user is still logged in from the client side only?
- Project management/build tools for a Django project?
- Django 1.4 Unknown command: 'runserver'
- How to create a triple-join table with Django
- Django (admin.e104) must inherit from 'InlineModelAdmin'
0👍
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:
-
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', ... }
-
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 andBearer token
isBase64($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 }
-
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.