Cloudflare has launched OAuth scope customization, letting developers mark specific OAuth scopes as optional when configuring an OAuth client. Users can then deselect optional scopes at authorization time, narrowing access without an all-or-nothing consent screen. Required and optional scopes are evaluated only against the scopes requested in a given authorization flow, not the client's full configured set. Developers must check the granted scope set after code exchange rather than assuming the full requested scopes were approved, and Cloudflare plans to expand role and scope coverage across nearly all its products in coming weeks.
Table of contents
Copy link More control, without overwhelming usersCopy link Scoping to the authorization requestCopy link Configuring an OAuth client to use optional scopesCopy link Building with partial grants in mindCopy link Scopes for every ProductCopy link Build with Optional ScopesCopy link Thank you to our amazing internsQuestions this post answers
How do I mark OAuth scopes as optional when creating a Cloudflare OAuth client?
Include an optional_scopes array alongside the scopes array when creating the client via the Cloudflare API. Any scope listed in optional_scopes can be deselected by the user on the consent screen at authorization time, while scopes left out of that array remain required whenever they are part of the requested set. Developers wiring up Cloudflare OAuth apps can track these API changes as they build consent flows on daily.dev.
Does an OAuth client always get the full set of scopes it was granted originally in Cloudflare's new optional scope model?
No, if a user deselects any optional scopes during consent, the resulting access token only contains the scopes they approved. Developers need to check the granted scope set after exchanging the authorization code rather than assuming the originally requested scopes were all approved, and apps should degrade gracefully when given a narrower grant. Teams building agents on partial OAuth grants can follow this pattern on daily.dev before it bites them in production.
How does Cloudflare decide which OAuth scopes to show as optional on the consent screen for a given login?
Required and optional status is evaluated only against the scopes actually requested in that specific authorization flow, not against every scope configured on the client. So if a client is configured with four scopes but only requests two of them in a given flow, only those two are shown or enforced on the consent screen, regardless of what else the client could theoretically request. daily.dev helps developers stay current on OAuth scoping details before wiring up consent screens.