Cloudflare's production migration to Hydra 2.X took approximately three hours. During that window, its OAuth service continued issuing credentials and accepting revocations while the company prepared a replacement database for cutover.
The upgrade cleared the way for Cloudflare to release self-managed OAuth on June 3. Any Cloudflare customer can now create an OAuth application and request scoped access to another customer's account through a standard authorization flow.
Previously, third-party OAuth access was limited to a small set of manually onboarded integrations. Other developers generally had to use API tokens when building SaaS integrations, internal developer platforms, and agentic tools. API tokens can carry scoped permissions, but they are awkward for delegated access: the user must create, copy, transmit, store, and eventually revoke the credential outside the application's authorization flow.
OAuth moves those decisions into an explicit consent process. The user sees which application is requesting access and which permissions it wants. Cloudflare also added dashboard revocation and made application ownership more visible to reduce OAuth phishing risk.
Cloudflare's existing OAuth service ran on Hydra, an open-source OAuth engine. The company planned two sequential upgrades, first to the latest 1.X release and then to 2.X.
Even the first step required changes. Hydra's supplied database migrations created indexes using exclusive locks on critical tables, which would have blocked active OAuth operations. Schema changes also conflicted with an older SDK that issued SELECT * queries and could fail to deserialize the resulting rows. Cloudflare rewrote the migrations to use operations such as CREATE INDEX CONCURRENTLY and built a Hydra version that selected explicit columns.
The 1.X deployment completed without user impact, but its stricter refresh-token handling exposed a client concurrency problem. Reusing a refresh token caused Hydra to invalidate the entire access and refresh token chain. That behavior was particularly disruptive for Wrangler and MCP clients because their request volume made retries more likely.
Cloudflare added refresh-request coalescing to the Worker routing OAuth traffic. It briefly cached a refresh request so a retry could receive the existing response before Hydra interpreted the reuse as a security event. Hydra 2.X later provided a configurable refresh-token grace period for the same class of retry.
The move to 2.X involved enough schema change that Cloudflare rejected an in-place upgrade and used a blue-green deployment. The migrations ran against a copy of the production database, followed by a coordinated cutover of Hydra and two internal systems.
Keeping the service writable created a consistency problem. Token writes made after the database copy could be absent from the replacement database. Cloudflare increased token lifetimes to multiple hours, reducing refresh activity and allowing credentials issued before the upgrade to remain usable.
Revocations required stronger handling. Losing one during cutover could restore an application's access after a user had removed it. Cloudflare recorded revocation events in Cloudflare Queues, then replayed them against the green database after the switch. This is the part of the migration design worth copying: revocation is security state, so it needs an explicit path through any database replacement or replication gap.
After cutover, Cloudflare saw an increase in HTTP 403 responses. A Hydra migration had corrupted the state of some valid OAuth sessions and marked them invalid. An authorization-service cleanup job, relying on Hydra's consent-session API, then purged OAuth policy data too aggressively because the two systems disagreed about session validity.
Cloudflare responded with data restorations and began changing its authorization behavior to remove reliance on static policy data. It also made several smaller fixes for specific client behaviors. OAuth traffic subsequently remained stable, with improved performance and reliability according to the company.
For operators, the failure mode shows why an OAuth upgrade cannot be treated as an isolated identity-service deployment. Token introspection compatibility forced Cloudflare into a hard cutover during the 1.X upgrade. Refresh-token semantics affected high-volume clients. Session migration state influenced a separate authorization cleanup process. Revocation events had to survive a database boundary independently of ordinary writes. A useful migration test plan should therefore cover concurrent refreshes, client retries, old and new token introspection, consent-session validity, downstream authorization decisions, and revocations issued during cutover. Database schema success alone does not establish that delegated access still has the state users intended.