Keycloak: a single entry point for all services
When there are three services, a custom-built login looks like a reasonable solution: a form, a user table, token issuance.
The problem shows up at the tenth service, when accounts diverge across databases, some employees retain access after leaving, and the password has to be changed separately in each application.
Every new integration is yet another way of authenticating services that has to be maintained, tested, and secured.
Keycloak eliminates this branching: single sign-on is built on top of a single identity provider, and applications stop storing passwords and verifying them themselves.
A service receives a signed token and trusts it — the issuance rules, lifetime, and data composition are described in one place. Access management moves out of each application's code into roles and groups that an administrator changes without a release.
Then federation comes into play: the employee directory is connected as a user source, external contractors log in through a corporate provider, and service-to-service calls are authorized using machine accounts.
A user authenticates once and gets into all systems without re-entering a password, and access revocation takes effect centrally — the session is closed and tokens stop being refreshed.
Let's break down how this is deployed: from the realm and client scheme to a fault-tolerant setup with a standby node, so that single sign-on does not become a single point of failure.
What managed identity delivers
A single entry point removes manual work from the team that used to consume time on every new service.
Instead of a separate user database and homegrown authorization in each application, a service registers as a client in Keycloak — connecting a new application takes hours, not days, and does not require writing and maintaining your own authentication code.
Manual operations are reduced through centralization. Users, groups, and permissions live in one place: an employee joining, transferring between departments, or leaving is a single operation that is immediately reflected across all connected systems.
Revoke access in one place — it disappears everywhere, and no "forgotten" accounts remain in individual services.
A unified access policy stops being a set of agreements and becomes an enforceable rule. Password requirements, mandatory two-factor authentication, session lifetime, role restrictions — everything is configured once and applied identically to all applications. A new service inherits this policy upon connection instead of assembling its own.
Transparency of logins closes an entire class of access-related incidents. Every login, denial, and permission change is recorded in a single journal: you can see who logged in, when, and through which service, and who still has active sessions.
When investigating an incident, there is no need to collect logs from dozens of systems — the picture is assembled from a single source, and a suspicious session can be forcibly terminated.
Separately, the risk that usually surfaces during an audit is eliminated: desynchronization of accounts between systems.
When there is a single source of truth and services are connected according to a proven template, access rights stop "living their own life" — and that is precisely the managed identity that the customer receives as a result.
Deployment options and their limitations
Deploying Keycloak is rarely just "spin up a container": the choice of platform determines who is responsible for availability, updates, and the legal cleanliness of storing credentials. Below are three schemes that are realistically chosen between at the start, and their limitations.
| Option | When it fits | Limitations |
|---|---|---|
| Managed environment on our side | You need a quick launch, you don't have your own support team, and placement outside your perimeter is acceptable | Less control over network isolation and updates; data approval is required |
| Deployment in the customer's infrastructure | Strict requirements for storing personal data, you have your own capacity and on-call shift | Updates and fault tolerance are on your side; access for support is required |
| Hybrid scheme | The main environment is inside the perimeter, while some services or external partners are outside | Routing and session synchronization are more complex; careful federation configuration is required |
What determines the choice
A managed environment provides a predictable start: we maintain the cluster, replication, and backups, and you get working login without your own infrastructure. The limitation is that data resides outside your perimeter, and this does not always pass approval.
Deployment on your side is the flip side: full control over the network and storage, but support, updates, and recovery fall to your team. A hybrid removes some of the limitations, adding work on federation between environments.
Let's discuss your requirements for the perimeter and data — we'll come back with an assessment and a plan.
How implementation works: stages of work
Implementing SSO is not installing a product, but rebuilding every entry point into the systems. That is why we start with an inventory, not with deployment: until the full picture is visible, any policy configuration is done blindly.
How the process is structured
- Audit of entry points. We collect all systems that employees and external users log into: internal services, admin panels, partner portals. We record where accounts are stored, which protocols are supported, whether there are local password databases and service accounts with shared credentials.
- Integration scheme. We determine which applications we connect via modern protocols and which require a proxy layer or customization. We agree on the role and group model so that permissions do not have to be rewritten after launch.
- Deployment and policy configuration. We bring up a cluster with replication, configure federation with the existing user directory, password rules, multi-factor authentication and session lifetimes. We describe policies declaratively — the configuration is reproducible rather than assembled by hand.
- Scenario testing. We run through real paths: first login, password reset, session expiration, access revocation upon termination, login of an external contractor with limited rights. We separately test fault tolerance — what happens when one node is unavailable.
- Handover to operations. We provide documentation, administration regulations and instructions for the support service. We train the customer's team in standard operations: adding an application, granting a role, troubleshooting a login incident.
What matters at every step
The audit and integration scheme take more time than the configuration itself — and they are exactly what determines whether it will have to be redone a month later. Scenario testing happens before handover, not after: login incidents paralyze work faster than any other failure.
Describe your task — we will come back with an estimate and a stage-by-stage plan.
What the customer receives after implementation
Sign-in stops being a set of local accounts: a single authentication point serves internal services, admin panels, and external partner portals. Below is what stays with your team after handover, so that support and further development do not depend on the contractor.
- Realm and client configurations — exported to files: settings for user federation, role and group mapping, session timeouts, and token refresh. They are deployed on an environment with a single command, rather than reassembled from memory.
- Login flow diagrams — diagrams for each scenario: employee sign-in via the corporate directory, external user via a one-time code, service account via a machine token. It is clear where multi-factor verification kicks in and where an external identity provider is connected.
- Access policies — rules for granting roles and visibility scopes, restrictions by address and device, session lifetimes, and forced logout conditions. Each rule is tied to a specific group, not to an individual person.
- Support procedures — the procedure for adding and blocking users, rotating signing keys, renewing certificates, and responding to sign-in incidents. With an indication of who performs each step and within what timeframe.
- Documentation — an integration map, a description of roles and their assignments, instructions for the support service, and a checklist for diagnosing typical authentication failures.
- Monitoring and logs — export of sign-in and denial events to your log collection system, a set of alerts for a spike in failed attempts and for provider unavailability.
- Backup and recovery scripts — a tested scenario for bringing up configuration and data on a clean environment with recovery time measurement.
Everything listed is handed over in your repository with a change history: configuration edits go through review rather than being made by hand in the interface. Describe your task — we will come back with an estimate and a work plan.
Case: single sign-on for internal services
Before: authentication was scattered across services. Some systems ran on their own user tables, some on an LDAP directory, and a few more on custom-built tokens.
Passwords were stored in three places, permissions were granted manually, and when an employee left, access was revoked according to a checklist where something was regularly forgotten.
Connecting a new service took 3-4 weeks: agree on the scheme, write the integration, test the login scenarios, roll out to production.
After: we deployed Keycloak as a single identity provider. We set up federation with the existing directory so we wouldn't have to migrate accounts, and connected services via standard protocols — OIDC for web applications, SAML for legacy systems that can't do otherwise.
Roles and groups were moved into a single registry, and user provisioning was tied to the directory: a termination in the HR system automatically closes access in all connected services.
What changed in numbers
- Time to connect a new service: from 3-4 weeks to 2-3 days — a typical integration boils down to registering a client and configuring redirects.
- Support requests for passwords and access: down 70% in the first quarter — password resets and permission grants moved to self-service.
- Access revocation upon termination: from several hours of manual work to automatic triggering within minutes.
- Number of password storage locations: from three to one, with a unified complexity policy and mandatory two-factor authentication for administrative roles.
Why it worked
The key is not the product itself, but the access model brought into a unified form: a single source of truth for users, predictable roles, standard protocols instead of custom-built solutions.
After that, every new service is connected using a proven template rather than reinventing authentication from scratch.
We keep the configuration in a repository and roll out changes through automation — environments are reproduced identically, including federation and policy settings.
How is Keycloak different from a custom-built login?
A custom-built login almost always starts the same way: a login form, a user table, a password hash, a session in a cookie.
Six months later, password reset, email confirmation, lockout after a series of failed attempts, roles and permissions, plus login through a corporate directory and a second factor get added on top.
Each item is a separate task with edge cases, and it is these that consume most of the time, not the login form itself.
An off-the-shelf solution covers this set out of the box: federation protocols, brokering of external providers, password policies, a login event log, fine-grained configuration of permissions by roles and groups.
Our engineers deploy it in a fault-tolerant configuration, connect it to your user directory, and set up token issuance and renewal. You do not need to design a secret storage scheme or think through what happens when an authentication node becomes unavailable.
Support cost is the main argument. A custom-built login quietly accumulates dependencies: swapping a library, updating because of a vulnerability, adapting it for a new service. Every change is made by one person, and their departure turns the system into a black box.
An off-the-shelf solution has a community, documentation, and a predictable security update cycle — updating the version does not require rewriting the login logic.
The speed of change is different too. Connecting a new service to an off-the-shelf solution is a matter of configuring a client and permissions, a few hours of work. In a custom-built scheme, it is a code change, tests, and deployment.
When the business asks for single sign-on for a new product, the difference is measured in days versus weeks.
Security is not just about hashes. An off-the-shelf solution undergoes community review and penetration tests for years, while a custom-built login is vulnerable exactly to the extent that its author was careful at the moment of writing.
We are not claiming that in-house development is pointless — sometimes it is justified by narrow requirements. But if the goal is reliable login without constant maintenance, an off-the-shelf solution wins on total cost of ownership.
Common technical concerns
Concerns about Keycloak usually come down to four topics: compatibility with existing applications, migrating users from the current system, behavior under load, and integration with already running services. Below is a breakdown of each, from an engineering perspective.
Compatibility: will applications have to be rewritten?
In most cases, no. Keycloak works over standard identity federation protocols — OIDC and SAML — so applications that already support authentication through an external provider can be connected by changing connection parameters, without code changes.
For legacy systems without support for these protocols, we set up proxy authentication or an adapter. We separately verify scenarios: single sign-on, logout from all sessions, token refresh, roles and groups.
Migration: how do you migrate existing users?
We transfer accounts, password hashes, and role mappings from the current store — Active Directory, LDAP, or a custom database.
If the hash format is compatible, users continue to sign in with their old passwords; if not, we set up a forced change on first login so as not to reset everyone at once.
We carry out the migration in stages: first synchronization, then traffic cutover, with the ability to roll back to the previous system until the full transition is complete.
Load: will it handle the entire company signing in at once?
Keycloak scales horizontally: multiple instances behind a load balancer, a shared database, and a distributed session cache. The morning peak, when hundreds of employees sign in within a few minutes, is a normal mode for such a scheme.
We spread the cluster across availability zones so that the failure of one node does not interrupt sign-in. Before going live, we run a load test on a real sign-in profile and record the headroom in the number of concurrent sessions.
Integration: what about corporate services and access?
We connect the corporate directory as a user source, set up group synchronization, and automatic access revocation upon termination. Roles from the directory are projected onto applications, so permissions are changed in one place.
For external contractors, we create a separate perimeter with a limited set of services and an account expiration date.
Describe your landscape — which applications, directory, and load profile — and we will come back with an assessment and migration plan.
Let's discuss your identity challenge
A turnkey Keycloak deployment starts with a conversation, not with installation.
It's important for us to understand your current identity setup: where accounts are stored, which applications and services need to be connected, whether there are external contractors and partner systems that need access.
This determines the federation architecture, the choice of protocols, and how rollback will be structured if something doesn't go according to plan.
Describe the task in your own words — we'll come back with an estimate and a work plan. On the first call, we'll clarify:
- which applications and services we're connecting and which protocols (SAML, OIDC) they can work with;
- where we're migrating accounts from and how we transfer passwords and groups without a mass reset;
- whether federation with external directories and corporate domains is needed;
- what the requirements are for multi-factor authentication and password policies;
- how roles and permissions are structured: who gets access to what;
- whether integration with existing monitoring and logging systems is needed;
- which fault-tolerance scenarios are critical: standby node, recovery, scheduled updates;
- who on the customer's side accepts the result and by what criteria.
After the call, you'll receive a work plan with stages, timelines, and areas of responsibility, as well as a target architecture diagram. We work remotely and connect to your infrastructure in whatever way is convenient for your security team. Let's discuss the task — and we'll come back with a specific estimate.