Identity providers

Cerbos authorization for Keycloak

Keycloak provides authentication, SSO, and identity federation with realm roles, client roles, and group hierarchies. Cerbos uses Keycloak's rich identity model to make fine-grained authorization decisions that go beyond what Keycloak's built-in authorization services can express.

Realm and client roles

Map Keycloak realm roles and client-specific roles directly to Cerbos principal attributes for policy evaluation

Group hierarchy in policies

Use Keycloak's nested group structure in Cerbos policies to model organizational access patterns like /department/team

Application-layer authorization

Evaluate authorization where your application has full resource context, not at the identity provider layer

How Cerbos works with Keycloak

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

Users authenticate via Keycloak, Keycloak handles SSO, identity federation, social login, and MFA. The access token contains realm roles, client roles, and group memberships.
Extract identity from the Keycloak token, Your application verifies the Keycloak-issued JWT and extracts realm roles, client roles, group paths, and any custom user attributes from the token claims.
Send identity and resource context to Cerbos, Pass the Keycloak user ID, realm roles, client roles, group memberships, and user 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 Keycloak identity data and resource context, returning allow or deny. Your application enforces the result.

FAQ

How does Cerbos use Keycloak roles and groups?

Keycloak includes realm roles, client roles, and group memberships in the access token. Cerbos receives these as principal attributes, so your policies can reference specific roles, combine role checks with resource attributes, or enforce rules based on group hierarchy, such as "members of /engineering/backend can deploy services."

Does Cerbos replace Keycloak's built-in authorization services?

Keycloak's authorization services (resources, scopes, policies) are tightly coupled to Keycloak and evaluated at the identity provider. Cerbos evaluates authorization at the application layer, where it has access to the full resource context. This means your policies can reference both the Keycloak identity and the specific data being accessed, enabling fine-grained decisions Keycloak cannot express on its own.

Can I use Keycloak's group hierarchy in Cerbos policies?

Yes. Keycloak supports nested groups like /department/team/sub-team. Pass the user's group paths to Cerbos and write policies that match on group prefixes or specific paths. This lets you model organizational hierarchies in your authorization rules without flattening them.