I am trying to use Auth0 as the OAuth Authorization Server for an MCP server that is consumed by ChatGPT.
ChatGPT is using Client ID Metadata Document (CIMD) registration.
The ChatGPT Client ID Metadata Document is:
https://chatgpt.com/oauth/BpZIpxL-aggt/client.json
The document is publicly accessible and currently contains metadata similar to:
{
"client_id": "https://chatgpt.com/oauth/BpZIpxL-aggt/client.json",
"client_uri": "https://chatgpt.com/",
"redirect_uris": [
"https://chatgpt.com/connector/oauth/BpZIpxL-aggt"
],
"token_endpoint_auth_method": "private_key_jwt",
"token_endpoint_auth_methods_supported": [
"none",
"private_key_jwt"
],
"grant_types": [
"authorization_code",
"refresh_token"
],
"response_types": [
"code"
],
"client_name": "ChatGPT",
"logo_uri": "https://persistent.oaistatic.com/sonic/misc/openai-logo.png",
"token_endpoint_auth_signing_alg": "RS256",
"jwks_uri": "https://chatgpt.com/oauth/jwks.json"
}
Problem
Auth0 successfully validates the ChatGPT CIMD using the preview endpoint, but the registration endpoint rejects the exact same document.
Step 1 — CIMD preview
I call:
curl -sS \
-X POST "https://${AUTH0_DOMAIN}/api/v2/clients/cimd/preview" \
-H "Authorization: Bearer ${AUTH0_MGMT_TOKEN}" \
-H "Content-Type: application/json" \
--data "$(jq -nc \
--arg u 'https://chatgpt.com/oauth/BpZIpxL-aggt/client.json' \
'{external_client_id:$u}')"
Auth0 returns:
{
"mapped_fields": {
"external_client_id": "https://chatgpt.com/oauth/BpZIpxL-aggt/client.json",
"name": "ChatGPT",
"callbacks": [
"https://chatgpt.com/connector/oauth/BpZIpxL-aggt"
],
"logo_uri": "https://persistent.oaistatic.com/sonic/misc/openai-logo.png",
"grant_types": [
"authorization_code",
"refresh_token"
],
"app_type": "regular_web",
"jwks_uri": "https://chatgpt.com/oauth/jwks.json",
"client_authentication_methods": {
"private_key_jwt": {
"credentials": [
{
"credential_type": "public_key",
"kid": "cimd-20260428030119",
"alg": "RS256"
}
]
}
}
},
"validation": {
"valid": true,
"violations": [],
"warnings": [
"response_types is validated for format but is not persisted. This field is used for internal validation only.",
"Ignoring unsupported properties: client_uri, token_endpoint_auth_methods_supported. These properties are not validated or mapped to the Auth0 client configuration."
]
}
}
So the preview confirms that:
-
Auth0 can fetch the CIMD.
-
Auth0 can parse it.
-
Auth0 can fetch the JWKS.
-
The
private_key_jwtcredential is recognized. -
The RS256 key and
kidare recognized. -
validation.validistrue. -
There are no validation violations.
The only relevant warning is:
Ignoring unsupported properties:
client_uri, token_endpoint_auth_methods_supported
Step 2 — CIMD registration
I then call:
curl -sS -i \
-X POST "https://${AUTH0_DOMAIN}/api/v2/clients/cimd/register" \
-H "Authorization: Bearer ${AUTH0_MGMT_TOKEN}" \
-H "Content-Type: application/json" \
--data "$(jq -nc \
--arg u 'https://chatgpt.com/oauth/BpZIpxL-aggt/client.json' \
'{external_client_id:$u}')"
Auth0 returns:
HTTP/2 400
with:
{
"statusCode": 400,
"error": "Bad Request",
"message": "The Client Metadata document at https://chatgpt.com/oauth/BpZIpxL-aggt/client.json cannot be applied. See /api/v2/clients/cimd/preview output for additional details.",
"errorCode": "invalid_client_metadata"
}
The problem is that /cimd/preview does not provide any additional validation error.
It explicitly reports:
valid = true
violations = []
Potential interoperability issue
The ChatGPT CIMD contains both:
"token_endpoint_auth_method": "private_key_jwt"
and:
"token_endpoint_auth_methods_supported": [
"none",
"private_key_jwt"
]
My understanding is that ChatGPT is advertising support for both authentication methods while expressing private_key_jwt as its preferred method.
Auth0 currently reports that token_endpoint_auth_methods_supported is unsupported and ignores it.
This makes me wonder whether Auth0 is treating:
token_endpoint_auth_method = private_key_jwt
as a strict requirement rather than negotiating one of the mutually supported methods.
For example, if the Auth0 tenant cannot use private_key_jwt for this CIMD client, I would expect the Authorization Server to be able to select:
none
because ChatGPT explicitly advertises support for it in:
"token_endpoint_auth_methods_supported": [
"none",
"private_key_jwt"
]
There have been similar interoperability issues in other OAuth/MCP implementations when consuming the current ChatGPT CIMD format, particularly around the distinction between:
token_endpoint_auth_method
and:
token_endpoint_auth_methods_supported
Expected behavior
One of the following would be expected:
/cimd/registersuccessfully registers the client using a mutually supported token endpoint authentication method.
or:
/cimd/previewreports a validation violation explaining exactly why the document cannot be applied.
Currently, the API behavior is inconsistent:
/cimd/preview
↓
valid = true
violations = []
/cimd/register
↓
400 invalid_client_metadata
Additional information
Dynamic Client Registration with the same ChatGPT/MCP integration works correctly against this Auth0 tenant.
The issue appears specific to CIMD registration.
The ChatGPT CIMD and JWKS are publicly reachable:
https://chatgpt.com/oauth/BpZIpxL-aggt/client.json
https://chatgpt.com/oauth/jwks.json
Questions
Could the Auth0 team clarify the following?
-
Why does
/api/v2/clients/cimd/previewreturnvalid: trueand no violations while/api/v2/clients/cimd/registerrejects the same document withinvalid_client_metadata? -
Is
token_endpoint_auth_methods_supportedcurrently supported by Auth0 CIMD? -
If it is not currently supported, is support planned?
-
Does Auth0 currently perform authentication-method negotiation between the methods advertised by a CIMD client and the methods supported by the tenant?
-
Is
private_key_jwtbeing treated as mandatory because it appears intoken_endpoint_auth_method, even though ChatGPT also advertises support fornone? -
Is there any tenant setting, feature flag, subscription requirement, or configuration needed to make this ChatGPT CIMD register successfully?
-
Is the difference between
/cimd/previewsucceeding and/cimd/registerfailing a known issue?
I can provide additional tenant logs or request details if needed.
Thanks.