What Keycloak Is and Why You Need It

Keycloak from scratch: a ready-made login and single sign-on (SSO) server. What problem it solves, what IAM and SSO mean in plain words, and where it sits relative to your application and API.

Published 27 июня 2026 updated 28 июня 2026 ~13 min read Author: Вадим Викулин

← Back to the section

Almost every application has a login: registration, a password, a "forgot your password?" button, roles (a regular user and an admin). It looks like a couple of screens and one database table. In reality, a whole layer of work hides behind those screens — work that is very easy to get wrong, and a mistake here means a security hole. Keycloak is a ready-made service that takes this entire layer off your hands. Let's work through it from scratch and without rushing: what problem it solves, what the words IAM and SSO mean, and where Keycloak sits relative to your application and API.

The problem: "I'll write authorization myself"

Let's honestly look at what "building login yourself" means. When login is written by hand, a list of tasks like this gradually appears in the project:

store passwords — but not the password itself, rather its salted hash, otherwise a database leak leaks every password;
build registration, login, logout, password change, and password reset by email;
set up roles (who is a regular user, who is an administrator) and check permissions on every page and in every request;
protect against password brute-forcing, session hijacking, and token leaks;
and then, when the business asks, add login through Google, a second factor (a one-time code from an app), account lockout.

Each item on its own looks simple. The trouble is twofold. First: there are dozens of such items, and a mistake in any of them is not an "ugly button" but a vulnerability someone can use to log in under someone else's name. Second: as soon as you have a second application, all of this code has to be written again or copied from project to project — and the bugs get copied along with the code.

The conclusion writes itself: login is not an "application feature" but a separate, self-contained task. And since it is the same for everyone, it makes sense to take a ready-made solution rather than reinvent your own.

What Keycloak is

Keycloak is a separate, ready-made service to which you hand over all the work with login. It is developed by Red Hat, it is free and open source. Once you connect Keycloak, your application stops storing passwords and dealing with login. It only asks Keycloak one question: "who is this person, and what are they allowed to do?"

An analogy from life. Imagine a business center with a dozen offices. Previously, each office kept its own guard at the door who checked passports and kept its own visitor log. That is expensive, and the guards check differently. Keycloak is a single shared reception desk at the building entrance. You show your document at the desk once, get a badge pass, and then walk between offices showing the badge instead of your passport. The offices never see your passport at all — they trust the reception desk.

In this analogy:

the reception desk is Keycloak;
the passport is your login and password;
the badge pass is the token that Keycloak issues;
the offices are your applications and services.

IAM and SSO in plain words

Two abbreviations often come up around Keycloak — let's unpack them without jargon.

IAM stands for Identity and Access Management. It is the umbrella name for everything that answers two questions: "who is this person" (identity) and "what are they allowed to do" (access). Keycloak is an IAM system: it both stores accounts and decides who can do what. When people say "we use Keycloak as our IAM," they mean exactly this — a single place where users and their permissions live.

SSO stands for Single Sign-On. It is a convenience for the user: log in once and get access to all applications at once, without entering a password in each one again.

Let's explain through the pain. A company has five internal applications, and each has its own login screen. An employee enters a password five times and keeps five different passwords in their head. With SSO they log in once through Keycloak, and all applications connected to it recognize the employee automatically. Log out of one application — you are logged out of all of them. This is more convenient for people and safer for the company: there is a single account, and if an employee leaves, you can block them in one place instead of running around five systems.

The connection is simple: IAM is about what Keycloak does (it manages identities and access). SSO is one of the main conveniences that follows from it (one login for all applications).

Where Keycloak sits relative to the application and API

The most important thing to understand is where Keycloak sits in the overall picture. It stands off to the side, as a separate service, and login passes through it. Remember the key division of roles:

Keycloak verifies who the user is (login and password) and issues them a "pass" — tokens.
Your application does not check the password at all. It receives a token and only checks that the pass is genuine and not expired.
Your API (the backend the application goes to for data) accepts the token on every request and, based on it, decides whether to return data or not.

Now, what's on the diagram. The user works with the application; the application sends them to log in to Keycloak; Keycloak checks the password and issues tokens back to the application; then the application calls the protected API, attaching an Authorization: Bearer access_token header to each request — and the API verifies that token. Keycloak sits at the center as the single identity provider.

Note the main point: the arrow carrying the password goes only to Keycloak. Your API never sees the password — it sees only the token. That is the whole point of the exercise: one service is responsible for login, and the rest trust it based on the token.

What is this "pass" that Keycloak issues

That badge pass from the analogy is a token. Most often Keycloak issues it in JWT format: a string that holds, in readable form, the user's name, their roles, and an expiry date, with Keycloak's digital signature at the end. The application or API makes sure the signature is genuine, and after that it trusts the contents: "yes, Keycloak's signature is valid, so these really are this person's roles."

In short, there are actually several tokens, and each has its own role:

access_token — the main "working pass." This is exactly what the application puts in the Authorization: Bearer ... header when calling the API. From it, the API understands who has come and what they are allowed to do.
id_token — answers the question "who exactly logged in" and is meant for the application itself, so it can show the user's name in the interface. It is not sent to the API.
refresh_token — needed to get a new access_token when the old one expires, without forcing the user to enter their password again. It is only sent back to Keycloak.

Don't worry if it hasn't all clicked yet — how tokens are built is a separate big topic (see the links at the end). What matters here is one idea: login and login verification are different roles of different systems, and the token is what connects them.

What Keycloak gives you out of the box

Keycloak's main value is a long list of ready-made capabilities that you would otherwise have to write and maintain yourself.

