Hey All, I was looking at implementing RFC-7662 (token introspection), and had some questions and thoughts that I figured I'd put out to the group, since that RFC is nearly 10 years old and there have been many advancements in various A/S implementations since.
- The RFC suggests the endpoint be authenticated, yet what is the consideration for non-confidential clients and those that auth via PKCE? These clients cannot be reasonably expected to provide much more than their client_id, but is this enough? - https://www.oauth.com/oauth2-servers/token-introspection-endpoint/ suggests the endpoint be authenticated to avoid token fishing, yet many A/S implementations (including ours) issue access tokens in the shape of JWTs, which are, by nature, self-describing; however, 6749 does not make any specification as to token opacity or format. So we issue JWT-based access tokens, but we never tell our clients of this fact and merely use it as an implementation detail to allow for better scaling. I can't see how any party (malicious) in possession of an access token would first introspect instead of trying to tease the token apart or simply present it to a protected resource as a means to ascertain validity. With both these points in mind, I CAN see value in rate limiting the introspection endpoint on some dimension, but authentication? Thoughts? Regards, Michael
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
