Why must the RFC 7662 introspection endpoint authorize its callers, and what does an open one hand an attacker?

## What the endpoint is, from an attacker's point of view Introspection is a question-answering service about credentials. Present a string, learn whether it is live and, when it is, learn what it is for. That is exactly what a resource server needs — and exactly what an attacker who has picked up a token string would like. The endpoint is therefore a security surface in its own right, and RFC 7662 treats it as one: the call goes over TLS, and the endpoint **MUST require some form of authorization** before it answers. ## What "authorized" means here The specification deliberately leaves the mechanism open and the requirement closed. Two shapes are named: - **Client authentication** as RFC 6749 defines it, the same credentials a client uses at the token endpoint. - **A separate access token** presented by the protected resource that is doing the asking. The point is not which one you pick. The point is that the server knows who is asking before it says anything, because every property that makes introspection useful makes an anonymous version dangerous. ## The two harms, kept apart | an open endpoint gives an attacker | why it matters | |---|---| | a **liveness oracle** — is this string a real, live token? | a pile of strings from a log, a cache or a scan becomes a shortlist of working credentials, with no rate limit imposed by the resource server | | **disclosure about the token** — `scope`, `client_id`, `username`, `sub`, `aud`, expiry | the identity of a resource owner and the extent of a grant leak to a party with no relationship to either | The first is the reason the specification's security considerations single out token scanning. The second is a privacy failure that survives even if the attacker never manages to use the token: learning that a particular user has an active grant, to a particular client, with particular scope, is information that was never theirs to have. ## Authorization shapes the answer, not just the door A subtlety worth carrying into an interview: a caller may be allowed through the door and still not be entitled to ask about a *particular* token. RFC 7662 lets the server answer such a caller with `active: false`. Read that as a design pattern rather than a quirk: 1. A truthful "this token exists but is not yours" would still confirm the string is live. 2. Collapsing unknown, expired, revoked and not-yours into one `false` answer denies the caller anything it can build on. 3. The entitled caller is unaffected, because for its own tokens the answer is the real one. The same instinct explains why a well-behaved server withholds the optional members on a `false` answer: nothing beyond the verdict is owed to someone who was told no. ## How this is commonly got wrong - **"It is safe because you need a token to query it."** That inverts the problem. The string you are querying *is* the attacker's input; it is not a credential for the endpoint. Something separate has to authenticate the caller. - **"Authentication there is just about metering."** Rate limiting is a benefit, but the requirement is about who may learn what, not about load. - **"The response reveals nothing useful."** A boolean about an arbitrary string is one of the most useful things an attacker can be handed for free. - **Confusing the two validations.** Authorizing the *caller* and evaluating the *token presented* are different checks, and an endpoint that does only the second will answer anyone. ## Where the boundary of this question sits This is the specification's requirement and the reason for it. How a particular deployment satisfies it — which credential the resource server holds, how it is rotated, how the call is protected in a service mesh — belongs to the people building the resource server, not to the wire contract. What you should be able to state from the specification alone is the requirement, the two harms it prevents, and the fact that `active: false` doubles as the safe answer to a caller that has no business knowing.