Pular para o conteúdo principal

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

Plug-and-play autenticação para servidores MCP

O MCP Auth fornece tudo que você precisa para adicionar autenticação de nível de produção ao seu servidor MCP. Não perca semanas lendo especificações e fazendo conexões.

Começar

Por que MCP Auth?

Pule as especificações. Pule o boilerplate. Apenas autentique.

A especificação MCP requer OAuth 2.1 e outros RFCs, fornecendo uma base sólida para autenticação. Com o MCP Auth, você pode seguir em frente conectando-se a provedores confiáveis com apenas algumas linhas de código.

Começar

Conecte-se a qualquer provedor. Isso é agnóstico de provedor.

O MCP Auth funciona com qualquer provedor que implemente OAuth 2.1 ou OpenID Connect. Escolha da nossa lista verificada ou use nossas ferramentas para verificar se seu provedor está em conformidade.

Verificar Provedores

Entregue rápido e com segurança.

Pronto para produção? Nós te ajudamos. O MCP Auth segue as especificações e melhores práticas para que você possa lançar com confiança.

Realmente são apenas algumas linhas 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 }) }] };
  }
);

E quanto aos SDKs 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.