We’re excited to announce that Stytch now supports Client ID Metadata Documents (CIMD), a new technique that makes OAuth setup simpler and more secure by letting apps automatically discover and verify clients. Instead of pre-registering or hardcoding credentials, a client can simply identify itself to an authorization server through its own hosted metadata file. This is especially useful for Model Context Protocol (MCP), where clients and servers discover each other dynamically.

In this post, we’ll cover:

• What CIMD is and why it matters
• The problem CIMD solves
• How Stytch supports CIMD today
• How to get started with CIMD in your Stytch project

What is CIMD and why it matters

Historically, OAuth integrations required developers to manually configure application information in developer portals: redirect URIs, scopes, application terms of service, and so on. These settings are served to the end user during the OAuth consent flow, enabling the user to make an informed decision about what information they were sharing and who they were sharing it with.

Earlier this year, Dynamic Client Registration (DCR) gained popularity following the rapid adoption of MCP. With DCR, the OAuth client registers itself on-the-fly, as opposed to the OAuth client developer registering their client ahead of time. However, DCR comes with quite a few security and operational headaches because the client self-identifies, phishing based attacks become much easier to launch. The MCP core maintainers have written extensively about the downsides of DCR.

CIMD is a more secure alternative to DCR. When OAuth Clients and Servers both support CIMD, OAuth clients can use public HTTPS URLs as their client IDs. OAuth servers will fetch a JSON document stored at that HTTPS URL, and use that document to identify that client's settings. End users and authorization servers can strongly trust the CIMD URL - if information is pulled from ‘https://claude.ai/oauth/client.json’ then we know that the client is ClaudeAI and not an imposter masquerading as Claude. CIMD preserves all the benefits of DCR, without the security and operational drawbacks. In short, the client’s metadata becomes discoverable and verifiable, making it possible to:

• Automate registration and validation
• Improve interoperability across identity providers and ecosystems
• Reduce operational overhead for teams onboarding new OAuth clients
• Increase confidence in the authenticity of client configurations

The problem CIMD solves

Lack of trust and verification

In multi-tenant or partner-driven environments, verifying that a client integration is valid can be difficult. Without a standard metadata document, teams rely on manual auditing or custom onboarding flows.

Simplified Client Management

Anyone that’s used DCR in production knows that DCR clients are incredibly difficult to manage with a large user base. Many clients will re-register themselves once per user, or sometimes once per session. Each registration creates a unique-yet-duplicate client ID, meaning an ever-growing list of DCR clients needs to be tracked. Duplicate clients make it difficult for IT Admins to grant (or revoke!) access. With CIMD, all installations of a client can reference a single HTTPS URL and all duplicates are eliminated.

How Stytch supports CIMD

We’ve added CIMD support into Stytch’s Connected Apps flows. Here’s what’s live now:

• CIMD discovery and validation: When a client publishes its metadata at a publicly accessible endpoint, Stytch can automatically fetch, parse, and validate that document. No manual uploads required.
• Dashboard toggle and UI support: In the Stytch dashboard under Connected Apps / Client Settings, you’ll see a new CIMD toggle. Turning it on enables Stytch to start fetching client metadata.
• Terraform support: Our Terraform modules now include options to enable or disable CIMD programmatically.
• Backward compatibility: Clients that don’t use CIMD will continue to work with manual configuration. Enabling CIMD is optional.
• Developer guide & client.dev: We’ve published a guide for more information, and created the client.dev microsite, which is designed for testing and understanding the implementation of CIMD.

“CIMD will be supported in VS Code Insiders TODAY and stable VS Code in next month’s release. Special thanks to Stytch for having a ready-to-go authorization server to test against (AFAIK - the first authorization server to EVER support CIMD)”
- Den Delimarsky, Principal Product Engineer at Microsoft

How to get started with CIMD and Stytch

1. Publish your client metadata. Create a JSON document that declares your redirect URIs, JWKS URI, grant types, and other metadata. Host it at a public URL, such as https://your-client-domain/oauth/client-metadata.json.
2. Enable CIMD from the Stytch dashboard, Management API, or Terraform. Turn on CIMD discovery for your project.
3. Initiate an OAuth Authorization Flow using the CIMD endpoint as the client_id. Stytch will fetch the CIMD document and dynamically create the client within your project.
4. Validate and correct any issues. If Stytch encounters missing or invalid fields, it will surface feedback in the dashboard logs or API response.

Why we believe in CIMD

CIMD is a foundational step toward a more interoperable OAuth ecosystem. Instead of locking developers into proprietary registration flows, CIMD makes metadata universal and portable.

Standardization over specialization: A shared metadata format helps developers focus on building, not troubleshooting configuration mismatches.

Safer client registration: Metadata can be verified automatically, reducing the risk of impersonation and misconfiguration.

Ecosystem unlock: For AI agent-based OAuth flows, multi-tenant SaaS, and open protocols like MCP, CIMD lets clients and providers verify and trust each other programmatically.

Incremental adoption: You can layer CIMD on top of your existing OAuth setup without rewriting your integration.

Frequently asked questions

Do I have to use CIMD?

No. Stytch clients without CIMD continue to work with manual configuration. CIMD is an optional enhancement.

What happens if my metadata changes?

You can update your /oauth/client-metadata.json document at any time. Stytch will periodically revalidate and refresh it.

What format is expected?

Use a JSON document that includes fields such as redirect_uris, grant_types, client_uri, and client_id. The full schema and examples are available in our documentation.

How does Stytch handle security and trust? Stytch validates metadata over HTTPS to verify that key sets and fields match expected values. You can also configure manual overrides for additional control.

How often does Stytch fetch metadata? By default, Stytch caches metadata and re-fetches periodically or when triggered manually.

Get started

CIMD is a part of Stytch Connected Apps which can be used along with Stytch’s core auth platform or with your existing auth infrastructure. And it’s free to get started!

If you’re already using Stytch Connected Apps, you can enable CIMD directly in your Stytch dashboard or API.

Docs: https://stytch.com/docs/guides/connected-apps/client-types#client-id-metadata-documents-(beta)

Examples: client.dev