OAuth 2.0 Token Introspection [RFC-7662]

[cross311]

When I clicked to create an issue, I intended to create an issue that token introspection (RFC-7662) was included in this authorization server.

However after looking a bit more, is the authenticate function intended for this? authenticate takes in an access_token and returns the database understanding of the full token generation. It has most of the information required for the RFC spec.

[maricn]

authenticate function uses req.body.access_token as you can see here: https://github.com/oauthjs/node-oauth2-server/blob/91d2cbe70a0eddc53d72def96864e2de0fd41703/lib/handlers/authenticate-handler.js#L114

However RFC-7662#section-2 defines that the endpoint for tokeninfo MUST be authenticated and has a REQUIRED POST body parameter token.

It's important to note the difference between req.body.access_token used by authenticate and req.body.token as specified by the RFC.

If you'd just use authenticate for checking the token together with endpoint protection using this library, you'd basically successfully validate any token submitted because the authenticate method would only check if exactly one of {header (Authorization), body param (access_token), query param (access_token)} has token, and it would use that one to verify it. In case you would implement client_credentials, or password_grant as the protection mechanism for the Token Introspection endpoint (as required by the RFC-7662#section-4, also below), and pass the request for the subsequent validation using authenticate method - it would return success for any valid token used to authenticate the Token Introspection endpoint access, without looking into the HTTP req body parameter token.

RFC-7662#section-2.1:

   The protected resource sends a parameter
   representing the token along with optional parameters representing
   additional context that is known by the protected resource to aid the
   authorization server in its response.

   token
      REQUIRED.  The string value of the token.  For access tokens, this
      is the "access_token" value returned from the token endpoint
      defined in OAuth 2.0 [RFC6749], Section 5.1.  For refresh tokens,
      this is the "refresh_token" value returned from the token endpoint
      as defined in OAuth 2.0 [RFC6749], Section 5.1.  Other token types
      are outside the scope of this specification.

RFC-7662#section-4:

   If left unprotected and un-throttled, the introspection endpoint
   could present a means for an attacker to poll a series of possible
   token values, fishing for a valid token.  To prevent this, the
   authorization server MUST require authentication of protected
   resources that need to access the introspection endpoint and SHOULD
   require protected resources to be specifically authorized to call the
   introspection endpoint.  The specifics of such authentication
   credentials are out of scope of this specification, but commonly
   these credentials could take the form of any valid client
   authentication mechanism used with the token endpoint, an OAuth 2.0
   access token, or other HTTP authorization or authentication
   mechanism.

UPDATE: Also, any token of refresh_token type will result in an error:

{"statusCode":400,"status":400,"code":400,"message":"Invalid request: token of wrong type","name":"invalid_request"}

That is also in conflict with RFC-7662 specs, as the Token Introspection endpoint should support both access and refresh tokens.