OAuth Client Registration

Cognism's MCP server supports two ways for a client application to register and obtain OAuth credentials: Dynamic Client Registration (DCR) and CIMD (pre-registered static clients). Which one applies depends on what kind of integration you're building.

Dynamic Client Registration (DCR)

DCR lets a client self-register against the MCP server's /register endpoint (per RFC 7591) without any manual onboarding step.

How it works
• Your client POSTs a registration request, including the redirect_uri it wants to use.
• Cognism issues a random client_id. No client_secret is issued — all DCR clients are public clients, authenticated via PKCE and redirect-URI matching, not a shared secret.
• The registration is temporary (time-limited and automatically renewed/expired), not a permanent record.

Limitation
• Your redirect_uri must match an entry on Cognism's DCR allow-list. This list is intentionally small and currently limited to a few large, reputable platforms (e.g. Claude, ChatGPT, Microsoft Copilot/consent).
• This is a deliberate security boundary, not an oversight: the /register endpoint is unauthenticated, so anyone can call it. The allow-list of permitted redirect destinations is the only thing standing between open self-service registration and anyone being able to mint a client that redirects auth codes anywhere. Because of that, it's reserved for platforms whose domain itself represents an established trust boundary — it is not available on request for individual customer integrations or internal gateways.

Use DCR if: you're a widely-used, Cognism-reviewed marketplace/platform and your redirect endpoint is already allow-listed (or you're requesting to become one, subject to Cognism's review).

CIMD (pre-registered static clients)

CIMD ("Client ID Metadata Document" convention) is the path for integrations that don't qualify for the open DCR allow-list — most customer-specific gateways and internal tools.

How it works
• There is no self-service endpoint. A Cognism admin manually adds your client to server-side configuration ahead of time: a client_id (expressed as a URL you control) and the exact redirect_uri(s) you'll use.
• Like DCR, these are public clients — no client_secret is issued or required.
• Once configured, the registration is permanent (until explicitly changed) and the redirect URI is trusted outright — there's no per-request allow-list check, because the entry itself was individually vetted.

Limitation
• Requires a manual onboarding step with Cognism before you can authenticate — you cannot self-register. Expect to provide:
  ◦ Your client identifier URL (ideally a URL that serves a fetchable metadata document describing your client, per the CIMD convention)
  ◦ The exact redirect URI(s) your gateway will use
• Any change to your redirect URI requires Cognism to update the configuration again.

Use CIMD if: you're integrating a customer-specific or internal MCP gateway/client that isn't on the DCR allow-list. This is the path most customer integrations should use.

Summary

DCR: Self-service, open endpoint. Onboarding required: No. client_secret: Never issued. Redirect URI trust: Must match a small, Cognism-maintained allow-list. Lifetime: Temporary, auto-expiring. Typical user: Large, pre-vetted marketplace platforms.

CIMD: Manual, admin-configured. Onboarding required: Yes — contact Cognism. client_secret: Never issued. Redirect URI trust: Individually pinned per client by an admin. Lifetime: Permanent until changed. Typical user: Individual customer gateways / internal tools.

If your redirect URI isn't on the DCR allow-list, don't try to force a DCR registration — reach out to your Cognism contact to get a CIMD client provisioned instead.