OAuth consent and token reuse: what IAM teams need to fix

TL;DR: Attackers in the Salesforce breach exploited OAuth consent and API token reuse to bypass MFA, exposing how connected apps turn convenience into a persistent access path, according to HYPR. The breach shows that deterministic identity assurance and least privilege matter more than login hardening alone.

NHIMG editorial — based on content published by HYPR: The Salesforce Breach Is Every RevOps Leader’s Nightmare: How to Secure Connected Apps

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.

Questions worth separating out

Q: How should security teams govern OAuth consent for connected apps?

A: Security teams should treat OAuth consent as a privileged access grant, not a normal user click.

Q: Why do token reuse and refresh tokens create so much risk in SaaS integrations?

A: Token reuse is risky because bearer tokens act as proof of access by possession.

Q: What breaks when organisations secure logins but ignore app approvals?

A: What breaks is the assumption that MFA on the login page is enough to control access.

Practitioner guidance

• Review connected app consent scopes Inventory every Salesforce-connected app, identify offline access and broad permissions, and remove any scope that is not required for a documented business process.
• Treat OAuth approvals as privileged events Require security review or step-up approval for new connected apps, scope expansions, and token resets.
• Replace reusable trust with phishing-resistant verification Use FIDO2 passkeys or equivalent phishing-resistant controls for administrators and operators who can approve integrations, reset tokens, or grant delegated access.

What's in the full article

HYPR's full blog covers the operational detail this post intentionally leaves for the source:

• The consent attack paths that let attackers turn a trusted connected app into a persistent access channel.
• The specific FIDO passkey and identity-proofing controls the vendor proposes for reducing approval abuse.
• The RevOps-oriented hardening steps for trimming app permissions, expiring scopes, and reducing token reuse.
• The vendor's implementation framing for deterministic identity assurance across high-risk approvals.

👉 Read HYPR's analysis of the Salesforce breach and connected app identity risk →

OAuth consent and token reuse: what IAM teams need to fix?

Explore further

View Full Forum →  |  NHI Foundation Course →