# From all-or-nothing to task-based OAuth consent

[Cloudflare](https://yomu.fyi/company/cloudflare) · Miller Vargas · Aug 20, 2026

**Type:** Announcement

## Summary

Cloudflare introduced OAuth scope customization to replace all-or-nothing consent flows for third-party applications. Previously, users had to approve every requested scope or deny access completely, compelling developers of tools like MCP servers to construct custom pre-consent selection interfaces. With the new feature, developers can designate specific permissions as optional alongside required scopes when configuring an OAuth client. During authorization, users can deselect these optional scopes, while unrequested client scopes remain hidden to maintain task-specific consent screens. Because resulting access tokens contain only the granted subset of permissions, client applications must inspect returned scopes after code exchange rather than assuming full authorization.

## Context

Cloudflare OAuth permission models grew more granular to support integrations, internal tools, CLIs, and agents, but the consent experience remained all-or-nothing. Users could only accept or deny an application's entire requested scope set, forcing developers of tools with broad permissions, such as MCP servers, to build custom pre-consent scope selection screens.

## Approach / What changed

Cloudflare introduced optional scope configuration for OAuth clients via an optional\_scopes field. Users can deselect optional scopes during authorization while required scopes remain mandatory. Cloudflare evaluates scopes dynamically against the specific authorization request rather than all client-configured scopes and issues access tokens containing only consented permissions.

## Takeaways

- Scope customization allows developers to configure optional scopes on OAuth clients, letting users deselect specific permissions during authorization while keeping required scopes mandatory.
- Required and optional scopes are evaluated strictly against the scopes requested in a specific authorization flow, not against all scopes configured on the client.
- Access tokens generated after authorization contain only the scopes granted by the user, requiring applications to verify returned permissions rather than assuming full approval.

**Tags:** [Authentication](https://yomu.fyi/topic/authentication), [Developer Experience](https://yomu.fyi/topic/developer-experience)

[Read original post](https://blog.cloudflare.com/task-based-oauth-consent)