Authorization changedspecification/2025-11-25/basic/authorization
Nearest release: v2.1.305, published under an hour before upstream edited the page. Shown because the two are within 24 hours of each other. Nothing here says the release caused the edit.
Upstream edited this page at 20 Oct 2026 20:02 UTC, give or take a minute or two: the time comes from Anthropic’s own sitemap rather than from a commit. This site recorded the change at 22 Oct 2026 20:37 UTC.
Upstream edited
Recorded here
Lines+5added
Lines−5removed
From line
340
where the diff opens
First seen
26 Aug 2026
this site's first read of the page
Recorded edits4to this page, all time
The whole hunk
from line 340, old and new numbered
/
from line 340
340340
341341This approach minimizes user friction while following the principle of least privilege.
342342The `scopes_supported` field is intended to represent the minimal set of scopes necessary
343for basic functionality (see [Scope Minimization](/specification/2025-11-25/basic/security_best_practices#scope-minimization)),
343for basic functionality (see [Scope Minimization](/specification/2025-11-25/basic/security_best_practices.md#scope-minimization)),
344344with additional scopes requested incrementally through the step-up authorization flow steps
345345described in the [Scope Challenge Handling](#scope-challenge-handling) section.
346346
from line 564
564564* MCP clients **MUST** include the `resource` parameter in authorization and token requests as specified in the [Resource Parameter Implementation](#resource-parameter-implementation) section
565565* MCP servers **MUST** validate that tokens presented to them were specifically issued for their use
566566
567The [Security Best Practices document](/specification/2025-11-25/basic/security_best_practices#token-passthrough)
567The [Security Best Practices document](/specification/2025-11-25/basic/security_best_practices.md#token-passthrough)
568568outlines why token audience validation is crucial and why token passthrough is explicitly forbidden.
569569
570570### Token Theft
from line 665
665665
666666### Confused Deputy Problem
667667
668Attackers can exploit MCP servers acting as intermediaries to third-party APIs, leading to [confused deputy vulnerabilities](/specification/2025-11-25/basic/security_best_practices#confused-deputy-problem).
668Attackers can exploit MCP servers acting as intermediaries to third-party APIs, leading to [confused deputy vulnerabilities](/specification/2025-11-25/basic/security_best_practices.md#confused-deputy-problem).
669669By using stolen authorization codes, they can obtain access tokens without user consent.
670670
671671MCP proxy servers using static client IDs **MUST** obtain user consent for each dynamically
from line 678
678678This vulnerability has two critical dimensions:
679679
6806801. **Audience validation failures.** When an MCP server doesn't verify that tokens were specifically intended for it (for example, via the audience claim, as mentioned in [RFC9068](https://www.rfc-editor.org/rfc/rfc9068.html)), it may accept tokens originally issued for other services. This breaks a fundamental OAuth security boundary, allowing attackers to reuse legitimate tokens across different services than intended.
6812. **Token passthrough.** If the MCP server not only accepts tokens with incorrect audiences but also forwards these unmodified tokens to downstream services, it can potentially cause the ["confused deputy" problem](#confused-deputy-problem), where the downstream API may incorrectly trust the token as if it came from the MCP server or assume the token was validated by the upstream API. See the [Token Passthrough section](/specification/2025-11-25/basic/security_best_practices#token-passthrough) of the Security Best Practices guide for additional details.
6812. **Token passthrough.** If the MCP server not only accepts tokens with incorrect audiences but also forwards these unmodified tokens to downstream services, it can potentially cause the ["confused deputy" problem](#confused-deputy-problem), where the downstream API may incorrectly trust the token as if it came from the MCP server or assume the token was validated by the upstream API. See the [Token Passthrough section](/specification/2025-11-25/basic/security_best_practices.md#token-passthrough) of the Security Best Practices guide for additional details.
682682
683683MCP servers **MUST** validate access tokens before processing the request, ensuring the access token is issued specifically for the MCP server, and take all necessary steps to ensure no data is returned to unauthorized parties.
684684
685685A MCP server **MUST** follow the guidelines in [OAuth 2.1 - Section 5.2](https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-13.html#section-5.2) to validate inbound tokens.
686686
687MCP servers **MUST** only accept tokens specifically intended for themselves and **MUST** reject tokens that do not include them in the audience claim or otherwise verify that they are the intended recipient of the token. See the [Security Best Practices Token Passthrough section](/specification/2025-11-25/basic/security_best_practices#token-passthrough) for details.
687MCP servers **MUST** only accept tokens specifically intended for themselves and **MUST** reject tokens that do not include them in the audience claim or otherwise verify that they are the intended recipient of the token. See the [Security Best Practices Token Passthrough section](/specification/2025-11-25/basic/security_best_practices.md#token-passthrough) for details.
688688
689689If the MCP server makes requests to upstream APIs, it may act as an OAuth client to them. The access token used at the upstream API is a separate token, issued by the upstream authorization server. The MCP server **MUST NOT** pass through the token it received from the MCP client.
690690
No line in this hunk matches that.