Thanks Aaron, To the point of the RFC outlining the context as between a R/S and A/S - is there a valid case wherein a client would want to introspect an access token, and how would that look substantially different from this RFC? I can definitely think of a handful of scenarios, including scope and validity information. For example, were the client to not preserve the scope identified in the original token response body.
Regards, Michael On Mon, Apr 28, 2025 at 2:18 PM Aaron Parecki <aa...@parecki.com> wrote: > RFC 7662 Token Introspection is for Resource Servers to introspect tokens. > OAuth clients do not introspect access tokens, and clients should never > have any business knowing the details of what an access token represents. > > The requests to the introspection endpoint should be authenticated, but > how that is done is the business between the resource server and > authorization server, and can leverage any mechanism that meets the needs > of the deployment. > > The "token fishing" language is admittedly a bit confusing, it would > probably be better described as "token scanning". JWTs are essentially > unscannable already, as in there is basically 0% chance of someone randomly > creating a string that happens to be a valid JWT. For random-string tokens, > it is more likely that an attacker-generated random string could be a valid > token, like if you for some reason used the pattern "at-XXXXXX" for access > tokens, an attacker could generate all valid tokens and iteratively test > them at the introspection endpoint. > > Aaron > > > On Mon, Apr 28, 2025 at 2:02 PM Mike Kuredjian < > michael.kuredj...@gmail.com> wrote: > >> 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 >> >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
