Vicedomini Softworks

Software Security

30 Minute Keycloak Quickstart for Engineers, Hardened for Production

8 September 2026

Decorative Keycloak quickstart title card

Keycloak is an open-source identity and access management server that gives development teams single sign-on, identity brokering, and federation without licensing fees. It suits organisations with the engineering capacity to configure, harden, and operate their own authentication layer, particularly where on-premise deployment or deep customisation matters. The fastest way to evaluate it is direct: run a development instance through Docker or the distribution ZIP, then open the admin console.

TL;DR:

  • Keycloak requires replacing its default database with a supported production system like PostgreSQL before going live, as the default H2 is only for development.
  • To secure a production deployment, all endpoints must use TLS/SSL, and admin console access should be tightly restricted with regular key and certificate rotation scheduled.
  • Load testing with realistic session volumes and token lifetimes is essential to size the system appropriately for enterprise-scale use.
  • Custom authentication flows should be peer-reviewed, automated tested, and staged prior to deployment to prevent brittle, hard-to-maintain logic under operational load.
  • Implementing Keycloak successfully in enterprise settings involves operational practices such as infrastructure-as-code, automated backups, and monitoring to ensure stability over time.
Vicedomini Softworks
Build Secure Enterprise Software
Vicedomini Softworks helps organizations integrate complex systems and build secure, scalable software with direct collaboration from experienced engineers.

Table of Contents

What is Keycloak used for?

Keycloak solves the problem every application eventually faces: centralising authentication instead of rebuilding login screens, password resets, and token issuance for every service. It works as a standalone authorisation server that other applications trust, rather than a library each team wires in separately.

The feature set is broad enough to replace several point solutions at once:

  • Single sign-on and single sign-out across multiple applications, backed by a token model built on standard session cookies and refresh tokens.
  • Identity brokering and social login, letting users authenticate through Google, Microsoft, or a corporate identity provider without Keycloak storing their credentials directly.
  • Protocol support for OpenID Connect, OAuth 2.0, and SAML, covering both modern API-driven applications and legacy enterprise systems that still expect SAML assertions, according to the server administration guide.
  • User federation with LDAP and Active Directory, so existing corporate directories stay the system of record instead of duplicating user records.
  • Flexible authentication flows, multi-factor authentication, and fine-grained authorisation, configurable per realm or per client rather than hardcoded into application logic.
  • Admin and account consoles, giving IT teams centralised control and giving users a self-service portal for their own credentials and sessions.

Keycloak authentication is not just login. It is the layer that decides who gets a token, what that token contains, and which resources it unlocks.

How do you get started with Keycloak?

Reaching a working setup takes roughly 30 minutes if you follow the official quickstart paths closely, according to the Docker getting-started guide. Two routes get you there, depending on whether you prefer containers or a local distribution.

Docker route:

  1. Pull and run the image: docker run -p 8080:8080 -e KEYCLOAK_ADMIN=admin -e KEYCLOAK_ADMIN_PASSWORD=change_me quay.io/keycloak/keycloak:latest start-dev
  2. Open localhost:8080 and log in with the admin credentials you set.
  3. Create a new realm, register a client, and enable the sample single-page application to confirm the authentication flow works end to end.

Distribution (ZIP) route, for teams that prefer running Keycloak outside a container:

  1. Download the distribution from the official downloads page and unpack it.
  2. Run bin/kc.sh start-dev, then create the initial admin user as prompted.
  3. Create a realm and client exactly as in the Docker path, following the steps in the ZIP getting-started guide.

Both routes rely on start-dev, which disables production safeguards to speed up local iteration. Never run that flag against a public endpoint.

Pro Tip: Test the sample SPA login before you touch your own application’s code. If the sample authenticates cleanly, any later failure is almost certainly in your client configuration, not the Keycloak server.

What does it take to run Keycloak in production?

The gap between a dev instance and a production deployment is where most Keycloak projects lose time. The default H2 database and permissive dev flags exist purely for convenience, and neither belongs anywhere near a live environment, per the ZIP getting-started guide.

Before go-live, work through this list:

  • Replace the embedded H2 database with PostgreSQL or another supported production database.
  • Configure TLS/SSL for every endpoint, including internal cluster traffic, not just the public login page.
  • Restrict and separately secure the admin console, since it carries far more privilege than any application login screen.
  • Rotate signing keys and certificates on a defined schedule rather than leaving defaults in place indefinitely.
  • Choose a deployment pattern: the Keycloak Operator on Kubernetes or Red Hat OpenShift for lifecycle management, standalone containers for simpler setups, or a clustered high-availability arrangement for larger user bases.
  • Build in session replication, automated backups, and load testing before the first real user logs in.

Keycloak is listed as a Cloud Native Computing Foundation incubating project, and the CNCF project page tracks contributor activity and project health as a rough proxy for its long-term maintenance trajectory. That matters when you are choosing infrastructure you will depend on for years, not months.

