# What is Keycloak? Keycloak is an open-source identity and access management system. It answers two questions for every application you run: who is this person, and what are they allowed to do. It handles single sign-on, multi-factor authentication, social login, and federation with LDAP and Active Directory, and it speaks OAuth 2.0, OpenID Connect and SAML 2.0. It is backed by Red Hat, is a CNCF incubating project, and is licensed under Apache 2.0. ## The problem it solves Every application needs to know who is using it. Left to itself, every application solves that separately, and an organization ends up with a familiar mess: - Each application has its own user table, its own password rules and its own password reset flow. - A new employee is created by hand in six places. Someone who leaves is removed from four, and nobody is certain which four. - Multi-factor authentication has to be built, separately, in each one. - "Who has access to what" cannot be answered without asking every application owner. An identity provider takes that job away from the applications. There is one place users exist, one login screen, one set of rules about password strength and second factors, and one place to look when someone leaves. ## What single sign-on actually means The visible part is that a user logs in once and reaches several applications without logging in again. The mechanism is the part worth understanding, because it is what makes the security argument work. The application never sees the password. It redirects the browser to Keycloak, Keycloak authenticates the person however it is configured to, and sends the browser back with a signed token saying who they are and what they can do. The application checks the signature and trusts the contents. The consequence: a compromised application cannot leak credentials it never had. It is also why adding multi-factor authentication is a change in one system rather than in fifteen. **OpenID Connect** is the modern protocol for this and what new applications should use. **SAML 2.0** is older, more verbose, and what a great deal of enterprise and government software supports. Keycloak speaks both, which in practice is often why it gets chosen: real estates contain both kinds of application. ## Two different problems wear the same name Before the question of whether you need one, the question of which one, because the answers diverge sharply. **Workforce identity** is your own people: employees and contractors signing in to internal systems. Numbers are bounded by headcount, the directory usually already exists, and in most organizations it is a Microsoft estate with Active Directory or Entra ID at the center. Keycloak federates with that rather than replacing it. **Customer identity** is the users of a product you sell. Numbers are bounded by how well the product does, which is to say unbounded, and they are the people you least control: they arrive with a Google or Microsoft account and expect to use it. The distinction decides the economics. Per-user pricing is tolerable at headcount and punishing at customer scale, where the bill grows with success and every dormant account keeps costing. It is also where self-hosting stops being an operations decision and becomes a pricing one, because the crossover arrives much earlier than teams expect. For customer identity specifically, the capability that saves the most work is federation. Letting people sign in with the account they already have, Google, Microsoft, Apple, or their employer's own identity provider, is built in. Teams routinely underestimate this and build it themselves, once per application, and then maintain it. The payoff either way is the same shape: applications stop each holding their own idea of who a user is, and get one place to authenticate against and one token to validate. ## When you need one - **More than a few applications with overlapping users.** The cost of not having one grows with the number of user tables. - **A product with customer accounts**, where per-user pricing scales with your success and federation is expected rather than exotic. - **Joiners, movers and leavers as a real process.** Central identity turns offboarding into one action instead of a checklist. - **Multi-factor authentication as a requirement**, which is far easier to impose in one place. - **An auditor asking who can access what.** One answer, not fifteen. ## When you do not **A single application with a handful of internal users** does not need this. Its own login is fine, and an identity provider is more infrastructure than the problem justifies. **If a hosted identity service fits and its pricing works**, that is a legitimate answer and involves less to run. Okta, Auth0 and Microsoft Entra ID all do this well, and so does a managed Keycloak from any provider. The comparison worth making is per-user pricing at your expected size against the cost of operating Keycloak, and the crossover point is usually clearer than people expect. Our [SaaS versus open source comparison](/comparison/) works through it, and [open-source IAM](/open-source-iam/) covers the alternatives to Keycloak specifically. ## Why running it is not a weekend project Keycloak installs quickly. That is the trap: the install is not the work. - **It is the most critical service you will run.** When the identity provider is down, every application behind it is down, including the one you would use to fix it. High availability is not an optimization here. - **It has a database, and that database is your users.** Backups, restore rehearsals, and the same care any primary datastore needs. - **Upgrades touch everything.** Keycloak releases regularly, and major versions have changed significant things in the past. Upgrades need a staging environment and a rollback plan, because the blast radius is total. - **Realm configuration is complex and consequential.** Realms, clients, roles, scopes, mappers, flows. It is powerful, and a misconfigured token mapper can hand an application more authority than intended, quietly. - **Certificates and key rotation.** Token signing keys need rotating, and doing that without breaking every integration takes planning. - **Session and token lifetimes are a security decision.** Defaults are a starting point, not an answer. ## Where VSHN fits VSHN operates Keycloak on Swiss cloud infrastructure from CHF 360 per month, with up to 99.99% SLA, 24/7 operations and no per-user pricing, together with Inventage, who bring the Keycloak side of the expertise. The availability, upgrade and backup questions above are the service. If you are earlier than that and still deciding between a hosted identity service and running one, the comparison pages linked above are the useful place to start. [Get a cost comparison](#contact)