Salesforce made Drift OAuth token governance a SaaS-integration accountability test because a trusted connected application can carry a valid hosted identity long after the business reason, owner or expected use has changed. The security question is not whether OAuth exists. It is whether each delegated identity remains unique, attributable, bounded and revocable in the running environment.

A token is a hosted network identity

A connected application uses an OAuth token to act across a service boundary. The operator record should bind that authority to an application, tenant, issuer, scopes, owner, approval reason, creation time, last use, rotation state and revocation path. Without that record, a valid token can look normal while representing an abandoned or compromised integration.

A FINRA cybersecurity alert described attackers using stolen Salesloft Drift OAuth tokens to impersonate a trusted application and reach connected customer environments. The alert distinguished the integration path from a direct weakness in Salesforce or Google Workspace and recommended disconnecting affected integrations, rotating credentials and reviewing activity.

That boundary matters. The hosted platform can operate as designed while delegated authority is abused. A status page or successful login therefore cannot establish the accepted state. Operators need evidence about the identity that made the request, its allowed scope, the objects accessed and whether the authorization still had a valid owner.

Revocation must be a recorded state transition

Salesforce's public incident record is part of the customer evidence trail. A platform response becomes actionable when customers can tie it to their own connected-app inventory, revoke or restrict the affected identity, rotate exposed credentials and verify that the old authority no longer works.

Revocation is not complete when an administrator clicks a control. The operator should confirm that access and refresh tokens are invalid, related secrets and API keys are rotated where required, unexpected sessions or jobs are investigated, integration logs are retained and the replacement connection has only the intended permissions.

The record should also preserve timing: when the integration was disabled, which dependent workflow stopped, who accepted the interruption, when the replacement identity became active and what evidence showed that normal operation resumed. That sequence makes containment reversible and avoids restoring an old route simply because a business process is blocked.

The integration inventory must match running access

An FBI IC3 advisory placed the incident in a broader threat context and supplied actions for organizations reviewing exposure. The local reality layer remains the tenant's own evidence: connected applications, granted scopes, token use, source addresses, queried objects, administrator actions and retained audit events.

A quarterly spreadsheet of approved integrations is insufficient if the running tenant contains different apps, scopes or owners. The accepted inventory should be compared with current platform state. Orphaned connections should be removed, broad scopes should have documented need, and every retained integration should have an owner capable of responding when the vendor or credential changes.

Continuity includes the ability to replace authority

A SaaS integration may support sales, support or reporting workflows that cannot stop indefinitely. That makes least privilege and recovery part of the same design. The organization needs a tested way to disable one identity, preserve evidence, create a bounded replacement and verify downstream behavior without silently restoring excessive authority.

The useful measure is not the number of connected applications. It is whether the organization can identify the authority behind a request, close that route, restore the required workflow and explain the resulting state. That is operational continuity across a hosted identity boundary.

Verdict

The Drift incident shows why OAuth governance belongs in the reality layer of hosted network identity. Salesforce, integration vendors and customers hold different control points, but the accepted state requires a unique application identity, accurate scope and owner records, observable use and a verified revocation path. This is not advocacy copy about one platform; it is evidence about delegated authority in the running system.

Sources

  1. Salesforce: Public Incident Record
  2. FINRA: Salesloft Drift AI Supply Chain Attack
  3. FBI IC3: Cybersecurity Advisory