Single sign-on (SSO)

We already covered this above: the user logs in once, all connected applications recognize them without re-entering a password, and logging out of one means logging out of all. For the user it's convenience; for the company it's a single point of account management.

OAuth2 and OpenID Connect out of the box

These are two standard protocols — that is, the commonly accepted "rules of conversation" by which applications and Keycloak agree on login. Their value is that you don't have to invent your own format: Keycloak already speaks a common language that everyone understands.

OAuth2 answers the question "what is this user allowed to do" — that is, it's about access and permissions.
OpenID Connect (OIDC) is a layer on top of OAuth2 that adds an answer to the question "who is this" — that is, it's about identity and the fact of login itself. In practice, it is exactly OIDC that is used for login.

Why this matters in practice: because the protocols are standard, a React frontend, a mobile app, and a Spring backend all connect to Keycloak without any trouble — they all understand OAuth2/OIDC. You are not tied to a single technology and can change its parts independently.

User and role management

Keycloak has a ready-made administration section — a web interface where you can:

create and block users, reset their passwords;
create roles (for example, customer, seller, admin) and assign them to people;
group users together for convenience;
configure the password policy and a second factor (a one-time code).

And all of this — without a single line of your code. The roles you assigned to a person, Keycloak puts inside the token, and the application uses them to decide what the user is allowed to do. An important side benefit: users can be managed not by programmers but by administrators — through the interface, not by editing the database.

Federation is the ability to let into your application users who are stored not in Keycloak itself but somewhere else.

Social login — those "Log in with Google / GitHub / VK" buttons. Keycloak talks to these services by their rules itself, so you don't have to deal with each one separately.
Connecting a corporate directory — for example, LDAP or Active Directory. Employees log in with their work accounts, and Keycloak acts as an intermediary between your application and that directory.

The principle is the same as with everything else: Keycloak hides the variety of login sources behind itself and hands your application one clear token. The application doesn't care at all whether the person logged in by password, through Google, or with a corporate account — it sees only the token.

What Keycloak consists of

The structure is simple — essentially two parts plus a couple of concepts.

The Keycloak server — the application itself, which runs separately (often in a container). It shows login pages to users, checks passwords, and issues tokens. It needs its own database where accounts and settings are stored.
The admin console — a web interface for configuration. Through it you create users and roles and connect applications and social networks. Technically these are just pages of the same server.

And two concepts you will encounter in your first minutes of work:

Realm (you can think of it as an "area" or "space") — an isolated set of users, roles, and settings. One realm does not see another realm's users. This is handy when, on a single server, you need to separate, say, employees and external customers, or several independent projects.
Client — a record of a specific application that connects to Keycloak. Each frontend, backend, or mobile application is registered as a separate client within a realm.

The structure comes out like this: a server has one or more realms, each realm has its own users and roles and a list of clients (connected applications). More on realms, clients, and roles — in a separate article in the series.

How an application connects to Keycloak

Connecting is mostly configuration, not code. Let's show the general picture using a backend as an example. A Spring application only needs to be told where Keycloak lives, and it will learn to verify tokens on its own:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://keycloak.example.ru/realms/marketplace

Here issuer-uri is the address of your realm in Keycloak. From this address, Spring itself finds Keycloak's public keys (their set is called JWKS — a set of keys for verifying the signature) and then verifies each token's signature locally, without calling Keycloak on every request. The keys are downloaded once and kept in memory; if Keycloak rotates a key, Spring pulls in the new one automatically. This matters for speed: token verification does not depend on whether Keycloak is available right now.

The main idea stays the same: you don't need to write the login logic — it has already been written in Keycloak. Your job is to point to the address and trust the tokens it has signed.

When Keycloak is needed and when it's overkill

Keycloak is powerful, but not free in terms of effort: it's another service you have to run, update, and keep alive, plus a separate database for it. So the "adopt it or not" decision depends on scale.

Keycloak is justified when:

there are several applications and you want a single login for all of them (SSO);
you need social login, a second factor, or a connection to a corporate directory;
there are many users and roles, and administrators, not programmers, should manage them;
login security is critical and you don't want to write it yourself.

Keycloak is overkill when:

the project is small, there is one application, and there are dozens of users;
login is simple and there are no plans for social login or a second factor;
there are no resources to maintain another service and a database for it.

For a small project, a separate login server is unnecessary complexity: it's easier to get by with your framework's built-in tools. Keycloak starts to pay off when login stops being "a couple of screens" and becomes a self-contained task with its own requirements.

In short

Keycloak is a separate, ready-made login service (an IAM system) that takes password storage and authorization logic away from your application.
IAM is identity and access management (who this is and what they are allowed to do); SSO is single sign-on: one login for all applications.
The application does not check the password — only Keycloak sees the password. The application and API receive a signed token (usually a JWT) and verify its authenticity.
Keycloak sits off to the side as the single identity provider: user → application → Keycloak for tokens, then application → API with an Authorization: Bearer access_token header.
There are several tokens: access_token goes to the API, id_token is for the application itself, refresh_token goes only back to Keycloak.
Out of the box: SSO, the OAuth2/OIDC protocols, user and role management, social login, and connecting corporate directories (federation).
It consists of a server (issues tokens, needs a database) and an admin console. Inside: a realm is an isolated space, a client is a record of a connected application.
Connecting is mostly configuration (issuer-uri pointing at a realm), not code; tokens are verified locally using the JWKS keys.
Keycloak is justified with several applications, social login, a second factor, and many roles; for a small project with one simple login it is overkill.