TokenIntrospectionRequest is lenient on authorization / authentication

[Okke Harsta]

The Token Introspection spec https://tools.ietf.org/html/rfc7662 states: To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint.

The implementation in TokenIntrospectionRequest is very lenient as the following test demonstrates:

    @Test
    public void introspectContract() throws MalformedURLException, ParseException {
        HTTPRequest request = new HTTPRequest(POST, new URL("http://localhost:8080/introspect"));
        request.setContentType(CommonContentTypes.APPLICATION_URLENCODED);
        request.setQuery("token=123456");
        //https://tools.ietf.org/html/rfc7662 is vague about the authorization requirements, but apparently this is ok
        TokenIntrospectionRequest.parse(request);
    }

The https://tools.ietf.org/html/rfc7662 spec is also vague about the exact details, so the implementation could be considered correct.

Proposal is add functionality to easily enforce one of the described authorization mechanism as documented in the JavaDoc of TokenIntrospectionRequest.

[Vladimir Dzhuvinov]

Hi Okke and thanks for the feedback.

How do you see this enforcement? On the client or server side?

In the Connect2id server we simply check if there is client auth / token in the parsed request, and if there is none, the server returns 401 Unauthorized.

https://connect2id.com/products/server/docs/api/token-introspection#introspect-endpoint-post

[Okke Harsta]

Server side, I’m using the oauth2-oidc-sdk library to implement a OpenID Connect server and yes I could do the check myself, but I was wondering if the lenient implementation in TokenIntrospectionRequest is a deliberate choice or an omission?

[Vladimir Dzhuvinov]

The spec says this:

TLS:

The introspection endpoint MUST be protected by a transport-layer security mechanism as described in Section 4.

"Some form of" authZ, so the exact "how" is left out of scope for the spec. The SDK allows for authZ via token or client auth, but doesn't enforce one or the other to be present and also allows the constructor and parse methods to be reused / overridden.

To prevent token scanning attacks, the endpoint MUST also require some form of authorization to access this endpoint, such as client authentication as described in OAuth 2.0 [RFC6749] or a separate OAuth 2.0 access token such as the bearer token described in OAuth 2.0 Bearer Token Usage [RFC6750]. The methods of managing and validating these authentication credentials are out of scope of this specification.

Let’s also look at the “to prevent token scanning attacks, the endpoint MUST also require some form of authorization” statement and ask:

Resources that are protected by bearer tokens - do they also require additional client authZ to prevent token scanning attacks?

To me this is nonsense. Tokens must have sufficient randomness to prevent any practical guessing. I.e. you shouldn’t rely on the randomness of an additional token or secret to ensure the combined randomness of token + secret is practically impossible to guess.

The additional authZ makes sense in a situation when a bearer token is leaked and you want to prevent unauthorized parties (e.g. not the resource server) from inspecting it.