An organization worries that an access token for its MCP server could leak from client storage or a server log. Which authorization server practice does the MCP authorization specification call for to limit the impact of a leaked token?
Select an answer to reveal the explanation.
Short Explanation
A stolen token is like a stolen parking pass: the shorter it lasts, the less the thief gets out of it. You keep access tokens short-lived, and for public clients make each refresh token single-use by rotating it. Long-lived and shared tokens just hand the thief a bigger prize.
Full Explanation
The authorization security considerations on token theft say clients and servers MUST implement secure token storage and follow OAuth best practices, authorization servers SHOULD issue short-lived access tokens to reduce the impact of leaked tokens, and for public clients authorization servers MUST rotate refresh tokens as described in OAuth 2.1. A short lifetime caps how long a stolen access token remains useful, and rotation means a stolen refresh token is invalidated the next time the legitimate client refreshes. Long-lived access tokens do the opposite, extending the attacker's window for convenience. Placing tokens in the URI query string is explicitly forbidden; MCP clients must send tokens in the Authorization header, and query strings are exactly where tokens end up in logs and browser history. A single shared organization token removes per-user accountability, makes every leak organization-wide, and turns revocation into an outage for everyone. Exam caveat: MCP servers must also never log or cache tokens carelessly, since attackers who obtain tokens cached or logged on the server can make requests that look legitimate. Operational check: decode a sample access token to confirm a short expiry, then use a refresh token twice and confirm the second use fails for a public client.