Zum Hauptinhalt springen

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

Plug-and-play Authentifizierung für MCP-Server

MCP Auth bietet Ihnen alles, was Sie brauchen, um produktionsreife Authentifizierung zu Ihrem MCP-Server hinzuzufügen. Keine Wochen damit verbringen, Spezifikationen zu lesen oder Dinge zu verdrahten.

Loslegen

Warum MCP Auth?

Überspringen Sie die Spezifikationen. Überspringen Sie den Boilerplate-Code. Nur Authentifizierung.

Die MCP-Spezifikation erfordert OAuth 2.1 und andere RFCs bietet eine solide Grundlage für die Authentifizierung. Mit MCP Auth können Sie noch weiter gehen, indem Sie sich mit nur wenigen Codezeilen mit einem vertrauenswürdigen Anbieter verbinden.

Loslegen

Verbinden Sie sich mit jedem Anbieter. Es ist anbieterunabhängig.

MCP Auth funktioniert mit jedem konformen OAuth 2.1 oder OpenID Connect Anbieter. Wählen Sie einen aus unserer verifizierten Liste oder nutzen Sie das Tool, um zu prüfen, ob Ihr Anbieter konform ist.

Anbieter anzeigen

Lassen Sie uns schnell ausliefern und sicher sein.

Bereit für die Produktion? Wir haben Sie abgesichert. MCP Auth folgt der Spezifikation und den Best Practices, damit Sie mit Vertrauen starten können.

Es können wirklich nur ein paar Codezeilen sein

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

Wie sieht es mit den MCP SDKs aus?

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.