Zuplo

Credentials and registration

How a client obtains a client identity and an access token before it calls anything.

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. #

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
On this site: OAuth 2.1 authentication for MCP servers
Read next: CIMD Issuer identification

Dynamic Client Registration

DCR Deprecated in 2026-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. #

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.

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.

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 MCP 2026-07-28: Dynamic Client Registration
On this site: Dynamic Client Registration not supported
Read next: CIMD ASM Deprecated, Removed, and Active

Client ID Metadata Documents

CIMD New in 2026-07-28 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. #

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.

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.

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 draft-ietf-oauth-client-id-metadata-document-02, Section 4
On this site: Dynamic Client Registration not supported
Read next: DCR ASM

Identity Assertion JWT Authorization Grant

ID-JAG Outside the specification 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. #

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.

An IETF Internet-Draft at revision -04, not a published RFC, and not referenced by the MCP specification. Vendors ship it ahead of both.

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 draft-ietf-oauth-identity-assertion-authz-grant-04, Section 2.2
Read next: Token exchange Official extension Audience