Identity providers

Cerbos authorization for Okta

Okta manages authentication, SSO, and user directories. Cerbos takes Okta's group memberships, app assignments, and profile attributes and uses them to drive fine-grained authorization policies, keeping access control logic separate from your identity layer.

Groups and directories

Map Okta group memberships and Universal Directory attributes directly to Cerbos principal attributes for policy evaluation

Profile-driven policies

Write authorization rules that reference Okta profile fields like department, job title, and custom attributes

Resource-level decisions

Go beyond Okta's scope-based API access to resource-level authorization that combines identity with business context

How Cerbos works with Okta

Okta handles authentication, confirming who a user is. Cerbos handles authorization, deciding what that user can do. Together they give you a complete access control stack without coupling identity logic to business rules.

Cerbos lets you write fine-grained, context-aware authorization policies in human-readable YAML. Policies are decoupled from application code so product and security teams can update permissions without a release cycle.

Because Cerbos runs as a stateless Policy Decision Point (PDP) next to your application, authorization checks are sub-millisecond and scale horizontally with your infrastructure.

Policy-as-codeHuman-readable YAML policies managed like source code Scalable PDPStateless policy decision point with sub-millisecond latency Centralized managementManage, test, and deploy policies from a single control plane

How Cerbos works with Okta

Users authenticate via Okta, Okta handles SSO, MFA, and federation. The user's token contains group memberships, roles, and profile claims from the Universal Directory.
Extract identity from the Okta token, Your application verifies the Okta-issued JWT and extracts the user's groups, app assignments, and any custom profile attributes.
Send identity and resource context to Cerbos, Pass the Okta user ID, groups, and profile attributes as principal attributes alongside the target resource and action to the Cerbos PDP.
Cerbos evaluates policies and returns a decision, Cerbos evaluates your YAML policies against the Okta identity data and resource context, returning allow or deny. Your application enforces the result.

FAQ

How does Cerbos use Okta group memberships?

Okta groups are included in the user's token or retrieved via the Okta API. Cerbos receives these groups as principal attributes, so your policies can reference specific groups, combine group membership with resource attributes, or enforce rules like "only members of the Engineering group can deploy to production."

Can I use Okta custom profile attributes in Cerbos policies?

Yes. Okta's Universal Directory supports custom profile attributes like department, cost center, or manager. Include these in the token via custom claims or retrieve them server-side, then pass them to Cerbos as principal attributes for use in your policies.

How does this differ from Okta's built-in authorization features?

Okta provides basic scope and group-based access at the API gateway level. Cerbos adds resource-level authorization, your policies can reference both the user's Okta attributes and the specific resource being accessed, along with any runtime context. This enables decisions like "editors can only publish articles in their own department."