--- title: "Credentials and registration — MCP glossary" description: "How a client obtains a client identity and an access token before it calls anything." canonicalUrl: "https://zuplo.com/learn/mcp/glossary/credentials" pageType: "mcp-glossary-group" --- # Credentials and registration How a client obtains a client identity and an access token before it calls anything. One group of the [MCP glossary](/learn/mcp/glossary), which indexes every term A to Z. ## Proof Key for Code Exchange (PKCE) An extension to the OAuth authorization code flow that stops a stolen authorization code from being redeemed by anyone else. The client generates a random `code_verifier`, sends its transformed `code_challenge` on the authorization request, and presents the original verifier at the token endpoint. OAuth 2.1, which MCP requires, makes PKCE mandatory for the authorization code grant. **Where you meet it.** The registered `code_challenge_method` values are `plain` and `S256`, where `S256` is `BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))`. RFC 7636 says a client capable of `S256` must use it, and `plain` is only for clients that cannot compute a SHA-256. Every MCP client that runs the OAuth flow itself does this unprompted, so PKCE usually surfaces only when an authorization server rejects the method. **Also written:** PKCE, proof key for code exchange, RFC 7636, code_challenge, code_verifier, S256 **Source:** [RFC 7636, Section 4.2](https://datatracker.ietf.org/doc/html/rfc7636#section-4.2) **On this site:** [OAuth 2.1 authentication for MCP servers](/learn/mcp/authentication/oauth-2-1) **Read next:** [CIMD](/learn/mcp/glossary/credentials#cimd) · [Issuer identification](/learn/mcp/glossary/authorization#iss) ## Dynamic Client Registration (DCR) _Deprecated in 2026-07-28._ Deprecated, not removed: it stays in the specification for backward compatibility with authorization servers that do not support Client ID Metadata Documents, and is eligible for removal no earlier than the first revision on or after 2027-07-28. A protocol, defined by RFC 7591, that lets a client register itself with an authorization server over HTTP and receive a `client_id` back, with no human in the loop. The authorization server advertises support by publishing a `registration_endpoint` in its metadata. MCP clients and authorization servers may support it. **Where you meet it.** Many enterprise identity providers do not offer it, which is why MCP integrations stall before the login screen. It is deprecated in favor of Client ID Metadata Documents, but it is still available and still the fallback when an authorization server has no CIMD support. Since `2026-07-28` an MCP client must send an appropriate `application_type` when it registers — a field OpenID Connect Dynamic Client Registration 1.0 defines, not RFC 7591 — because omitting it defaults to `web` under OIDC and collides with a native redirect URI. **Also written:** DCR, dynamic client registration, RFC 7591, registration_endpoint, dynamic client registration not supported **Source:** [RFC 7591, Section 3](https://datatracker.ietf.org/doc/html/rfc7591#section-3) · [MCP 2026-07-28: Dynamic Client Registration](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#dynamic-client-registration) **On this site:** [Dynamic Client Registration not supported](/learn/mcp/errors/dynamic-client-registration-not-supported) **Read next:** [CIMD](/learn/mcp/glossary/credentials#cimd) · [ASM](/learn/mcp/glossary/discovery#authorization-server-metadata) · [Deprecated, Removed, and Active](/learn/mcp/glossary/governance#deprecated-vs-removed) ## Client ID Metadata Documents (CIMD) _New in 2026-07-28._ MCP clients and authorization servers should support it. Two sources differ on the revision: the MCP specification normatively cites `draft-ietf-oauth-client-id-metadata-document-00`, while the IETF draft reached `-02` on July 6, 2026. It is a draft either way, not a published RFC. A registration mechanism in which the client's `client_id` is an HTTPS URL that resolves to a JSON document of its own metadata, so the authorization server fetches the client's details on demand instead of storing a registration. The `client_id` URL must use the `https` scheme, must contain a path component, and the `client_id` inside the document must match the URL exactly. **Where you meet it.** It is the migration target for DCR and the mechanism MCP names for the common case where client and server have no prior relationship. An authorization server advertises support with `client_id_metadata_document_supported: true` in its metadata, and CIMD client IDs are portable across authorization servers because nothing is registered anywhere. **Also written:** CIMD, client ID metadata document, client_id_metadata_document_supported, URL client_id, DCR replacement **Source:** [MCP 2026-07-28: Client ID Metadata Documents](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration#client-id-metadata-documents) · [draft-ietf-oauth-client-id-metadata-document-02, Section 4](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-client-id-metadata-document-02#section-4) **On this site:** [Dynamic Client Registration not supported](/learn/mcp/errors/dynamic-client-registration-not-supported) **Read next:** [DCR](/learn/mcp/glossary/credentials#dcr) · [ASM](/learn/mcp/glossary/discovery#authorization-server-metadata) ## Identity Assertion JWT Authorization Grant (ID-JAG) _Outside the specification._ An IETF Internet-Draft at revision -04, not a published RFC, and not referenced by the MCP specification. Vendors ship it ahead of both. An IETF draft profile of the JWT authorization grant that gives a client delegated access to a resource in another trust domain on behalf of a user, without a separate user-approval step at that domain's authorization server. The client first exchanges its token at the shared identity provider for an ID-JAG, requesting `requested_token_type=urn:ietf:params:oauth:token-type:id-jag`, then redeems that grant at the resource's own authorization server using `grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer`. **Where you meet it.** The draft itself names the pattern Cross-App Access (XAA), describing it as the application-ecosystem name and explicitly informal — so XAA is the pattern and ID-JAG is the artifact, not two competing grant types. It is the standards-track answer to one enterprise agent needing access to another vendor's API through the identity provider both already trust for single sign-on. **Also written:** ID-JAG, identity assertion JWT authorization grant, Cross-App Access, XAA, urn:ietf:params:oauth:token-type:id-jag, identity chaining **Source:** [draft-ietf-oauth-identity-assertion-authz-grant-04, Section 3](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-04#section-3) · [draft-ietf-oauth-identity-assertion-authz-grant-04, Section 2.2](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant-04#section-2.2) **Read next:** [Token exchange](/learn/mcp/glossary/authorization#token-exchange) · [Official extension](/learn/mcp/glossary/governance#official-extensions) · [Audience](/learn/mcp/glossary/authorization#aud)