Beyond simply creating a client, these settings control how it actually behaves in a real integration.

Protocol mappers control exactly what information gets included in a token or SAML assertion for a given client — for example, adding a user’s department as a custom claim, or mapping a role into the token in a specific format.

A service account is a special, non-human identity tied to a confidential client, allowing an application itself (rather than a logged-in user) to authenticate and call other secured services directly.

Direct access grants allow a client to send a username and password straight to Keycloak’s token endpoint and receive a token back, without redirecting through the login page — useful for trusted first-party clients like mobile apps, but generally discouraged for third-party integrations.

Beyond a simple client secret, Keycloak supports stronger client authentication methods like signed JWT assertions, where the client proves its identity using a cryptographic signature instead of a shared secret.

Default client scopes are automatically included in every token issued to a client, while optional client scopes are only included if explicitly requested during login, giving finer control over what data different login requests return.

Fine-grained admin permissions let you grant specific administrators limited management rights — such as only being able to manage users in one particular group — instead of giving them full realm-admin access.

Keycloak’s login process is not fixed — it’s built from configurable steps that intermediate users learn to customize.

An authentication flow is a configurable, ordered sequence of authentication steps (called executions) that Keycloak runs through during login, browser registration, or password reset — administrators can rearrange, add, or remove steps.

The browser flow is the default authentication flow used when a user logs in through a web browser, typically including steps like cookie checking, username/password entry, and optional multi-factor steps.

Each step in a flow is marked as Required (must pass), Alternative (any one of several alternatives must pass), or Disabled (skipped), which together determine the overall logic of the login sequence.

A conditional flow only executes certain authentication steps if a specific condition is met — for example, only requiring a second factor if the user is logging in from an unrecognized device or location.

OTP (One-Time Password) two-factor authentication requires users to enter a time-based code, usually from an authenticator app, in addition to their password, adding a second layer of proof during login.

WebAuthn allows users to authenticate using hardware security keys or built-in device biometrics (like a fingerprint reader), configured as an authentication step within a flow, as a stronger alternative to OTP.

Identity brokering lets users log in through an external identity provider (such as a corporate Azure AD or another Keycloak realm) while Keycloak still issues the final tokens to your application, acting as a middleman.

Intermediate work often involves shaping exactly what’s inside a token and how long it stays valid.

Token lifespan settings control how long access tokens, refresh tokens, and ID tokens remain valid before expiring, balancing security (shorter is safer) against user convenience (longer means fewer re-authentications).

The audience claim identifies which client or service a token is intended for, and services should verify this claim so a token issued for one application can’t be reused to access a completely different one.

Token introspection is an API call a service can make to Keycloak to check whether a given token is still valid and retrieve its details, useful when a service can’t or doesn’t want to validate a token’s signature locally.

An offline token is a special type of refresh token that doesn’t expire due to normal session timeouts, intended for applications that need long-term, background access to a user’s resources (like a scheduled sync job).

Token exchange lets one service trade a token it has for a different token — for example, a backend service exchanging a user’s token for a differently-scoped token to call another internal service on the user’s behalf.

Beyond default claims, protocol mappers let you add fully custom claims to tokens — such as pulling a value from a user attribute or a group membership — tailoring the token’s contents to what your specific application needs.

Beyond simple roles, Keycloak offers a full authorization system for controlling access at the level of individual resources.

A resource server is a client configured to have its protected resources (like specific API endpoints or data records) managed by Keycloak’s authorization services, enabling fine-grained access control beyond simple roles.

A resource represents something being protected — such as a specific document, API endpoint, or data record — that policies and permissions will be applied to.

An authorization scope defines a specific action that can be performed on a resource, like “view” or “edit,” letting you grant different levels of access to the same resource for different users.

A policy defines a condition under which access should be granted — for example, “user must have the manager role” or “request must come from a specific time window” — policies are the building blocks combined into permissions.

A permission ties together a resource (or scope) with one or more policies, defining the actual access rule — for example, “the edit scope on the invoice resource requires the finance-team policy to pass.”

A policy enforcer is a component running on the resource server side that actually checks incoming requests against configured permissions, blocking or allowing access before the request reaches application logic.

Connecting Keycloak to other identity systems introduces its own set of configuration concepts.

