The user did not grant every permission: how an OAuth app should handle partial access

Clearing one checkbox should not disable reading

A user connects an assistant to read and summarize tasks. On the consent screen, they allow reading but decline editing. If the integration then displays a generic error or demands every permission again, it is not respecting the user’s decision.

OAuth is a way to give one application limited access to data or actions in another service without sharing the user’s password. It serves people who connect third-party applications and developers who build integrations: they can approve only the necessary actions instead of exposing an entire account.

On 20 August 2026, Cloudflare introduced an option to decline optional permissions on its consent screen. It is a current example of a broader rule: requested does not mean granted. An application must determine its actual access and keep the features for which that access is sufficient working.

Who takes part in granting access

Consider an integration with a task service. This scenario has four OAuth roles:

• The user, or resource owner, decides which tasks and actions the application may access.
• The client application is the assistant that wants to read or change tasks.
• The authorization server processes the request and the user’s decision, then issues the access values defined by the flow.
• The resource server accepts protected requests and checks the token and permission for a particular operation.

An access token is a digital pass issued by the authorization server and presented by the client to the resource server. It is not the user’s password or proof of unlimited access. What it permits depends on the granted rights, its lifetime, and the provider’s rules. Token expiration and revocation also follow the provider’s documented mechanisms.

Scopes often define the boundaries of access. For example, tasks.read might permit reading, while tasks.write permits editing. Each provider defines its own scope names and exact meanings.

Five permission sets that must not be confused

When designing an integration, it is useful to separate five sets. A particular provider may not name or display every set separately.

• Configured scopes are the permissions the client may request under its registration and configuration.
• Requested scopes are included in a particular authorization request.
• Required scopes are necessary for the application’s core task under its product model.
• Optional scopes enable extra features without being necessary for the core task.
• Granted scopes are the final set that the authorization server associates with the token after the user’s decision and its own policy checks.

In the Cloudflare implementation described on 20 August, a client owner can mark some configured scopes as optional. Only scopes requested in the current flow are evaluated: users may decline requested optional scopes, while unrequested scopes are neither shown nor enforced. This is Cloudflare’s behavior, not a universal OAuth consent-screen design.

In our example, reading is configured, requested, classified as required, and granted. Editing is also configured and requested, but it is optional for summarization and the user does not grant it. Administrative access is not requested at all. This partial grant is a normal result when the core task can continue without every requested scope.

Inspect what was granted instead of assuming it

In the OAuth 2.0 authorization code flow, the client exchanges a short-lived, one-time code for an access token. Under Section 5.1 of RFC 6749, the scope field may be omitted from the token response when the granted set is identical to the requested set. If the sets differ, that field is required.

Consult the provider’s official documentation to interpret the response correctly and identify any other provider-defined source of access data. Do not infer the result only from the initial request or consent screen. Do not treat claims from a decoded token as an authoritative permission list unless the provider’s documentation explicitly says to do so.

After inspecting the grant, the application can choose its behavior using a simple model:

Access result	Reading	Editing	Application behavior
Full	Works	Works	All approved features are available
Partial	Works	Unavailable	Read-only mode with a precise explanation
Required scope missing	Does not work	Unavailable	Explain why and let the user retry consent or cancel the connection

This is how the application applies least privilege: an assistant used for summaries does not receive editing or administrative access just in case it might need it later.

From understanding to safe verification with an AI agent

An AI agent can help inspect and test this model only after a person understands the difference between requested and granted scopes.

1. Understand the model

• Context and limits. Give the agent only this article and a fictional scope list. It may explain terms and ask review questions. It must not recommend changes to a real OAuth client or claim that all providers behave identically.
• Stop, artifact, and verification. Do not continue until you can explain requested versus granted access in your own words. The artifact is your short explanation. Check it against the OAuth definition, role model, and five permission sets above.

2. Inspect materials without changing them

• Context and limits. Use a redacted client configuration, official provider documentation, and a sample test-server response without secrets, codes, active tokens, or personal data. The agent may only extract and compare scopes. Network calls, edits, and production credentials are prohibited.
• Stop, artifact, and verification. Stop if a secret appears or no provider-defined source of actual scopes can be found. The artifact is a feature list with configured, requested, required-or-optional, and granted fields. Check every field manually against the source materials.

3. Plan the behavior

• Context and limits. Provide the verified list and a description of the required features. The agent may propose full, partial, and denied-access behavior and draft a test plan. It must not add scopes, change production, or classify an optional permission as required without a product reason.
• Stop, artifact, and verification. Stop if the team cannot identify the minimum scope needed for the core task. The artifact is an approved behavior map and test plan. Have the feature owner and a security specialist review them independently.

4. Act only in isolation

• Context and limits. Use a disposable OAuth client, test tenant, or local environment with synthetic data and minimal code. The agent may prepare scope checks and tests and run them locally. Production deployment, external calls, secrets, consent on a user’s behalf, and real administrative actions are prohibited.
• Stop, artifact, and verification. Stop on an unexpected write, contact with a real account, privilege expansion, or loss of isolation. The artifact is a patch, tests, and a run log. Review the code manually and rerun full, partial, and zero-access scenarios.

5. Verify independently

• Context and limits. Give the agent sanitized logs, a test-server response, and the approved behavior map. It may identify discrepancies, but its confidence is not evidence. It must not rely only on the initial request, consent screen, or decoded token without support from provider documentation.
• Stop, artifact, and verification. Stop if the source of actual scopes is unknown or the evidence conflicts. The artifact is a discrepancy report. Independently confirm an allowed operation, rejection of a forbidden operation, and loss of access after token revocation through the provider’s documented mechanism.

6. Explain the result

• Context and limits. Give the agent the approved map, test results, and clearly labeled provider-specific behavior. It may draft a user message and short decision record. It must not hide limitations, promise unverified features, or present Cloudflare’s implementation as an OAuth requirement.
• Stop, artifact, and verification. Stop if an unresolved discrepancy remains or the text promises an action without the required scope. Have a developer, a security specialist, and someone new to OAuth review the result.

Partial access should be understandable

This approach works for a cloud integration, command-line application (CLI), Model Context Protocol (MCP) server that connects AI to external tools, or an AI assistant itself. Request the minimum, inspect what was actually granted, and disable only dependent features. Declining editing can then leave reading available, keeping consent a genuine user choice.

Sources

• IETF — The OAuth 2.0 Authorization Framework, RFC 6749
• IETF — OAuth 2.0 Token Revocation, RFC 7009
• Cloudflare — From all-or-nothing to task-based OAuth consent