# Cloudflare's Workers OAuth Provider Reaches v1 With Split Authorization and Resource Server API

The package now separates token issuance from token validation so one authorization server can serve multiple MCP servers, and it adds support for the MCP 2026-07-28 authorization specification.

Canonical URL: https://freelancenews.online/news/cloudflare-s-workers-oauth-provider-reaches-v1-with-split-e8ebe0d6
Published: 2026-10-01T16:17:45.232Z
Updated: 2026-10-01T16:17:45.232Z
Source published: 2026-10-01T00:00:00.000Z
Event date: Not established
Review status: source-reviewed
Review method: Automated comparison against retrieved source text; not independent fact-checking.

## Report

Cloudflare's @cloudflare/workers-oauth-provider package has reached version 1, according to a changelog entry on the company's developer documentation site. The release introduces what the changelog describes as a new split API, in which one Worker acts as the authorization server that signs users in and issues tokens, while the MCP server acts as the resource server and can run in a separate Worker.

The two halves communicate over a Service Binding rather than the public Internet. In the documented pattern, the resource server validates each token by calling the authorization server through that binding, so the MCP Worker does not need its own KV namespace. The changelog's example configuration shows a services entry named AUTH_SERVER pointing at an auth-server service and an AuthServer entrypoint, with a compatibility date of 2026-10-01.

Support is stated in the release for the MCP authorization specification dated 2026-07-28, covering Client ID Metadata Documents along with issuer identification. Compatibility with older clients is also affirmed by the changelog, among them those depending on Dynamic Client Registration — a point of consequence for anyone whose existing integrations were built before the newer specification arrived.

Tied to the split model are several capabilities. Tokens for many MCP servers can be issued by one authorization server, while different Workers — with differing WAF and rate limiting rules — may host the authorization server and the resource server. This separation is presented by the changelog as the redesign's point, not as an incidental detail.

The package also publishes RFC 9728 protected resource metadata, which the changelog says MCP clients use to locate the authorization server. Requests arriving without a token receive a 401 challenge pointing to that metadata, and tokens issued for a different resource are rejected. That behavior is described as part of the resource server's default handling.

For step-up authorization, the changelog documents an insufficientScope() helper that returns a scope challenge in one line. The example shows a calendar MCP Worker checking whether a POST request carries the calendar:write scope and, if not, returning insufficientScope with the read and write scopes. Consent page and upstream sign-in helpers are said to implement the MCP confused deputy protections.

Other additions listed in the changelog include sliding refresh token expiry via refreshTokenIdleTTL, resumable KV cleanup through purgeExpiredData(), and an internal reason attached to every error passed to onError. These are operational details rather than headline features, but they affect how deployments age and how failures are diagnosed.

The changelog outlines two migration paths. A migration skill is bundled inside the published npm package so that a coding agent can carry out the upgrade, and for the majority of 0.x deployments, the changelog says, the only change needed is to add resourceMetadata: { resource }. It points readers either to a migration guide or to the skill file shipped at skills/migrate-to-1.0/SKILL.md within the package directory, and it observes that OAuthProvider is still able to function as both an authorization server and an MCP server.

For developers building MCP servers on Workers, the practical change is architectural. Splitting the authorization server from the resource server means token validation happens over a Service Binding, so the resource Worker can be deployed and scaled independently and can carry its own WAF and rate limiting rules. Teams running several MCP servers behind one identity provider can consolidate sign-in and token issuance in a single Worker instead of duplicating that logic per server.

The migration skill is the more unusual item. Shipping an agent-readable skill file inside the package means the upgrade path can be handed to a coding agent rather than followed manually, which is a workflow choice as much as a technical one. Developers who prefer to review each change themselves can still use the migration guide, and the changelog presents both routes as available rather than one replacing the other.

The changelog does not state a release date for v1 beyond the compatibility date shown in its configuration examples, and it does not describe pricing, hosting limits, or performance characteristics of the Service Binding validation path. It also does not say how many existing deployments are on 0.x or how long the older API will be supported. Those gaps are worth noting before planning an upgrade.

It is also worth being precise about what the source claims. The changelog asserts full support for the MCP 2026-07-28 authorization specification and continued compatibility with older clients, but it does not publish test results, a compatibility matrix, or independent verification of those claims. The code samples are illustrative configurations, not benchmarks.

For freelancers and small studios maintaining MCP integrations, the split API is the part most likely to change day-to-day work: it determines where secrets live, which Worker holds the KV namespace, and how a scope failure surfaces to a client. The insufficientScope() helper and the 401 challenge behavior are the pieces a client-facing integration will actually encounter.

The reasonable next step is to read the migration guide or the bundled skill before upgrading, confirm whether the deployment relies on OAuthProvider in its combined role, and check whether adding resourceMetadata is sufficient for the current setup. Anything beyond that depends on details the changelog does not supply.

## Key points

- Workers OAuth Provider reached v1 with a split API separating an authorization server Worker from resource server Workers.
- Token validation between the two runs over a Service Binding rather than the public Internet, and the resource Worker needs no KV namespace of its own.
- The release supports the MCP 2026-07-28 authorization specification, including Client ID Metadata Documents and issuer identification, while remaining compatible with older clients using Dynamic Client Registration.
- One authorization server can issue tokens for multiple MCP servers, and the two roles can run in different Workers with separate WAF and rate limiting rules.
- For most 0.x deployments the changelog says the only required change is adding resourceMetadata: { resource }, with a migration skill bundled in the npm package.

## Practical implications — editorial interpretation

Editorial interpretation: teams running more than one MCP server can consolidate sign-in and token issuance into a single authorization Worker and let each resource Worker validate tokens over a Service Binding, which simplifies secret and KV placement and lets each server carry its own WAF and rate limiting rules. The bundled migration skill offers an agent-assisted upgrade path, though developers who want to review each change can follow the migration guide instead.

## Limitations and unknowns

The changelog does not give a precise v1 release date beyond the compatibility date in its examples, does not state pricing or hosting limits, and does not quantify the performance of Service Binding token validation. Its claims of specification support and backward compatibility are not backed by published test results or a compatibility matrix in the supplied evidence. The code samples are illustrative configurations, not benchmarks, and no independent verification is provided.

## Sources

- [1] developers.cloudflare.com: Changelog
  https://developers.cloudflare.com/changelog/post/2026-10-01-workers-oauth-provider-1x/
  Retrieved: 2026-10-01T16:17:24.519Z

## Claim references

- Workers OAuth Provider reached v1 with a split API in which one Worker is the authorization server and the MCP server is the resource server. [source 1]
- The resource server validates tokens with the authorization server over a Service Binding without crossing the public Internet. [source 1]
- The release supports the MCP 2026-07-28 authorization specification, including Client ID Metadata Documents and issuer identification, and still works with older clients using Dynamic Client Registration. [source 1]
- One authorization server can issue tokens for many MCP servers, and the two roles can run in different Workers with different WAF and rate limiting rules. [source 1]
- For most 0.x deployments the only required change is adding resourceMetadata: { resource }, and a migration skill ships in the npm package. [source 1]
- OAuthResourceServer publishes RFC 9728 protected resource metadata, answers tokenless requests with a 401 challenge pointing to it, and rejects tokens issued for another resource. [source 1]