How Are Your SaaS Connections Secured and Monitored?

Here’s an exercise: list every third-party application connected to your Google Workspace or Microsoft 365. Every OAuth grant, every API integration, every “Sign in with Google” token your employees have issued.

If your answer is “I don’t know,” you’re normal. Most organizations have dozens to hundreds of SaaS connections they don’t know about. Marketing connected a social scheduling tool. Sales linked their inbox to a productivity app. An engineer authorized a code analysis service. Each connection is a potential data access path.

This isn’t a theoretical risk. OAuth token abuse is an established attack technique. Supply chain compromises hit SaaS vendors regularly. Every connection is a relationship you need to manage—and you can’t manage what you don’t see.

The SaaS Connection Landscape

Modern organizations operate in a web of interconnected services. Understanding the landscape is the first step.

OAuth Integrations

OAuth enables applications to access resources without sharing passwords. When you click “Allow” on “AppX wants to access your Google Drive,” you’re granting an OAuth token.

The problem: OAuth tokens often have broad permissions and don’t expire. That marketing tool granted access three years ago still has read access to employee calendars.

Common OAuth permission scopes to watch:

• Email read/send (can exfiltrate data, send phishing)
• File read/write (can access and modify documents)
• Calendar access (can read meeting details, potentially sensitive)
• Admin scopes (can modify organization settings, manage users)

API Integrations

Beyond OAuth, applications connect through API keys and service accounts. Your Salesforce connected to marketing automation. Your Slack connected to ticketing. Your GitHub connected to CI/CD services.

These integrations often have service-account-like access—persistent, privileged, and invisible to normal monitoring.

Shadow SaaS

Employees adopt SaaS applications without IT approval. Credit card signup takes five minutes. Nobody reviews security. The application accesses company data via OAuth grants employees can issue themselves.

Shadow SaaS isn’t malicious—it’s employees finding tools that help them work. But it creates unmanaged access paths.

The Audit Process

To secure SaaS connections, first understand what exists.

Step 1: Inventory OAuth Grants

For major identity providers (Google Workspace, Microsoft 365, Okta), you can enumerate OAuth grants.

Google Workspace:

• Admin Console → Security → API Controls → App Access Control
• Shows third-party apps with access to your organization’s data
• Can drill down by user, permissions, and access level

Microsoft 365:

• Entra ID → Enterprise Applications
• Shows applications users have consented to
• Permissions and user assignments visible

Okta:

• Admin → Applications
• Shows connected applications and their permissions

Export this data. You’ll likely find surprises—applications you forgot about, applications with more access than expected, applications whose vendors you’ve never assessed.

Step 2: Classify by Risk

Not all connections are equal. Classify based on:

Data access: What can this application access? Email content is higher risk than calendar availability.

Permission scope: Read-only is lower risk than read-write. User-level is lower risk than admin-level.

Vendor maturity: Established vendors with security programs are lower risk than unknown startups.

Business criticality: Is this integration essential or experimental?

Create tiers:

• Tier 1 (High risk): Broad data access, write permissions, unknown vendors
• Tier 2 (Medium risk): Limited data access, read-only, established vendors
• Tier 3 (Low risk): Minimal access, well-known vendors, low-sensitivity data

Step 3: Review Tier 1 Integrations

For high-risk integrations:

Validate business justification. Who authorized this? Why do they need this access? Is it still in use?

Assess vendor security. Do they have SOC 2? Security documentation? History of breaches?

Verify permission scope. Does the application need all the permissions it has? Can scope be reduced?

Check token status. Is this integration active? When was it last used?

If you can’t justify the access, revoke it.

Step 4: Discover Shadow Connections

OAuth grant enumeration finds sanctioned connections. Finding shadow SaaS requires additional approaches:

CASB (Cloud Access Security Broker): Tools like Netskope, Microsoft Defender for Cloud Apps, or Zscaler can discover SaaS usage via traffic analysis.

Expense reports: SaaS subscriptions often show up in expense reports. Search for common SaaS vendors.

SSO logs: Failed SSO attempts may indicate users trying to access SaaS they expect to work but isn’t configured.

Employee surveys: Ask teams what tools they use. You’ll find things other methods miss.

Browser extension audits: Extensions can have OAuth-like access. Audit what extensions are installed on corporate devices.

