| name | okta-identity |
| description | Okta identity platform detection guidance — System Log event schema (eventType taxonomy, actor/target/outcome structure), session token mechanics, authentication flows (FastPass, FIDO2, delegated auth), admin API abuse patterns, ThreatInsight signals, Okta-to-Entra federation trust chains, and Okta-specific attack patterns (cross-tenant impersonation, HAR file session theft, MFA factor reset abuse, inbound federation hijacking). Use for identity-focused detections targeting Okta telemetry ingested into SIEMs. |
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:
- Social engineer IT help desk to reset MFA for a Super Administrator
- Enrol attacker-controlled MFA factors
- Create a second Identity Provider (inbound federation)
- Manipulate username parameter in source IdP to impersonate target users
- 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 creationtransaction.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 removedpolicy.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 log | SIEM connector (API polling or Event Hook) | Primary detection source |
eventType | Event classifier | Mapped to SIEM-specific field | Use as primary filter |
actor.alternateId | User identity | Mapped to SIEM user field | Email address |
outcome.result | Action result | Mapped to SIEM result field | SUCCESS / FAILURE |
client.ipAddress | Source IP | Mapped to SIEM source IP field | Client IP |
published | Event timestamp | Mapped to SIEM timestamp field | ISO 8601 |
securityContext | IP reputation | Mapped to SIEM enrichment fields | Proxy, ASN, ISP |
Ingestion methods
| Method | Latency | Notes |
|---|
| API polling (System Log API) | Minutes | Most common; SIEM polls /api/v1/logs on interval |
| Event Hooks (webhook push) | Near-real-time | Okta pushes events to SIEM endpoint; requires SIEM webhook receiver |
| Log streaming (AWS EventBridge) | Near-real-time | Native integration for AWS-based SIEMs |
8. Cross-platform entity correlation
When correlating Okta events with other identity or endpoint platforms, align on these entity categories:
| Entity type | Okta field | Correlation key |
|---|
| User | actor.alternateId (email) | Email / UPN — matches across most IdPs when email is consistent |
| User ID | actor.id (Okta UUID) | Platform-specific — requires mapping table for cross-platform joins |
| Session | authenticationContext.externalSessionId | Okta-specific — correlate within Okta events only |
| IP address | client.ipAddress | Universal — correlate across all platforms |
| Application | target[].alternateId (app label) | App name — may differ across platforms; use app ID where available |
| Device | client.device / debugContext.debugData.dtHash | Device hash — Okta-specific; correlate with endpoint platforms via device ID mapping |
Cross-platform correlation works best on actor.alternateId (email) ↔ UPN when the email address is consistent across identity platforms. For user ID correlation, maintain a mapping table between Okta UUIDs and other platform identifiers.
9. Quality checklist
