Notifications
Clear all
Topic starter
07/06/2026 8:35 pm
TL;DR: CIMD makes the OAuth client itself a discoverable HTTPS document, letting MCP servers validate redirect URIs, auth method, and key location on demand while Python clients use Authorization Code + PKCE and private_key_jwt, according to WorkOS. The control shift is from shared secrets and per-server registration toward exact-match metadata and key publication, which raises the bar for identity hygiene.
NHIMG editorial — based on content published by WorkOS: MCP auth for AI agents and CIMD-based OAuth client registration in Python
Questions worth separating out
Q: How should security teams govern MCP client identity when using CIMD?
A: Treat the CIMD document as a governed identity source, not a developer convenience.
Q: Why do MCP clients increase the importance of redirect URI hygiene?
A: Because the authorization code can be stolen if a server sends it to the wrong callback.
Q: What do teams get wrong about private_key_jwt in MCP flows?
A: They often assume it replaces lifecycle management.
Practitioner guidance
- Pin exact-match identity fields Require byte-for-byte validation for client_id, redirect_uri, iss, and aud across every MCP integration.
- Publish and rotate keys as a lifecycle object Host JWKS on stable HTTPS infrastructure, publish the next public key before changing the signing key, and keep the old key available until all issued assertions and tokens age out.
- Scope MCP clients by server and purpose Avoid treating one client identity as a universal connector for every MCP server.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step Python code for generating RSA keys, publishing JWKS, and creating the CIMD JSON document.
- Client-side examples for constructing the authorization request, including PKCE parameters and redirect handling.
- Token endpoint exchange details for private_key_jwt, including JWT claims, signing flow, and request formatting.
- Server-side metadata validation and JWT verification examples for implementations that need to enforce the full trust chain.
👉 Read WorkOS's guide to MCP auth for AI agents using CIMD →
CIMD for MCP clients: what changes for AI agent OAuth trust?
Explore further
08/06/2026 8:12 am
CIMD shifts MCP from static registration to runtime identity discovery. That is useful, but it also means the trust boundary now lives in a hosted metadata document that can be cached, re-fetched, or misconfigured. The identity control plane becomes part of the attack surface, so practitioners need to treat exact-match URL governance as a core requirement, not a documentation detail.
A few things that frame the scale:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How do you know an MCP token is safe to accept for tool access?
A: Check more than signature validity. The token must match the expected issuer, audience, and time window, and the client assertion should be tied to the correct key in JWKS. If any of those checks are loose, the server may accept a valid token from the wrong trust context.
👉 Read our full editorial: CIMD for MCP clients shows where OAuth trust now shifts
