The OAuth grant lifecycle problem nobody is managing

There is a category of access in your environment that outlives your employees, ignores your SSO configuration, and leaves no trace in your activity logs. It's the OAuth grant, and most security teams misunderstand how it works.

‍

When a user clicks "authorize" on an OAuth consent screen, they aren't logging in. They're establishing a long-standing trust relationship between two applications on their behalf. That relationship persists independently of the user's session, their password, and in many cases, the user themselves.

‍

OAuth sits outside your identity controls

The first misunderstanding is assuming OAuth grants inherit the controls you've built around user identity. They don't. OAuth is a completely separate protocol from authentication. SSO governs how a user proves who they are. MFA adds friction to that proof. An OAuth grant is neither of those things. It's a delegation of access that, once established, no longer requires the user to be present at all.

‍

This means the security controls you rely on for user access simply don't apply. A grant issued by a user with hardware-key MFA and strict conditional access policies is just as durable as one issued by a user with a weak password. The controls gated the moment of creation. They have no bearing on the grant's ongoing life.

‍

Disabling a user does not disable their grants

Here's where the lifecycle disconnect gets dangerous. Most teams assume that when they disable a user in their identity provider, everything that user could do dies with the account. That assumption holds in exactly one narrow case.

‍

If you disable a user in Google or Microsoft, grants that originated within that platform are suspended. Note the word: suspended, not removed. The grants remain in place, inactive only for as long as the account stays disabled. Re-enable the account and the trust relationships come right back.

‍

Everything outside those platforms is a different story. Grants issued from third-party applications continue operating completely uninterrupted when the user is disabled in your IdP. And this is true even when the issuing application sits behind your single sign-on configuration. The user can't log in anymore. The grant doesn't care. It was never a login to begin with.

‍

This is the blind spot in nearly every offboarding runbook I've seen. Teams disable the account, reclaim the laptop, revoke the sessions, and consider the job done. The delegated access that user spread across dozens of platforms over their tenure remains untouched, unaudited, and in most cases, unknown.

‍

Grants need access reviews, just like users

If you accept that OAuth grants are a form of standing access, the conclusion follows naturally: they need to be reviewed the way you review user access.

‍

That starts with an inventory. Not a sample, not the grants in your Google Workspace admin console. A complete inventory of grants across every application that has issued them and every application that has received them. For each one, you need to answer the same question you'd ask in a user access review: is there an ongoing need for this access? A grant created three years ago by an employee who left two years ago, connecting a tool you no longer pay for, should not still be valid. In most environments, it is.

‍

You can't find them in your logs

Now for the part that makes this genuinely hard. The instinct of every security team is to go to the activity logs. Pull the audit trail, find the OAuth activity, build the inventory from there. That approach fails, and it fails silently.

‍

OAuth grants can sit dormant for a very long time and remain fully valid. A grant that hasn't been exercised in months produces no log entries, but the trust relationship is intact and the access can be exercised tomorrow. Searching your activity logs gives you visibility into grants that are active, and tells you nothing about grants that exist.

‍

The worst offender here is the identity-only grant. This is the "sign in with Google" pattern, where the provider asserts the user's identity and nothing more, because the receiving platform already has all the data it needs. There's no subsequent data retrieval. No API calls pulling files or reading mail. Nothing that would ever show up in an activity log. And this is one of the most common grant types in any environment, which means the grants you're least able to see are also the ones you have the most of.

‍

At small scale you can muddle through this manually. At the scale of a real organization, where employees average 88 OAuth grants each and 31 of them carry data-level permissions, log-based discovery gives you a false sense of coverage, not real visibility.

‍

Where to start

Treat OAuth grants as what they are: standing trust relationships with their own lifecycle, separate from the users who created them. That means three things in practice.

‍

First, build a real inventory using discovery methods that don't depend on activity, so dormant and identity-only grants are included. Second, fold grant reviews into your existing access review cadence, validating ongoing need for both the issuing and receiving side of every grant. Third, fix your offboarding runbook so that revoking a user's delegated access across platforms is an explicit step, not an assumed side effect of disabling their account.

‍

The user lifecycle and the OAuth grant lifecycle are two different things. The organizations that get burned are the ones managing only one of them.