Securing SaaS Connections

Once you know what’s connected, implement controls.

Implement OAuth Controls

Most identity providers allow you to control OAuth grants:

Google Workspace:

• Restrict which apps can access data (allowlist/blocklist)
• Require admin approval for new high-privilege apps
• Set default trust levels for app types

Microsoft 365:

• Enterprise app consent policies
• Require admin consent for specific permissions
• Block user consent entirely (everything requires admin approval)

Recommendation: At minimum, require admin approval for apps requesting high-privilege scopes (email read, admin access, full drive access). Users can still request; IT/Security approves.

Token Lifecycle Management

OAuth tokens often don’t expire. Implement lifecycle controls:

Regular access reviews: Quarterly, review OAuth grants and revoke unused ones.

Token expiration policies: Where possible, configure shorter token lifetimes.

Usage monitoring: Track which tokens are actively used. Inactive tokens should be revoked.

Vendor Security Requirements

Establish requirements for connected applications:

Tier 1 (high-risk):

• SOC 2 Type II or equivalent
• Completed security questionnaire
• Defined data handling practices
• Incident notification provisions

Tier 2 (medium-risk):

• SOC 2 or attestation of security practices
• Basic security questionnaire
• Acceptable privacy policy

Tier 3 (low-risk):

• Reasonable reputation
• Acceptable terms of service

Enforce these at the approval stage. Don’t approve Tier 1 apps without appropriate security validation.

API Key Management

For API integrations (beyond OAuth):

Inventory API keys. Where are they stored? Who has access? What do they access?

Rotate regularly. API keys should rotate at least annually, more frequently for high-privilege access.

Scope appropriately. Create keys with minimum necessary permissions. Don’t use admin keys for limited-scope integrations.

Monitor usage. Most SaaS providers offer API usage logs. Monitor for anomalies.

Monitoring SaaS Connections

Ongoing monitoring catches changes and abuse.

Monitor for New Connections

Alert when new OAuth grants are issued—especially for high-privilege scopes.

Google Workspace:

• Admin SDK or Google Workspace Alert Center
• Alert on OAuth token grants with sensitive scopes

Microsoft 365:

• Azure AD audit logs
• Alert on consent grants

What to alert on:

• Any new Tier 1 (high-privilege) OAuth grants
• OAuth grants outside of approved application list
• Grants from high-value accounts (executives, admins)

Monitor for Suspicious Activity

Connected applications can be compromised or abused. Monitor for:

• Unusual API call volumes from integrated services
• Data access patterns inconsistent with application purpose
• Access from unexpected IP ranges
• Sudden increase in OAuth token usage

Some CASB solutions provide this monitoring. Native provider logs (Google Workspace audit logs, Microsoft 365 audit logs) can also be analyzed.

Monitor for Vendor Compromises

Subscribe to security news for vendors in your ecosystem. When a connected vendor has a breach:

1. Assess whether your data was affected
2. Review access logs for suspicious activity
3. Consider revoking/rotating tokens
4. Communicate with vendor about incident response

Responding to OAuth Compromise

If you suspect a connected application is compromised:

Immediate actions:

1. Revoke OAuth tokens for the affected application
2. Rotate any shared credentials (API keys, etc.)
3. Review access logs for the application
4. Notify potentially affected users
5. Block new connections to the application

Investigation:

1. Identify what data the application could access
2. Determine if that data was exfiltrated
3. Check for persistence mechanisms (did the attacker create new tokens?)
4. Assess blast radius

Recovery:

1. Decide if the application can be re-trusted
2. If re-connecting, scope permissions more narrowly
3. Increase monitoring on re-connected application
4. Document lessons learned

The Realistic Challenge

SaaS connection security is a continuous battle, not a one-time project.

Employees will always find new tools. OAuth grants will be issued faster than you can review them. Vendor ecosystems will have security incidents.

The goal isn’t perfect control—it’s appropriate visibility and risk management:

• Know what’s connected
• Classify by risk
• Control high-risk connections
• Monitor for changes and abuse
• Respond when things go wrong

Build this muscle gradually. Start with the audit. Implement the most impactful controls. Establish monitoring. Then iterate.

The alternative—not knowing what’s connected to your data—is worse.