Access - Managed OAuth for non-browser clients

Cloudflare Access supports managed OAuth, which allows non-browser clients — such as CLIs, AI agents, SDKs, and scripts — to authenticate with Access-protected applications using a standard OAuth 2.0 authorization code flow.

Previously, non-browser clients that attempted to access a protected application received a 302 redirect to a login page they could not complete. The established workaround was cloudflared access curl, which required installing additional tooling.

With managed OAuth, clients instead receive a 401 response with a WWW-Authenticate header that points to Access's OAuth discovery endpoints (RFC 8414 ↗ and RFC 9728 ↗). The client opens the end user's browser to the Access login page. The end user authenticates with their identity provider, and the client receives an OAuth access token for subsequent requests.

Access enforces the same policies as a browser login; the OAuth layer is a new transport mechanism, not a separate authentication path.

Managed OAuth can be enabled on any self-hosted Access application or MCP server portal. It is opt-in for existing applications to avoid interfering with those that run their own OAuth servers and rely on their own WWW-Authenticate headers.

Note

For MCP server portals, managed OAuth is enabled by default on new portals. It remains opt-in for self-hosted applications.

To enable managed OAuth, go to Zero Trust > Access controls > Applications, edit the application, and turn on Managed OAuth under Advanced settings.

You can also enable it via the API by setting oauth_configuration.enabled to true on the Access applications endpoint.

For setup instructions, refer to Enable managed OAuth.