active
Registry Context
`active` tells the caller whether the presented token is currently active. Every introspection response includes this Boolean member. A properly authorized request returns `active: false` when the token is inactive, nonexistent on that server, or unavailable for introspection by that protected resource.
Technical Summary
RFC 7662 Section 2.2 defines `active` as a REQUIRED top-level Boolean member of an introspection response. The authorization server MUST set it to `false` when a properly authorized introspection request concerns an inactive or nonexistent token, or when the protected resource may not introspect that token.
When Used
Used in OAuth 2.0 token introspection responses to indicate whether the presented token is currently active.
Normative Requirements
Authorization servers
RFC 7662 - Section 2.2
return an introspection response with `active` set to `false`.
Condition: when the introspection call is properly authorized but the token is inactive, does not exist on that server, or the protected resource is not allowed to introspect that particular token
"the authorization server MUST return an introspection response with the \"active\" field set to \"false\"."
RFC 7662 - Section 2.2
include `active` as a top-level Boolean member of the introspection response.
Condition: when returning an OAuth 2.0 token introspection response
`active` — "REQUIRED. Boolean indicator of whether or not the presented token is currently active."
RFC 7662 - Section 2.2
include additional information about an inactive token, including why it is inactive.
Condition: when returning an introspection response for an inactive token
"the authorization server SHOULD NOT include any additional information about an inactive token, including why the token is inactive."
Validation Guidance
Reject or flag an introspection response that omits the top-level Boolean `active` member.
Verify that a properly authorized request produces `active: false` when the token is inactive, nonexistent on that server, or unavailable for introspection by that protected resource.
Flag additional token information in a response for an inactive token because it can disclose authorization-server state.
Security Notes
RFC 7662 - Section 2.2
To avoid disclosing too much authorization-server state to a third party, the authorization server SHOULD NOT provide additional information about an inactive token, including the reason it is inactive.
Reference
Details
- Entry Id
active- Name
active- Description
Token active status- Change Controller
IESG- Reference
RFC7662 - Section 2.2