Notifications
Clear all
Topic starter
25/06/2026 3:09 pm
TL;DR: The Salesforce-Drift attack exposed sensitive data from more than 700 organisations by abusing compromised OAuth tokens, showing how static secrets and weak governance can turn trusted SaaS integrations into entry points, according to Akeyless. Standing tokens, not MFA bypass alone, remain the decisive trust failure in interconnected identity environments.
NHIMG editorial — based on content published by Akeyless covering the Salesforce-Drift OAuth attack: OAuth token security and SaaS trust-chain risk
By the numbers:
- The August 2025 Salesforce-Drift OAuth attack exposed sensitive data from over 700 organizations.
Questions worth separating out
Q: What breaks when OAuth tokens are managed like static app settings?
A: Static token handling turns delegated access into standing privilege.
Q: Why do OAuth tokens create more risk than a normal password reset process?
A: Password resets affect a human login path, but OAuth tokens often remain valid for APIs and third-party integrations after the user has changed a password.
Q: How do security teams know whether token rotation is actually working?
A: Look for short credential lifetimes, automatic revocation of old tokens, and no successful reuse after rotation.
Practitioner guidance
- Classify OAuth tokens as governed identities Assign each token an owner, business purpose, scope, and expiry date, then review it alongside other non-human identities instead of leaving it in app-specific settings.
- Shorten token lifetime through policy-based rotation Replace static bearer tokens with centrally managed rotation schedules that revoke old credentials automatically before they can be reused across connected SaaS tools.
- Instrument token-level anomaly detection Forward secret access logs into SIEM workflows and alert on bulk API queries, unusual source IPs, and abnormal integration traffic patterns.
What's in the full article
Akeyless's full blog post covers the operational detail this analysis intentionally leaves for the source:
- Step-by-step examples of how the platform stores OAuth tokens, API keys, passwords, and certificates in a unified vault
- Policy details for automated secret rotation across SaaS, CI/CD, and hybrid environments
- Configuration guidance for just-in-time access and zero standing privileges in connected application workflows
- Audit and SIEM integration examples for secret access monitoring and alerting
👉 Read Akeyless's analysis of the Salesforce-Drift OAuth attack and token risk →
Salesforce-Drift OAuth tokens: what SaaS teams need to fix?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 4:30 pm
OAuth tokens are non-human identities with delegated authority, not harmless integration artefacts. Once a token is issued, it can operate independently of the original login event and continue acting until revoked or expired. That makes lifecycle governance, scope review, and ownership assignment part of identity control, not separate hygiene. Practitioners should govern tokens as machine identities with explicit accountability.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
A question worth separating out:
Q: Who is accountable when a third-party integration token is abused?
A: Accountability should sit with the business owner of the integration, the IAM or NHI team that governs the credential lifecycle, and the application owner who approved the connection. Shared responsibility does not mean shared inaction. A token with delegated access needs a named owner at every stage of its lifecycle.
👉 Read our full editorial: Salesforce-Drift OAuth token abuse exposes SaaS trust gaps
