The organisation that granted the integration access must own the decision, even if the token was issued through a vendor app. Third-party access should have a named owner, a revocation path, and an offboarding process so the credential does not outlive accountability.
Who should own revocation when a third-party OAuth integration is compromised?
The organisation that granted the integration access must own the decision, even if the token was issued through a vendor app. Third-party access should have a named owner, a revocation path, and an offboarding process so the credential does not outlive accountability.
Why the grantor owns the revocation decision
OAuth can make it look as though the vendor “holds” the access, but the authority to approve and withdraw that access sits with the organisation that connected the app to its systems. That owner understands the business purpose, the data the app can reach, and the blast radius if the integration is abused or no longer needed.
The practical test is simple: if your organisation can authorise the scope, it must also be able to remove it. Treating revocation as the vendor’s problem creates delay, especially when the integration spans multiple systems or when the vendor is unavailable during an incident.
In compromised-integration cases, revocation is not just a technical reset. It is a governance action that should be tied to asset ownership, consent history, and the approval record for the original connection. A clear owner is what lets security teams act fast without arguing over who is allowed to pull the plug.
What a usable revocation path looks like
A usable revocation path is one that can be executed without hunting through vendor support queues or waiting for an internal committee decision. The owner should know where the app registration lives, who can disable it, and what downstream sessions, refresh tokens, or delegated permissions also need to be cut off.
Good practice is to pair the technical control with process clarity. The organisation should know who can trigger emergency revocation, who confirms scope of impact, and who validates that access was actually removed from the target systems. For background on OAuth roles, grants, and token behaviour, see OAuth 2.0 and OpenID Connect Guide for Identity Teams.
Where third-party access is recurring, revocation should be part of the same lifecycle as onboarding and review. The strongest control is not a one-time kill switch, but a repeatable offboarding process that ensures access can be withdrawn cleanly when the business relationship ends or the trust signal weakens.
Third-party access also benefits from explicit ownership and time bounds. Third-Party, B2B and Contractor Access Guide is a useful reference for sponsorship, least privilege, reviews, and offboarding because those controls reduce the chance that an integration survives longer than its approval.
How to assign ownership before an incident happens
The owner should be the business or technical function that obtained value from the integration, not the vendor that issued the token or the team that merely configured it. In practice, that is often the application owner, data owner, or service owner, with security enforcing the revocation standard and IAM or platform teams operating the control.
Ownership should be recorded in the integration register alongside purpose, scope, approver, renewal date, and emergency contacts. If the integration reaches production without a named owner and a documented deprovisioning path, the organisation has already accepted a latent revocation failure.
This is the same reason OAuth incidents often become supply-chain incidents: a trusted third-party path is still an organisational asset, and asset ownership must follow the connection into production. Real breach patterns, such as stolen OAuth tokens used to reach downstream data, show why the revocation decision cannot be deferred to the partner alone. See Salesloft OAuth token breach for a concrete example of that failure mode.
Risk and Threat Considerations
A compromised OAuth integration can keep access alive even after the original trust decision should have been withdrawn. The risk is not only data exposure, but also persistence: a stolen or over-scoped token can continue to act inside the connected environment until revocation reaches the right control point.
Failure mechanism: ownership is split between the business, the platform team, and the vendor, so no one can revoke quickly enough when compromise is suspected. Refresh tokens, cached consent, or lingering app grants extend the attacker window after the initial token theft.
Impact: delayed revocation increases the chance of data theft, lateral access through connected systems, and repeat abuse of the same integration path. In regulated or high-trust environments, it can also turn a contained compromise into a broader third-party incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party OAuth compromise is a third-party identity risk. |
| NHI-05 — Overprivileged NHI | Compromised integrations often retain more access than needed. | |
| NHI-07 — Long-Lived Secrets | OAuth tokens and refresh tokens can outlive their safe use window. | |
| Recommendation — Assess vendor-integrated access for compromise paths and revoke exposed third-party credentials quickly. Reduce integration scopes to the minimum permissions required for the business task. Set expiry and rotation rules so delegated credentials do not remain valid indefinitely. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen or misused OAuth tokens represent broken authentication to downstream APIs. |
| API5 — Broken Function Level Authorization | Revocation and scope control determine what functions the integration can still invoke. | |
| Recommendation — Invalidate affected tokens and re-establish trust at the authentication boundary. Remove excessive privileges so compromised clients cannot call sensitive functions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth tokens and refresh tokens require lifecycle control and revocation. |
| AC-6 — Least Privilege | Third-party integrations should be limited so revocation blast radius stays small. | |
| AU-2 — Event Logging | Revocation decisions need auditability and traceability for third-party access. | |
| Recommendation — Enforce issuance, rotation, revocation, and expiration for authenticators and tokens. Constrain delegated access to the minimum privileges needed for the integration. Log integration grant, use, and revocation events so responders can reconstruct access history. | ||
| ISO/IEC 27001:2022 | A.5.19 — Information security in supplier relationships | Third-party OAuth integrations are supplier relationships that need governed access. |
| A.5.20 — Addressing information security within supplier agreements | Revocation obligations and response expectations should be contractually defined. | |
| Recommendation — Apply supplier security controls to approved integrations and their access boundaries. Specify revocation, notification, and offboarding duties in supplier agreements. | ||
Practitioner Guidance
What to prioritise: put a named owner on every third-party OAuth integration and make revocation authority explicit. If the ownership record does not tell an incident responder who can remove access within minutes, the control is incomplete.
What to verify: confirm that revocation disables the actual access path, not just the visible app entry. Check whether refresh tokens, consent grants, delegated scopes, and downstream sessions are also covered, especially when the integration can reach production data.
Common mistake: assuming the vendor’s willingness to cooperate is a substitute for internal ownership. If your organisation granted the access, your process must be able to withdraw it without external dependency.
Practitioner takeaway: revocation ownership should sit with the organisation that accepted the risk, because only that organisation can make the withdrawal decision fast enough when the integration becomes unsafe.