Keycloak, OAuth2, and Identity Providers
Keycloak is an open-source identity and access management solution. It acts as an OAuth2/OpenID Connect server and federates external identity providers such as LDAP, Active Directory, and social logins.
Identity Providers
An identity provider (IdP) is a system that creates, maintains, and manages identity information, and provides authentication to other services. It validates the identity of users on behalf of applications.
Types of identity provider:
- External IdP: Google, GitHub, or any OpenID Connect-compatible service. The user authenticates with their existing account.
- Internal IdP: LDAP, Active Directory, or a custom database. The organisation controls the user store.
Keycloak supports both. It acts as a broker: applications trust Keycloak, and Keycloak trusts one or more identity providers.
OpenID Connect and SAML 2.0
OpenID Connect (OIDC) is an identity layer built on top of OAuth2. It allows clients to verify the identity of the end-user based on authentication performed by an authorisation server, and to obtain basic profile information. It uses JWTs (JSON Web Tokens) as identity tokens.
SAML 2.0 is an XML-based standard for exchanging authentication and authorisation data between parties. Older than OIDC, more common in enterprise environments. Keycloak supports both as an identity provider and as a service provider for SAML 2.0 flows.
User Federation
User federation connects an external user store to Keycloak so that users are managed in the external system but authenticated through Keycloak. Common use cases:
- LDAP directory: users exist in an existing LDAP server. Keycloak reads and optionally writes back to LDAP.
- Active Directory: same pattern, common in Windows enterprise environments.
Users do not need to be manually migrated. Keycloak queries the external store at login time.
Public vs Confidential Clients
OAuth2 distinguishes between client types based on their ability to keep secrets:
| Client type | Description | Examples |
|---|---|---|
| Public | Cannot securely store a client secret | Browser SPAs, mobile apps |
| Confidential | Can securely store a client secret | Backend services, server-side apps |
Public clients use flows such as Authorization Code with PKCE (Proof Key for Code Exchange) to avoid sending a client secret. Confidential clients use the standard Authorization Code flow or Client Credentials flow.
Server-to-server connections use confidential clients because the secret never leaves the server.
How Keycloak Works
The flow for an API protected by Keycloak:
User → Authenticate with Keycloak → Access token issued
Client → API request with Access token in Authorization header
API → Validate token via Keycloak OAuth middleware
API → Return responseThe access token is a signed JWT. The API validates the signature against Keycloak’s public key without calling Keycloak on every request. Keycloak only needs to be called when the token expires and a refresh is needed.
LDAP and Active Directory Integration
LDAP (Lightweight Directory Access Protocol) and Active Directory are directory services that store user accounts, groups, and organisational data. Keycloak connects to them as a user federation provider.
When a user logs in through Keycloak with LDAP federation:
- Keycloak receives the credentials.
- It forwards authentication to the LDAP server.
- On success, it issues its own access and ID tokens.
- The application works entirely with Keycloak tokens, unaware of LDAP.
This decouples the application from the directory technology and allows centralised session management, role mapping, and multi-factor authentication through Keycloak regardless of the backend identity store.