OAuth grant

An OAuth grant is what one click on a consent screen leaves behind. An employee approves an application, that application receives a refresh token, and from then on it can call the API as that employee whenever it likes. The person does not have to be present. Nothing about the arrangement expires on its own, and the record of it lives in an admin console nobody visits.

The word grant is doing more work than it looks. It is not a login but a standing delegation: a third party now holds a slice of one person's access, defined by the scopes it asked for and forgot to explain.

employee clicks "Allow" on a consent screen
        |
        v
+-------------------------------+        +--------------------------------+
| the identity provider or      |  ----> | the third-party app now holds  |
| workspace records a GRANT     |        | a refresh token for that user  |
+-------------------------------+        +--------------------------------+
                                                    |
   what the grant carries:                          v
   - the scopes the app asked for      it calls the API as the employee,
     (read all mail, manage files,      without them present, for as long
      see the whole calendar)           as the grant stands
   - no expiry, in most cases
   - no manager, no review              password reset:      grant survives
   - the employee's identity            MFA enrolled:        grant survives
     as the actor                       employee offboarded: grant often survives

How does an OAuth grant work?

Four steps, and the fourth is where the risk lives.

1The application asks for scopes

An application redirects the employee to the identity provider or workspace with a list of scopes it wants. That list is chosen by the application's developer rather than by the company, and nothing in the protocol requires it to be minimal or to explain itself.

2The employee approves a consent screen

The employee sees a consent screen naming those scopes in the vaguest language the standard allows, and approves it. Two properties of that moment matter a great deal later. The approval is made by one person acting on their own authority. The screen names scopes rather than the data behind them. A request for every file in the drive and a request for one calendar therefore look much alike.

3The provider issues two tokens

The provider issues an access token, valid for an hour or so, and a refresh token, valid until revoked, both of them defined in RFC 6749. The access token is the short-lived half that everyone means when they say a token expires. The refresh token is the grant itself, and it is the half nobody ever sees.

4The application refreshes forever

The application exchanges the refresh token for new access tokens indefinitely, calling the API as that employee, without a session, an MFA prompt or a login event that looks unusual. Nothing in that exchange re-checks the person's password, their device or whether they still work at the company.

Which grant types leave a delegation behind

OAuth defines several grant types, and only some of them leave a standing delegation. The authorization code grant is what a consent screen runs, and it is the one that produces a refresh token held on a person's behalf. Public clients using it must use PKCE, defined in RFC 7636, which protects the code in transit rather than narrowing what the resulting grant can reach. The client credentials grant has no person in it at all, so what it produces is a service account rather than a delegation. The device authorization grant, defined in RFC 8628, covers command line tools and devices without a browser. It ends in the same kind of refresh token as the authorization code flow. Two older types are now closed off: RFC 9700 states that the resource owner password credentials grant must not be used, and that clients should not use the implicit grant.

The fourth step is the difference between a grant and a login, and it is why integrations are built on grants in the first place. A practitioner in a thread about long-lived credentials put the requirement plainly:

Okay but now how do you recommend I hook up my Sentry instance to create tickets in Jira, now that Jira has deprecated long-lived keys and I have to refresh my token every 6 weeks or whatever. It needs long-lived access. Whether that comes in the form of a OAuth refresh token or a key is not particularly interesting or important, IMO.

That is the honest position, and integrations do need standing access, so the question is never whether grants should exist. It is who holds them, what they can reach, and what happens when the person behind one leaves.

What does a grant carry that a login does not?

Why a grant survives what a login does not

All three survivals have the same cause: the refresh token is bound to the grant rather than to the credential or the session. A password reset invalidates sessions and the old password, and the grant references neither of them. Enrolling in MFA changes an authentication-time control, and a refresh exchange is not an authentication event, so there is nowhere in it to insert a prompt. Offboarding is the one that varies by provider. Suspending a workspace account stops most grants issued by that workspace. A grant created inside a third-party SaaS application has no relationship to the directory, so it keeps working. Microsoft Learn and Google Workspace admin help each document their own review and revocation path, which is the practical confirmation that this is console-by-console work rather than one action in a directory.

Where do OAuth grants accumulate?

Every place an employee can click Allow, which is more places than a stack diagram shows.

