The OAuth Grants That Survive Offboarding

Quick Answer

An OAuth grant is a standing authorization that survives almost everything you would expect to end it. It outlives the password reset, the MFA re-enrollment, the forced sign-out, the employee who approved it, and in many cases the suspension of that employee's account. The grant lives in each SaaS application's consent store, not in your identity provider, which is why offboarding does not touch it and quarterly access reviews do not see it. When a vendor holding one of those grants is breached, the attacker inherits your authority without touching a single employee credential.

Key Takeaways

• Revoking a session is not revoking a grant. The grant is a separate authorization object, and only removing the consent record ends the access.
• Grants do not appear in the identity provider, so joiner-mover-leaver processes never reach them.
• A grant approved by an employee can keep working after that employee's account is disabled. That is an orphaned grant, and it behaves like a stale service account with broader reach.
• Adoption is integration. One consent click joins a third-party application to your estate in seconds, with no security review and no procurement conversation.
• Scope granted is blast radius inherited. The attacker gets exactly what the app was allowed to do, no more and no less.
• When a connected vendor discloses a breach, treat it as a token compromise in your own tenant and start with grant-level revocation, not a password reset campaign.
• AI agents and connectors are now among the largest grant holders in most estates, which makes agent inventory and grant inventory the same problem.

Why does an OAuth grant survive things that should have ended it?

Because a grant is a separate authorization object from the user's credential. Password rotation, MFA re-enrollment, and forced sign-out all operate on interactive authentication. The grant operates on delegated authorization, and the two are governed in different places by different teams.

Three artifacts get confused constantly, and the confusion is where incident response goes wrong.

If your containment step did not remove an app registration or a service principal consent record, you did not contain an OAuth incident. For the mechanics of how those tokens are issued and abused in the first place, see our breakdown of OAuth tokens and their vulnerabilities and the ten OAuth vulnerabilities attackers exploit.

Three failure modes follow:

1. Password reset theater. The help desk resets credentials, the attacker keeps refreshing tokens.
2. Offboarding leakage. An employee leaves, their account is disabled, but a grant tied to a service principal or a maker-mode credential keeps running.
3. Interest decay. Nobody uses the app anymore. The grant does not care. It stays valid until someone revokes it.

Why do OAuth grants stay invisible to the IdP and to offboarding?

Grants live inside each SaaS application's consent store, not in your identity provider's session or sign-in view. Your IdP can show you that a user authenticated. It usually cannot show you that a third-party app has held Files.Read.All against that user's data for fourteen months.

That gap explains the operational pain security teams describe constantly:

• Adoption is integration. A user clicks consent and an application joins the estate in seconds.
• No lifecycle owner. Nobody is accountable for a grant the way someone is accountable for a laptop or a VPN account.
• No expiry tied to intent. The grant outlives the project, the team, and the employee.
• Configuration is not reality. A posture view tells you the app could read mail. It does not tell you whether it did, when, or how much.

This is what ghost chasing looks like in practice: reviewing theoretical configuration with no runtime evidence of what actually happened. The question is not only which grants exist. It is which grants were used, by whom, against what data, and whether any of that is policy-aligned.

What is an orphaned OAuth grant, and why is it worse than a stale account?

An orphaned OAuth grant is a standing authorization whose approving user has left, been disabled, or forgotten it exists, and which no longer has an accountable owner. It is worse than a stale user account for three reasons: it never prompts for MFA, it does not appear in the access review that covers human accounts, and it frequently carries broader scope than the person who approved it needed.

The pattern compounds with AI adoption. Employees adopt AI-powered note-takers, meeting assistants, and analytics tools by clicking a consent screen. Each approval is a grant. Most are never revisited. A 2026 Cloud Security Alliance research note on OAuth consent phishing and AI identity documents shadow AI applications whose OAuth grants were used as a pivot into internal environments, with the grants surviving normal credential rotation.

