Enforcer

Keycloak alternatives

Keycloak is an open source identity and access management server you run yourself. The Cloud Native Computing Foundation's project page records that Keycloak was accepted to CNCF on April 10, 2023 at the Incubating maturity level. Alongside sign-in it ships Authorization Services, a policy decision point that models resources, scopes and permissions, with nine built-in policy types: user, role, JavaScript, time, aggregated, client, group, client scope and regex. Applications obtain permissions through the UMA ticket grant at the token endpoint, which returns a requesting party token by default. The optional response_mode parameter changes that: decision returns only the overall decision, { "result": true }, and permissions returns the list of permissions granted. Most teams who go looking elsewhere are not unhappy with sign-in. They are unhappy with what the authorisation layer costs to operate and how little it tells them when a request is refused. Below: the reasons to leave, the reasons to stay, six alternatives, and where our own product, Enforcer, loses to Keycloak.

Why teams look past Keycloak's authorisation layer

• A refused request does not say which rule refused it. The authorization services guide documents one shape for a refusal: By default, Keycloak responds with a 403 HTTP status code and a request_denied error in case the client can not be issued with an RPT. The body printed beside it is { "error": "access_denied", "error_description": "request_denied" }. Asking for a bare decision does not change this; of response_mode the same guide says If the authorization request does not map to any permission, a 403 HTTP status code is returned instead. So the policy enforcement point learns that access was refused and not which policy refused it. Keycloak does expose per policy detail, but at design time rather than in the response: You can access the Policy Evaluation Tool by clicking the Evaluate tab when editing a resource server. That helps while you are writing a policy. It does not help a running application explain a denial to a user.
• Changing custom policy logic means a server build. This is about logic the built-in policy types cannot express. Two routes exist and they are not equivalent. JavaScript policies are a preview feature: the server development guide states Scripts is Preview and is not fully supported. This feature is disabled by default. To enable start the server with --features=preview or --features=scripts, and the authorization services guide adds By default, JavaScript Policies can not be uploaded to the server. Java is not preview: Keycloak provides an SPI (Service Provider Interface) that you can use to plug in your own policy provider implementations. What both routes share is a deployment step. For a script JAR the development guide says you just need to copy the JAR to the Keycloak providers/ directory, then run bin/kc.[sh|bat] build. The built-in policy types are not affected by any of this. Each is created from a list in the admin console, for example To create a new time-based policy, select Time in the item list in the upper right corner of the policy listing.
• Delegated realm administration carries a measured overhead. This applies to fine grained admin permissions, the feature for delegating administration of realm resources such as users, groups and clients. It is not the Authorization Services layer an application uses on its own data, so check which one you are buying. The admin guide is direct about the cost: When enabling the feature to a realm, there is an additional overhead when realm administrators are managing any of the supported resource types. It names listing and searching, and updating or deleting, as the operations affected, and its own advice is to reference a realm administrator from fewer permissions, for example by granting through a group. If delegated administration is on your roadmap, price that in. If you are only protecting application resources, this one does not apply to you.

When to stay

Stay on Keycloak if you need to run identity yourself, on your own infrastructure, with no vendor in the request path. It is a CNCF incubating project with years of production use behind it. Eight of its nine built-in policy types cover user, role, time, aggregated, client, group, client scope and regex conditions with no policy code at all, created from a list in the admin console. The console also has an Evaluate tab: When designing your policies, you can simulate authorization requests to test how your policies are being evaluated. That is a real safety net, and Enforcer does not have one. Keycloak also answers a question most check-only services cannot: an authorization request sent with no permission parameter returns an RPT of granted permissions. Take that scoped the way Keycloak scopes it. The note printed beside that exact example reads This will not evaluate the permissions for all resources. Instead, the permissions for resources owned by the resource server, owned by the requesting user, and explicitly granted to the requesting user by other owners are evaluated. It covers resources registered with Keycloak as a resource server, not arbitrary rows in your database. If you already operate realms and have the people to run and tune the server, replacing it is a large project with little upside.

The options

Where Enforcer fits, and where it does not

What is actually different. In Enforcer, identity and authorisation are one service, so POST /authz/check is handed a caller that the same service already signed in, and the response carries a reason and the policy_id that produced the decision. Round trips are not the difference: Keycloak can return a bare decision too, with response_mode=decision giving { "result": true } and no RPT to unpack. The reason on a denial is. Custom policies are Rego in package enforcer.custom, compiled when you write them, capped at 64KB with a 100ms evaluation budget, so there is no JAR, no bin/kc.[sh|bat] build and no preview feature flag. Creating one needs tenant admin. Where Keycloak is better. List filtering only over Enforcer’s own resource types. The engine compiles the same policy into a SQL WHERE clause by partial evaluation, exposed over gRPC as CompileFilter, but only for the eleven types registered in Enforcer’s own process (account, group, tenant, ticket, wallet and six more). There is no REST endpoint for it and no way to register your own tables, so you cannot use it to filter your application’s data. It cannot answer "which resources can this user read". Keycloak answers a version of that in two places: the RPT returned when no permission is named, scoped to resources owned by the resource server, owned by the requesting user or explicitly granted to them by other owners, and fine grained admin permissions, which partially evaluate permissions to filter and paginate results when a realm administrator queries realm resources. OpenFGA, Keto, Cerbos and WorkOS FGA all answer it in their own domains. Enforcer answers none of it. Enforcer also has no shadow or preview evaluation: an inactive policy is stored and simply not evaluated, whereas Keycloak's Evaluate tab simulates a request against your policies before they go live. And there is no decision log out of the box. GET /audit-events is the identity and admin trail, covering logins, API keys, roles, tenants and terms, and it never records an authorisation decision, so you log the returned reason and policy_id yourself. Keycloak also composes where Enforcer replaces: it has a documented Decision Strategy across evaluated permissions, where Affirmative means that at least one permission must evaluate to a positive decision in order grant access to a resource and its scopes. and Unanimous means that all permissions must evaluate to a positive decision in order for the final decision to be also positive. Enforcer has no equivalent. Two behaviours that are easy to get wrong. With no policy_id named, a built-in baseline runs, and it is not blanket default-deny. Before any rule exists it already allows any action other than manage on a row whose owner_id is the caller, plus group and group type reads in your tenant, your own audit events and global policies, with a cross tenant admin getting everything. A named policy replaces that built-in decision rather than intersecting with it, and contexts only reaches a named policy. On /authz/check the resource is described by the caller and never looked up, so owner_id is an assertion your application has to resolve server side before it trusts the answer. Size. Enforcer is small and new. There are no independent reviews and no large community, against a CNCF incubating project with years of production use behind it.

Sources checked 15 September 2026: www.cncf.io/projects/keycloak/ · www.keycloak.org/docs/latest/authorization_servi · www.keycloak.org/docs/latest/server_development/ · www.keycloak.org/docs/latest/server_admin/index. · openfga.dev/docs/concepts · openfga.dev/docs/interacting/relationship-querie · github.com/openfga/openfga · github.com/ory/keto · github.com/cerbos/cerbos · github.com/zitadel/zitadel · github.com/goauthentik/authentik · workos.com/pricing

Enforcer is identity and authorization in one system, for applications and AI agents. Docs at docs.instruxi.dev. Related: Authorization tools compared · Why was this request denied? · OpenFGA alternatives · Cerbos alternatives · Permit.io alternatives