Okta's 2023 support-system breach: when your IdP gets phished

What happened

In October 2023 Okta disclosed that an attacker accessed its customer support case management system using a stolen credential. Support cases often include HAR (HTTP Archive) files that customers upload to reproduce issues, and those files contained live session tokens. The attacker used them to pivot into a handful of Okta customers. Several customers, including 1Password, BeyondTrust, and Cloudflare, detected the suspicious activity and reported it, and Cloudflare's own controls contained it.

Root cause

Two failures combined. First, a service account credential was reportedly saved to a personal Google profile on a managed device, giving the attacker a way in. Second, the support system stored HAR files that still contained valid session tokens, so a read of support data became a set of usable credentials.

The identity lesson

Your identity provider, and the tooling around it, is the highest-value target you own. A breach of support infrastructure became an identity breach because session tokens were sitting in uploaded files. Tokens are bearer credentials: whoever holds one is the user until it expires.

How to defend

• Sanitize HAR files and any support uploads to strip cookies and tokens before storage.
• Bind sessions to a device or client where possible (token binding, DPoP) so a stolen token is useless elsewhere, and keep session lifetimes short.
• Treat admin and support tooling as tier-zero: phishing-resistant MFA, no shared or personal-profile credentials, and tight monitoring.
• Adopt continuous session evaluation so anomalous token use triggers revocation. This is core ITDR territory.

The lesson generalizes beyond identity vendors

The mechanism here was not exotic: support tooling held artifacts that contained live credentials, and reading support data became holding credentials. Any system that collects diagnostics has this property. HAR files, browser exports, memory dumps, log bundles, and crash reports routinely contain cookies, tokens, and authorization headers, and they are stored in systems that are not treated as tier zero because they are "just support".

The August 2026 GitGuardian research on leaked n8n API tokens is the same shape one layer out: 4,576 live tokens found in public commits, with roughly a third of reachable instances still accepting them. Credentials leak through the systems nobody classifies as credential stores.

Concentration risk is the structural point

Consolidating authentication in one provider is the right architecture and it makes that provider the highest-value target in your estate. That is not an argument against SSO, it is an argument for planning around it:

• Have a tested answer to "the identity provider is compromised". Which sessions do you revoke, in what order, and who can execute it if the identity provider itself is the thing you cannot trust?
• Have a tested answer to "the identity provider is down". Break-glass access that does not depend on the failed component, exercised on a schedule.
• Monitor the identity control plane itself, not just the applications behind it. Admin role assignments, new federation trusts, and API token creation are the events that matter. See what is ITDR.
• Detect from the customer side. Several Okta customers found this before Okta did, because they were watching their own tenants for anomalous administrative activity. Do not outsource detection of your own identity provider entirely to its vendor.

Related

News: Okta support-system breach. Vendors: ITDR, MFA. Glossary: session hijacking, account takeover.