On October 20, 2023, Okta disclosed that an attacker had gained access to its customer support case management system using stolen credentials. The attacker was able to view files uploaded by certain Okta customers as part of support cases—including HTTP Archive (HAR) files that contained active session tokens. Those tokens were then used to hijack customer sessions.
This was Okta's second major security incident in less than two years, following the January 2022 Lapsus$ breach. For a company whose entire business is identity and access management, the pattern was troubling.
What Happened
The timeline, as disclosed by Okta and corroborated by affected customers:
September 28, 2023: BeyondTrust, an Okta customer, detects suspicious activity—an attacker attempting to use a valid Okta session token to create an admin account in their Okta tenant. BeyondTrust's security team blocks the attempt and notifies Okta.
October 2, 2023: Cloudflare, another Okta customer, detects similar suspicious activity. An attacker uses a session token stolen from an Okta support HAR file to access Cloudflare's Okta instance. Cloudflare's security team detects and blocks the intrusion within minutes.
October 11-17, 2023: 1Password discloses that it too was targeted. An attacker used a stolen HAR file session token to access 1Password's Okta tenant on September 29, two days before Okta acknowledged BeyondTrust's initial report. 1Password's security team detected the unauthorized access through their own monitoring.
October 19, 2023: Okta identifies the root cause—a compromised service account for the customer support system.
October 20, 2023: Okta publicly discloses the breach, initially stating that approximately 1% of its customers (around 134 organizations) were affected.
November 29, 2023: Okta revises the scope dramatically upward, admitting that the attacker downloaded a report containing names and email addresses of all Okta customer support system users—not just the initially reported 134.
The HAR File Problem
HTTP Archive (HAR) files are commonly requested by support teams to diagnose authentication issues. They contain a complete record of HTTP requests and responses between a browser and a server, including:
- Full URLs with query parameters
- Request and response headers (including cookies and authentication tokens)
- Request and response bodies
- Timing information
When Okta support asks a customer to upload a HAR file, that file often contains valid session tokens for the customer's Okta tenant. If those tokens haven't expired, anyone with access to the HAR file can impersonate the user who generated it.
This is a known risk. Okta's own documentation warns customers to sanitize HAR files before uploading them. But in practice, most people don't—they're troubleshooting an urgent issue and follow support's instructions without thinking about the security implications.
The Customers Who Caught It
The most notable aspect of this incident is that Okta's customers detected the breach before Okta did.
BeyondTrust detected the attack on September 28 and immediately notified Okta. According to BeyondTrust, Okta took over two weeks to confirm the breach, during which time other customers were compromised.
Cloudflare published a detailed blog post describing how their security team detected the unauthorized access through their own logging and monitoring, and contained it within minutes. Cloudflare was blunt in its criticism of Okta's response time.
1Password similarly detected the intrusion through internal monitoring before being notified by Okta.
The fact that three sophisticated security-focused companies independently caught the same attack, while Okta's own security team took weeks to investigate, raised serious questions about Okta's detection capabilities.
Broader Impact
Okta sits at the center of identity infrastructure for thousands of organizations. As an identity provider, Okta has access to authentication flows for every application its customers protect with single sign-on. A compromise of Okta isn't just a breach of Okta—it's potentially a breach of every application behind Okta SSO.
The October 2023 incident, while more limited in scope than a full Okta platform compromise, still demonstrated the cascading risk. An attacker with a valid Okta session token can:
- Access any application the user has SSO access to
- Modify authentication policies
- Create new admin accounts
- Disable multi-factor authentication
- Reset passwords for other users
The support system compromise was a lower-impact vector than a direct platform compromise, but it still provided session tokens that gave attackers initial access to customer tenants.
Lessons Learned
Never upload unsanitized HAR files. Strip all cookies, authentication headers, and tokens before sharing HAR files with any vendor. Better yet, build internal tooling that automatically sanitizes HAR files.
Monitor your identity provider independently. Don't rely on your identity provider to tell you when they're compromised. Implement your own logging and alerting for suspicious activities in your Okta tenant (or any identity provider).
Detect anomalous session behavior. Session tokens appearing from unexpected IP addresses, geolocations, or user agents should trigger immediate investigation. All three companies that caught the breach had this capability.
Evaluate identity provider risk as a critical supply chain dependency. Your identity provider is arguably the most critical SaaS vendor in your stack. Treat it accordingly in your risk assessments.
Assume breach and plan accordingly. Have a runbook for identity provider compromise, including session invalidation, credential rotation, and audit log analysis.
How Safeguard.sh Helps
Safeguard.sh treats identity providers as critical supply chain components and monitors them accordingly. Our platform tracks security incidents at major SaaS vendors, alerts you when your identity infrastructure is affected, and provides guidance for incident response. By integrating with your authentication logs, Safeguard.sh can detect anomalous access patterns that may indicate session token theft—helping you catch identity-based attacks even when your vendors can't.