Microsoft Graph OAuth Scopes are the permissions an app requests to read or change data in Microsoft 365 and related services. They define what an identity can access through OAuth tokens, using delegated or application permissions to limit access to mail, files, users, groups, and other resources.
What Microsoft Graph OAuth Scopes Mean in Practice
OAuth scopes are the permission boundaries that determine what an app can do through microsoft graph. They are not just labels, they are the difference between a token that can read a mailbox and one that can change directory data or access files.
For security teams, the key idea is that scopes translate business intent into token authority. A scope request should match a real use case, because every extra permission widens the blast radius if the app, consent flow, or token is abused.
Delegated and Application Permissions
Microsoft Graph scopes usually appear in two broad forms: delegated permissions, where the app acts with a signed-in user’s context, and application permissions, where the app acts on its own. That distinction matters because delegated access inherits the user’s own rights, while application access can become tenant-wide if it is broadly approved.
Scope design therefore affects both user-facing consent and service-to-service trust. A carefully chosen scope set can keep an app useful without giving it more power than it needs, especially when it touches mail, files, users, groups, calendars, or security-relevant directory objects.
Consent, Token Reach, and Abuse Paths
Scopes become dangerous when users or administrators approve more access than the app truly needs, or when a compromised app retains access longer than expected. A valid token with the wrong scopes can still be enough to exfiltrate data, modify records, or pivot into additional Microsoft 365 services.
That is why Microsoft Graph scope review is really a control over token reach. The scope list determines what an attacker gains if they steal a token, trick a user into consent, compromise an app registration, or abuse a service principal with excessive permissions. The OAuth security model defined in RFC 6749: The OAuth 2.0 Authorization Framework explains why those permission boundaries matter.
How to Review and Limit Scope Exposure
Organisations should treat scope review as part of application inventory and access governance, not as a one-time developer task. The practical questions are simple: what data does the app need, who approved it, which permission type was granted, and whether the scope still matches the current business purpose.
Because Microsoft Graph scopes can expose identity, content, and collaboration data, they should be reviewed alongside app registrations, enterprise consent, and tenant-wide permissions. When scopes are broader than the use case, the safer response is to reduce the permission set, replace broad delegated access with narrower access where possible, and prefer least-privilege design for long-lived integrations. For broader OAuth and scope hygiene, the OAuth 2.0 and OpenID Connect Guide for Identity Teams is a useful reference, and Microsoft Graph-specific governance issues are explored in the SaaS-to-SaaS and OAuth App Governance Guide.
For identity and access teams, Microsoft Graph scopes sit in the same control family as app permissions, consent policy, and token lifecycle. The OWASP Non-Human Identity Top 10 is a useful external lens when app permissions, secrets, and overprivilege are part of the same risk picture.
Monitoring, Detection, and Post-Compromise Review
After an app is granted Graph access, defenders need visibility into unusual consent events, abnormal token use, and unexpected access patterns. A scope that looks reasonable on paper can still become a compromise path if it is used from a new tenant, a suspicious client, or an unexpected automation workflow.
Post-incident review should include app registrations, grants, secrets or certificates tied to the app, and any Microsoft 365 data accessed through Graph. If there is evidence of abuse, the response should consider revoking consent, rotating app credentials, and checking whether the app was used to move laterally across mail, files, or directory resources. The patterns described in Microsoft verified publisher OAuth phishing 2022 and CoPhish OAuth phishing via Copilot Studio show how consent-driven access can be abused when users or admins grant trust too quickly.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Graph scopes depend on the lifecycle of tokens, secrets, and app credentials used to obtain them. |
| AC-6 — Least Privilege | Scopes are the permission boundary that should be minimized to the app's actual business need. | |
| AU-2 — Audit Events | Scope grants and app-based access should be logged for consent and abuse investigation. | |
| Recommendation — Manage token and credential lifecycle so Graph access can be revoked, rotated, and bounded when permissions change. Restrict app permissions to the minimum Graph scopes required for the use case. Log consent grants, token use, and app access events needed to investigate Graph permission abuse. | ||
| CIS Controls v8 | CIS-5 — Account Management | App permissions and service principals are governed as accounts and access paths that need inventory and review. |
| Recommendation — Inventory and review app registrations, delegated grants, and application permissions tied to Graph access. | ||
| OWASP ASVS | V10 — OAuth and OIDC | OAuth scopes are a core part of how applications request and constrain Graph access. |
| Recommendation — Validate OAuth scope requests and consent flows so apps only receive the permissions they truly need. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | App permissions and service principals can become overprivileged non-human identities with broad Graph access. |
| Recommendation — Right-size Graph app permissions to prevent overprivileged non-human identities from gaining excessive access. | ||