mcpauth vs. Stytch

Stytch has published some of the deepest technical writing on MCP OAuth and Dynamic Client Registration of any vendor in this space — genuinely useful explainers of a spec that trips up most implementers. Where mcpauth and Stytch differ is in what you adopt to get there: mcpauth is a narrow, drop-in authorization server for one MCP server; Stytch's Connected Apps is a feature of its broader CIAM (customer identity and access management) platform.

What Stytch is

Stytch is a full identity platform — passwordless login, session management, fraud detection, and B2B org/role management, among other things. Connected Apps extends that platform to cover the OAuth flows an MCP server needs (dynamic client registration, authorization, token issuance) so that an MCP client can authenticate against an app already built on Stytch. Stytch's blog and docs are a genuinely good resource for understanding how the MCP auth spec works, independent of which provider you end up choosing.

The tradeoff is scope. Connected Apps is designed to sit on top of Stytch as your identity provider. If you want MCP OAuth from Stytch, the natural path is to adopt Stytch for user authentication generally — not just point it at an existing MCP server and get DCR and token issuance back in a few lines.

What mcpauth is

mcpauth does one thing: it is an OAuth 2.1 authorization server purpose-built for MCP, implementing Dynamic Client Registration (RFC 7591) and discovery (RFC 8414) out of the box. You register a project in the dashboard, get a registration secret, and drop the mcpAuth() Express middleware in front of your MCP server:

import { mcpAuth } from "getmcpauth";

app.use(
  "/mcp",
  mcpAuth({ registrationSecret: process.env.MCPAUTH_SECRET })
);

That middleware wraps the official @modelcontextprotocol/sdk bearer-auth verifier, so unauthenticated or invalid requests get a spec-correct 401 before they reach your handlers, and successful verifications are cached in-process so a chatty agent conversation doesn't add a network round-trip to every tool call. mcpauth doesn't ask you to move your users anywhere — it doesn't have a concept of "your users" beyond what you tell it.

If you already have your own user auth

This is the case where the difference matters most. Say your product already has its own login system — you know who your users are, you have sessions, you have a users table. You're now adding an MCP server and need it to speak OAuth so MCP clients can connect to it correctly.

With Stytch, the on-ramp to Connected Apps runs through Stytch being (or becoming) your identity provider. With mcpauth, your backend — which already knows who the logged-in user is — can call POST /api/oauth/token/exchange directly, server-to-server, and mint a token for that user without sending them through a GitHub-login-and-consent screen at all:

import { mintToken } from "getmcpauth";

const token = await mintToken({
  registrationSecret: process.env.MCPAUTH_SECRET,
  clientId,
  subject: currentUser.id,
  scopes: ["mcp:read", "mcp:write"],
});
// => { accessToken, tokenType: "Bearer", expiresIn, refreshToken, scope }

This is the pattern documented at /docs/token-minting. It exists specifically so a product with its own auth doesn't have to replace it just to bolt MCP-compliant OAuth onto one server.

Free tier and pricing

Stytch's free tier is generous — 10,000 monthly active users — but it's priced and scoped around Stytch being your full authentication provider, not a narrow add-on for one MCP server.

mcpauth's free tier covers 1 project and up to 1,000 monthly active tokens on community support, at $0/mo. The Pro plan is $29/mo with unlimited projects, 10,000 monthly active tokens included, and $5 per additional 1,000 monthly active tokens, with priority support. See /pricing for details.

When to choose which

Choose Stytch if you don't have a user identity system yet, or you're happy to build on one platform for login, sessions, and MCP OAuth together — and their technical docs on the MCP spec itself are worth reading regardless of which provider you pick.

Choose mcpauth if you already have your own user auth and just need a standards-compliant OAuth 2.1 + DCR layer in front of your MCP server, without adopting a new identity platform underneath it.

Read the quickstart See pricing