OAuth grant governance: reviewing the apps connected to your directory

what an OAuth grant is

When an employee signs into a third-party app with their company Google or Microsoft account, they are doing more than logging in. The app asks for permission to do specific things with company data. Read your mail. See your files. Access your calendar. Read your profile. The employee clicks Allow, and the app receives a token.

That token is an OAuth grant. It is standing access to company data, held by the app, tied to the employee's identity, with no password that your company manages or rotates. The app does not need the employee to log in again to keep using it. The grant persists until someone revokes it.

The access an app holds is defined by its scopes. A scope is a single named permission. User.Read lets an app read the signed-in user's basic profile. Mail.Read lets it read that user's mailbox. Files.ReadWrite.All lets it read and write files across what the user can reach. The app shows the list of scopes it wants on the consent screen. Few people read that list closely, and once Allow is clicked, the grant is live.

This is the quiet part of your access surface. It sits next to your password policy, your MFA, and your offboarding process, but it does not pass through any of them. An app authorised two years ago by someone who has since left can still hold a valid grant today.

why grants accumulate and why that matters

Three things make OAuth grants pile up.

They are easy to create. In a default Google Workspace or Microsoft 365 setup, a regular employee can grant many delegated permissions on their own. No ticket, no approval, no review. One click and the connection is made.

Nobody approves most of them. The grant happens inside a third-party app's flow, not inside your IT process. IT often learns an app exists only when something breaks or when someone runs an inventory.

They outlive their use. An employee tries a tool for a project, the project ends, the tool is forgotten. The grant stays. The person leaves the company, their account is disabled, and the app-level grant can still be valid because it was created at the app, not at the login.

The result is a growing list of apps with standing access, most of which nobody is watching. That matters because many of these apps request more than they need. A scheduling tool asks for full calendar write. A note app asks to read the whole mailbox. Broad scopes on a forgotten app, held by a third party you no longer track, is access you cannot account for. Third-party involvement appeared in 48% of breaches, up from 30% a year earlier, according to the Verizon Data Breach Investigations Report 2026. Connected apps are one of the most direct forms of third-party access into your data, and in most companies they are the least reviewed.

how to read scopes: a plain-language reference

You do not need to memorise every scope name. You need to tell the difference between a sign-in scope and a data scope.

A sign-in scope lets an app confirm who the user is and read basic profile information. These are low risk. They do not give the app access to your mail, files, or directory.

A data scope lets an app read or change actual company data. Mailbox contents. Drive or SharePoint files. Calendar entries. The directory itself. These are the scopes worth reviewing, and the broad ones are worth questioning every time.

One more scope is worth knowing by name. offline_access lets an app keep working without the user present, by holding a refresh token. An app with a data scope plus offline_access can keep reaching your data after the user has closed the browser and gone home, until the grant is revoked.

• openid, profile, email · Platform: Both · What it lets the app do: Confirm identity, read name and email · Risk: Low. Sign-in only
• User.Read · Platform: Microsoft · What it lets the app do: Read the signed-in user's basic profile · Risk: Low. Sign-in only
• Calendars.Read / calendar.readonly · Platform: Both · What it lets the app do: Read calendar entries · Risk: Medium. Reveals meetings and attendees
• Mail.Read / gmail.readonly · Platform: Both · What it lets the app do: Read the user's full mailbox · Risk: High. All past and future mail
• Mail.ReadWrite / Mail.Send · Platform: Both · What it lets the app do: Read, change, or send mail as the user · Risk: High. Can act as the user in email
• Files.ReadWrite.All / drive · Platform: Both · What it lets the app do: Read and write files across what the user can reach · Risk: High. Broad document access
• Sites.ReadWrite.All · Platform: Microsoft · What it lets the app do: Read and write SharePoint sites · Risk: High. Broad document access
• Directory.Read.All · Platform: Microsoft · What it lets the app do: Read all users, groups, and roles in the directory · Risk: High. Full directory enumeration
• offline_access · Platform: Both · What it lets the app do: Keep access after the session ends · Risk: Raises the risk of any data scope it accompanies

A useful test when you read a grant: does the scope match what the app is for. A scheduling tool needs to read free and busy time. It does not need to read every email. When the scope is far broader than the job, that is a flag, not a feature.

