skip to content

In an RFC 7662 introspection response for an OAuth 2.0 access token, what does the `active` member assert?

level: middleimportance: must knowfreq 58%

answer

  1. one member decides accept or reject
  2. required versus optional members
  3. a boolean, not a claim set
  4. issuance, revocation and the clock
  5. the specification says 'generally'

basics

~20 s

active is the one REQUIRED member of an RFC 7662 introspection response, and a true value generally indicates that this authorization server issued the token, it has not been revoked, and the call falls inside its validity window.

solid answer

~50 s

Introspection is the call a resource server makes when it cannot judge a token by itself: it POSTs the token to the authorization server's introspection endpoint and gets back a JSON document. `active` is the **only REQUIRED member** of that document and it is a boolean. RFC 7662 words its meaning carefully — a `true` value *will generally indicate* that the token was issued by this server, has not been revoked, and is inside its validity window — because what a server knows about its own tokens varies, so the precise state machine is the server's. Everything else is OPTIONAL: `scope`, `client_id`, `username`, `token_type`, `exp`, `iat`, `nbf`, `sub`, `aud`, `iss`, `jti`. A caller must therefore code for their absence. When the token is not live the answer is `{"active": false}` and the other members are withheld, so the caller cannot tell expired from revoked from never-issued.

code

http · 6 lines
http
POST /oauth2/introspect HTTP/1.1
Host: as.example.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic czZCaGRSa3F0Mzo3RmpmcDBaQnIxS3REUmJuZlZkbUl3

token=mF_9.B5f-4.1JqM&token_type_hint=access_token

go deeper

for a junior

Remember that the response is JSON and that one boolean, active, carries the verdict. If it is false the request is rejected and nothing else in the body matters.

for a middle

Explain the required-versus-optional split and why it constrains your code: a conforming server may return active alone, so reading scope without a presence check is a defect against the specification.

for a senior

Show that you separate liveness from permission — active true still leaves the scope and audience comparison to do — and that you fail closed when an optional member you depend on is missing.

for a principal

Treat the introspection contract as an interface agreement with the issuer: which optional members you require, what your services do when they are absent, and how much of your authorisation logic you are willing to make dependent on another team's response shape.

## The call, in one paragraph Some access tokens carry no readable content: they are just a random string, and only the issuer knows what they stand for. A resource server holding one cannot decide anything on its own, so **RFC 7662** gives it a question to ask. It POSTs the token to the authorization server's introspection endpoint as `application/x-www-form-urlencoded`, with `token` REQUIRED and `token_type_hint` OPTIONAL, and receives a JSON document — the **introspection response** — describing the token's current state. ## `active` is the gate, and it is the only guaranteed member The response has exactly one REQUIRED member. `active` is a boolean, and the whole accept-or-reject decision hangs on it. The specification's own wording is worth quoting in spirit rather than tightening: a `true` value **will generally indicate** that - the token **was issued by this authorization server**; - it **has not been revoked** by the resource owner; - the moment of the call is **inside the token's validity window** — after any issuance time and before its expiry. "Generally" is not hedging for its own sake. Servers differ in what they retain about issued tokens, so RFC 7662 describes the usual constituents of the active state and leaves the exact definition to the implementation. A caller must therefore treat `active` as **the issuer's verdict**, not as a formula it could recompute. ## Everything else is optional, and that changes how you code | member | presence | what it carries | |---|---|---| | `active` | REQUIRED | whether the server regards the token as live | | `scope` | OPTIONAL | the space-delimited scope the token carries | | `client_id` | OPTIONAL | the client the token was issued to | | `username` | OPTIONAL | a human-readable identifier for the resource owner | | `token_type` | OPTIONAL | the token's type, for example `Bearer` | | `exp`, `iat`, `nbf` | OPTIONAL | expiry, issuance and not-before times | | `sub`, `aud`, `iss`, `jti` | OPTIONAL | subject, audience, issuer and token identifier | The practical consequence is blunt: **a resource server that reads `scope` unconditionally has written a bug against the specification**, because a conforming server may answer with `active` and nothing more. Either agree with your issuer about which members it returns, or handle their absence as a deny. ## `active` decides liveness, not permission This is the second half of the question and the half candidates skip. `active: true` says the credential is live; it does not say the credential covers *this* request. The resource server still has to compare what the response tells it — the scope, the audience, the subject — against what the endpoint being called requires. A token that is perfectly live and was issued for a different purpose must still be rejected. ## What a `false` answer tells you, and what it hides When the token is not active — expired, revoked, unknown to this server, or one the caller is not entitled to ask about — the answer is `{"active": false}`. The optional members are withheld, which means the caller **cannot distinguish those cases**, and that is the point: introspection is not supposed to be a way of mapping the issuer's internal state. A caller that tries to branch on "expired versus revoked" from a `false` response is inventing information it was not given. 1. Read `active` first. If it is `false`, reject; there is nothing else to read. 2. If it is `true`, check the members the request actually needs, treating each as possibly absent. 3. Only then let the request through. ## Failure modes worth recognising - **Treating a missing member as a permissive default.** No `scope` in the response does not mean unrestricted scope; it means you were told nothing. - **Reading `active: false` as "expired".** It collapses several causes, and a revoked token looks exactly like one that never existed. - **Expecting an error instead of `false`.** An introspection call about a dead token is a *successful* call with a negative answer, not a failed one. - **Assuming the members mirror a self-contained token's claims.** The names overlap deliberately, but this document is the issuer speaking now, not a snapshot frozen when the token was minted.

  • What may a resource server conclude from `active: true` alone?
    Only that the authorization server regards the token as live right now. Authorisation is a separate step: the resource server still compares `scope`, `aud` and `sub` against what the request needs. Since those members are OPTIONAL, their absence is itself an answer and should fail the request rather than pass it.
  • Why does RFC 7662 describe `active` with "generally" rather than a fixed rule?
    Because servers differ in what they retain about their own tokens. The specification names the usual constituents — issued here, not revoked, inside the validity window — but leaves the state machine to the implementation, so a caller must treat the boolean as the issuer's verdict rather than something it could recompute.
  • What is in the body when the token is not active?
    `{"active": false}`, and in practice nothing else. Every other member is optional, and withholding them keeps introspection from becoming a way to learn about tokens the caller has no business seeing — expired, revoked and never-issued all look identical.

A door desk phoning the issuing office to ask whether a visitor pass is still on the list. The office answers yes or no; whose pass it is and which floors it opens are only worth reading once the answer is yes.

saying these in an interview costs you the question

  • Treats scope or exp as guaranteed members of the response.
  • Reads active false as proof the token merely expired.
  • Expects a revoked token to produce an error rather than active false.
  • Assumes active true also means the token covers this request.
  • Says the specification fixes exactly what active means.