메인 콘텐츠로 건너뛰기

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.