Aller au contenu principal

MCP Auth 1.0 for Node.js is here, built for the MCP TypeScript SDK v2!

Plug-and-play authentification pour serveurs MCP

MCP Auth vous fournit tout ce dont vous avez besoin pour ajouter une authentification prête pour la production à votre serveur MCP. Plus besoin de passer des semaines à lire des spécifications ou à connecter des composants.

Commencer

Pourquoi MCP Auth ?

Passez les spécifications. Passez le code répétitif. Juste l'authentification.

La spécification MCP nécessite OAuth 2.1 et d'autres RFC, fournit une base solide pour l'authentification. Avec MCP Auth, vous pouvez aller plus loin en vous connectant à un fournisseur de confiance en quelques lignes de code.

Commencer

Connectez-vous à n'importe quel fournisseur. C'est indépendant du fournisseur.

MCP Auth fonctionne avec n'importe quel fournisseur compatible OAuth 2.1 ou OpenID Connect. Choisissez-en un dans notre liste vérifiée ou utilisez l'outil pour vérifier si votre fournisseur est compatible.

Voir les fournisseurs

Déployons rapidement et soyons sécurisés.

Prêt pour la production ? Nous vous couvrons. MCP Auth suit la spécification et les meilleures pratiques, pour que vous puissiez lancer en toute confiance.

Cela peut vraiment être juste quelques lignes de code

// 1. Declare this MCP server and the authorization server it trusts
const mcpAuth = new MCPAuth({
  protectedResourceMetadata: {
    resource: 'https://api.example.com/mcp',
    authorizationServer: { issuer: 'https://auth.example.com/oidc', type: 'oidc' },
    scopesSupported: ['read', 'write'],
  },
});

// 2. Gate your MCP endpoint with the MCP SDK's `requireBearerAuth`:
// signature, issuer, audience, expiration, and scopes all enforced
const gate = requireBearerAuth(mcpAuth.getBearerAuthOptions({ requiredScopes: ['read'] }));

// 3. Serve the OAuth discovery documents with the MCP SDK's metadata helpers
const metadata = oauthMetadataResponse(request, await mcpAuth.getAuthMetadataOptions());

// 4. Read the verified identity in your tools
server.registerTool(
  'whoami',
  {
    description: 'Returns the current user info',
  },
  (context) => {
    const { subject, claims } = getAuthInfo(context);
    return { content: [{ type: 'text', text: JSON.stringify({ subject, claims }) }] };
  }
);

Qu'en est-il des SDK MCP ?

The official MCP SDKs now ship the HTTP layer of MCP authorization themselves: bearer auth middleware, metadata endpoints, and framework adapters. What they ask you to bring is provider integration: a token verifier and your auth metadata.

MCP Auth gives you both, for any OAuth 2.0 / OpenID Connect provider.

You could write the verifier yourself; a correct one is about a hundred lines with a JWT library. These are the parts that tend to go wrong silently:

  • Audience binding (RFC 8707): required by the MCP spec, left to the verifier by the SDK. MCP Auth always validates the aud claim against your resource identifier, with no opt-out.
  • Expiration mapping: miss the exp → expiresAt mapping and the SDK rejects every token. MCP Auth maps it automatically.
  • Error mapping: raw JWT-library errors surface as 500s with no challenge, so clients never re-authorize. MCP Auth turns verification failures into proper 401 challenges.
  • Claim quirks across providers: scope strings vs. scopes arrays, client_id vs. azp: all handled.
  • Discovery hygiene: issuer validation, cached metadata and JWKS fetches, and cache reset on transient failures, all built in.

Or: all of the above is one MCPAuth instance, tested and kept up to date as the MCP spec and SDKs evolve.

What stays in your hands: provider-side configuration (audience, scopes, client registration), permission design, and your app-level authorization. That is exactly what the tutorials and provider guides walk you through.