The @cloudflare/workers-oauth-provider package has been promoted to version 1 and now exposes a split API: one Worker functions as the OAuth authorization server, while a separate Worker (or your existing MCP server) acts as the resource server. This change lets the two roles communicate over a Service Binding, keeping token validation off the public Internet and aligning with the MCP 2026‑07‑28 authorization specification.
Split API Overview
The new model separates concerns:
- Authorization server Worker handles user sign‑in, token issuance, and supports client‑ID metadata documents and issuer identification as defined by MCP 2026‑07‑28.
- Resource server (your MCP endpoint) validates incoming tokens by calling the authorization server via a Service Binding, eliminating external network hops.
Both workers can be deployed independently, each with its own WAF and rate‑limiting policies.
Implementation Considerations
Switching to the split API requires updating import statements to use OAuthAuthorizationServer and OAuthResourceServer from the package. The provided migration skill in the npm distribution can automate most code changes. Existing clients that rely on dynamic client registration or older token flows continue to work, so a full rewrite is not mandatory.
import { OAuthAuthorizationServer, OAuthResourceServer, insufficientScope } from "@cloudflare/workers-oauth-provider";
const authServer = new OAuthAuthorizationServer({
issuer: "https://auth.example.com",
resources: ["https://calendar.example.com/mcp"]
});
The insufficientScope() helper now returns a step‑up authorization response in a single call, simplifying scope escalation logic.
Operational and Security Implications
Running the two roles in separate Workers allows you to apply distinct security policies. For example, you might enforce stricter rate limits on the authorization endpoint while keeping the resource server more permissive for internal traffic. Because token validation occurs over a Service Binding, the traffic never leaves the edge network, reducing exposure to external attacks.
One authorization server can issue tokens for multiple MCP servers, which centralizes credential management but also creates a single point of trust. Monitoring should therefore focus on the health and security posture of the auth Worker, and you may want to implement health checks that verify token issuance and validation paths.
Related CloudNinjas coverage: security.
What This Means For Practitioners
Adopt the split API to isolate authentication logic, gain tighter control over edge security policies, and stay compliant with the latest MCP spec. Use the migration skill to upgrade existing deployments, verify that your Service Binding is correctly configured, and update any custom scope‑handling code to use insufficientScope(). Keep an eye on the upcoming releases of the Workers runtime for any enhancements to Service Bindings that could further reduce latency or improve observability.