SAML Bridge for MCP

Most enterprises still use SAML 2.0 for single sign-on. MCP uses OAuth 2.0. Bridging the two requires an intermediary — an identity broker that accepts SAML assertions from the enterprise identity provider and issues OAuth tokens for MCP. The broker acts as a SAML service provider (receiving assertions from the IdP) and an OAuth authorization server (issuing tokens to MCP clients). The flow: MCP client redirects to broker's /authorize, broker redirects to enterprise IdP, user authenticates via SAML, IdP sends assertion to broker, broker validates assertion and issues OAuth authorization code, MCP client exchanges code for tokens.

Attribute mapping is where SAML-to-OAuth bridges get complicated. SAML assertions carry attributes (name, email, groups, department) in XML elements with enterprise-specific names. The broker must map these attributes to OAuth token claims. Group memberships are particularly important — they drive authorization decisions downstream. Map SAML groups to OAuth scopes or custom claims so that MCP servers can enforce access control based on the user's enterprise identity without querying the IdP directly.

Session lifetime mismatch is a subtle problem. SAML sessions often last 8 hours (the workday). OAuth access tokens should be short-lived (1 hour). Refresh tokens bridge the gap, but what happens when the SAML session expires? The user should be prompted to re-authenticate, but if the MCP client is silently refreshing tokens, the SAML session expiry is invisible. The broker must check SAML session validity on token refresh and reject the refresh if the upstream session has expired. This forces re-authentication through the IdP.