Django-oauth-toolkit: Introspection : response when the bearer is ok, but the token is not

[broxane]

RFC 7662 specifies that :

If the introspection call is properly authorized but the token is not
active, does not exist on this server, or the protected resource is
not allowed to introspect this particular token, then the
authorization server MUST return an introspection response with the
"active" field set to "false".

However, in introspect.py:

    @staticmethod
     def get_token_response(token_value=None):
        try:
            token = get_access_token_model().objects.get(token=token_value)
        except ObjectDoesNotExist:
            return HttpResponse(
                content=json.dumps({"active": False}),
                status=401,
                content_type="application/json"
            )
        else:
            if token.is_valid():
               [ ... ]
            else:
                return HttpResponse(content=json.dumps({
                    "active": False,
                }), status=200, content_type="application/json")

Is there a reason not to send the same response when the token does not exists or is invalid ?

[JonathanHuot]

I think the introspection code can be migrated to oauthlib, since oauthlib has now integrated it. It should solve this specific issue.

https://oauthlib.readthedocs.io/en/v3.0.1/oauth2/validator.html#oauthlib.oauth2.RequestValidator.introspect_token

[n2ygk]

I've found that many of the oauthlib functions only implement the server side, so this code would be used by the introspect endpoint implementation. However, DOT can also call out to an external introspection endpoint, so just a reminder not to forget that little-used aspect when making changes.

[broxane]

As long as the RFC is concerned, the endpoint should only accept POST requests, and a token whose valid period has not started yet should be considered as invalid

[IvanAnishchuk]

To use oauthlib's implementation we would need to add introspect_token method to the Validator class. It needs to be able to fetch token object by token (and optional type hint) and return it as a dictionary of "claims" (mostly it's just assigning values from the token object to standard JWT keys, like sub, exp, at, username, etc.)

I'd also add a hook for adding more claims. I already see a couple things I'd want to see in my project that are not generic enough to implement here. But if someone figures out a good way to generate claims like iss and aud it would be good too.

I'm not quite sure whether I like this -- it expects introspect_token to only return None or active token details but I guess they had some reasons for implementing it this way, security considerations perhaps.

Overall sounds like a nice weekend project, I'll take a look when I happen to have a free weekend.

[IvanAnishchuk]

For me, btw, the main problem with the current implementation is that it doesn't return standard errors when bearer is missing or expired, it breaks my client workflow that depends on 401 status for automatic token refreshing.