Key takeaway: OAuth scopes are coarse, consent is all-or-nothing, and tokens persist after the application is forgotten. Each of those is a structural weakness rather than a misconfiguration.
The Granularity Problem
A scheduling tool needs to read calendar availability. The available scope may be full calendar read-write. A tool that summarises recent messages may require full mailbox read access, including years of history.
Providers define scopes at a coarse granularity because fine-grained scopes are hard to design and harder to explain. The consequence is that legitimate applications request far more than they use, users become accustomed to broad requests, and consent stops being meaningful.
There is also no negotiation. A user cannot grant read access to one calendar and decline the rest. It is accept or abandon, which means the choice is between over-granting and not using the tool.
Why Tokens Outlast Attention
An access token is short-lived; a refresh token is not. Once granted, an application can maintain access indefinitely without any further user interaction.
That property causes the real risk. A tool used briefly two years ago retains access unless someone revokes it. The vendor may have been acquired, changed its data practices, suffered a breach, or shut down while its tokens remain valid.
Nothing prompts review. There is no expiry, no reminder, and in most organisations no inventory.
The Enterprise Exposure
The situation is worse organisationally than individually, because a single consent can affect everyone.
Some scopes are application-wide rather than user-scoped — granting access to all users’ data rather than the consenting user’s. If any user can consent to a third-party application, one person’s decision can expose the entire tenant.
| Control | Effect |
|---|---|
| Disable user consent, require admin approval | Strongest, adds friction |
| Allowlist verified publishers only | Good balance |
| Permit only low-risk scopes for user consent | Practical middle ground |
| Periodic review of granted applications | Necessary regardless |
| Alert on new high-privilege grants | Catches problems early |
Restricting consent to admin approval is effective and unpopular, and the unpopularity produces workarounds. The middle path — users may consent to narrow scopes, anything touching mail, files or directory data requires review — captures most of the benefit while keeping the process tolerable.
Attacker Use of Consent
Illicit consent grants are an established technique. A phishing message leads not to a credential form but to a genuine provider consent screen for an attacker-controlled application with an innocuous name.
The user authenticates on the real provider domain, so nothing looks wrong, and grants persistent access. No password was stolen, so a password reset does not remediate it, and multi-factor authentication does not prevent it. Only revoking the grant does.
Detection depends on alerting when a new application receives a high-privilege scope, which is why the inventory matters operationally rather than just administratively.
The Bottom Line
Require review for scopes touching mail, files or directory data, maintain an inventory of granted applications, revoke anything unused, and alert on new high-privilege grants. Remember that consent-based compromise survives password resets and MFA.
