Perform all applicable state checks
02The authorization server must evaluate the token’s actual state. Reading a token’s claims without validating applicable conditions is not introspection success.
The authorization server returns active true and scope read. A request to write still stops at the API’s permission check; active alone is not an allow-all decision.
Source for this drawing: RFC 7662 · Read RFC section 4 ↗
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
- Audience
- The intended service or services for which a token can be used.
- Scope
- A space-separated set of permissions, interpreted within the deployment’s policy.
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
The authorization server MUST perform all applicable token-state checks. A token’s active meaning depends on the implementation and available authorization context.
- The authorization server MUST perform all applicable token-state checks. A token’s active meaning depends on the implementation and available authorization context.
- For applicable time limits, it MUST check expiration and whether the validity period has begun. If revocable, it MUST check revocation; if signed, it MUST validate the signature.
- If restricted to particular resource servers, it MUST check whether the token can be used at the resource server making this call. Not every deployment uses every listed mechanism.
- An active result supplies authorization context, not permission for every operation. The protected resource still makes the relevant authorization decision using scope, context and its own policy.
Chosen example times nbf100, now150 and exp200 are schematic seconds on one illustrative timeline, not current real timestamps. The later signed/revocable/audience-restricted example assumes all those checks apply and pass. The final write request fails because its token has only read scope even though active is true. This guide does not implement proof-of-possession key confirmation: Appendix A leaves those details to extensions.
Read the RFC section ↗