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
@@ -296,6 +296,17 @@ Servers **MUST** return appropriate HTTP status codes for authorization errors:
296
296
297
297
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).
298
298
299
+
### Token Audience Binding and Validation
300
+
301
+
[RFC 8707](https://www.rfc-editor.org/rfc/rfc8707.html) Resource Indicators provide critical security benefits by binding tokens to their intended
302
+
audiences **when the Authorization Server supports the capability**. To enable current and future adoption:
303
+
304
+
- MCP clients **MUST** include the `resource` parameter in authorization and token requests as specified in the [Resource Parameter Implementation](#resource-parameter-implementation) section
305
+
- MCP servers **MUST** validate that tokens presented to them were specifically issued for their use
306
+
307
+
The [Security Best Practices document](/specification/draft/basic/security_best_practices#token-passthrough)
308
+
outlines why token audience validation is crucial and why token passthrough is explicitly forbidden.
309
+
299
310
### Token Theft
300
311
301
312
Attackers who obtain tokens stored by the client, or tokens cached or logged on the server can access protected resources with
0 commit comments