The OAuth token that outlived three employees

Offboarding is a solved problem, organizationally speaking. Someone leaves, HR triggers a workflow, IT disables the account, badge access is revoked, laptop comes back. Most companies do this competently and have done for years.

Here's the gap: that workflow disables the human identity. It very often does nothing at all about the things that human authorized along the way.

And here comes my story. Lately I've been working with a few different clients on security topics. While they usually hire me for bringing AI into their security flow, I kinda always end up also fixing the basics.

Let me tell you the lessons learned, and what you can do in your organization to not let this happen to you.

The specific shape of the problem

First, you need to understand the problem. When an employee connects a third-party tool to a company system — a project management app to the calendar, a note-taking tool to shared drives, an AI assistant to the inbox, a scheduling integration to anything — they authorize an OAuth grant. That grant creates an access relationship that belongs to the application, not to the person's login session. It doesn't require their password. It doesn't prompt their MFA. It has its own token, its own refresh cycle, and it keeps working as long as it isn't explicitly revoked.

Disabling the user account frequently doesn't revoke it. Depending on the platform and how the grant was scoped, the token can keep functioning, meaning reading data, syncing files, holding access to a shared resource that outlived the person who granted the access in the first place.

Why this survives audits

Because nobody's looking in the right place. Access reviews traditionally enumerate user accounts and their permissions. An OAuth grant to a third-party app isn't a user account. It shows up, if at all, in a separate console that a different team may own, often labeled something like "connected apps" or "third-party integrations," and nobody has a recurring calendar reminder to read it.

The result is a category of access that persists across departures, reorganizations, and vendor changes, with genuine reach into company data, and no owner who can even confirm what it's for. I've seen grants still active for tools the company stopped paying for.

What makes this a real risk rather than just messy

Three things stack.

The token doesn't need the human. Revoking a person's login doesn't touch it. Rotating their password doesn't touch it. Their MFA is irrelevant to it.

The scope is frequently broader than anyone intended. OAuth consent screens are notoriously skimmed. "Read and write access to all files in your Drive" is a real, commonly-granted scope that nobody reads carefully at 4pm on a Thursday when they just want the integration to work.

The vendor becomes your attack surface. If the third-party app's own environment is compromised, every organization that granted it access is exposed through a credential that is, from the target's perspective, entirely legitimate. There's no suspicious login to detect. There's an authorized integration doing authorized things, possibly slightly more of them than usual.

What actually closes this

Extend the offboarding checklist to explicitly include OAuth grant revocation for the departing user — this is a concrete, addable step, and most identity providers expose the grants per-user in a way that makes it feasible.

Run a recurring review of connected third-party applications at the org level, not just per-user. Ask, for each one: is this still in use, who owns it, and what scope does it actually hold. Anything that fails all three questions gets revoked, and if something breaks, you've just discovered an undocumented dependency, which is itself a useful finding.

Restrict which applications can be authorized in the first place. Most enterprise identity providers support allowlisting or requiring admin approval for third-party OAuth grants. This is a policy toggle that converts an ongoing sprawl problem into a controlled one, and it's frequently left off because turning it on means someone has to field approval requests.

The honest tension

Turning on approval requirements creates friction, and friction is real — people connect these tools because the tools help them work. Locking it down completely means either a slower company or a shadow-IT problem where people find workarounds you can't see, which is worse. The workable middle is usually: allowlist the common, vetted tools so the ordinary case stays frictionless, and require approval for everything else.

The part nobody automates

Deciding which integrations are worth the access they're asking for is a judgment call about your specific data, your specific risk tolerance, and what your team actually needs to do their jobs. A tool can enumerate the grants. It can't tell you that the marketing team genuinely needs that scheduling integration and the finance team absolutely should not be authorizing a free PDF converter to read everything in their drive.

If you're struggling with understanding your current security posture and you don't really know what you don't know, contact me at evaincybersec@gmail.com