Documentation
Documentation
MCP Server Setup (SAML)
Exposing your resource as an MCP server when the requesting agent's users are federated with SAML 2.0.
StreamableHTTP transport, RFC 9728 protected resource metadata, the WWW-Authenticate discovery hint, token validation and scope enforcement are identical to the OIDC path. See MCP Server Setup (OIDC) for the full multi-language server examples and metadata requirements. All of it applies unchanged.
This page covers what differs: which user the tool call runs as.
Requirements
- Implement StreamableHTTP transport (
POST /mcp) - Validate the Bearer token against the Auth Server's JWKS
- Publish RFC 9728 metadata at
/.well-known/oauth-protected-resource - Return a
WWW-Authenticatediscovery hint on 401 responses - Enforce scopes per tool
- Resolve the calling user from
sub_id, notsub← the SAML-specific step
Items 1–5 are covered in MCP Server Setup (OIDC).
Why this matters more for MCP
An MCP server is called by an agent, not by the person sitting at a browser. The token is the only thing telling you whose data the agent may touch, and every tool call (list_files, search, send_message) resolves a user before it does anything.
On a REST API a mis-resolved user leaks one endpoint's data. On an MCP server it leaks whatever the agent asks for next, because the same resolution feeds every tool. Resolve on the NameID without its issuer and an agent acting for Customer A can enumerate Customer B's records through ordinary, correctly-scoped tool calls, every response a valid 200.
Resolve on the composite identity (sub_id.issuer, sub_id.nameid, sub_id.sp_name_qualifier when present), exactly as described in REST API Setup (SAML), then scope every tool to that user.
Resolving the user in a tool handler
With the MCP SDK's StreamableHTTP transport, a tool handler receives (args, extra) and reads the bearer token off extra.requestInfo.headers.authorization. Verify it, then resolve the user from the decoded claims:
Verify the token inside each tool handler rather than only at the transport layer. A tool that skips the check is reachable by any caller who can open the MCP session.
An agent can put anything in args. If a tool accepts a userId, tenant, or account parameter and trusts it, the token's identity becomes decorative. The resolved user from sub_id is the only authority for what the call may read.
Token scopes for MCP
Unchanged from the OIDC path: request the scopes your tools require (for example mcp.access alongside your data scopes) and enforce them per tool. See MCP Server Setup (OIDC).
Next step
Run the five-step SAML flow against your MCP endpoint with the Testing Guide. If you issue your own access tokens, start with Own Auth Server.
On this page