跳转到主要内容

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

Plug-and-play MCP 服务器认证

MCP Auth 为您的 MCP 服务器提供所有必需的生产级认证功能。无需花费数周时间阅读规范和连接配置。

开始使用

为什么选择 MCP Auth？

跳过规范。跳过样板代码。专注认证。

MCP 规范需要 OAuth 2.1 和其他 RFC，为认证提供坚实基础。使用 MCP Auth，您只需几行代码即可连接到可信任的提供商。

开始使用

连接任何提供商。这是提供商无关的。

MCP Auth 可与任何兼容 OAuth 2.1 或 OpenID Connect 的提供商配合使用。从我们的已验证列表中选择，或使用工具检查您的提供商是否合规。

查看提供商

快速部署，安全可靠。

准备投入生产？我们为您提供支持。MCP Auth 遵循规范和最佳实践，让您可以自信地启动服务。

确实只需几行代码

// 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 }) }] };
  }
);

MCP SDK 怎么样？

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.