Is your feature request related to a problem? Please describe.
When connecting Tableau MCP to ChatGPT using OAuth, the connection fails during Client ID Metadata Document (CIMD) validation.
ChatGPT publishes the following client metadata:
{
"token_endpoint_auth_methods_supported": [
"none",
"private_key_jwt"
],
"token_endpoint_auth_method": "private_key_jwt"
}
The Tableau MCP server currently rejects this metadata with:
invalid_client_metadata
Client metadata is invalid:
Invalid enum value. Expected 'none' | 'client_secret_basic' | 'client_secret_post',
received 'private_key_jwt' at "token_endpoint_auth_method"
The issue appears to originate from the CIMD schema in src/server/oauth/schemas.ts, which does not include private_key_jwt.
Simply adding private_key_jwt to the enum would not be sufficient, because the token endpoint would also need to validate the client assertion JWT.
Describe the solution you'd like
Please add full support for OAuth CIMD clients using private_key_jwt.
The implementation should:
Accept private_key_jwt in the CIMD metadata schema.
Read the client’s JWKS metadata.
Validate the client_assertion JWT sent to the token endpoint.
Validate at least the following claims:
iss
sub
aud
exp
jti
kid
Verify the signature using the public key published in the client’s JWKS.
Reject invalid, expired, replayed, or incorrectly targeted assertions.
Continue supporting public clients using token_endpoint_auth_method: "none".
Preserve the existing PKCE validation for authorization-code exchanges.
The authorization server metadata should continue advertising CIMD support:
{
"client_id_metadata_document_supported": true,
"token_endpoint_auth_methods_supported": ["none"]
}
For CIMD clients that advertise both none and private_key_jwt, the server should accept either method according to the client metadata and local policy.
Additional context
The current CIMD validation is implemented in:
src/server/oauth/schemas.ts
src/server/oauth/authorize.ts
The token exchange is implemented in:
src/server/oauth/token.ts
The current implementation supports DCR as a fallback, but DCR is considered a backwards-compatibility mechanism in newer MCP authorization specifications. Supporting CIMD with private_key_jwt would provide a more future-proof integration with ChatGPT and other MCP clients.
Related issue:
#193 – Add a config flag to disable CIMD support
A temporary workaround is to disable CIMD and force DCR with token_endpoint_auth_method: "none", but this should not be required for clients that correctly implement CIMD and private_key_jwt.
Acceptance criteria
ChatGPT can connect to a Tableau MCP server configured with embedded OAuth.
CIMD metadata containing private_key_jwt is accepted.
The authorization-code flow completes successfully using PKCE.
Token requests with valid client_assertion JWTs succeed.
Invalid client assertions are rejected with invalid_client.
Existing none public-client flows continue to work.
Existing DCR behavior remains backward-compatible.
Is your feature request related to a problem? Please describe.
When connecting Tableau MCP to ChatGPT using OAuth, the connection fails during Client ID Metadata Document (CIMD) validation.
ChatGPT publishes the following client metadata:
{
"token_endpoint_auth_methods_supported": [
"none",
"private_key_jwt"
],
"token_endpoint_auth_method": "private_key_jwt"
}
The Tableau MCP server currently rejects this metadata with:
invalid_client_metadata
Client metadata is invalid:
Invalid enum value. Expected 'none' | 'client_secret_basic' | 'client_secret_post',
received 'private_key_jwt' at "token_endpoint_auth_method"
The issue appears to originate from the CIMD schema in src/server/oauth/schemas.ts, which does not include private_key_jwt.
Simply adding private_key_jwt to the enum would not be sufficient, because the token endpoint would also need to validate the client assertion JWT.
Describe the solution you'd like
Please add full support for OAuth CIMD clients using private_key_jwt.
The implementation should:
Accept private_key_jwt in the CIMD metadata schema.
Read the client’s JWKS metadata.
Validate the client_assertion JWT sent to the token endpoint.
Validate at least the following claims:
iss
sub
aud
exp
jti
kid
Verify the signature using the public key published in the client’s JWKS.
Reject invalid, expired, replayed, or incorrectly targeted assertions.
Continue supporting public clients using token_endpoint_auth_method: "none".
Preserve the existing PKCE validation for authorization-code exchanges.
The authorization server metadata should continue advertising CIMD support:
{
"client_id_metadata_document_supported": true,
"token_endpoint_auth_methods_supported": ["none"]
}
For CIMD clients that advertise both none and private_key_jwt, the server should accept either method according to the client metadata and local policy.
Additional context
The current CIMD validation is implemented in:
src/server/oauth/schemas.ts
src/server/oauth/authorize.ts
The token exchange is implemented in:
src/server/oauth/token.ts
The current implementation supports DCR as a fallback, but DCR is considered a backwards-compatibility mechanism in newer MCP authorization specifications. Supporting CIMD with private_key_jwt would provide a more future-proof integration with ChatGPT and other MCP clients.
Related issue:
#193 – Add a config flag to disable CIMD support
A temporary workaround is to disable CIMD and force DCR with token_endpoint_auth_method: "none", but this should not be required for clients that correctly implement CIMD and private_key_jwt.
Acceptance criteria
ChatGPT can connect to a Tableau MCP server configured with embedded OAuth.
CIMD metadata containing private_key_jwt is accepted.
The authorization-code flow completes successfully using PKCE.
Token requests with valid client_assertion JWTs succeed.
Invalid client assertions are rejected with invalid_client.
Existing none public-client flows continue to work.
Existing DCR behavior remains backward-compatible.