where to find the grants

The grants are visible in the admin console of each platform. The path differs, but the idea is the same: a list of apps, the scopes each holds, and how many users authorised it.

Google Workspace. Sign in to the Admin console. Go to Security, then API controls. Open App access control to see the third-party apps connected to your directory. For each app you can see the scopes it holds and the number of users who granted access. From here you can mark an app as trusted, limited, or blocked, and you can remove access. Newly authorised apps can take a day or two to appear in this view.

Microsoft Entra. Sign in to the Entra admin center. Go to Identity, then Enterprise applications. This lists the apps consented to in your tenant. Open an app and look at its Permissions to see the scopes it holds and whether each is a delegated permission, which acts as a user, or an application permission, which acts as itself across the tenant. Application permissions with a .All suffix deserve the closest look, because they apply across every mailbox or file rather than one user's.

Read the lists in both consoles if you run both platforms. An app connected in Google does not appear in Entra, and the reverse holds too.

the review workflow

A review is four steps. Inventory, sort, triage, document. Then you repeat it on a schedule.

Step one: inventory. Export or list every connected app from each console. Capture the app name, the scopes it holds, the number of users, and the publisher where shown. A simple spreadsheet is enough. The goal is one row per app, with its scopes in plain view.

Step two: sort. Order the list by scope risk first, then by number of users. The apps that hold high-risk data scopes and reach many users sit at the top. A low-risk sign-in app used by one person can wait.

Step three: triage. Decide each app into one of three outcomes.

• Keep. The app is known, in use, and its scopes match its job. No action beyond recording the decision.
• Restrict. The app is wanted, but its access is broader than needed, or it should be limited to fewer users or to an admin-approved state. Note the change to make.
• Revoke. The app is unknown, unused, tied to a departed employee, or holds broad scopes with no justification. Remove its access.

For the top of the list, ask three questions of each app. Do we know what this is and who uses it. Does the scope match the job. Is the publisher one we recognise. An app that fails any of these moves toward restrict or revoke.

Step four: document. For each app, write down the decision, the reason, and the owner. The owner is the person accountable for that app continuing to hold access. A decision with no owner is a decision that gets reversed by the next person who clicks Allow. Keep the record. It is also what an auditor will ask to see.

Then set a cadence. Grants accumulate continuously, so a one-time review ages quickly. A quarterly review of high-risk and high-reach apps, with a half-yearly pass over the rest, is a defensible starting point. Tie a grant check into your offboarding process as well, so a departing employee's connected apps are reviewed when their account is disabled rather than months later.

preventing future sprawl

Reviewing the list is half the work. The other half is slowing how fast it grows back. Four controls do most of this, and all of them live in the same admin consoles.

Set admin consent for high-risk scopes. Configure your tenant so that apps requesting data scopes, such as mailbox or full file access, require an administrator to approve them. Employees can still use apps. They cannot silently hand over broad access on their own.

Restrict user consent to low-risk scopes. Allow employees to consent on their own only to sign-in level scopes from recognised publishers. Anything beyond that routes to review.

Maintain an app allowlist. Keep a list of approved apps pre-cleared for use. In Google Workspace you can set API access to a restricted state and trust specific apps. In Entra you can manage which apps are permitted and which are blocked. The allowlist is the list you reviewed and decided to keep.

Give employees a request path. A control that only blocks creates pressure to work around it. Pair the consent restriction with a simple way for an employee to request an app and get a quick decision. The point is to make sure someone sees the request before the access is live, while people still get their tools.

Together these turn app access from something that happens by default into something that passes through a light, visible step.

the honest scope note

A directory-based review is a clear view, but it is not the whole view. It sees apps connected through OAuth and through your single sign-on. That is a real and important part of your access surface, and for most companies it is the part that has never been looked at.

It does not see everything. An employee using a personal account outside the directory does not show up here, because nothing was connected to your tenant. A browser extension running on someone's laptop does not show up either, because it lives on the endpoint, not in your directory. Those need other signals. Endpoint or mobile device management gives visibility into what runs on company devices. A browser-security tool gives visibility into extensions and into what employees sign into in the browser.

Knowing this keeps the review honest. It tells you what you have covered and what you have not, so you do not mistake a clean OAuth list for a complete picture of every tool in use.