# invalid_token

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](https://www.nauthera.io/docs/v1/runbooks/problems) · Generated from [`internal/runbook/problems.yaml`](https://github.com/nauthera/nauthera-server/blob/main/internal/runbook/problems.yaml) in nauthera-server.