okta-identity

Okta Identity — detection authoring

Okta is a major non-Microsoft identity platform with its own telemetry schema, attack surface, and detection patterns. This skill covers the platform internals needed to write detections against Okta System Log events, regardless of which SIEM ingests them.

Not to be confused with entra-id (Microsoft Entra ID) or identity-providers (cross-vendor identity mechanics).

---

1. System Log event schema

Every Okta event follows a consistent JSON structure:

Field	Type	Detection use
eventType	string	Primary event classifier. Hierarchical dot-notation (e.g. user.session.start).
actor	object	Who performed the action. Contains id, type, alternateId (email), displayName.
target[]	array	What was acted upon. Array of objects with id, type, alternateId, displayName. Search by type, not array position — target order is not guaranteed.
outcome	object	result (SUCCESS, FAILURE, SKIPPED, UNKNOWN) + reason string.
client	object	Client context: userAgent, zone, device, ipAddress, geographicalContext.
authenticationContext	object	authenticationProvider, credentialType, externalSessionId, interface.
securityContext	object	isProxy (boolean), asNumber, asOrg, isp, domain. IP reputation context.
debugContext.debugData	object	Unstable but valuable: requestUri, dtHash, threatSuspected, logOnlySecurityData, behaviors.
transaction	object	id (correlation key), type (WEB or JOB), detail.requestApiTokenId (API token used).
published	ISO 8601	Event timestamp.
severity	enum	DEBUG, INFO, WARN, ERROR.
uuid	string	Unique event identifier.

Key eventType taxonomy

Category	eventType pattern	Examples
Authentication	user.session.*	user.session.start, user.session.end
MFA	user.authentication.auth_via_mfa	MFA challenge result
MFA factor lifecycle	system.mfa.factor.*	system.mfa.factor.activate, system.mfa.factor.deactivate, user.mfa.factor.reset_all
User lifecycle	user.lifecycle.*	user.lifecycle.create, user.lifecycle.activate, user.lifecycle.suspend, user.lifecycle.deactivate
Password	user.credential.*	user.credential.password.update, user.credential.forgot_password
App access	user.authentication.sso	SSO into an application
Admin actions	user.account.*	user.account.privilege.grant, user.account.update_profile
Policy changes	policy.lifecycle.*	policy.lifecycle.create, policy.lifecycle.update, policy.lifecycle.delete
IdP lifecycle	system.idp.lifecycle.*	system.idp.lifecycle.create, system.idp.lifecycle.update
API token	system.api_token.*	system.api_token.create, system.api_token.revoke
Group membership	group.user_membership.*	group.user_membership.add, group.user_membership.remove
Suspicious activity	user.account.report_suspicious_activity_by_enduser	End-user reported suspicious activity
Rate limiting	system.org.rate_limit.*	Rate limit warnings and violations

---

2. Authentication flows

Standard sign-in flow

User → Okta sign-in page → Primary auth (password/IWA/delegated)
  → MFA challenge (push/TOTP/FIDO2/FastPass)
  → Session token issued → SSO to applications

Delegated authentication

When Okta delegates to Active Directory, the authenticationContext.authenticationProvider is ACTIVE_DIRECTORY and credentialType is IWA or LDAP_INTERFACE. The password is validated by AD, not Okta — Okta cannot detect password spray against delegated auth directly.

FastPass (Okta Verify device-bound)

FastPass is Okta's phishing-resistant authenticator. Key detection signal: user.authentication.auth_via_mfa with outcome.reason eq "FastPass declined phishing attempt" — this fires when FastPass detects an AiTM proxy.

Device code flow

eventType eq "user.authentication.auth_via_mfa" with authenticationContext.credentialType eq "DEVICE_CODE". Monitor for abuse — device code phishing is a growing attack vector.

---

3. Attack patterns

3.1 Cross-tenant impersonation (Scattered Spider pattern)

The most significant Okta-specific attack pattern. Flow:

1. Social engineer IT help desk to reset MFA for a Super Administrator
2. Enrol attacker-controlled MFA factors
3. Create a second Identity Provider (inbound federation)
4. Manipulate username parameter in source IdP to impersonate target users
5. SSO into applications as any user

Detection signals:

