Managed OAuth for Access: Making Internal Apps Agent-Ready with One Click

Internal apps protected by Cloudflare Access have a login flow familiar to humans, but for agents it was simply a redirect barrier. To solve this, Cloudflare has released Managed OAuth in open beta, so that once turned on for an Access app, agents that understand OAuth 2.0 can automatically discover the authentication path, obtain a token, and use it.

Initially, only a temporary workaround was used internally at Cloudflare. They modified OpenCode's web fetch tool so that for specific domains it would open the authentication flow via the cloudflared CLI, receive a JWT, and attach it to requests, but now Access itself acts like an OAuth server instead of this approach.

The way it works follows the standard exactly.

• Unauthenticated requests get back a www-authenticate header.
• The agent looks up metadata at /.well-known/oauth-authorization-server.
• It registers a client via Dynamic Client Registration (RFC 7591).
• It obtains the user's consent through a PKCE (RFC 7636)-based authentication flow.
• After approval, the agent receives a JWT tied to the user and sends the authenticated request.

Cloudflare explains that this flow is the same as MCP. They had already supported acting as an OAuth server in the MCP server portal, and now they've extended that same approach across web pages, web apps, and REST APIs protected by Access.

The core message is clear: you don't need to build a new API, CLI, or MCP server every time to make an internal app agent-friendly. Just put Access in front of it and turn on Managed OAuth, and even an old legacy app instantly becomes accessible to agents.

Cloudflare also cautions against relying on service accounts and static credentials. The principle is that every action taken by an agent should be traceable back to the human who initiated it, and the agent should only have the permissions that user would originally have. That's why they emphasize the need for a standard like OAuth that can express the user-agent relationship.

They also believe agent tools need to change. Most web fetch tools don't do anything meaningful even when they receive a 401/403 and a www-authenticate header, but by following RFC 9728, an agent can discover the authorization server on its own and go through the login flow. Cloudflare has also published a draft pull request that applies this to OpenCode's web fetch tool.

Going forward, this model will also connect to Cloudflare's own API and to the Organizations beta spanning multiple Cloudflare accounts. They're also preparing a direction where a single IdP is shared across multiple accounts, continuing the trend of more broadly standardizing the connection between internal apps and agents.