Incremental authorization means an app asks for each permission only at the moment a feature needs it, not all at sign-in. It limits what a stolen token can do, raises consent rates because the reason is clear, and gives reviewers a smaller grant to approve.
The idea in plain words
Imagine a scheduling add-on. At install it asks to read your calendar, read your mail, send mail and read your files. You click through. Six months later, only the calendar feature is used, but the token holds all four permissions.
With incremental authorization, the add-on asks for calendar read first. The first time you use "email the invite", it asks for send permission, with a sentence explaining why. If you never use that feature, the permission is never granted.
Google's guidance for app developers states this directly: do not request access to data when the user first authenticates, ask at the moment the feature is used, and explain why each scope is needed. It also says that if a user declines some scopes, the app should disable the affected features and only prompt again when the user clearly signals intent to use them.
Why it matters to security
| Without it | With it |
|---|---|
| One large grant at install | Small grants over time |
| Unused permissions sit on a live token | Permissions exist only for features in use |
| Reviewers see a long list and guess | Reviewers see a short list with reasons |
| A leak exposes everything | A leak exposes what the user actually enabled |
RFC 9700 states the principle for tokens in general: privileges of an access token should be restricted to the minimum required for the application or use case.
What to look for when approving an app
- Does the first prompt match the first thing you do? A note-taking app asking for your whole drive is out of step.
- Does each later prompt explain itself?
- Can you use the core feature after declining the extras?
- Does the vendor document which feature needs which permission?
If the answers are no, ask the vendor. If they cannot explain, choose a narrower alternative, or approve only the minimum and test.
If you build integrations
- Write a table of features and the permission each needs.
- Ship the minimum at first connection.
- Request more only inside the feature's flow.
- Handle denial gracefully. Do not loop the prompt.
- Plan for revocation. Google notes refresh tokens can be invalidated, such as when a user revokes access, and apps should respond sensibly.
Quick check
Does this mean more consent pop-ups for users?
Yes, a few, but each has a clear reason, which is the point. Fewer broad grants makes later reviews easier.
Can an admin enforce it?
Admins cannot make an app request late, but they can limit which apps and scopes are allowed. Prefer apps that document and follow this pattern.
Safeguard's policies and asset discovery can help you track which connected apps hold which permissions. Try the free scan at gold.safeguard.sh/scan.
Sources
- OAuth 2.0 best practices, Google for Developers
- RFC 9700, Best Current Practice for OAuth 2.0 Security, IETF
Last reviewed: 19 October 2026.
