What is an OAuth grant?

An OAuth grant is an authorization one application holds to access data or perform actions in another application, on behalf of an account, without holding that account’s password.

The familiar version is the consent screen: an application asks to connect to your work Google or Microsoft account, lists what it wants access to, and you approve. From that point the application holds a credential it can use to keep accessing the account — typically a refresh token — rather than asking again each time.

Two properties follow from that, and both matter here. The grant is long-lived by design, and it belongs to the application, not to a browser session. Closing the laptop, changing the password or signing out does not end it.

Why OAuth access can persist

Nothing in the grant itself expires when the circumstances that justified it change.

A grant is created by an explicit act of consent and generally ends by an explicit act of revocation. There is no built-in link between “this employee has left” and “this application should lose its authorization” — those are separate facts held in separate systems.

Consent is also often given by an individual, at a moment when connecting the tool was obviously the right thing to do, without a central record being created. The organization is left holding an authorization it never explicitly decided to grant and has no list of.

Why disabling an identity may not remove every grant

Disabling an identity and revoking an application grant are different operations against different objects.

Disabling the identity acts on the user: it stops that person authenticating. Revoking a grant acts on the relationship between an application and an account. Depending on the provider, the scopes involved and how the application authenticated, an application’s authorization is not guaranteed to disappear the moment the user object is disabled.

This is why offboarding reviews that stop at the identity provider can leave application access in place, and why grants deserve to be enumerated as their own category rather than assumed to be covered.

How discovery and controlled revocation work

Discovery

Solvantra connects to a supported provider and enumerates the OAuth application grants visible against that tenant — through the admin surface in Google Workspace, and through Microsoft Graph in Microsoft 365 (Entra ID).

Analysis

Discovered grants are analysed to flag those that may be unnecessary or risky — for example, a grant associated with a person who has been terminated. The output is a reviewable list with the reasoning attached, not an automatic decision.

Administrator review

An administrator reviews what was found and can revoke flagged grants. Where the HRIS termination workflow is enabled in Live mode, the administrator’s decision to enable it authorizes automatic revocation of already-flagged grants when a termination event arrives. Dry-run shows what would be revoked first.

Revocation

Revocations run through the provider API. The application’s authorization against the account is removed, and the workflow records what was acted on.

Scope and provider limitations

What can be revoked depends on the provider, and the honest boundaries are worth stating plainly.

  • OAuth grant revocation is supported for Google Workspace and Microsoft 365 (Entra ID). No other provider is supported today.
  • Revoking a grant removes the application’s authorization. It does not delete or disable the underlying user account.
  • Discovery covers OAuth-connected applications. An application a person signed into with a username and password, with no OAuth relationship to the connected tenant, is not discovered this way.
  • Google Workspace discovery connects through a standard Google OAuth consent flow; revocation currently requires an administrator to supply a separate refresh-token credential. Microsoft 365 connects through Microsoft Graph using Solvantra’s own app registration (OAuth client credentials), with the organization’s Entra tenant ID supplied by an administrator.
  • Google Workspace discovery has been verified against a real production connection; Google revocation has been tested against simulated provider responses only. No Microsoft 365 tenant has yet been connected in production, and no customer deployment is live yet.
  • Solvantra does not have unrestricted autonomous access to customer environments. Revocation runs through defined workflows that an administrator controls, including whether the HRIS workflow is enabled and which mode it runs in.

Common questions

What is a persistent OAuth grant?

An OAuth grant that remains valid after the reason for it has gone — for example, an application still authorized to read a mailbox belonging to someone who left the organization months ago. It persists because grants end by explicit revocation rather than expiring on their own.

Does changing a password revoke OAuth grants?

Not reliably. An OAuth grant is held by the application through its own credential rather than through the user’s password, so it is not safe to assume a password change removes it. Revoking the grant is a separate, explicit action.

Which providers can Solvantra revoke OAuth grants in?

Google Workspace and Microsoft 365 (Entra ID), through the respective provider APIs. Solvantra does not currently provide connectors for Okta, Workday, BambooHR, Salesforce, GitHub, Slack or AWS IAM.

See which applications still hold access to your tenant.

The free assessment enumerates the OAuth grants Solvantra can discover in a connected environment.

Start Free Assessment