The OAuth Permission That Could Compromise Your Entire Org

The OAuth Permission That Could Compromise Your Entire Org

If your SaaS estate “supports SSO” but still leaks data, the culprit is often one word: offline_access. That single OAuth permission mints refresh tokens—long-lived keys that keep apps connected after password resets and user departures. Waldo Security finds these in minutes: we discover every SaaS app, tenant, account, and OAuth grant, flag durable tokens and risky scopes, and export audit-ready evidence. Start with Instant SaaS Discovery; package your proof in the SaaS Compliance Overview.

Forensic Teardown: How offline_access Becomes a Backdoor

1. User clicks “Sign in with ….”  The app asks for broad scopes (e.g., read/write to files) plus offline_access.

2. IdP issues a refresh token.  In Microsoft Entra, refresh tokens are long-lived and only issued when offline_access is requested. They can silently renew access tokens. (Microsoft Learn)

3. You rotate a password or disable the user.  Access can persist until the grant itself is revoked. Deleting the delegated permission (the oAuth2PermissionGrant) actually terminates future tokens. (Microsoft Learn)

4. SIEM sees nothing.  If the app never touches your IdP again, identity telemetry won’t show the ongoing sync. This is why Zero Trust insists on controls at the resource/SaaS layer. (NIST Computer Security Resource Center)

Reality check: attackers love credential paths. In the 2025 Verizon DBIR, ~88% of Basic Web App attacks used stolen creds—so any non-SSO login or persistent token is low-hanging fruit. (Verizon)

Myth vs. Fact (60-second read)

• Myth: “We’re fine—our apps support SSO.” Fact: You’re only fine when SSO/MFA is enforced and alternate paths (passwords, durable tokens) are governed. DBIR shows credentials are still the main door. (Verizon)
  

• Myth: “Consent is harmless; users can approve what they need.” Fact: Entra lets you restrict end-user consent to verified publishers and selected permissions—use it, or you’ll mint org-wide backdoors. (Microsoft Learn)
  

• Myth: “We’d catch risky apps in Google Workspace.” Fact: You must explicitly govern OAuth access with App access control and third-party settings, otherwise user installs can slip through. (Google Help)
  

Detection Recipes (paste into your SIEM/warehouse)

• Persistent & privileged grantsSELECT app, user, scopes FROM oauth_grants WHERE scopes ILIKE '%offline_access%' AND scopes ~ '(ReadWrite|mail.send|files.*write)' ;Follow-up: list refresh-token age and last use; prioritize tenant-wide/write scopes. (In Entra, revoke by deleting the oAuth2PermissionGrant.) (Microsoft Learn)

• Apps with traffic but no IdP trailProxy/DNS ⟂ IdP sign-ins → domains with usage but no enterprise logins. These are often personal tenants or end-user-installed apps.

• Password paths to SSO appsSELECT user, app FROM idp_signins WHERE app IN sso_catalog AND auth_method='password' ;These users bypass SSO and frequently also authorize offline_access.

Control What Matters: A 5-Step Remediation Plan

1) Lock down consent. In Microsoft Entra, set user consent to Verified publishers + Selected permissions; route write/tenant-wide scopes for admin approval. This blocks most risky offline_access requests up front. (Microsoft Learn)

2) Inventory and revoke.

Export all delegated grants and delete the worst offenders (write scopes + offline_access). Use Microsoft Graph to automate revocation at scale. (Microsoft Learn)

3) Enforce SSO/MFA—and measure coverage.

Alert on password logins to apps in your SSO catalog; close local-password fallbacks. (Yes, still the #1 web-app risk pattern.) (Verizon)

4) Govern Google the same way.

Use App access control to limit or block third-party OAuth apps by scope and publisher; require allowlisting for sensitive data access. (Google Help)

5) Prove it, monthly.

Ship an evidence packet: SSO coverage, revoked grants list, admin changes, offboarding timestamps. Faster identification/containment ≈ lower breach cost (global avg ~$4.44M). (IBM)

Quick FAQ for Your IT & Legal Teams

Does a password change kill tokens?

Not reliably across providers and apps. The safe move is to revoke the grant (and refresh token) explicitly; Google and Microsoft document token revocation semantics. (Google Cloud)

Is offline_access always bad?

No—but it should be rare and justified (e.g., service automation) and scoped to read-only where possible, with short lifetimes and monitoring.

How does this fit Zero Trust?

NIST ZTA expects control at the resource plane: verify continuously, least privilege by scope, and log everything—not just at the IdP. (NIST Publications)

What “Good” Looks Like (KPIs)

• OAuth health: # of grants with offline_access and write/tenant-wide scopes (trend ↓).

• SSO reality: % of high-risk apps enforcing SSO/MFA; # of password logins to SSO-catalog apps (trend ↓).

• Evidence freshness: % of artifacts updated in last 30 days (revocation logs, consent settings, admin changes).

With Waldo, you don’t need a spreadsheet marathon. We surface every risky grant, bulk-revoke where supported, and export proof with one click via the SaaS Compliance Overview.

Bottom Line

One checkbox—offline_access—can quietly outlive your passwords and policies. Treat consent and token hygiene as first-class controls, not afterthoughts. See the whole picture with Instant SaaS Discovery, lock down grants, enforce SSO/MFA, and prove it every month. That’s how you prevent a single permission from compromising your entire org.