The suspicious login alert was not the real problem. The attacker did not need the user’s password anymore. Months earlier, the user had approved a helpful-looking productivity app that requested mailbox and file permissions. The app still had a valid token. When the attacker took control of the app or abused the consent flow, they could read data without triggering the same alerts as a normal password compromise.
This is why a SaaS security audit has to include OAuth applications, third-party integrations, admin roles, and logs. Small businesses often harden endpoints and forget that the company now lives inside Google Workspace, Microsoft 365, Slack, GitHub, HubSpot, Notion, payroll tools, and dozens of browser-based services.
What You Are Looking For
A practical SaaS audit asks five questions: which apps have access, which users approved them, what scopes were granted, whether the access is still needed, and whether the app is trusted enough for the data it can reach. The highest-risk apps are usually the ones with mailbox, Drive, SharePoint, calendar, directory, or offline access.
High-risk OAuth patterns: - Mail.Read or Gmail read access - Mail.Send or Gmail send access - Files.Read.All or broad Drive access - Directory.ReadWrite permissions - Offline access / refresh tokens - App-only permissions with no user present - Unverified publishers or unknown vendors
Audit Google Workspace OAuth Access
In Google Workspace, start in the Admin console under Security, Access and data control, API controls. Review third-party app access and export the list. Google documents the ability to mark apps as trusted, limited, or blocked, and to restrict access to sensitive services such as Gmail and Drive.
Your first pass should classify apps into three buckets: approved business tools, unknown user-approved tools, and blocked or abandoned tools. Do not approve an app only because it is popular. A popular app with broad scopes still needs a business owner, a data purpose, and a review date.
Google Workspace review worksheet: App name: OAuth client ID: Verified status: Users: Requested services: Scopes: Business owner: Data accessed: Decision: Trusted / Limited / Blocked Review date:
Audit Microsoft 365 And Entra ID
In Microsoft Entra ID, review enterprise applications, app registrations, admin consent, user consent settings, and permissions. Microsoft’s least privilege guidance is a good north star: applications should only have permissions they actually need, and unused or reducible permissions should be removed.
Pay special attention to applications with admin-consented Graph permissions, app-only permissions, or long-lived access. If a user leaves the company but an app permission remains active, the company may still have exposure.
Microsoft Graph permissions to review closely: Mail.Read Mail.ReadWrite Mail.Send Files.Read.All Files.ReadWrite.All Sites.Read.All Directory.Read.All Directory.ReadWrite.All User.Read.All offline_access
Turn Consent Into A Managed Workflow
The security goal is not to block every integration. The goal is to stop random approval of powerful access. A small business can use a simple workflow: users request an app, the data owner approves the business need, IT reviews scopes, and security decides whether the app is trusted, limited, or blocked.
App approval questions: 1. What business problem does this app solve? 2. Which data will it access? 3. Which users need it? 4. Does it request write access or offline access? 5. Is the publisher verified? 6. Is there an enterprise plan with audit logs? 7. Who owns the app internally? 8. When will access be reviewed again?
Detection Ideas
Monitoring should focus on new consent grants, risky permissions, new service principals, publisher changes, and unusual use of existing tokens. In Microsoft environments, send Entra audit logs to your SIEM. In Google Workspace, export admin and OAuth-related logs where your plan supports it.
Example KQL-style hunting ideas:
AuditLogs
| where OperationName has "Consent"
| project TimeGenerated, OperationName, TargetResources, InitiatedBy
AuditLogs
| where OperationName has "Add service principal"
| project TimeGenerated, TargetResources, InitiatedBy
SigninLogs
| where AppDisplayName !in ("Office 365", "Google Workspace")
| summarize count() by AppDisplayName, UserPrincipalName
The exact table names vary by logging setup, but the logic is consistent: new app, new consent, high-risk scope, unusual user, unusual location, or access after offboarding.
The Monthly SaaS Audit
Once the first cleanup is done, make SaaS review a monthly routine. Export apps, compare to last month, investigate new entries, remove abandoned apps, and confirm business owners. Review admin roles at the same time. Many SaaS incidents are not clever exploits; they are old privileges nobody remembered.
Monthly SaaS audit checklist: [ ] Export third-party OAuth apps [ ] Review apps added since last month [ ] Remove access for abandoned tools [ ] Confirm owner for each trusted app [ ] Review admin roles and break-glass accounts [ ] Check users who left the company [ ] Review suspicious consent and token activity [ ] Document exceptions with an expiration date
Further Reading
Useful official references include Google Workspace Admin Help on third-party app access, Microsoft guidance on least privileged application access, and CISA’s secure configuration baselines for Microsoft 365 and Google Workspace.