Topic starter
11/11/2026 6:01 pm
TL;DR: 92% of organisations expose NHIs to third parties, according to Tracecat's survey-backed analysis of OAuth app connections and token access. Connected apps turn user consent into shared credential risk, so inventory, scope review and revocation need to happen at issuance time.
Editorial analysis by NHI Mgmt Group, based on content published by Tracecat: “Managing the lifecycle of Google OAuth apps with agents”.
Key questions
Q: Why are OAuth consent grants hard to govern after approval?
A: OAuth consent grants are hard to govern because approval can create long-lived delegated access that survives the original user interaction, often with scopes that are wider than intended.
Q: How should security teams govern OAuth scopes in SaaS environments?
A: Treat OAuth consents as non-human identities with owners, lifecycles, and revocation rules.
Q: How do connected OAuth apps create shared credential risk?
A: A connected OAuth app receives a token that can act with the scopes the user approved, so the app can keep accessing mail, files or other services until the token is revoked.
Practitioner guidance
- Inventory every connected OAuth app Build a complete register of third-party apps connected to user accounts, including who approved them, which scopes they hold and when they were last seen active.
- Review high-risk scopes as privileged access Treat mailbox, file and offline access scopes as elevated entitlements and require explicit business justification before allowing them to remain connected.
- Revoke tokens when purpose is unclear Remove access when ownership, publisher identity or business need cannot be confirmed, and record the reason so the decision is auditable later.
Bottom line: OAuth consent can create durable delegated access that survives the original sign-in and bypasses routine authentication checks.
Glossary terms: OAuth Consent, OAuth Token, Third-Party Applications, Google Workspace Integration
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:06 pm
Connected OAuth apps turn consent into standing identity risk: The control decision happens at approval time, but the security exposure persists for as long as the token remains valid. That breaks the old assumption that user approval is a bounded event with a clean end point. Identity governance now has to treat delegated app access as a live entitlement, not a snapshot.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should IAM teams do after an OAuth app is found to be suspicious?
A: They should disconnect the app, revoke or rotate the relevant access, and review the consent path and audit history to understand what the token could reach. Response should focus on containment first, then on re-establishing a trustworthy baseline.
👉 Read our full editorial: Google Workspace OAuth consent leaves shared tokens active until revoked