HTTP Basic Auth support for introspection

[Abhishek8394]

Expanding upon the issue #529

It seems that introspection endpoint is not allowing client authentication via HTTP Basic auth. As mentioned in the comments in the code at introspect.py#L13
The RFC allows for HTTP basic auth: https://tools.ietf.org/html/rfc7662#section-2.1

It seems that the authentication is bound to access tokens. This is a problem because the only straight forward way to get access tokens is using client_credentials grant type. But currently apps are allowed only one grant type.

Reproducing issue

1. Create an confidential application with grant type authorization_code
2. Get an access token for some user with respect to the newly created app.
3. send introspection request

import requests
import base64
CLIENT_ID='aa'
CLIENT_SECRET='aa'

def introspect(access_token):
	payload = {
		'token': access_token
	}
	auth = base64.b64encode((CLIENT_ID + ':' + SECRET).encode())
	resp = requests.post('http://localhost:8000/o/introspect/', payload, 
		headers={
			'Authorization': 'Basic ' + auth.decode('latin-1')
		})
	return resp

print(introspect('tokenhere').text)

There is a workaround proposed for going into django admin and creating an access token for the app but that wouldn't scale.

An alternative would be to use the setting for resource auth token and exclusively allow it only for introspection routes. That might work too, but it would have you leak your introspection token across several resource services.

I would like to work on this if this qualifies as a bug/issue.

[JonathanHuot]

Also oauthlib supports introspection since 3.x, I'd suggest to move the DOT code to that. You benefit of the RequestValidator.authenticate_client for this endpoint automatically.

[Abhishek8394]

Oh yes, I did see it in oauthlib. I'll try to get a pr for it over the weekend.

…

[Abhishek8394]

When trying to switch to oauthlib implementation, current tests for introspection fail because instead of raising an exception, oauthlib returns a 401 response on invalid clients. But tests simply expect a {"active":false} in response. Should I try to raise an error myself to satisfy existing tests or modify tests to expect an exception?

[JonathanHuot]

The expected response is 401, as specified by the specification. However, I guess the DOT changelog/semver should highlight this breaking change.

Spec https://tools.ietf.org/html/rfc7662:

2.3. Error Response
If the protected resource uses OAuth 2.0 client credentials to
authenticate to the introspection endpoint and its credentials are
invalid, the authorization server responds with an HTTP 401
(Unauthorized)

[Abhishek8394]

Got it. Also currently OAuth2Validator.authenticate_client does not support authenticating clients with access token. However the RFC says that bearer tokens are also allowed (For introspection at least) and in case of expired tokens, we send a 200: {"active": false} response. If we were to allow bearer tokens, there are two issues:

1. How would we (if we should) know that the token being introspected in the payload indeed belongs to the app that the bearer tokens claims to be. For e,g: App B can try to introspect App A's tokens using any valid access token.

2. We need to introduce a new default introspection scope for allowing bearer tokens to introspect.

I have basic auth working by using oauthlib's introspection implementation. I can work on including client auth using bearer token in the same pull request if we can sort out the issues mentioned above.

[mike42smith]

@Abhishek8394:
I am currently also interested in a solution to access to the introspection endpoint by client_id and client_secret (HTTP Basic Authentication). Would you share your solution with us?

Further I see the same issue that you mentioned with the missing test what application the access token belongs to. However, this shouldn’t be that problem because the access token is generally linked to the application it belongs to. There might just the question where is the right point in code to implement this.

Thanks

[Abhishek8394]

I was trying to make introspection use the oauthlib implementation. It breaks quite a few tests. I can however get a quick patch by end of week for just client auth in current introspection implementation.

[mike42smith]

Thanks.

By the way, I tested the following code successfully to verify that the bearer token of the application and the access token of the user belongs to the same application (client_id).

I would appreciate for any suggestions to improve this approach.
`
@method_decorator(csrf_exempt, name="dispatch")
class IntrospectTokenView(BaseIntrospectTokenView):

def get_token_response(self, token_value=None):
    """
    To check that the token_value belongs to the application that sends a request to the introspection endpoint.
    The bearer token in the header of request is primary validated by the authorization process on this endpoint.
    Further the application (client_id) of both tokes has to be the same, otherwise response a 401.
    Right now it works only with bearer token requests on the introspection endpoint,
    not with other auth methods like credentials.
    """
    bearer_token = self.request.headers.get('Authorization').split('Bearer ', 1)[1]

    tokens = get_access_token_model().objects.filter(token__in=[token_value, bearer_token])

    if tokens.count() < 2 or tokens[0].application.client_id != tokens[1].application.client_id:
        return HttpResponse(
            content=json.dumps({"active": False}),
            status=401,
            content_type="application/json"
        )

    token = [item for item in tokens if item.token == token_value][0]

    if token.is_valid():
        data = {
            "active": True,
            "scope": token.scope,
            "exp": int(calendar.timegm(token.expires.timetuple())),
        }
        if token.application:
            data["client_id"] = token.application.client_id
        if token.user:
            data["username"] = token.user.get_username()
        return HttpResponse(content=json.dumps(data), status=200, content_type="application/json")
    else:
        return HttpResponse(content=json.dumps({
            "active": False,
        }), status=200, content_type="application/json")

`

[Abhishek8394]

So the current pull request only fixes the issue of authenticating client. I have left out the port to oauthlib's implementation of introspection.

Thanks.

By the way, I tested the following code successfully to verify that the bearer token of the application and the access token of the user belongs to the same application (client_id).

I would appreciate for any suggestions to improve this approach.

• If authenticated with access token, the request method already has an attribute set to reflect the user id of the bearer token, so you need not parse it again. In case of HTTP basic auth that information is not available. You might have to parse the HTTP basic auth string to extract it - there are methods implemented for this. Or there can be client id in request body itself. Ideally irrespective of how client is authenticated, the client id must be available in request object.
• Instead of querying for two tokens, simply query the token being introspected. Then make sure the token was issued by client id retrieved from previous step.
• Again, ideally this feature would be added in oauthlib first and then DOT should use that implementation.