DataHub MCP Server: Per-User Authentication and Usage Limits Best Practices – DataHub Customer Support Portal

Area: Best Practices

Sub-Area: MCP Server Authentication, Authorization, and Rate Limiting

Issue

Organizations integrating the DataHub Managed MCP Server into internal AI initiatives often have questions about how to implement per-user authentication securely at scale, what API usage limits apply to MCP tool calls, and what patterns other teams have adopted for production-grade MCP deployments. Using a single shared access token for all users violates the principle of least privilege, complicates auditing, and is not recommended for enterprise use. This article consolidates guidance on OAuth2 authentication, Personal Access Tokens (PATs), response token budgets, and general best practices for scalable MCP adoption.

You Might Be Asking

What is the recommended authentication strategy for DataHub MCP when multiple users need access?
Should I create one DataHub Personal Access Token per user, or is there a better approach?
Is OAuth2 supported for the Managed MCP Server, and how does it differ from PAT-based auth?
Are there rate limits or token limits on DataHub MCP tool responses?
How are other teams using DataHub MCP in production AI workflows?

Solution

1. Per-User Authentication: OAuth2 (Recommended) vs. Personal Access Tokens

Never use a single shared access token across multiple users for MCP access. Two supported per-user authentication models are available:

OAuth2 with Authorization Code + PKCE (Recommended for Interactive Users)
DataHub Cloud includes a built-in OAuth2 Authorization Server. Users authenticate via a browser-based OAuth2 flow without needing to create or manage static long-lived tokens. This is the preferred approach for interactive AI client integrations.
- Each user signs in with their own DataHub credentials, including SSO via your existing identity provider.
- Tokens are short-lived and automatically refreshed.
- Permissions are scoped to the authenticated user's DataHub RBAC roles — no additional configuration required.
- Supported by modern AI clients such as Claude Desktop, Cursor, and VS Code Copilot that implement the MCP OAuth2 specification.
- Full audit trail per user is preserved in DataHub's access logs.
To enable OAuth connectivity, refer to the "Connecting to Managed MCP Server with OAuth" section in the DataHub MCP documentation. No DataHub Personal Access Token is required when using this method.
Personal Access Tokens (PATs) per User (Recommended Starting Point or for Automation)
Each user creates their own DataHub PAT via Settings → Access Tokens. This is suitable as a simpler starting point or for service accounts and unattended CI/CD workflows.
- Each token is validated against DataHub GMS on session initiation using a lightweight GraphQL me query.
- Token validation results are cached server-side with a 60-second TTL, so there is no per-tool-call authentication overhead.
- Each token is scoped to the creating user's exact RBAC permissions — if a user cannot view a dataset in DataHub, the MCP server enforces that transparently.
- PAT-per-user scales well because the MCP server is stateless and validation is cached.
```
# Example: Configuring a DataHub MCP client with a per-user PAT
# Each user supplies their own token; never share tokens between users.

DATAHUB_MCP_SERVER_URL=https://<your-instance>.datahubproject.io/mcp
DATAHUB_ACCESS_TOKEN=<your-personal-access-token>
```

2. BigQuery Plugin: Per-User Google OAuth

When using the DataHub BigQuery MCP plugin, per-user authentication is handled natively via Google OAuth. Each user connects with their own Google account through Settings → AI Settings → Connect. BigQuery IAM controls what data each user can query, and DataHub never stores or shares a common Google credential across users.

3. Understanding Usage Limits and Token Budgets

All MCP tool calls result in underlying DataHub API requests. Be aware of the following limits:

GMS HTTP Rate Limiting: The DataHub GMS layer enforces server-side rate limits. If limits are exceeded, the API returns an HTTP 429 response with a Retry-After header. MCP clients should implement exponential backoff and retry logic.
MCP Response Token Budget: Each MCP tool response is capped at approximately 80,000 tokens by default. Individual per-entity schema fields are truncated at approximately 16,000 tokens. These limits protect against context window overflow in AI clients. For typical interactive usage (metadata exploration, Ask DataHub), you are unlikely to encounter this limit.
Write Operation Backpressure: For metadata write operations, backpressure is applied when internal consumer lag is elevated. This is primarily relevant for ingestion-heavy workloads, not read-focused MCP usage.
Tenant-Level Adjustments: Response token budget limits can be adjusted per tenant by the DataHub Cloud team if your workload requires higher limits. Contact DataHub support to discuss your requirements.

4. General Best Practices for Production MCP Deployments

Always use per-user authentication. OAuth2 PKCE is preferred for interactive users; PATs are acceptable for automation and service accounts. Never share tokens between users.
Start with read-only tools. DataHub Cloud allows you to control which MCP tools are enabled. Mutation tools (writing tags, descriptions, etc.) are disabled by default. Enable them selectively with appropriate RBAC guardrails.
Monitor for 429 and 5xx errors. Implement retry logic with exponential backoff in your MCP client or AI orchestration layer to handle transient rate-limit responses gracefully.
Use built-in filtering and pagination. Leverage the MCP server's filtering and batching capabilities to minimize payload size and avoid hitting token budget limits on large result sets.
Leverage session tracking for observability. Every MCP session receives a stable session ID. Capture these IDs in your logging infrastructure to correlate user activity and simplify debugging.
Reference integration guides for common AI clients. DataHub provides step-by-step configuration examples for integrations such as Snowflake Cortex Agents, Databricks Agent Bricks, and Cursor, all demonstrating OAuth2 and PAT configuration patterns.

# Example: Recommended MCP client configuration structure (generic)
# Replace placeholders with your actual values.

{
  "mcpServer": {
    "url": "https://<your-instance>.datahubproject.io/mcp",
    "auth": {
      "type": "oauth2_pkce",          // or "pat" for Personal Access Token
      "clientId": "<your-oauth-client-id>",
      "authorizationEndpoint": "https://<your-instance>.datahubproject.io/oauth/authorize",
      "tokenEndpoint": "https://<your-instance>.datahubproject.io/oauth/token"
    },
    "tools": {
      "readEnabled": true,
      "writeEnabled": false           // Enable selectively with RBAC review
    }
  }
}

Additional Notes

OAuth2 connectivity for the Managed MCP Server is available on DataHub Cloud. Consult the official MCP feature documentation to confirm availability for your plan tier. The 80,000-token response cap is a default platform value and may be adjusted by contacting DataHub support for tenants with specialized high-volume use cases. When evaluating authentication strategy, prefer OAuth2 PKCE for any workflow involving human users interacting with an AI assistant, and reserve PATs for fully automated, non-interactive service account scenarios. Shared tokens should never be used in production environments regardless of workload type.