Keycloak Provides Open-Source Identity Management. The Tokens It Issues Carry No Governance Binding.
by Nick Clark | Published March 28, 2026
Keycloak is the leading open-source identity and access management platform, backed by Red Hat and deployed across enterprises, governments, and SaaS providers worldwide. It implements OAuth 2.0 and OpenID Connect, SAML 2.0, identity brokering against external providers, and multi-tenancy through realms. It issues access tokens, refresh tokens, ID tokens, and SAML assertions; it manages user sessions, federations, and fine-grained authorization through UMA and policy-based resource permissions. The platform is comprehensive, mature, and operationally sound. But the tokens Keycloak issues carry identity claims and scope permissions. They do not carry cryptographically bound governance policy for specific operations. A token with appropriate scopes allows operations. Whether those operations comply with governance requirements under current conditions is not the token's concern. The gap is between identity token issuance and cryptographic governance attached to the operation itself.
The identity stack is real, the governance binding is absent
Keycloak's coverage of the identity problem is genuinely broad. Its OAuth 2.0 and OpenID Connect implementations support the standard grant flows including authorization code with PKCE, client credentials, device authorization, and token exchange. SAML 2.0 support handles the long tail of enterprise SSO into legacy applications. Identity brokering allows Keycloak to act as a hub between external providers (Google, GitHub, Microsoft Entra, arbitrary OIDC or SAML peers) and downstream applications, with mappers translating claims between formats. Realms provide tenant isolation, each with its own users, clients, roles, and signing keys. Red Hat's commercial backing through Red Hat build of Keycloak supplies the long-term support, security response, and certification posture that regulated enterprises require.
What is not in scope for Keycloak — and not in scope for any standards-conformant OIDC or SAML implementation — is the binding of governance policy to a specific operation at the moment of execution. Keycloak's job ends when a token is issued or an authorization decision is rendered. From that point onward, the token is a bearer credential that travels with the request, and what happens at the resource is the resource's problem.
Authorization scopes are static permissions, not dynamic governance
Keycloak tokens carry scopes that define which resources a token may access and which actions it permits. Scopes are issued at authentication time based on the client's request, the user's roles, and the realm's policy configuration. They are then encoded into the access token as claims and signed.
Scopes are static permissions. A token with the write scope allows writing for the lifetime of the token, regardless of subsequent context. Whether the data being written has since become subject to a hold, whether the writing entity's risk posture has degraded, whether a governance policy change in the meantime would have caused the original authorization decision to come out differently — none of that is reflected in the token. The token's authority was fixed at issuance. The system has no native mechanism to express, at the level of the token, that the governance context binding the operation is the context at the moment of the operation, not the moment of issuance.
Fine-grained authorization narrows scope but does not bind operations
Keycloak's Authorization Services and UMA 2.0 support allow much finer-grained control than raw OAuth scopes. Resources, scopes, policies, and permissions are modeled in the realm; policy enforcement points evaluate access at request time, optionally consulting a policy decision point that takes contextual claims into account. This is genuinely valuable, and for many applications it is more than sufficient.
But the authorization decision is evaluated at the Keycloak server (or at a policy enforcement point that defers to Keycloak), and the result is communicated as a permission ticket or a Requesting Party Token. Once that token reaches the resource, the operation it authorizes is not cryptographically bound to the policy that authorized it. There is no signed artifact attached to the operation that records "this specific write, of this specific payload, into this specific resource, at this specific time, was authorized under this specific policy version, evaluated against this specific context." The decision was made; the evidence of the decision is the token; the operation proceeds.
Identity brokering and realms compound the temporal gap
Identity brokering and multi-realm deployments make the issuance-versus-execution gap more visible. A user authenticates against an external identity provider, Keycloak brokers the assertion, mappers translate claims, a token is issued in the local realm, and downstream services accept it. Each hop has its own clock, its own policy state, and its own caching. By the time the token authorizes an operation at a downstream resource, several minutes (or, with refresh, several hours or days) of policy drift may separate the decision from the act. None of that drift is visible in the token. The token is a snapshot. The operation it authorizes is not a snapshot — it is a live event in a live system.
The realm model makes this still sharper, because realms are the unit of policy configuration. A change to a realm's policies is effective for tokens issued after the change. Tokens issued before the change continue to authorize whatever they authorized at issuance, until they expire or are revoked. Revocation, in turn, is best-effort: it depends on resources consulting introspection endpoints or honoring revocation lists, neither of which is universal practice.
Why this is a structural limit, not an implementation gap
Nothing in this analysis is a criticism of Keycloak's engineering. The behavior described is the behavior the OAuth 2.0 and OIDC specifications define. A token is a bearer credential whose authority is fixed at issuance and verified by signature. The standards do not contemplate per-operation cryptographic binding of governance policy. Any conformant implementation — Keycloak, Auth0, Okta, Microsoft Entra, AWS Cognito — will exhibit the same structural property, because the property follows from the standards, not from the implementation.
That is what makes the gap interesting. It is not closed by configuring Keycloak more carefully or deploying a different IAM product. It is closed by adding a layer of cryptographic governance binding that operates at the moment of execution, not at the moment of authentication.
What cryptographic governance provides
Cryptographic governance binds signed policy to each operation at the point of execution. The governance policy is evaluated in the current context — the live state of the data, the current trust posture of the actor, the current version of the policy — and a signed governance artifact is attached to the specific operation, naming the policy version and the context under which it was evaluated. That artifact accompanies the operation through the system and is verifiable by any downstream component independently of the IAM that originally authenticated the actor.
Keycloak's identity stack — OAuth 2.0, OpenID Connect, SAML 2.0, identity brokering, realms, fine-grained authorization, Red Hat support — continues to do exactly what it does well: authenticate principals, broker federations, and issue identity tokens. Cryptographic governance adds the missing layer: real-time, operation-specific governance binding that is cryptographically associated with the act, not with the actor. The IAM is preserved. The governance becomes legible.
