[OAUTH-WG] OAuth 2.0 Introspection RFC Issues

[Michael Ciarlillo <[e-mail]>]

Hello all,

I have a couple of comments/issues with the RFC at
https://tools.ietf.org/html/rfc7662.

According to Section 2.1 (Introspection Request) says that "To prevent
token scanning attacks, the endpoint MUST also require some form of
authorization to access this endpoint..." This might make sense for token
introspection requests only coming from Resource Servers, but to many
implementers it makes sense to allow Clients access to the introspection
endpoint since it would serve the same purpose (token validity checking,
particularly for refresh tokens, but also for access tokens, or identity
tokens in OpenID Connect, or possibly other token types in UMA and other
specs). Unfortunately, this means that public clients should be accounted
for in some way, as refresh tokens don't have an explicit requirement in
the OAuth 2.0 spec that they be issued only to Confidential Clients. As
such, many implementers don't feel like the Introspection spec fits well
for Client consumption because of the "MUST" requirement on authentication,
when public clients won't have a Client Secret to authenticate with.
Further, token scanning attacks would not be mitigated for authenticated
callers (be they Resource Servers or Clients).

An example of a real-world implementer discussion talking about this topic
is one I had with Kévin Chalet:
https://github.com/aspnet-contrib/AspNet.Security.OpenIdConnect.Server/pull/159

We are not the only ones who see this as a problem with the spec, and there
do not seem to be many concrete reasons for this endpoint ONLY being for
Resource Servers themselves. Can some insight into why this is the case?
Can the MUST be changed to a SHOULD with the Security Considerations
section expanded to talk about the issue? If not, is there another spec or
draft out there somewhere for OAuth token validity for which the intent is
explicitly client consumption? Any and all feedback on this would be
greatly appreciated as we develop the ASOS middleware project.

Another (small) comment on the spec: Section 2.1 (Introspection Request)
currently says that requests be HTTP POST method requests, however Section
4 (Security Considerations) mentions Authorization Servers explicitly
disallowing the GET method due to server logs. What is the requirement
here? POST with optional GET or explicitly only allowing POST requests?

Sincerely,
Michael Ciarlillo