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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
