invalid_token

Docs version v1 (main) · Nauthera is pre-1.0, in a design-partner program

UserInfo refused the access token, which is missing, invalid, expired or misused (401).

#Meaning

/userinfo answers this (RFC 6750 §3.1) when no access token was sent, or the token is malformed, does not verify, has expired, was revoked or is meant for another audience. It also answers it for a DPoP-bound token sent as Bearer, or with a proof for another key (RFC 9449 §7.1). With no token at all, WWW-Authenticate is a bare Bearer challenge naming no error.

#Impact

The relying party gets no claims. An expired token is expected and is solved by a refresh; a token always refused points at the client using the wrong token, scheme or issuer.

#Diagnosis

1. Read WWW-Authenticate: its error_description says whether the token or the scheme was the problem.
2. Refusals are recorded as oauth.token.presented with a cause such as token_expired, token_signature_invalid, token_issuer_mismatch, dpop_scheme_required or dpop_binding_mismatch. They are platform records, so only platform.audit holders see them.

#Mitigation

• As a client developer: refresh or obtain a new access token; send a DPoP-bound token as Authorization: DPoP <token> with a proof from the key it is bound to; call the UserInfo endpoint of the issuer that issued the token.

#Escalation

Escalate when a freshly issued, correctly presented token is refused. Check the replicas' clocks first. Open an issue with the request id, the audit cause and the server version. Never attach the token.

Problem code runbooks · Generated from internal/runbook/problems.yaml in nauthera-server.