Origin
Anchit has run the same test on a dozen calls in the past year: open the Google Workspace admin console, go to API controls, read out the number of third-party apps with granted access. The number is always higher than the team expected. Roughly half the names are ones nobody on the call recognizes.
Every one of those grants was made by an employee who clicked "Connect with Google" in something they were evaluating. None of them went through IT. None of them expire.
What the grant actually is
The grant lets an application act as that user, inside the scope it asked for. Apps ask for more than they need, so the scopes skew wide: read all Drive files, read and send mail, full calendar access. An engineer wiring up a reporting tool in an afternoon has just delegated persistent read access to a production data source, and the only record of that decision lives in a consent screen they clicked past.
This is an entitlement grant. It just doesn't look like one to the person making it, which is why it never reaches a review.
Why offboarding never touches them
Disable the account in your IdP and the login stops. The grant doesn't. Tokens issued under it keep working, and refresh tokens frequently survive a password reset and sometimes survive a disable, because credential revocation and session revocation are separate operations and most checklists only do the first one.
So the shape is this. Someone leaves in March. Their access is closed, correctly, in every system your provisioning tool knows about. The analytics vendor they connected to the CRM in 2024 keeps pulling records into a workspace nobody owns. Nobody wrote a leaver process for a token, so nothing runs.
The higher-risk versions are the ones tied to people who had real access: a database connected through an automation platform, finance data feeding a reporting app, the CRM wired to something a growth team trialled and abandoned. Those grants are the least likely to be reviewed and the most expensive to be wrong about.
Where to look first
Google Workspace gives you the cleanest view: admin console, Security, API controls, third-party app access. Sort by scope rather than by name and start with anything holding broad Drive or Gmail permissions. GitHub keeps authorized OAuth apps and GitHub Apps under organization settings, with the authorization events in the audit log. For Microsoft, the Entra admin center lists enterprise applications and their consented permissions, though the scope detail is coarser than Google's.
Export whichever list you can get and diff it against your current roster. Grants belonging to people who already left are the ones to revoke this week. Not a full audit, just the part that pays for itself immediately.
What actually keeps it closed
You can add OAuth review to your offboarding template, and you should. It will get skipped, because it sits outside the report your identity tooling produces and nobody misses a step that was never on the screen.
What actually holds is pulling the grant list out of each provider on a schedule, diffing it against who should still be there, and acting on the difference. Discovery is the control. The checklist is a note about the control.
Teams that get this working stop treating OAuth as a category of its own. It becomes another population that gets reconciled, alongside the accounts and the keys. We cover the providers that expose their grant data well and we're still working through the ones that don't. Partial visibility beats the current state, which is a list nobody has opened.