Workers OAuth Provider v1 splits the auth server from the MCP server

Cloudflare’s changelog for 1 October 2026 says @cloudflare/workers-oauth-provider is now v1, with a split API. One Worker is the authorization server: it signs users in and issues tokens. The MCP server is a resource server and can run in another Worker. It checks each token by calling the authorization server over a Service Binding, so that check does not cross the public internet. The npm registry shows 1.0.0 published on 24 September 2026 and 1.2.1, the current latest, on 28 September 2026. The changelog post is seven days after 1.0.0.

What v1 adds, according to the changelog

The package supports the MCP authorization specification dated 28 July 2026, including Client ID Metadata Documents and issuer identification. Cloudflare says it still works with older clients that use Dynamic Client Registration. insufficientScope() is described as step-up authorization in one call: the example returns it when a POST lacks calendar:write even though calendar:read was enough to get in. One authorization server can list several MCP resource URLs and issue tokens for each. The resource server and the authorization server can sit behind different WAF and rate-limiting rules because they are different Workers.

OAuthResourceServer publishes the protected-resource metadata from RFC 9728, answers a request that has no token with a 401 that points at that metadata, and rejects a token that was issued for a different resource. In the sample, the calendar Worker has no KV namespace of its own. The binding name in the example is AUTH_SERVER, and the entrypoint is AuthServer. You can still run OAuthProvider as both sides. Cloudflare says that for most 0.x deployments the only required change is resourceMetadata: { resource }.

Helpers that ship beside the split

The same post lists a consent-page helper and an upstream sign-in helper for the MCP confused-deputy protections, sliding refresh-token expiry through refreshTokenIdleTTL, resumable KV cleanup with purgeExpiredData(), and an internal reason on errors passed to onError. A migration skill ships inside the npm package at skills/migrate-to-1.0/SKILL.md. The install line in the post is npm i @cloudflare/workers-oauth-provider@latest. The sample wrangler file sets compatibility_date to 2026-10-04 and tells the reader to use today’s date, so that string is an example, not a second release date.

Practical takeaway

If your MCP server and your login Worker are the same script today, the changelog’s migration is the resource metadata plus, if you want the split, a Service Binding that exposes validateToken. Confirm you are on a 1.x release: the registry’s 1.0.0 timestamp is 24 September, ahead of the blog post. The July 2026 MCP auth spec is the target, and older Dynamic Client Registration clients are still in scope according to Cloudflare. Read the migration skill before an agent rewrites the Worker for you.