Rewriting authentication logic in every application leaves duplicated credentials, password policies that drift apart and no single place from which to remove an access. An Identity and Access Management (IAM) server moves that logic outside the application: the application stops holding passwords and is left to verify tokens signed by an external authority. Keycloak — a WildFly community project, sponsored by Red Hat and released under the Apache 2.0 licence — is one Open Source implementation of this model; its first production release dates to September 2014 and the current version is 1.9.

Context and problem

In a company with ten internal applications, home-grown authentication becomes ten user tables, ten password-reset mechanisms, ten session formats. When an employee leaves, revoking their access depends on remembering all ten systems. The hard part is not writing the login code: it is keeping it consistent and auditable as the systems grow.

Moving identity into a dedicated service is a pattern described by public specifications: OAuth 2.0 (RFC 6749, October 2012) for delegated authorisation, OpenID Connect (Core 1.0, February 2014) for authentication built on top of OAuth 2.0, SAML 2.0 (OASIS, 2005) for talking to older enterprise systems. An IAM server, in concrete terms, is an implementation of these protocols, with an administration console and a user store sitting on top.

Architecture

Keycloak organises everything into realms: a realm is an isolated space, with its own users, roles, clients and signing keys. A client is a registered application that asks to authenticate; a single realm can serve dozens of clients sharing the same user base.

The typical flow with OpenID Connect is the Authorization Code Flow described in Core 1.0. The application never sees the password: it redirects the browser to Keycloak, which authenticates the user and returns an authorisation code. The application exchanges that code for an ID token and an access token, both signed JWTs. Verification on the application side reduces to checking the signature against the realm’s public key (exposed at a JWKS endpoint) and the claims — iss, aud, exp. No query to a shared session database, in the common case.

Applications talk to the server through official adapters for Java (JBoss/WildFly application servers, Tomcat, Jetty), for the browser via JavaScript, and for Node.js. An adapter wraps the redirect handling, the code exchange and token validation, so application code only ever sees an already-authenticated user. Where no adapter exists, the application speaks OIDC or SAML directly, because the endpoints are standard.

The default user store is a relational database, but federation moves the backing store onto external directories: LDAP and Active Directory providers are configured as sources, with user synchronisation and attribute mapping into the internal model. The user lives in LDAP; Keycloak keeps a local projection for roles and sessions.

The critical point

Between an IAM server and a block of login code, the practical difference is the centralised SSO session. With Single Sign-On the user authenticates once and reaches every client in the realm without logging in again; the flip side is Single Logout, which closes the session across all clients at once. Ten separate systems cannot do this: each holds its own idea of an “active session” and knows nothing of the others.

Identity brokering carries the pattern outward. Keycloak can act as an intermediary with third-party identity providers — Google, GitHub, or any OIDC/SAML provider — bringing incoming identities back into the realm’s model. The application sees a single token issuer (Keycloak) even when the real authentication happened elsewhere. The broker translates; the application stays tied to one authority.

The detail not to overlook concerns the signing keys. All of the system’s trust rests on the application verifying the token’s signature and claims correctly. A misconfigured adapter that accepts tokens without checking aud or exp, or that skips the signature check, throws away the centralisation: the server is sound, but real security is that of the weakest verifier.

Implications

Delegating identity to a dedicated server concentrates in one place the decisions that were previously scattered: password policies, token lifetimes, multi-factor authentication, revocation. The web administration console holds these controls per realm — clients, roles, mappers, sessions — without asking for application code changes when a policy changes. Adding MFA to every application in the realm becomes a configuration step, not a coordinated release across ten codebases.

There is an audit effect too. With authentication concentrated, “who signed in, when, from where, to what” is a question with a single source of answer. It is the opposite of the opening scenario, where the same question means querying ten logs in ten formats.

Limits

Centralisation creates a dependency point: if the identity server is unreachable, new authentications stop. Sessions already open with short-lived tokens hold until they expire, but login and refresh need the server to be reachable, and that forces treating it as a high-availability component, not an auxiliary service.

LDAP federation introduces a dual representation of the user, with the consistency problems of any synchronisation: what happens when an attribute changes in LDAP but the local projection is stale, or when a user is removed upstream. These are matters of configuration and sync interval, but they have to be decided explicitly.

As of today, finally, Keycloak does not yet appear among the OpenID Connect implementations certified by the OpenID Foundation. It implements OIDC and SAML to specification, and interoperability with other conforming providers is the norm, but where the requirements are strict it is worth verifying formal conformance certification against the specific version and flows in use.

Cover image: OAuth standard logo: the lowercase wordmark “OAuth” with a large stylized “O” on a light background — logo by Chris Messina, CC BY-SA 3.0 — https://commons.wikimedia.org/wiki/File:Oauth_logo.svg