Authorization Security Considerations changedspecification/draft/basic/authorization/security-considerations
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+7added
Lines−7removed
From line
11
where the diff opens
First seen
26 Aug 2026
this site's first read of the page
Recorded edits3to this page, all time
The whole hunk
from line 11, old and new numbered
/
from line 11
1111[RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) Resource Indicators provide critical security benefits by binding tokens to their intended
1212audiences **when the Authorization Server supports the capability**. To enable current and future adoption:
1313
14* MCP clients **MUST** include the `resource` parameter in authorization and token requests as specified in the [Resource Parameter Implementation](/specification/draft/basic/authorization#resource-parameter-implementation) section
14* MCP clients **MUST** include the `resource` parameter in authorization and token requests as specified in the [Resource Parameter Implementation](/specification/draft/basic/authorization.md#resource-parameter-implementation) section
1515* MCP servers **MUST** validate that tokens presented to them were specifically issued for their use
1616
17The [Security Best Practices document](/docs/draft/tutorials/security/security_best_practices#token-passthrough)
17The [Security Best Practices document](/docs/draft/tutorials/security/security_best_practices.md#token-passthrough)
1818outlines why token audience validation is crucial and why token passthrough is explicitly forbidden.
1919
2020## Token Theft
from line 57
5757
5858## Mix-Up Attacks
5959
60An attacker that controls one of the authorization servers an MCP client interacts with may attempt to have the client send it an authorization code or token issued by a different, honest authorization server (a mix-up attack, described in [RFC9207 Section 1](https://datatracker.ietf.org/doc/html/rfc9207#section-1)). [Authorization Response Validation](/specification/draft/basic/authorization#authorization-response-validation) specifies the required mitigation.
60An attacker that controls one of the authorization servers an MCP client interacts with may attempt to have the client send it an authorization code or token issued by a different, honest authorization server (a mix-up attack, described in [RFC9207 Section 1](https://datatracker.ietf.org/doc/html/rfc9207#section-1)). [Authorization Response Validation](/specification/draft/basic/authorization.md#authorization-response-validation) specifies the required mitigation.
6161
6262## Open Redirection
6363
from line 76
7676
7777## Client ID Metadata Document Security
7878
79When implementing [Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration#client-id-metadata-documents), authorization servers **MUST** consider the security implications
79When implementing [Client ID Metadata Documents](/specification/draft/basic/authorization/client-registration.md#client-id-metadata-documents), authorization servers **MUST** consider the security implications
8080detailed in [OAuth Client ID Metadata Document, Section 6](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-00#name-security-considerations).
8181Key considerations include:
8282
from line 101
101101
102102## Confused Deputy Problem
103103
104Attackers can exploit MCP servers acting as intermediaries to third-party APIs, leading to [confused deputy vulnerabilities](/docs/draft/tutorials/security/security_best_practices#confused-deputy-problem).
104Attackers can exploit MCP servers acting as intermediaries to third-party APIs, leading to [confused deputy vulnerabilities](/docs/draft/tutorials/security/security_best_practices.md#confused-deputy-problem).
105105By using stolen authorization codes, they can obtain access tokens without user consent.
106106
107107MCP proxy servers using static client IDs **MUST** obtain user consent for each
108[dynamically registered client](/specification/draft/basic/authorization/client-registration#dynamic-client-registration)
108[dynamically registered client](/specification/draft/basic/authorization/client-registration.md#dynamic-client-registration)
109109before forwarding to third-party authorization servers (which may require additional consent).
110110
111111## Access Token Privilege Restriction
from line 116
116116
117117A 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.
118118
119MCP 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](/docs/draft/tutorials/security/security_best_practices#token-passthrough) for details.
119MCP 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](/docs/draft/tutorials/security/security_best_practices.md#token-passthrough) for details.
120120
121121If 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.
122122
No line in this hunk matches that.