In an enterprise environment, users don't live in your own database but in a single company directory, and they log in once when they sign into the system. Two old but resilient technologies usually stand behind this — LDAP and Kerberos. Let's look at what they are, why they exist, and how they connect to a modern OAuth2/JWT application through Keycloak.

LDAP — a user directory

LDAP (Lightweight Directory Access Protocol) is a protocol for accessing a directory: a tree-structured database of users, groups, and their attributes (login, email, department, group membership). The most widespread implementation is Microsoft's Active Directory; there are open ones too (OpenLDAP, FreeIPA).

The directory is the single source of truth about who is who in the company: an employee is created once and then appears in every system. An application asks the directory "does this user exist and is the password correct" and "which groups is the user in" — permissions are granted by group.

Kerberos — ticket-based SSO

Kerberos solves a different problem: single sign-on (SSO) within a domain. A user authenticates once when logging into their workstation and then accesses internal services without re-entering a password.

The idea is tickets. A center (in Active Directory this is the domain controller) issues the user an encrypted ticket, which the user silently uses to prove their identity to services. No password travels over the network. On the web, Kerberos is passed to the browser through the SPNEGO mechanism: the browser automatically presents the ticket to a site on the internal network — the user simply opens the page and is already logged in.

How to connect this to a modern application

Building LDAP and Kerberos support into every service is a bad idea. The modern approach is to place Keycloak (or another identity provider) between the corporate directory and the applications, letting it handle this integration:

  • LDAP federation. Keycloak connects to Active Directory/LDAP and sees corporate users as its own — without copying passwords. Login is verified against the directory, and outward Keycloak issues a standard OAuth2/OIDC token.
  • Kerberos / SPNEGO. Keycloak can accept a Kerberos ticket from the browser and immediately issue a token based on it — resulting in end-to-end corporate SSO with no login screen.

For your Spring service, this means that nothing beyond the familiar JWT needs to be known: the service still validates the token from Keycloak, and where Keycloak got the user from — a login form, LDAP, or a Kerberos ticket — is a detail hidden behind the identity provider.

In short

  • LDAP is the directory of company users and groups (most often Active Directory); the single source of truth for "who is who".
  • Kerberos is ticket-based single sign-on within a domain: one login, then no repeated password; on the web it's passed through SPNEGO.
  • Don't embed them into every service — place Keycloak between the directory and the applications.
  • Keycloak provides LDAP federation (it sees corporate users) and accepts Kerberos tickets, while issuing a standard OAuth2/JWT outward.
  • The application only needs to validate the JWT — the authentication source is hidden behind the identity provider.
  • What is Keycloak — why an identity provider is needed and what it takes on.
  • OAuth2 and OIDC — the standard protocols that Keycloak "translates" corporate login into.
  • Keycloak and Spring Security — how a service validates a token from Keycloak.