What it is: WorkOS AuthKit is a full authentication and user-management product that — per WorkOS — turns into an MCP-compliant OAuth 2.1 authorization server with a single configuration value, so your remote MCP server can meet the 2026-07-28 spec's authorization requirements without hand-building the OAuth machinery.
The 10-second answer: The new MCP spec removed the handshake and put OAuth 2.1 in charge of access. Your server now needs to be an authorization server — token issuance, Dynamic Client Registration, discovery metadata, RFC 9207 issuer validation. WorkOS AuthKit provides exactly that surface as configuration, free up to 1M monthly active users. If you already run auth, its Connect middleware layers the MCP-compliant OAuth surface in front of it.
Why this matters this week#
The stateless rewrite got the headlines, but the authorization change is what lands in your code. With the initialization handshake and Mcp-Session-Id gone, there is no protocol-level place to stash "who is this caller." Access moves entirely onto standard OAuth 2.1, and the spec hardened the rules:
- Clients must validate the
issparameter on authorization responses, per RFC 9207 — a mixup-attack defense. - Clients declare an OpenID Connect
application_typeduring Dynamic Client Registration. - Credentials are treated as bound to the issuing authorization server's
issuer— a token minted for one server is not valid at another.
The practical consequence: a remote MCP server is now expected to behave like a real OAuth 2.1 authorization server — exposing discovery metadata, accepting dynamic client registrations, and issuing issuer-scoped tokens. That is a non-trivial amount of security-critical plumbing to write correctly. It's exactly the plumbing WorkOS sells as a config value.
Who it's for#
- Founders shipping a remote MCP server who need it to pass the 07-28 auth checks and would rather not become OAuth-server maintainers.
- Teams that already have auth (Auth0, Clerk, a homegrown IdP) and just need the MCP-compliant authorization surface bolted on — that's the Connect path.
- Solo builders standing up one server to validate the new flow against the beta SDKs, who want a free tier that doesn't expire.
If you think of identity as infrastructure you'd rather call than build, this is aimed at you. If identity is your product, roll your own — the standards are open.
Getting started#
The two shapes map to where you already are:
- Starting from scratch → AuthKit. Stand up AuthKit as your auth product; enabling the MCP mode makes it the OAuth 2.1 authorization server your MCP clients discover and register against. WorkOS documents drop-in paths for FastMCP, the official MCP SDKs, and Cloudflare Workers — the three most common ways founders are deploying remote servers right now.
- Existing auth → Connect. Put Connect in front of your current identity provider so MCP clients get a spec-compliant OAuth surface while your users keep their existing login.
The fastest way to see the whole loop is a working reference: the community mcp-oauth-workos-template wires an MCP server to AuthKit OAuth end to end, so you can watch a client register, authorize, and call a tool with an issuer-scoped token before touching your own codebase.
Pricing, honestly#
AuthKit is free up to 1,000,000 monthly active users — and that's the real product, not a crippled trial: email/password, social login, MFA, and user management are all included. You only start paying when you add the enterprise connectors, SSO or SCIM, at $125 per connection per month (with volume discounts). Separately, WorkOS publishes MCP-specific pricing that starts at $0/mo for 1 project and up to 1,000 monthly active tokens, with community support — enough to build and validate a server.
Translated: for most early-path products, the auth that satisfies the new MCP spec costs nothing until you're selling to enterprises who demand SSO — which is precisely when you can afford $125/connection.
The catch#
Buying auth means renting your identity provider. That's the right trade for the majority of founders shipping a remote MCP server this quarter — the spec's OAuth requirements are fiddly, security-critical, and easy to get subtly wrong. But it is a dependency: your login surface, your token lifetimes, and your registration flow now live behind someone else's roadmap and status page. OAuth 2.1 discovery, Dynamic Client Registration, and RFC 9207 issuer validation are open standards; if identity is a core competency, implementing them yourself keeps that surface in-house. Most teams shouldn't — but you should make the call deliberately, not by default.
If you're migrating a server this week, pair this with our client-side auth checklist for the 07-28 spec and the full breakdown of what the authorization rewrite changed. The server side (be a valid OAuth authorization server) and the client side (validate iss, declare application_type) have to agree, or the handshake-free flow simply fails closed.
