Keycloak for enterprise IAM: when self-hosted identity is the right call

Keycloak is one of the few pieces of enterprise infrastructure where the open-source option is genuinely competitive with the commercial leaders. It speaks OIDC and SAML, handles single sign-on, federation and identity brokering, and costs nothing per seat. That last part excites people and gets them in trouble, because the license is free and the operation is not. This article is about when self-hosted identity is the right call, and when you are better off paying for managed IAM.

What Keycloak actually gives you

Keycloak is a full identity and access management server. It implements the protocols enterprise systems expect: OpenID Connect (OIDC) for modern web and mobile apps, OAuth 2.0 for API authorization, and SAML 2.0 for the legacy and B2B integrations that still run half of corporate Europe. On top of those it gives you single sign-on across every connected application, user federation against an existing LDAP or Active Directory, and identity brokering: it can sit in front of external identity providers (a customer's Entra tenant, a partner's SAML IdP, a social login) and present one consistent token to your applications.

In practice that is one place to manage authentication for a portfolio of applications that would otherwise each roll their own login: internal admin tools, customer portal, partner integrations and machine-to-machine API traffic, all on the same server, session, MFA policy and audit trail. The feature set is roughly at parity with the managed leaders for what most enterprises need. Where Okta, Auth0 or Microsoft Entra pull ahead is in the polish around the edges: turnkey integration catalogs, threat intelligence feeds, and a support contract with an SLA.

The honest trade-off versus managed IAM

The pitch for self-hosting is simple: managed IAM bills per monthly active user, and at enterprise scale that grows into real money, especially for B2C or large-partner workloads where you pay for identities that log in twice a year. Keycloak removes that line entirely. No per-seat cost, no surprise overage when a campaign triples your active user count.

What you take on instead is operational responsibility. With Okta or Entra, an identity outage is their problem and their on-call engineer. With Keycloak, it is yours. Identity is the single most load-bearing service in your stack: if it is down, nothing authenticates, which means everything is down. So you are not comparing a license fee against zero, but against the fully loaded cost of running a tier-zero service: infrastructure, high availability, patching, upgrade testing, and the people who know how it works at 3am.

For organizations that already operate critical infrastructure competently, that cost is marginal and the savings obvious. For those whose core competence is not infrastructure, the per-seat fee is often cheaper once you price the operational burden honestly. Be candid about which one you are.

Realm and client design done properly

This is where most self-hosted Keycloak deployments quietly go wrong, slowly and expensively. A realm is an isolated tenant: its own users, roles, clients and keys. A client is an application that authenticates against it. These decisions look trivial on day one and become structural debt on day three hundred.

The common mistakes: putting B2B partners, internal staff and B2C customers in one realm because it was easier at the start, then finding you cannot apply different password policies or token lifetimes to each. Or the reverse, fragmenting into a realm per application and losing single sign-on entirely, because SSO does not cross realm boundaries. Or modeling authorization as a sprawl of fine-grained roles nobody can audit, instead of a clean split between coarse realm roles and application-specific client roles.

Get the token design right early too. Token lifetimes, what claims go in the access token versus userinfo, audience restrictions, and whether you use offline tokens all propagate into every connected application. Changing them later means coordinated changes across every client, a multi-quarter project at enterprise scale. The realm and client model is architecture, not configuration, and deserves a design review before the first user exists.

Hardening and high availability

A Keycloak instance you can demo on a laptop and one you can put in front of production traffic are different systems. The gap between them is where self-hosting earns its reputation as harder than it looks.

High availability means clustering. Keycloak nodes share session and cache state through an embedded Infinispan layer, and getting that right across availability zones (cache replication, sticky sessions or stateless validation, split-brain handling) is real distributed-systems work. The database underneath is a tier-zero dependency too: its own HA, backups you have actually tested, and pooling sized for your peak login storm.

Then the token and session strategy. Stateless validation, where applications verify JWT signatures locally against the realm's public keys, scales beautifully but makes revocation harder. Stateful sessions give instant logout but load the cluster more. Most enterprises land on a hybrid (short-lived access tokens plus a session check for sensitive operations), but that is a deliberate decision, not a default to inherit.

Hardening is the rest of the checklist: TLS everywhere, the admin console off the public internet, brute-force protection on, MFA enforced for privileged realms, key rotation scheduled, security headers and CORS locked down. None of it is exotic. All of it is your responsibility now, where with managed IAM it shipped on.

Upgrade discipline and data residency

Keycloak moves fast. The migration to Quarkus a few years back broke a lot of assumptions, and the project ships meaningful releases regularly. Self-hosting means you own the upgrade treadmill: testing each version against your realm config, custom themes, authentication flows and any extensions you wrote, before it touches production. Skip upgrades and you accumulate security exposure plus a painful multi-version jump later. This is the discipline that gets dropped first when a team is busy, and the one that bites hardest.

The flip side, a genuine advantage, is control. When you self-host identity, every credential, every session and every piece of personal data sits on infrastructure you choose. For European enterprises under GDPR, that is the cleanest possible answer to data residency: no third-party processor, no transatlantic transfer to justify, no vendor sub-processor list to audit. You run identity in your own European region, and the data protection conversation gets dramatically simpler. For regulated sectors, that alone can be the deciding factor.

When to self-host, when to pay

Choose self-hosted Keycloak when you already run critical infrastructure well, when per-seat IAM pricing is a material cost at your scale (large B2C or partner ecosystems especially), when data residency and full control over identity data are hard requirements, and when you have, or will fund, the operational capacity to treat identity as a tier-zero service with real on-call ownership.

Choose managed IAM (Okta, Auth0, Entra) when your team is small or stretched, when identity is not where you want to spend operational attention, when you need the turnkey integration catalog and a vendor SLA, and when the per-seat cost is comfortably below what running it yourself would actually cost once you price the people in.

The wrong reason to self-host is "it is free." The right reasons are control, residency and scale economics, backed by the capability to operate it. Keycloak is excellent software. It is also a system you must run, not a SaaS you can forget. The teams that succeed with it go in with both eyes open.

Get the Keycloak decision right

DNA Solutions helps European enterprises make the self-host-versus-managed call honestly, then design and operate the result: realm and client architecture, clustering and high availability, hardening, upgrade strategy, and GDPR-aligned data residency. Whether you are standing up Keycloak from scratch or rescuing a deployment that outgrew its design, we help you treat identity as the tier-zero service it is. Talk to us.