The OAuth Grants Nobody Reviews: Governing Third-Party SaaS Access

An OAuth grant is a standing credential. When a user consents to a third-party application accessing their mailbox, files or calendar, the application receives a token that continues to work after the user has forgotten the consent screen. The grant is not visible in the identity provider's user list, it does not appear in the password reset process, and it survives the password change that the incident response plan treats as containment.

This is a governance gap rather than a technical one. The data is available in the identity provider. The problem is that nobody owns it.

What a grant actually authorises

The scope of an OAuth grant is defined by the scopes the application requested and the user consented to. In practice, the scopes that matter are the ones that permit broad read access to mail, files or directory data. A grant with mail read scope gives the application the ability to read every message in the mailbox, including password reset links, one-time codes and internal documents.

The token itself is usually a refresh token with a long lifetime. Unlike an access token, which expires in minutes or hours, a refresh token can be exchanged for new access tokens indefinitely until it is revoked or it expires. Some providers issue refresh tokens without an expiry, which makes the grant effectively permanent.

Why the grant survives incident response

A standard incident response sequence for a compromised account is: reset the password, revoke sessions, enable MFA. None of those steps revokes OAuth grants. The refresh token is not a session in the sense the session revocation feature understands, and the password change does not invalidate it.

That gap has been used in real intrusions. The pattern is: compromise a user account, consent to a malicious or compromised application, and retain access through the token after the password is reset. The persistence mechanism is a legitimate OAuth grant, which makes it hard to distinguish from normal application access.

The inventory problem

The first requirement is knowing what grants exist. Most identity providers expose this through an administrative view or an API. The useful fields are:

• The application name and its publisher or verified publisher status
• The user or users who consented
• The scopes granted
• The consent date and, where available, the last time the token was used
• Whether the application is admin-consented or user-consented

Admin-consented applications are the higher-priority set. A single admin consent grants the application access across the tenant, and it is not visible to individual users.

The controls that change the outcome

Restrict user consent. Most providers allow administrators to require approval before a user can consent to an application. Setting user consent to require admin approval, or restricting it to applications from verified publishers with low-risk scopes, removes the ability of a user to grant a broad credential on their own.

Review admin-consented applications on a schedule. An admin consent granted for a proof of concept in a previous year is a standing tenant-wide credential. A quarterly review with an owner per application is the minimum.

Include grant revocation in incident response. The containment checklist should include revoking OAuth grants for the affected user, not just resetting the password and killing sessions.

Monitor consent events. A new consent to an application with mail read scope is a high-signal event. It should generate an alert, not just a log entry.

Track the publisher. An unverified publisher requesting broad scopes is a different risk from a verified publisher with a support contract. The publisher status is a field, and it should be part of the review.

The lifecycle question

Grants accumulate because nothing removes them. A user leaves, and the grant remains if the account remains. A project ends, and the integration remains. A vendor is acquired, and the application keeps its verified publisher status.

A lifecycle process needs three triggers: user offboarding, application decommissioning, and an annual review of everything that remains. Each trigger produces a revocation, and each revocation should be recorded so the next review has a baseline.

What this does not solve

The controls above reduce the number of standing third-party credentials and make the remaining ones visible. They do not address a legitimate vendor whose own environment is compromised, which is a supply chain problem with a different control set. They also do not address tokens issued outside the managed identity provider, such as personal accounts used for work.

The value is bounded and concrete: the organisation can answer the question "which third-party applications can read our mail and files, and who approved them?" Most organisations cannot answer it today.

References

• Microsoft, Manage app consent policies in Microsoft Entra ID.
• Microsoft, Revoke user access in an emergency in Microsoft Entra ID.
• Google, Control access to apps using OAuth and Google Workspace.
• IETF, RFC 6749: The OAuth 2.0 Authorization Framework.
• IETF, RFC 9700: Best Current Practice for OAuth 2.0 Security.
• CISA, Mitigating Cloud Computing Risks.