The MCP client cannot get a client ID

If your authorization server is Microsoft Entra ID

1. 1 Expect no registration endpoint. Microsoft's own MCP guidance says so plainly: many providers don't support Dynamic Client Registration, Entra ID among them, and where it is unavailable you preconfigure the client with a client ID.
2. 2 Create an app registration for the MCP server and expose at least one delegated scope on it — api://<client-id>/user_impersonation is what App Service creates for you. Then add the MCP client's own Entra application id to preAuthorizedApplications for that scope. Skip the pre-authorization and a client that never surfaces an interactive login, such as GitHub Copilot in VS Code, fails on consent instead of on registration.
3. 3 Give the client that pre-registered client ID: oauth.clientId in mcp.json for VS Code, the OAuth Client ID field on a Claude custom connector, claude mcp add --client-id for Claude Code.

// .vscode/mcp.json
{
  "servers": {
    "my-server": {
      "type": "http",
      "url": "https://your-server.example.com/mcp",
      "oauth": { "clientId": "00000000-1111-2222-3333-444444444444" }
    }
  }
}

If your authorization server is Okta

1. 1 Expect the client to try registration and be refused. Okta implements RFC 7591 and its authorization server metadata advertises a registration_endpoint of https://{yourOktaDomain}/oauth2/v1/clients, so the client tries it rather than skipping it. The POST is then rejected, because Okta documents that endpoint as requiring the okta.clients.register scope. There is no anonymous registration.
2. 2 Create the OAuth app in Okta yourself and register every redirect URI the client will actually use. VS Code requires two: http://127.0.0.1:33418 and https://vscode.dev/redirect. Hosted Claude surfaces use https://claude.ai/api/mcp/auth_callback. Claude Code takes a loopback redirect on an ephemeral port, so pin the port with claude mcp add --callback-port 8080 and register http://localhost:8080/callback rather than trying to allow every port.
3. 3 Hand that client ID to the client. You can instead stand up a /register shim that forwards to Okta with your API token attached, and people do — but then every MCP client that reaches your server mints a real app in your Okta org, and you own that lifecycle.

If your authorization server is Auth0

1. 1 Turn the tenant flag on. Auth0 accepts open registration at POST /oidc/register with no access token, but documents Dynamic Client Registration as disabled by default for all tenants. Enable it at Dashboard > Settings > Advanced, or PATCH /api/v2/tenants/settings with the enable_dynamic_client_registration flag.
2. 2 Configure default permissions too, because the flag alone is not enough. Every app created by registration is a third-party application with a tpc_ client ID prefix, and Auth0 is explicit that without default permissions such a client can access no API at all. Set default permissions for third-party applications on the API your MCP server represents before you turn registration on, or registration succeeds and every tool call still comes back unauthorized.
3. 3 If registration used to work and stopped, check the two limits rather than the flag: /oidc/register is rate-limited to 5 requests per second per tenant, and a Tenant Access Control List rule carrying the dcr scope can block requests to it. Note also that clients created this way only get authorization_code and refresh_token — client_credentials is not available through registration.

curl --request PATCH \
  --url 'https://{yourDomain}/api/v2/tenants/settings' \
  --header 'authorization: Bearer {YOUR_MANAGEMENT_API_TOKEN}' \
  --header 'content-type: application/json' \
  --data '{ "flags": { "enable_dynamic_client_registration": true } }'

If your authorization server is Keycloak

1. 1 Expect the anonymous form to be off. Keycloak implements OIDC Dynamic Client Registration at /realms/<realm>/clients-registrations/openid-connect and advertises it in the realm's /.well-known/openid-configuration, so the client tries it — but an MCP client needs the anonymous form, and the docs state that the Trusted Hosts policy allows no host by default, which leaves anonymous client registration disabled in practice.
2. 2 Either add the client's hosts and redirect-URI domains under Clients > Client registration > Client Registration Policies > Trusted Hosts, or create the client in the admin console and give the MCP client its client ID. Trusted Hosts also constrains the redirect URIs a registered client can use, so a desktop client redirecting to loopback won't pass a policy scoped to public hostnames.
3. 3 Check two more anonymous-registration policies after Trusted Hosts. Max Clients Policy rejects registration once the realm holds 200 clients, which is the default for anonymous registrations. Client Scope Policy allows only the realm's default client scopes, so a client requesting the scope you defined for the MCP server is refused until you add it.

If your authorization server is an Amazon Cognito user pool

1. 1 Expect no registration endpoint to advertise. AWS's endpoint reference for a user pool covers /oauth2/authorize, /oauth2/token, /oauth2/userInfo, /oauth2/revoke, the IdP-response endpoints, and the SAML endpoints, and OIDC discovery — no registration endpoint appears on it. Discovery is OIDC only, and it sits on a different host from the rest: https://cognito-idp.REGION.amazonaws.com/USER_POOL_ID/.well-known/openid-configuration. There is no RFC 8414 document, so a client that probes only /.well-known/oauth-authorization-server finds nothing at all.
2. 2 Create an app client per MCP client, with that client's callback URL and no secret — MCP clients are public clients using PKCE. Mind the constraint AWS documents on callback URLs: HTTPS is required, and http://localhost is the only exception, so a client whose redirect is an IP loopback — VS Code requires http://127.0.0.1:33418 — falls outside it.
3. 3 Put the returned client ID in the client's config. If you need one client identity to cover many MCP clients, put an authorization server in front of the MCP route instead of writing a /register shim that calls CreateUserPoolClient: a shim hands anyone who can reach it the ability to create app clients in your pool.

aws cognito-idp create-user-pool-client \
  --user-pool-id us-east-1_EXAMPLE \
  --client-name "Claude connector" \
  --no-generate-secret \
  --callback-urls "https://claude.ai/api/mcp/auth_callback" \
  --allowed-o-auth-flows code \
  --allowed-o-auth-scopes openid profile \
  --allowed-o-auth-flows-user-pool-client

If your identity provider has no dynamic registration and you don't want to pre-register an app for every client that connects

1. 1 Let the gateway own registration. For its MCP routes it is both the OAuth 2.1 resource server and the authorization server: it accepts RFC 7591 registration at /oauth/register, and with CIMD enabled it advertises client_id_metadata_document_supported: true and accepts URLs as client_id values — so a client registers dynamically or presents a Client ID Metadata Document URL, and either works.
2. 2 Delegate browser identity to an OIDC identity provider you configure: Auth0, Okta, or any provider with OIDC discovery. The identity provider authenticates the user, and the gateway then issues its own bearer token to the MCP client. The identity provider never sees the MCP client and never has to issue it a client ID, so its lack of registration stops being the blocker.
3. 3 On the upstream side, choose how the gateway registers as an OAuth client. clientRegistration: { mode: "auto" } publishes a per-upstream Client ID Metadata Document and falls back to RFC 7591 if the upstream won't accept a URL client ID; mode: "manual" uses a pre-registered clientId and clientSecret for upstreams that require an approved client.

Something else

Whatever your authorization server is, the fix has three shapes and you need only one. Pre-register the OAuth client and configure its client_id in the MCP client. Support Client ID Metadata Documents, so the client can present a URL instead of an id it had to be given. Or put something in front of the MCP route that owns client registration itself, and delegate user identity to your provider behind it. Read the metadata document from that curl and pick the shape your provider can do — and if it advertises a registration_endpoint that returns 401 or 403, the endpoint is gated rather than missing, so the setting to find is whichever policy decides who can register. Discount any advice that calls your provider non-conformant for lacking registration: it was a SHOULD in the 2025-06-18 revision and is a MAY in 2025-11-25.