This is the setup that tells Keycloak how to connect to an external login system — including its login URL, the protocol it uses (OIDC or SAML), and credentials Keycloak needs to communicate with it securely.

The first broker login flow runs the very first time a user logs in through an external identity provider, typically handling tasks like creating a matching local account or linking to an existing one.

Identity provider mappers translate information coming from an external identity provider (like a claim or attribute) into Keycloak’s own user attributes or role assignments during login.

Account linking connects an existing Keycloak user account to an external identity provider login, so the same person can log in either directly or through the external provider and land on the same account.

Just-in-time provisioning automatically creates a new local user account the first time someone successfully logs in through an external identity provider, avoiding the need to pre-create accounts manually.

Managing how long users stay logged in, and how securely, is a core intermediate operational responsibility.

SSO session idle defines how long a session can go without activity before expiring, while SSO session max sets an absolute upper limit on session length regardless of activity — both control how long a user stays logged in.

A client session tracks a user’s login state specifically within one client application, linked to (but distinct from) the broader SSO session that may span multiple applications.

Front-channel logout redirects the user’s browser to notify each application that they’ve logged out, while back-channel logout sends a direct server-to-server request instead, working even if the user’s browser is already closed.

Session revocation is the ability for an administrator to forcibly end a user’s active session (or all sessions), immediately invalidating their tokens, commonly used after a security incident or account compromise.

CORS (Cross-Origin Resource Sharing) settings on a client control which web origins are allowed to make requests to Keycloak’s endpoints from a browser, preventing unauthorized websites from silently interacting with your login system.

CSP headers, configurable in Keycloak’s security settings, restrict what content (scripts, styles, frames) is allowed to load on Keycloak’s login pages, reducing the risk of certain attacks like clickjacking.

When built-in behavior isn’t enough, Keycloak provides extension points for custom logic.

The SPI is Keycloak’s general extension mechanism, allowing developers to plug in custom Java code to change or add behavior in specific areas, like authentication, storage, or event handling.

A custom authenticator is a developer-written authentication step that can be added into a login flow, used when built-in steps (like password or OTP) don’t cover a specific business requirement.

A custom user storage provider lets Keycloak connect to a user database or system that isn’t natively supported (beyond built-in LDAP), by implementing the logic to look up and validate users from that external source.

The event listener SPI lets developers hook into Keycloak events (like login, logout, or registration) to trigger custom actions, such as sending data to an external audit system in real time.

A custom protocol mapper is developer-written logic for adding a specialized claim to tokens that isn’t covered by Keycloak’s built-in mapper types, such as computing a derived value from multiple user attributes.

Running Keycloak reliably in a real environment involves these operational concepts.

Clustering runs multiple Keycloak nodes together behind a load balancer, sharing session and cache data, so the system stays available even if one node fails and can handle more overall login traffic.

Infinispan is the caching technology Keycloak uses internally to store session and authentication data in memory, and in a clustered setup, it’s configured to replicate that cached data across nodes.

Realm export/import lets administrators save an entire realm’s configuration (clients, roles, and optionally users) to a file and load it into another Keycloak instance, useful for backups or moving between environments.

The Admin REST API allows programmatic management of realms, users, clients, and roles through HTTP calls, enabling automation of tasks that would otherwise require manually clicking through the admin console.

kcadm is a command-line tool for interacting with the Admin REST API, letting administrators script common tasks like creating users or updating client settings without writing custom code.

Use Authorization Services when access decisions need to consider specific resources or dynamic conditions (like ownership or time), rather than a broad yes/no permission that a simple role can express.

Generally no — since it requires the client to directly handle the user’s password, it should be reserved for trusted first-party applications, while third-party integrations should use the standard browser-based login redirect instead.

User federation connects Keycloak to a user store where Keycloak itself still performs the login (like LDAP), while identity brokering redirects the actual login process to an entirely separate identity provider, which then reports back to Keycloak.

Not necessarily — clustering adds operational complexity and is generally introduced once you need high availability or need to handle traffic beyond what a single Keycloak instance can comfortably serve.

A custom SPI centralizes logic (like a special authentication step or a custom claim) inside Keycloak itself, so every connected application benefits automatically, instead of duplicating that logic across each individual application.