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

Cloudflare’s OAuth implementation now aligns more closely with the principle of least privilege. Previously, users faced an all-or-nothing choice when approving scope requests, which often led to granting broader access than necessary. The new feature lets users deselect optional scopes during authorization, reducing the risk of overprivileged apps while maintaining compatibility with existing OAuth flows. This is particularly useful for tools like MCP servers, where agents might request broad permissions but users want to restrict access to specific tasks.

The change is opt-in for developers, requiring no immediate action for existing OAuth clients. By default, the consent screen still grants the full requested scope set, preserving backward compatibility. Developers must explicitly mark scopes as optional when configuring a client, and only those scopes will appear as deselectable during authorization. This ensures the feature doesn’t disrupt current workflows while providing a clear path for gradual adoption. The implementation also respects the OAuth spec’s allowance for narrower scope grants, avoiding proprietary extensions.

Scope evaluation is tied to the specific authorization request, not the client’s full configured scope set. This keeps the consent screen focused on the task at hand, preventing users from being overwhelmed by every possible permission an app could request. For example, if a client requests only two of its four configured scopes, the consent screen will only evaluate those two, even if others are marked as optional. This design choice simplifies the user experience while ensuring the feature scales across diverse use cases, from SaaS integrations to internal tools.

The feature introduces no new attack surface but shifts some responsibility to developers. While users gain finer control, developers must thoughtfully designate which scopes are truly optional. Poorly configured clients could still lead to overprivileged access if optional scopes are overused or mislabeled. Additionally, the feature doesn’t address scope creep over time, users may still grant broad access if they’re unaware of the risks. However, the change provides a foundation for more granular consent models, which could be extended with audit logs or scope expiration in the future.