Saltar al contenido principal

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

Plug-and-play autenticación para servidores MCP

MCP Auth te proporciona todo lo que necesitas para añadir autenticación lista para producción a tu servidor MCP. Sin semanas dedicadas a leer especificaciones o conectar componentes.

Comenzar

¿Por qué MCP Auth?

Salta las especificaciones. Salta el código repetitivo. Solo autenticación.

La especificación MCP requiere OAuth 2.1 y otros RFCs, proporciona una base sólida para la autenticación. Con MCP Auth, puedes ir más allá conectándote a un proveedor de confianza con solo unas pocas líneas de código.

Comenzar

Conéctate a cualquier proveedor. Es agnóstico al proveedor.

MCP Auth funciona con cualquier proveedor compatible con OAuth 2.1 o OpenID Connect. Elige uno de nuestra lista verificada o usa la herramienta para comprobar si tu proveedor es compatible.

Ver proveedores

Vamos a desplegar rápido y ser seguros.

¿Listo para producción? Te tenemos cubierto. MCP Auth sigue la especificación y las mejores prácticas, para que puedas lanzar con confianza.

Realmente pueden ser solo unas pocas líneas de código

// 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é hay de los SDKs de 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.