Third-party OAuth consent: the integration somebody approved in 2023
Verizon's 2026 breach analysis attributed roughly 48% of breaches to third-party and supply chain paths. A substantial share of those run through standing OAuth grants that nobody has looked at since the day they were approved.
Who approved that third-party integration in 2023?
Probably an administrator who has since left. A tenant-wide OAuth consent granted years ago persists, the scopes were never re-evaluated, and the application may have changed substantially since. The grant is live and the decision behind it is unrecoverable.
- OAuth consent was designed as a one-time user decision. Enterprise admin consent generalises it to the whole tenant, permanently, with no expiry and no reaffirmation.
- The approver is frequently unrecorded or departed, so nobody can be asked why the grant exists.
- Scope-risk scoring concentrates reaffirmation effort where tenant exposure is greatest, because reaffirming everything annually is how these programmes die.
Part of Machine and signing identity
What I found when I asked
I asked our security team a simple question after reading the 2026 breach figures: how many third-party applications have standing access to our tenant, and who approved each one?
The first number came back in an afternoon. It was roughly four times what I expected.
The second number never came back, because it does not exist in a usable form. Some grants had an approver recorded in an audit log within retention; most predated the retention window. Of the approvers we could identify, a third had left the company.
Why the grant is permanent by design
OAuth consent was specified for a consumer interaction: a user grants an application access to their own data, and revokes it when they stop using the application. That model is coherent.
Enterprise admin consent extends it so an administrator can approve on behalf of every user in the tenant, avoiding a consent prompt for thousands of people. That is an operational necessity and it changes the character of the decision entirely.
| Property | User consent | Admin consent |
|---|---|---|
| Who is affected | One user | Every user in the tenant |
| Duration | Until revoked | Until revoked |
| Expiry | None | None |
| Reaffirmation | Implicit — the user keeps using it | None |
| Visibility | The user sees the app | Nobody sees it after approval day |
What changes after the approval
Everything that mattered to the decision, and none of it feeds back.
- The vendor is acquired, and their security programme changes.
- The application adds features requiring broader scopes, sometimes granted incrementally without a fresh review.
- The business need that justified it ends, and nobody removes the grant because nobody owns it.
- The vendor suffers a breach, and your tenant grant is on their side of it.
- The approver leaves, and institutional memory of why it exists goes with them.
Scope-risk scoring
Reaffirming every grant annually produces a certification campaign, which produces rubber-stamping, which produces nothing. Concentrate the effort.
| Factor | Weight | Example high-risk value |
|---|---|---|
| Data breadth | High | Read all mail, read all files, read all sites |
| Write capability | High | Send mail as any user, modify files |
| Directory access | High | Read directory data, read group memberships |
| Offline access | Medium | Refresh tokens that survive password changes |
| Vendor concentration | Medium | Vendor holds grants across many of your peers |
| Business criticality | Low for risk, high for removal cost | Core workflow dependency |
The top three combined are what turns a grant into a tenant-wide data exposure. A grant with all three should reaffirm every six months; one with none can reaffirm every two years or not at all.
The reaffirmation act
Not a checkbox. A signed statement naming the approver, the scopes as they currently stand, the business owner, and the expiry.
{
"type": "manav-stmt/1",
"action": "third_party_consent_reaffirmation",
"application": "[name, publisher, application id]",
"scopes": "[current scopes, enumerated]",
"scope_delta": "[changes since prior reaffirmation]",
"business_owner": "[named individual]",
"notAfter": "[expiry per risk tier]",
"approver": "[credential assertion]"
}The scope delta field is what makes this worth doing. An application that has quietly broadened its permissions since the last review is the single most common finding, and today nothing surfaces it.
Platform reality
Major SaaS platforms do not natively support expiring admin consent. That means the expiry is enforced by your governance process rather than by the platform — a reaffirmation that lapses produces a removal task, not an automatic revocation.
That is weaker than platform enforcement and it is what is available. Stating it plainly is better than implying a control that does not exist.
Why OAuth grants are uniquely persistent
| Property | Employee access | OAuth grant |
|---|---|---|
| Reviewed periodically | Yes — certification | Rarely |
| Expires | Sometimes | No |
| Survives the approver's departure | No | Yes |
| Survives a password reset | No | Yes |
| Visible in access reviews | Yes | Frequently not |
Objections and honest limits
“We review third-party applications.” At onboarding. The review that matters is the second one, and most organisations have no trigger for it.
“Revoking old grants breaks things.” Some of them, which is why expiry with re-affirmation is better than periodic mass revocation. Re-affirming is a decision; discovering breakage is an incident.
Re-affirming consent
- Inventory tenant-wide grants and their approvers. Most organisations have never listed them.
- Expire grants by default. Annually is a reasonable starting point.
- Re-affirm as a signed act. By a current, named administrator.
- Trigger review on scope change. An application requesting more should require a new decision.
Terms used here
- Tenant-wide consent
- An administrator granting an application access on behalf of every user in an organisation.
- Scope
- What an application is permitted to do, which can be expanded by the application requesting more.
- Re-affirmation
- Explicitly renewing a grant, converting persistence from a default into a decision.
Frequently asked questions
Can we not just review the app list annually? That is a certification campaign over hundreds of items and it will be rubber-stamped. Scope-risk scoring concentrates genuine review on the grants that carry tenant-wide exposure.
Do platforms support expiring consent? Generally not natively. Expiry is enforced by your governance process, which is weaker than platform enforcement and should be described as such.
What about user-consented applications? Restrict user consent to low-risk scopes by policy and route everything else through admin consent, which is where this process applies.
How do we handle a departed approver? Reassign to a current business owner at the next reaffirmation, or remove the grant. A grant nobody will claim is a grant that should not exist.
Why do OAuth grants survive password resets? Because they are independent of the user's credential. Revoking a password does not revoke a grant the user or an admin approved.
Why not just revoke old grants? Some are load-bearing. Expiry with re-affirmation converts persistence into a decision without producing an outage.
What should trigger a review? Annual expiry, and any scope expansion requested by the application.
Where this fits in Manav
Manav anchors every machine and agent identity to a named human through a signed delegation with scope, expiry and enforced revocation — so the chain from an action to a person survives the identity outliving its creator.
Sources and further reading
- Verizon Data Breach Investigations Report
- FTC — business guidance on marketplaces and consumer protection
- CISA — known exploited vulnerabilities and incident reporting
- SaaS security posture management practice guidance.
- RFC 6749 — The OAuth 2.0 Authorization Framework
- OWASP — Non-Human Identities Top 10
- NIST SP 800-57 Part 1 Rev. 5 — key management