OAuth grant scanning is the review of third-party application permissions issued through identity platforms such as Google Workspace, Microsoft 365, Slack, or GitHub. It focuses on the scopes a user approved, because those grants can persist beyond the login session and continue to expose data.
Expanded Definition
oauth grant scanning is a governance and security review process for delegated access created through OAuth consent. It examines which third-party applications have been approved, what scopes they received, when the grant was created, and whether that access still fits current business need. In identity platforms such as Google Workspace, Microsoft 365, Slack, and GitHub, a grant can outlive the original login session and remain active until explicitly revoked, which makes it materially different from short-lived authentication events.
Definitions vary across vendors on whether the term includes only interactive user-consented grants or also administrator-approved and app-only permissions. For NHIMG, the useful boundary is practical: if an external application can act on behalf of a user or tenant, it belongs in the scanning scope. That makes the term closely related to access governance, consent hygiene, and third-party exposure management. NIST control families such as NIST SP 800-53 Rev 5 Security and Privacy Controls provide the broader control context for reviewing and constraining access, even though they do not name OAuth grants directly. The most common misapplication is treating grant review as a one-time OAuth login check, which occurs when teams ignore persistent scopes that continue to function after the user has left or the app is no longer trusted.
Examples and Use Cases
Implementing OAuth grant scanning rigorously often introduces operational friction, because legitimate productivity apps, automation tools, and security integrations may all request broad permissions that must be reviewed, justified, and sometimes reapproved.
- A security team reviews Microsoft 365 consented apps and finds a stale marketing integration still has mailbox read access long after the campaign ended.
- An identity team scans Google Workspace grants and revokes a file-sync tool that was approved by one user but can now enumerate shared drive content across a department.
- A GitHub administrator identifies an app granted repository write access for a temporary CI workflow and replaces it with a narrower, time-bound integration.
- A Slack workspace review detects an external app with message and channel scopes that exceed its documented function, prompting consent reduction and vendor reassessment.
- Using guidance from OWASP OAuth 2.0 Cheat Sheet, a team distinguishes between secure authorization flow design and post-consent grant governance, then updates its review workflow accordingly.
These use cases are especially important where service accounts, automation, and collaboration platforms blend together, because the visible user session may end while the delegated capability remains active. Some organisations also pair scanning with consent policy enforcement so that high-risk scopes require approval before access is granted.
Why It Matters for Security Teams
OAuth grant scanning matters because delegated permissions are easy to overlook and hard to see during incident response. A compromised or over-permissioned app can create silent data exposure, enable lateral movement through email or document stores, and undermine least privilege even when user authentication itself remains strong. In practice, the risk is not OAuth as a protocol, but the accumulation of durable permissions that no longer match the original purpose.
For identity and security teams, this term sits at the intersection of access governance, NHI-like third-party behavior, and cloud application risk. It is especially relevant when external apps hold access to content repositories, chat systems, or developer platforms that support sensitive workflows. A review program should therefore track who approved the grant, what scopes were granted, whether those scopes are still justified, and how quickly revocation can happen when a risk is detected. OWASP API Security Project is also relevant where OAuth grants expose API-backed resources and automation paths.
Organisations typically encounter the operational impact only after a breach investigation, when an old third-party grant is discovered to have provided the attacker with access that normal login monitoring never showed.
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 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5, NIST SP 800-63 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Supports least-privilege review of third-party access paths and scoped permissions. |
| NIST SP 800-53 Rev 5 | AC-2 | Account management governs authorization and removal of persistent access rights. |
| NIST SP 800-63 | Digital identity guidance informs session and authentication boundaries around delegated access. | |
| OWASP Non-Human Identity Top 10 | OAuth grants can function like unmanaged non-human access paths to sensitive data. | |
| NIST AI RMF | If AI agents use OAuth grants, governance must cover their delegated access and accountability. |
Treat third-party OAuth consents as sensitive machine-like identities and review them continuously.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
