You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/specification/draft/basic/authorization.mdx
+11Lines changed: 11 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -290,6 +290,17 @@ Servers **MUST** return appropriate HTTP status codes for authorization errors:
290
290
291
291
Implementations **MUST** follow OAuth 2.1 security best practices as laid out in [OAuth 2.1 Section 7. "Security Considerations"](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-12#name-security-considerations).
292
292
293
+
### Token Audience Binding and Validation
294
+
295
+
[RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) Resource Indicators provide critical security benefits by binding tokens to their intended
296
+
audiences **when the Authorization Server supports the capability**. To enable current and future adoption:
297
+
298
+
- MCP clients **MUST** include the `resource` parameter in authorization and token requests as specified in the [Resource Parameter Implementation](#resource-parameter-implementation) section
299
+
- MCP servers **MUST** validate that tokens presented to them were specifically issued for their use
300
+
301
+
The [Security Best Practices document](/specification/draft/basic/security_best_practices#token-passthrough)
302
+
outlines why token audience validation is crucial and why token passthrough is explicitly forbidden.
303
+
293
304
### Token Theft
294
305
295
306
Attackers who obtain tokens stored by the client, or tokens cached or logged on the server can access protected resources with
0 commit comments