---
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:
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 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

- [ ] `eventType` used as primary filter (not `displayMessage` which is human-readable and unstable).
- [ ] `outcome.result` checked for SUCCESS/FAILURE as appropriate.
- [ ] `target[]` searched by `type`, not array index (target order is not guaranteed).
- [ ] `securityContext.isProxy` considered for anonymising proxy detection.
- [ ] `authenticationContext.externalSessionId` used for session correlation.
- [ ] `debugContext.debugData` fields treated as unstable (may change between releases).
- [ ] SIEM field mappings validated against connector documentation (field names vary by SIEM and connector version).
- [ ] Admin account detections scoped to Super Administrator / Org Administrator roles.
- [ ] Inbound federation events (`system.idp.lifecycle.*`) monitored — especially if feature is not in use.
- [ ] API token creation (`system.api_token.create`) and usage (`transaction.detail.requestApiTokenId`) monitored.
- [ ] ThreatInsight signals (`security.threat.detected`) ingested and correlated.
- [ ] Okta Workflows creation and modification monitored for data exfiltration risk.
- [ ] OAuth app integration creation and scope grants monitored.
- [ ] MFA factor reset for admin accounts always generates high-severity alerts.
- [ ] Session hijacking detection: IP/ASN change mid-session on `externalSessionId`.
- [ ] Delegated authentication limitations documented (Okta cannot detect password spray against AD-delegated auth).