This is where machine insider risk begins. An AI agent or connector holds a bearer token with the full authority of whoever provisioned it. It has credentials, it touches data, it makes decisions, and no insider risk program covers it. Treat every grant as a non-human identity with a lifecycle, not as a setting.

How does a compromised vendor turn into access to your tenant?

A vendor already holds a valid grant into your environment. If the vendor is compromised, the attacker inherits that grant and reaches your data without touching a single employee credential. The direction of travel is vendor to tenant, and it scales to every customer that vendor serves.

Microsoft's analysis of ShinyHunters activity against SaaS applications documents the model: attackers used vishing to pressure victims into granting OAuth consent to attacker-controlled apps, and separately abused compromised integrations to reach connected SaaS environments. The same actor set has been tied to supply-chain compromise of widely deployed integrations, enabling unauthorized access, data exfiltration, and long-term persistence inside customer tenants.

Because the traffic is authenticated API traffic from a sanctioned application, it is indistinguishable from legitimate integration activity in most logs. As TechTarget's analysis of token theft attacks notes, these token theft intrusions generate no failed authentication events, which is exactly why sign-in dashboards look clean during an active compromise.

How do you find and reduce risky OAuth grants?

Start with enumeration, because you cannot govern what you cannot see. Pull a grant inventory from every major SaaS platform and AI agent builder, then triage on scope and usage rather than on app name recognition.

What a defender should enumerate for every grant:

Reduction checklist:

1. Revoke every grant with no usage in 90 days.
2. Cross-reference every grant against disabled accounts. Those are your orphans, and they go first.
3. Require admin consent for high-privilege scopes covering mail, files, directory, and full CRM access.
4. Restrict who can register OAuth applications in the tenant.
5. Shorten refresh-token lifetimes where the platform allows it.
6. Re-consent high-risk apps on a fixed cadence so intent has to be renewed rather than assumed.
7. Set an expiry clock on every new grant, so the default outcome is lapse rather than permanence.

The common mistake is cleaning the list once. Grant inventory is a continuous control, because every new AI agent and connector adds another token holder.

What should happen the moment a connected vendor discloses a breach?

Treat it as a token compromise in your own tenant, not the vendor's problem. Your first move is grant-level revocation, not a password reset campaign.

A workable first hour:

1. Identify every grant tied to the vendor, including sub-integrations and any AI connector they own.
2. Revoke the grant, then delete or disable the service principal and app registration. Do not stop at session revocation.
3. Pull API activity for that client ID: read volume, records touched, unusual geographies, off-hours bursts.
4. Check for secondary grants the attacker may have created using the vendor's access.
5. Reconcile scopes against what the integration actually needed, and do not re-consent at the old level.
6. Re-authorize deliberately, with narrowed scope and an owner of record.

Containment speed depends on whether you can answer "what did this token touch" without waiting for vendor disclosure. Teams that can only see configuration cannot answer it. Teams with runtime evidence can. Obsidian maps effective authority rather than theoretical configuration, correlating the identity that invoked an app or agent with the credentials that app actually used inside the SaaS application, which is what turns a consent record into an investigable event.

Where to start with orphaned OAuth grants

OAuth grant abuse is not a password problem, an MFA problem, or an endpoint problem. It is an authorization problem, and it lives in a layer most enterprise security programs never inventoried. The grant outlives the enthusiasm that created it, the employee who approved it, and sometimes the vendor that issued it.

Three next steps for the coming quarter:

1. Export grant inventories from your five largest SaaS tenants and sort by scope, not by user count.
2. Cross-reference every grant against disabled accounts to surface orphans, and revoke those first.
3. Rewrite your containment runbook so "revoke the grant and remove the app registration" appears before "reset the password."

Probabilistic agents and opportunistic attackers both exploit the same weakness: standing authority nobody is watching. Deterministic guardrails and a live view of effective authority are what replace ghost chasing with runtime truth.