Inactive results differ from unauthorized calls
04A validly authorized inspection that finds no usable token is different from a caller that is not allowed to use introspection at all.
This separate failure concerns the credential authorizing the lookup, not the submitted token’s activity. The request stops before exposing metadata.
Source for this drawing: RFC 7662 · Read RFC section 2.3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
- Inactive result
- A normal authorized response with active false.
- Lookup authorization
- Permission to call the introspection endpoint, separate from the token being queried.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
For a properly authorized call, an inactive token, a token unknown to this server or a token the resource is not allowed to inspect MUST produce active false.
- For a properly authorized call, an inactive token, a token unknown to this server or a token the resource is not allowed to inspect MUST produce active false.
- The authorization server SHOULD NOT include other information about an inactive token, including why it is inactive. The ordinary response shown is HTTP200 with {"active":false}.
- Invalid client credentials used for introspection produce HTTP401 under RFC6749§5.2. An invalid or insufficiently privileged Bearer lookup credential produces HTTP401 as described by RFC7662§2.3.
- A token’s invalid state is not itself an introspection endpoint authorization error. Do not substitute HTTP401 for a properly authorized negative token-state result.
The refused-call scene stops before reading token metadata; it shows the introspection response, not the protected API’s response to its end user. RFC7662’s reference to RFC6750§3 does not change its explicit401 wording here; this is not a claim about every resource-server error in other contexts. active false hides the precise reason and can be resource-specific. Unknown/foreign-token privacy is not proof that a token never existed anywhere.
Read the RFC section ↗