Connect Okta to CYBRET.
CYBRET reads your Okta tenant and treats identity as a first-class node in the attack graph. Group rules, app assignments, MFA policy, and the System Log become part of the same reachability model that covers your cloud and code.
The identity graph, including the rules that change it.
Okta is the source of truth for who is who in many of our customers. Reading it gives CYBRET the human side of the graph: which users sit in which groups, which groups grant which apps, which apps require which factors, and which sign-on policies are evaluated when. We read the rules, not just the static membership.
- Users and groups: profiles, group memberships including dynamic group rules expressed as Okta Expression Language, lifecycle status.
- Applications: all assigned applications, their assignment mode (group, individual, rule-based), SAML / OIDC settings, profile mappings, and inbound provisioning hooks.
- Policies: sign-on, password, MFA, authenticator enrollment, and the policy precedence order.
- Authenticators and factors: per-user factor enrollment, authenticator policies, FastPass status.
- Identity providers: inbound IdPs (social, SAML, OIDC), routing rules, JIT provisioning configuration.
- Admin surface: super admin and delegated admin role assignments, API tokens with their owners and last-used timestamps.
- Telemetry: System Log via Event Hooks for runtime correlation; admin access log for change attribution.
What we find in the first week.
Okta findings sit between IGA and AppSec. Most identity-governance tools cover the static state; CYBRET joins the rules that change it and the apps it grants reach to.
1. Long-lived admin API token in CI
Super admin API token created two years ago, no expiry → used in a CI variable named OKTA_TOKEN → fork pipeline can read it → full Okta admin if leaked.
The token has no expiry and no source-IP restriction. It's used in a single GitHub Actions workflow that runs on PRs. CYBRET joins the Okta token inventory (with its admin role) to the workflow file (where the token is referenced) and surfaces the path. The fix is rotation, source-IP zone, and a workflow scope change.
2. Group rule auto-assigns Everyone to a SaaS admin app
Dynamic group rule with user.email != null → populates a group called app-admins → group is assigned to a SaaS admin tenant.
The rule was meant to test population during a SaaS rollout and shipped to prod. Every active user in the tenant is now an admin on the SaaS application. CYBRET reads the rule expression in OEL, evaluates the matching set against the live user directory, and reports the effective membership. The fix is a corrected rule and a one-time deprovisioning sweep.
3. Partner IdP with weak sign-on bypasses MFA
Inbound SAML IdP added by partner team → routing rule matches by email domain → the IdP's sign-on policy doesn't require MFA → users from that domain skip the org MFA policy.
The downstream apps trust Okta; Okta trusts the partner IdP; the partner IdP doesn't enforce MFA. CYBRET reads the routing rule and the policy attached to the IdP, then resolves which apps the affected users can reach. The fix is either pulling MFA enforcement into Okta (factor-strength policy) or removing the routing rule.
Read-only API token plus an Event Hook.
Okta's API model uses scoped API tokens. CYBRET uses two: a read-only admin token for inventory, and an Event Hook for streaming System Log events. We can also run with OAuth 2.0 service-app credentials where the tenant is on the API service app model.
- Open the CYBRET console and go to Integrations → Okta.
- Click Connect Okta. Enter your tenant URL.
- In Okta, create an API service app with the read-only scopes shown in the console (
okta.users.read,okta.groups.read,okta.apps.read,okta.policies.read,okta.idps.read,okta.logs.read). - Paste the client credentials back into CYBRET. Or, for older tenants, paste a read-only API token.
- Configure the Event Hook for System Log streaming. CYBRET provides the endpoint URL and verification token.
- The first inventory pass completes inside ten minutes. Identity nodes appear in Exposure Intelligence and join the cloud / app graph as those integrations build.
Disconnect by deactivating the service app or revoking the token. CYBRET stops ingesting at the next poll.
Read-only. Source-IP scoped where supported.
The integration uses read-only Okta scopes; nothing in the default configuration permits a user, group, app, or policy mutation. We recommend, and most customers enforce, an Okta network zone that restricts the API service app to the CYBRET tenant's egress IPs. There is no agent installed anywhere on Okta's side.
For runtime detection, the System Log Event Hook delivers events to the customer-tenancy CYBRET deployment over TLS with a per-tenant verification token. Customers who use Okta Workflows can additionally send a curated subset of admin actions via Workflow flows; this is an alternative path for tenants that disable Event Hooks for policy reasons.
Where Okta data shows up in the platform.
Exposure Intelligence uses Okta as the human-identity layer of the attack graph. A reachable path that ends in "a finance contractor can read prod customer data" is meaningful only if CYBRET knows which contractor and what their effective Okta-derived access is. Okta connect closes that side of the graph.
Validation uses Okta context to build proof-of-exploit at the right identity. When CYBRET claims a BOLA path lets one user read another's order, Validation issues the paired requests using two Okta-modelled identities at the right assignment levels.
Runtime Detection consumes the System Log to alert on identity events tied to surfaced paths. A sudden enrollment of a new factor by a privileged user, or a group rule change that expands membership of an admin group, becomes a runtime event linked back to the affected paths.
Questions security engineers actually ask.
How does authentication work?
OAuth 2.0 service-app credentials with Okta scoped scopes, kept in a per-tenant CYBRET vault. We support legacy SSWS API tokens for older tenants. Network zones restricting the service app to CYBRET egress IPs are recommended.
Where does the Okta data live?
Inside the CYBRET deployment in your VPC. EU customers run an EU-resident control plane; US customers run a US one. We do not move Okta data to a multi-tenant SaaS backend.
Is the integration agentless?
Yes. The Okta integration uses Okta Identity APIs and the Event Hook subscription. Nothing is installed on Okta or on your endpoints.
How do you handle Okta API rate limits?
CYBRET respects Okta’s per-endpoint rate-limit headers and uses the bulk endpoints (users, groups, apps) where available. Tenants with hundreds of thousands of users complete first build inside a few hours; group-rule evaluation is the long pole.
Multi-tenant Okta and Okta Workforce + Customer Identity?
Multiple Okta orgs can be connected to a single CYBRET tenant. Workforce and Customer Identity (Auth0) deployments are separate connectors; the Workforce connector is described here, the Customer Identity one lives on the Auth0 page.
On-prem or air-gapped?
Okta is SaaS, but customers running a self-managed CYBRET in an air-gapped environment can still connect Okta over an outbound proxy from the CYBRET tenant. The same scopes apply.
Connect Okta →
Identity becomes a first-class node in your attack graph. The first "who can actually reach this?" questions get answered inside the first day.
Connect OktaSee Exposure Intelligence