[Feature]: Support Microsoft Entra ID (Azure AD) as an authentication provider for private MCP endpoints

[alamenai]

Problem Description

Organizations that manage private documentation in GitHub repositories often enforce access control through Microsoft Entra ID (Azure AD), either via GitHub Enterprise SAML SSO or internal compliance requirements.

Currently, Context7's private repository support authenticates MCP consumers through Context7's own OAuth 2.0 layer, which breaks this requirement.

This means teams who want to expose their private docs to customers' AI agents (Claude, Copilot, Cursor, etc.) via MCP cannot use Context7, not because of a missing indexing feature, but purely because of an authentication mismatch.

Proposed Solution

Allow organizations on the Pro or Enterprise plan to configure Microsoft Entra ID as the identity provider for their private MCP endpoints.

Concretely:

• Accept an Entra ID tenant ID + application (client) ID during MCP server setup.
• Enforce bearer token validation against that Entra ID tenant on every MCP request.
• Publish /.well-known/oauth-protected-resource metadata pointing to the Entra ID authorization server, so MCP clients (Claude Code, VS Code, etc.) can complete the OAuth flow automatically without manual token management.

The indexing side (reading the private GitHub repo) remains unchanged, only the consumer-facing auth layer changes.

Alternatives Considered

No response

Priority

Blocking my usage

Additional Context

Microsoft Entra ID is the dominant identity provider in enterprise environments.

The MCP spec's authorization section explicitly supports this pattern via protected resource metadata
(/.well-known/oauth-protected-resource), and Claude Code, VS Code Copilot, and Cursor all support automatic OAuth discovery from that endpoint, meaning once you publish the metadata, clients handle the login flow with zero configuration on the developer's side.

Azure itself is shipping this exact pattern in its App Service built-in MCP feature (currently in preview), which demonstrates that the demand is real and the standard is settled.

Context7 supporting Entra ID would make it the simplest end-to-end solution for enterprise teams , no custom MCP server, no Azure App Service setup, no API to build.

[Ben-Home]

Comment for #2780

Feature: Support Microsoft Entra ID (Azure AD) as an authentication provider for private MCP endpoints

Entra ID support is a critical gap for enterprise MCP adoption. Most organizations with private MCP endpoints are already on Azure/Entra — making them switch auth providers to use Context7 is a non-starter for security teams.

What makes Entra ID different from generic OAuth:

1. Token format: Entra issues JWT access tokens (not opaque) with the aud claim set to the Application ID URI, not the client ID. Standard OAuth validation that checks aud == client_id will reject Entra tokens silently.
2. Scope format: Entra uses api://<app-id>/<scope> format, not plain strings like read write. The .default scope (api://<app-id>/.default) is the equivalent of "all configured permissions."
3. V1 vs V2 endpoints: Entra v1 uses resource= parameter; v2 uses scope=. Most MCP implementations are built for v2 (plain scopes) but enterprise tenants often require v1 (resource-based).
4. Client assertion: Many enterprises require certificate-based client authentication (JWT bearer assertion) instead of client secrets for confidential clients.

Integration approach for Context7:

auth:
  providers:
    - type: oauth2
      issuer: https://login.microsoftonline.com/{tenant_id}/v2.0
      # Entra-specific config
      audience: api://corpusiq-mcp-prod  # App ID URI, not client ID
      scopes: ["api://corpusiq-mcp-prod/.default"]
      # Optional: certificate auth
      client_assertion_type: urn:ietf:params:oauth:client-assertion-type:jwt-bearer

Quickest path to MVP: Start with Entra v2 endpoint + client secret (simpler, covers 80% of use cases), then add certificate auth and v1 endpoint support as enterprise tier features. The audience-vs-client_id distinction is the biggest gotcha — handle that correctly and most of the integration works.

This is in our wheelhouse — we run an MCP server with 36+ business API connectors and multi-provider auth (OAuth, API keys, service accounts) is the core infrastructure layer. Happy to test an Entra ID integration once available.