Sizing depends heavily on session volume and token lifetime settings, so load-test with realistic concurrency figures rather than default configuration values before committing to a cluster size.

How does Keycloak fit into a wider integration strategy?

Most Keycloak deployments do not replace an identity store, they sit in front of one. That distinction shapes how teams actually use it day to day.

  • LDAP and Active Directory bridging: Keycloak maps existing directory attributes to OIDC claims, exposing modern authentication endpoints while your legacy directory stays the system of record, according to the server administration guide. This is a common route for organisations modernising legacy systems without a disruptive directory migration.
  • Securing SPAs and REST APIs: front-end applications and backend services validate OpenID Connect tokens issued by Keycloak rather than each service managing its own credential checks.
  • Kubernetes and OpenShift deployments: the Keycloak Operator handles lifecycle tasks like upgrades and scaling, and pairs naturally with Prometheus and Grafana for session and database monitoring.
  • Identity brokering for external providers: useful when a product needs to support customers who already have accounts with Google, Microsoft, or a partner organisation’s own identity provider.

Enterprise teams juggling multiple internal systems often reach for enterprise integration patterns that mirror this approach, using a broker layer instead of hardwiring every system to every other system.

Where does Keycloak get complicated?

Keycloak’s flexibility is also where it bites teams that move too fast. The authentication flow designer and its Service Provider Interface allow deep customisation, but that same flexibility increases the risk of brittle, hard-to-maintain logic if flows are not engineered with the same rigour as application code, per the server administration guide.

Common friction points:

  • Custom SPI extensions that work in testing but fail under production load or edge-case token expiry.
  • Documentation that assumes familiarity with identity protocol concepts, steepening the learning curve for teams new to OIDC or SAML.
  • Ongoing operational load: version upgrades, database scaling, and session store tuning don’t stop once the initial deployment ships.

Pro Tip: Treat every custom authentication flow like production application code. Peer review it, write automated tests against it, and roll it out to a staging realm before touching the production realm. Automated backups, infrastructure as code, and proper observability turn Keycloak from a maintenance burden into a stable, predictable service.

How would an engineering-first team deliver Keycloak for enterprise clients?

Vicedomini Softworks approaches a Keycloak engagement in phases: discovery and architecture review, implementation against agreed realms and client configurations, deployment onto containerised or Kubernetes-native infrastructure, and long-term support once the system is live. Engineering practices include peer-reviewed code, targeted testing, and production observability, using container orchestration technologies.

Deliverables typically include a hardened production Keycloak configuration, infrastructure-as-code pipelines for repeatable deployment, and monitoring runbooks the client’s own team can operate independently. Organisations evaluating this route can review Vicedomini Softworks’s services for the full scope of custom software and integration work on offer.

How would an engineering-first team deliver Keycloak for enterprise clients? — overview diagram

Where can you find authoritative Keycloak resources?

Primary sources save more time than any third-party summary once you’re past the conceptual stage.

An editorial take on running Keycloak in-house

The conventional pitch around Keycloak treats it as a free alternative to commercial identity platforms, full stop. That framing undersells the real cost. Keycloak is free to license, but it is never free to operate. Someone on your team owns the database migration, the certificate rotation, the SPI code that breaks quietly during an upgrade nobody tested in staging first.

Keycloak operational ownership responsibilities

Where the standard advice falls short is in treating “get it running” and “run it safely” as the same milestone. They aren’t. A dev instance reachable in 30 minutes tells you almost nothing about whether your team can operate a hardened, highly available identity server six months from now, under real load, with real attackers probing the admin console.

Prioritise operational readiness before feature breadth. Get PostgreSQL, TLS, and backup automation solid first. Custom authentication flows and SPI extensions can wait until the boring plumbing is trustworthy. Teams that skip that order tend to discover the gap during an incident, not during a planning meeting, and that is the most expensive time to learn it.

— Pepe F.

Sources

FAQ

What is Keycloak used for?

Keycloak is used to centralise authentication and authorisation across multiple applications, providing single sign-on, identity brokering, user federation with LDAP or Active Directory, and support for OpenID Connect, OAuth 2.0, and SAML.

Is Keycloak a secret manager?

No. Keycloak is an identity and access management server, not a secrets manager. It issues and validates authentication tokens; it does not store or manage application secrets, API keys, or encryption keys the way a dedicated secrets manager does.

Is Keycloak an SSO provider?

Yes. Single sign-on is one of Keycloak’s core capabilities, allowing users to authenticate once and access multiple connected applications without repeated logins, backed by its token-based session model.

What are the disadvantages of Keycloak?

The main disadvantages are operational: running Keycloak in production means owning database management, TLS configuration, upgrades, and monitoring yourself. Custom authentication flows built through its SPI can also become brittle if not tested and reviewed as rigorously as application code.

How long does it take to get a working Keycloak setup?

Following the official Docker or ZIP quickstart paths, most developers reach a working admin console and authenticated sample application in around 30 minutes, though production hardening takes considerably longer.