• The workspace suite, where a productivity tool asks for mail, drive and calendar scopes. This is the largest pool and the broadest scopes.
• The chat platform, where an installed app can often read every channel it is added to.
• The code host, where an OAuth app can read private repositories or open pull requests as the person.
• The CRM and the data warehouse, where a reporting tool reads whatever the approver could read.
• The identity provider itself, where a grant can carry directory-wide scopes.
• The AI tooling, which is the newest and fastest-growing pool: an assistant connected to mail, files and the CRM holds the same delegation an integration does, and the person who connected it usually did so alone.

What the pools have in common

Each one keeps its own list, in its own console, with its own export format and its own name for the same object. None of them can see the others, so a grant inventory is a manual join across six or more exports, and it starts going stale the day after it is built. That is why the count in the worked example below surprises the company that runs it: no single screen anywhere in the stack has ever shown the total.

Why the newest pool grows fastest

AI tooling arrives as a connection rather than as a purchase. An assistant asks for mail, files and calendar in one consent screen, and the person connecting it is usually working alone on a Tuesday afternoon. The Model Context Protocol authorization specification builds on the same OAuth flows, so an agent connected this way holds a refresh token carrying a person's scopes exactly as an integration does. What differs is the rate, because one person can connect a dozen tools in an afternoon and each connection is a delegation nobody reviewed.

Why do the scopes matter more than the app?

What the consent screen does not say

Because the consent screen hides the difference between reading one calendar and reading every file the approver can see. Scope names are written for developers, so a string like drive.readonly reads as a restriction while granting read access to everything in the drive. Nothing on the screen states how many records the scope reaches, whether shared folders pull in other people's data, or that the grant outlives the task it was approved for. A token with no meaningful scope boundary is a token with full authority, which is the lesson of a widely read incident where an agent used a credential its owner believed was narrow:

It sounds like the token the author created just didn't have any scope, it had full permissions. From the post: Tokens are not scoped by operation, by environment, or by resource at the permission level. There is no role-based access control for the Railway API, every token is effectively root.

Sorting by scope breadth

Sort a grant inventory by scope breadth rather than alphabetically and the shape of the problem appears in a minute: a handful of applications can reach everything, and they are rarely the ones anyone would have named as risky. Four bands are enough to sort an inventory by. Directory and administrative scopes come first, because a grant that can read or write the directory can reach every other system through it. Read-all scopes on mail, files and code come second, since each one exposes the largest volume of data available per grant. Write scopes on those same systems come third, because their reach is usually narrower while the damage from misuse is higher. Single-resource read scopes come last, and most of any inventory sits in that band.

How are OAuth grants governed?

Four moves, in order of what they buy.

1Inventory by scope

Export every grant from every console, and rank by what the scope permits rather than by vendor name. Read-all on mail, files, code or the directory is the top of the list.

2An owner per grant

The approver is the default owner, and a grant whose approver has left has no owner at all. That is the same rule every non-human identity follows, and grants are the most numerous kind in a SaaS company.

3Consent that is not open by default

Most workspace suites can restrict which applications employees may approve, and can route broad scopes to an administrator. Turning that on converts an invisible flow of new grants into a queue with a decision in it.

4Revocation in the offboarding run

Every departure revokes the grants that person approved, in each console, and the run records it. RFC 7009 defines the revocation endpoint; whether an application honours it promptly is a property of that application, which is why the check belongs in the run rather than in a policy document.

Iden lists OAuth grants beside service accounts and agent tokens on the Identities screen, read from each workspace and application rather than from the identity provider, with the scopes each one holds and the employee who approved it. A departure flags every grant that person created, which is the connection between offboarding and the grants nobody inventoried. The feature behind it is Service accounts, API keys and agents.

433 identities. 321 human, 112 not. cc_github and the MCP token sit in the same table as Amy Lee, with the same columns and the same offboarding states.

How does SCIM treat OAuth grants?

Why the protocol cannot see them

SCIM does not see them at all. It provisions accounts from a directory into applications, and a grant is created inside an application by an employee without ever passing through the identity provider. The gap sits in the data model rather than in any one implementation. RFC 7643 defines the core resources SCIM knows about, which are users and groups plus an enterprise extension. None of them represents a delegation held by a third party on a person's behalf. A directory that speaks SCIM perfectly is therefore complete about accounts and silent about grants.

What that means for discovery

So the identity provider's user list is complete and its picture of third-party access is empty. Grants are therefore discovered during an incident or an audit rather than during a review. The practical consequence is that grants have to be read from each application directly, on the same footing as the account lists in applications with no SCIM at all. An access review scoped from the directory will contain no grants whatsoever, however thorough the campaign looks.