OIDC Integration & Federation

OpenID Connect (OIDC) is OAuth 2.0 with an identity layer — it adds an ID token (a signed JWT containing user identity claims) to the authorization code flow. For MCP servers, OIDC is the preferred SSO mechanism because it is natively compatible with OAuth. The MCP client requests the "openid" scope, and the authorization server returns an ID token alongside the access token. The ID token contains the user's identity (sub, email, name) and authentication metadata (auth_time, amr, nonce). The MCP server validates the ID token's signature and uses the claims for user identification.

Identity provider federation allows an MCP server to accept authentication from multiple IdPs — Okta for customer A, Azure AD for customer B, Google Workspace for customer C. The MCP server's authorization endpoint presents a discovery step ("Choose your identity provider") before redirecting to the selected IdP. After authentication, the IdP returns to the MCP server with an ID token. The server validates the token against the correct IdP's JWKS (JSON Web Key Set) endpoint, maps the claims to a local user identity, and issues an MCP session. The challenge is maintaining a trust registry of IdPs with their JWKS URIs, issuer identifiers, and claim mappings.

1. Implement OIDC discovery Fetch the IdP's /.well-known/openid-configuration endpoint to discover authorization, token, JWKS, and userinfo endpoints. Cache the discovery document with a 24-hour TTL.
2. Validate ID tokens Verify the JWT signature against the IdP's JWKS. Check iss matches the expected issuer, aud contains your client_id, exp is in the future, and nonce matches if you sent one.
3. Build the federation registry Create a configuration table mapping each trusted IdP to its issuer URI, JWKS endpoint, and claim mappings. Add an admin interface for adding and removing IdPs without redeployment.