メインコンテンツにスキップ

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.