OAuth Grants: The Source Nobody Checks

A user clicks "sign in with" and grants an application read access to their mailbox. No money changes hands, no ticket is raised, and no discovery source based on spend or SSO will ever see it.

What the grant actually is

A standing permission for a third party to access your data through an API, on the user's behalf.

Scoped, in principle — read email, read files, read and write calendar. In practice users grant whatever is asked.

Persistent. It survives password changes and continues until revoked or the account is deleted.

Frequently broad. "Read, compose, send and permanently delete all your email" is a real scope that real applications request and real users approve.

Sometimes organisation-wide, where an admin granted it on behalf of everyone.

Where to find them

Every major workplace platform exposes this.

Your email and productivity suite has an admin view of third-party applications with granted access, per user and organisation-wide.

Your chat platform has an installed-applications list.

Your code hosting has OAuth applications and personal access tokens.

Your CRM and other major platforms have connected applications.

Export all of them. This is a half-day exercise and it is the highest-yield discovery activity available.

What the export shows

Applications you have never heard of, holding access to mailboxes.

Dormant grants to applications nobody uses any more.

Grants belonging to people who left, if account deletion did not revoke them.

Broad scopes on trivial applications — a scheduling tool with full mailbox access.

One user having granted access on behalf of a whole domain.

Applications that are the same product under different names, granted repeatedly.

Triaging the list

By scope first, not by name. Anything with write or delete access to email or files goes to the top regardless of how familiar the application is.

Then by user count. An application granted by one person is a different problem from one granted by two hundred.

Then by whether it is in the register. Unknown plus broad scope plus many users is where to start.

Then by vendor. An application from an identifiable company with a security page is a different risk from one you cannot attribute.

Acting on it

Revoke dormant grants. Anything not used in a defined period, revoked in bulk. Users who need it will re-grant, which is a signal.

Revoke on offboarding, which most offboarding processes do not do.

Restrict who can grant. Most platforms allow admin approval for third-party applications, either for all or for those requesting sensitive scopes. This is the durable control and it is off by default.

Publish an allow list of approved applications so the restriction does not simply block work.

Register what remains, with its scope recorded in the application register.

The ongoing control

Monthly export and diff. New grants since last month, reviewed.

Alert on broad scopes being granted.

Alert on organisation-wide grants, which should be rare and deliberate.

Include grant revocation in offboarding, explicitly, as a step with a tick.

Review the allow list quarterly.

Why this matters more than the spend

Most SaaS management work is about money. This one is about data access, and the exposure is asymmetric: a five-dollar application with full mailbox read access is a larger problem than a fifty-thousand-dollar platform with a security review and a contract.

A programme that has never exported its OAuth grants does not know its data exposure, whatever its inventory says.

The scope categories that matter

Not all grants are equal, and triaging by scope rather than by application name is what makes the list manageable.

Full mailbox access, including send and delete. The highest exposure available, and requested by more applications than seems reasonable.

Read all files. Broad and common.

Write or delete files, which is worse and less common.

Calendar read, which sounds harmless and reveals organisational structure, travel and meeting participants.

Contacts read, which exports your address book to a third party.

Offline access, meaning the grant works without the user being present. Combined with any of the above, this is the one to look at first.

Sort your export by these categories rather than alphabetically, and review from the top. The first twenty lines will occupy the first meeting.

Restricting who can grant

The durable control, off by default in most platforms, and the one that stops the list regrowing.

Admin approval required for third-party applications requesting sensitive scopes.

An allow list of approved applications that users can grant freely, so the restriction does not block ordinary work.

A request route for anything not on the list, answered in days.

Organisation-wide grants restricted to a small number of administrators, since one click there affects everyone.

Turn it on after publishing the allow list, not before. Restricting first and cataloguing later produces a week of blocked work and a permanent reputation problem for the programme.