How to Audit OAuth Permissions in Google Workspace and Microsoft 365 Without Installing an Agent

OAuth grants are the dominant form of third-party access in enterprise SaaS today. Each grant represents a token-based authorization that can persist far beyond a single session, often surviving password changes, multi-factor enrollment events, and even employee departure. Auditing the grant population is therefore a foundational hygiene activity for any organization that depends on Google Workspace or Microsoft 365.

The following procedure can be executed entirely through administrative consoles and well-documented APIs. No endpoint agent, browser extension, or network proxy is required.

Phase 1: Enumerate the existing grant population

Begin in Google Workspace. From the Admin Console, navigate to Security → Access and data control → API controls → Manage Third-Party App Access. This view lists every application that has been authorized by a user in your tenant, along with the requested OAuth scopes and the trust status the administrator has assigned. Export the complete list as a CSV for analysis.

In Microsoft 365, the equivalent picture is split across two locations. The Microsoft Entra portal's Enterprise Applications view shows applications with admin consent. User-consented grants — generally more numerous and more risk-relevant — are best retrieved through the Microsoft Graph endpoint /oauth2PermissionGrants. Combine the two sources before continuing.

Phase 2: Classify by scope sensitivity

Not all OAuth scopes carry equal risk. Read-only access to a user's profile is materially different from broad read-write access to mail or files. Create a three-tier classification:

• High: scopes that include mail.send, files.write, drive.full, mailbox.read.all, sites.fullcontrol, directory.write, or equivalent administrative permissions.

• Moderate: scopes that grant read access to mail, files, calendars, or contact lists for the consenting user.

• Low: scopes limited to profile information, OpenID Connect identifiers, or domain-restricted directory reads.

Authoritative scope guidance is documented by each vendor. For broader principles, NIST SP 800-63B and the OWASP Top 10 both speak to the risks of over-permissive authorization. CISA's SCuBA baselines for Microsoft 365 and Google Workspace include explicit guidance on third-party app access controls.

Phase 3: Identify high-priority remediation candidates

Within the high-tier list, prioritize grants meeting any of the following criteria: applications not in your sanctioned-vendor list; grants consented to more than 12 months ago without subsequent use; grants associated with departed employees or deactivated accounts; and grants from publishers that lack a verified domain or that you do not recognize. The dangerous-apps analysis provides additional indicators that warrant immediate review.

Phase 4: Execute revocation in two stages

Revocation requires two distinct actions, and missing either one will leave the grant effectively active. First, delete the grant itself through the appropriate console or Graph endpoint. Second, revoke any active sessions associated with the consenting user; otherwise, the application may request a new token immediately. In Microsoft 365 this is achieved via revokeSignInSessions in Microsoft Graph or the corresponding PowerShell cmdlet. Document each revocation with the application name, scope, consenting user, and timestamp.

Phase 5: Establish prospective controls

An audit produces a point-in-time snapshot. A control program is what prevents the population from re-accumulating. In Google Workspace, configure App Access Control to either trust, block, or limit applications by scope at the organizational unit level. In Microsoft 365, configure admin consent workflows and restrict user consent to verified publishers and low-risk scopes only. A short companion piece on the three highest-leverage SaaS and cloud queries describes adjacent controls worth reviewing at the same time.

Continuous monitoring beyond the audit

The audit described above produces a defensible baseline. Sustained governance requires continuous monitoring of new grants, scope expansions on existing grants, and the appearance of OAuth tokens tied to identities outside the workforce identity provider. Waldo Security's SaaS Discovery ingests OAuth telemetry from Google Workspace and Microsoft 365 continuously and surfaces high-risk grants, suspicious scopes, and dormant tokens for review without requiring endpoint software.

For a working session that demonstrates the continuous version of this audit against your environment, schedule a demonstration.