Managed OAuth for Access: make internal apps agent-ready in one click (opens in new tab)
Cloudflare’s managed OAuth makes internal apps behind Cloudflare Access usable by AI agents without modifying the apps themselves. By exposing standard OAuth discovery and authorization flows, agents can authenticate on behalf of the human user rather than relying on static service accounts. The result is immediate agent compatibility for legacy websites, APIs, and other internal tools. ## The Problem: Access Worked for Humans, Not Agents - Cloudflare protects thousands of internal and self-hosted applications with Cloudflare Access. - Humans can follow Access’s login-page redirect, but agents generally cannot interact with browser-based authentication flows. - Cloudflare initially addressed this internally by modifying OpenCode’s web fetch tool to use `cloudflared` to obtain a JWT and attach it to requests. ## Managed OAuth for Access Applications - Managed OAuth is now available in open beta for every Access application. - Enabling it requires one click and no application code changes. - Access acts as the OAuth authorization server and advertises authentication details through: - The `WWW-Authenticate` response header - `/.well-known/oauth-authorization-server` - OAuth-capable agents can then: - Dynamically register as clients using RFC 7591. - Send the user through a PKCE authorization flow using RFC 7636. - Receive a token representing the user’s authorization. - The same pattern supports web pages, web applications, REST APIs, and MCP servers. ## Making Legacy Internal Apps Agent-Ready - Retrofitting every internal application with APIs, CLIs, MCP servers, and new agent standards is impractical. - Many applications can already provide useful value when agents treat them as ordinary websites. - For example, an internal wiki may only need Markdown-for-Agents support and managed OAuth. - Putting Cloudflare Access in front of existing applications provides immediate agent compatibility without rebuilding them. ## User-Based Authorization Instead of Service Accounts - Static service accounts and tokens can be useful for simple integrations, but they weaken attribution and fine-grained access control. - Actions performed through shared credentials may appear in audit logs as originating from the agent or service account rather than the responsible human. - They can also create confused-deputy risks, where an agent gains authority beyond what its user should have. - OAuth preserves the user–agent relationship: - Tokens are scoped to the user’s identity and permissions. - Existing access policies continue to apply. - Audit logs can attribute actions to the initiating user. ## RFC 9728 and Agent Web Fetching - RFC 9728 standardizes how clients discover OAuth authentication requirements. - MCP has adopted the standard, but Cloudflare argues that general-purpose agents should use it for protected websites and REST APIs as well. - Most agent web-fetch tools currently ignore `WWW-Authenticate` headers and do not automatically: - Locate the OAuth authorization-server metadata. - Register as an OAuth client. - Complete the authorization flow. - Cloudflare has drafted changes to OpenCode’s web-fetch tool demonstrating how tools could check for existing credentials and initiate OAuth when necessary. Cloudflare’s recommendation is to enable managed OAuth for Access-protected applications and encourage agent developers to implement RFC 9728. This offers a practical path to agent adoption while retaining user-level permissions, accountability, and compatibility with existing internal software.