Stage	System Log query	Notes
MFA factor reset	eventType eq "user.mfa.factor.reset_all"	Alert on any all-factor reset for admin accounts
New IdP created	eventType eq "system.idp.lifecycle.create"	Critical — should be extremely rare
IdP modified	eventType sw "system.idp.lifecycle"	Broader — catches create + update + delete
Auth via external IdP	eventType eq "user.authentication.auth_via_IDP"	Alert if org doesn't use inbound federation
Admin privilege grant	eventType eq "user.account.privilege.grant"	Privilege escalation

3.2 Session token theft (HAR file exfiltration)

Okta session tokens stolen from HAR files (browser network recordings shared with support). The externalSessionId in authenticationContext is the session correlation key.

Detection: Alert on session reuse from a different IP/ASN than the original authentication:

• Correlate externalSessionId across events
• Flag when client.ipAddress or securityContext.asNumber changes mid-session

3.3 MFA fatigue / push bombing

Repeated MFA push notifications to exhaust the user into approving.

Detection: eventType eq "user.authentication.auth_via_mfa" with outcome.result eq "FAILURE" — count failures per user per time window. Threshold: >5 failures in 10 minutes.

3.4 Admin API token abuse

API tokens provide persistent access without MFA. Stolen tokens enable silent admin operations.

Detection signals:

• eventType eq "system.api_token.create" — new token creation
• transaction.detail.requestApiTokenId present in events — identifies API-driven actions
• Correlate API token usage with client.ipAddress — flag novel IPs

3.5 Policy weakening

Attacker modifies authentication policies to remove MFA requirements or weaken session controls.

Detection: eventType sw "policy.lifecycle" — alert on any policy modification, especially:

• policy.rule.update where MFA requirements are removed
• policy.lifecycle.delete for authentication policies

---

4. ThreatInsight and behavioural signals

Okta ThreatInsight provides pre-built threat detection signals available in the System Log.

Signal	eventType / field	Detection use
Credential stuffing	security.threat.detected with debugContext.debugData.threatSuspected	Automated credential attacks against the org
Password spray	security.threat.detected	Distributed password guessing
Suspicious IP	securityContext.isProxy = true	Traffic from anonymising proxies, VPNs, Tor
Brute force lockout	user.account.lock	Account locked due to repeated failures
Anomalous location	debugContext.debugData.behaviors containing New Geo-Location	Sign-in from unusual geography
Anomalous device	debugContext.debugData.behaviors containing New Device	Sign-in from unrecognised device
Suspicious activity report	user.account.report_suspicious_activity_by_enduser	End-user self-reported compromise

debugContext.debugData.behaviors is a JSON string containing Okta's behavioural analysis. Parse it to extract individual signals. Note: debugContext fields are unstable and may change between releases.

---

5. Okta Workflows and automation abuse

Attack vector	eventType	Detection signal
Workflow creation	system.workflow.create	New automation — check for data exfiltration flows
Workflow modification	system.workflow.update	Changed automation — may add malicious steps
Workflow with external connector	system.workflow.create / update	Connector to external service (Slack, email, HTTP) — data exfiltration channel
Workflow execution	system.workflow.execute	Automated action triggered — correlate with workflow definition

Risk: Okta Workflows can automate user provisioning, group membership changes, and external API calls. An attacker with admin access can create workflows that silently exfiltrate data or maintain persistence.

---

6. OAuth app and integration abuse

Attack vector	eventType	Detection signal
App integration created	app.lifecycle.create	New app integration — potential OAuth consent phishing
App assigned to user/group	app.user_membership.add / group.application.assignment.add	App access granted — check if app is legitimate
OAuth scope grant	app.oauth2.consent.grant	OAuth consent granted — check scope breadth
App credentials rotated	app.credential.update	App secret changed — potential credential theft
SAML certificate change	app.credential.update (SAML app)	Signing certificate changed — potential Golden SAML setup

Risk: Attackers can create rogue app integrations to harvest OAuth tokens, or modify existing SAML app certificates to forge assertions.

---

7. SIEM ingestion patterns

Column/field names vary by SIEM and connector version. Consult your SIEM's Okta integration documentation for exact field mappings.

Okta native field	Telemetry type	Ingestion method	Notes
System Log events	Identity audit lo

---

Content truncated.