Controlling who can access what means putting an identity provider into service and plugging in what already exists. This course has you install Keycloak on PostgreSQL, connect an application to it with OpenID Connect, federate an LDAP directory, then enforce strong authentication and automate the lifecycle of accounts. It is aimed at DevSecOps engineers, Platform Engineers and administrators who must plug a directory into an SSO. It starts from the vocabulary and aims at an identity provider that is fit to operate, not merely started.
What you will learn
- Tell apart identification, authentication and authorization, and choose an authorization model (DAC, MAC, RBAC, ABAC).
- Put Keycloak into service with a persistent PostgreSQL database, then create a realm, its users, groups and roles.
- Connect an application and an API to the identity provider with OAuth 2 and OpenID Connect, and validate the tokens received.
- Federate an LDAP directory and a partner identity provider, place SAML against OIDC, and troubleshoot an integration that fails.
- Enforce a second factor (TOTP) on the sensitive group, place WebAuthn and passkeys, which resist phishing, then govern the account lifecycle with SCIM, Workflows and the access review.
- Operate the whole: Keycloak in production, configuration as code, Kubernetes and Vault plugged into the realm.
Why does IAM deserve a course of its own?
Because, in a majority of breaches, a user makes a mistake or gets tricked, and access does the rest. In the Verizon 2024 Data Breach Investigations Report (DBIR, 2023 data), the non-malicious human element is present in 68% of confirmed breaches: a user's mistake or a successful social engineering attack, such as a credential stolen through phishing (report).
A second factor answers that risk. The study How effective is multifactor authentication at deterring cyberattacks? (Microsoft Research, 2023) covers Entra ID accounts (then named Azure Active Directory) showing suspicious activity: it measures that MFA reduces the risk of compromise of an account by 99.22% across that whole population (study). A well-deployed MFA therefore reduces risk in a measurable way.
IAM is not limited to the SSO of users. Machine identities (pipelines, services), the governance of rights over time and fine-grained authorization weigh just as much in an incident. The course covers human identity and the identity provider; workload identity appears through a lesson shared with the Secrets management course.
What prerequisites do you need before starting?
Every authentication flow is a series of HTTP redirects between services reached by name, protected by TLS and described in JSON. Without these basics, a login error remains an opaque message. The table says why each prerequisite matters here and where to learn it.
| Prerequisite | Why it matters here | Where to learn it |
|---|---|---|
| HTTP: redirects, cookies, headers | OAuth, OIDC and SAML are series of redirects | HTTP and HTTPS (in French) |
| TLS and certificates | Tokens are signed, the IdP is served over HTTPS | TLS diagnostics |
| DNS and hostnames | The hostname is the first Keycloak trap | Understanding DNS (in French) |
| JSON | Tokens, discovery document, APIs | Exploring an unknown JSON (in French) |
| Containers and Compose | All the exercises run in containers | Docker course (in French), Docker Compose (in French) |
| curl | Observe a flow, call an API | curl |
Terraform: init, plan, apply | The lesson on realm configuration as code and the level 2 challenge | The Terraform workflow (in French) |
| CI pipelines: jobs, workflows | The shared lesson on machine identity relies on GitHub Actions | What is a CI/CD pipeline?, GitHub Actions workflows |
Two modules also require background knowledge that their lessons do not repeat: the lesson on Keycloak and Kubernetes assumes the Kubernetes course (in French) and its RBAC (in French), and the module that plugs in the platform assumes the basics of Vault, covered in the Secrets management course.
Why does Keycloak seem so difficult?
Because it exposes all its power from the first page of its console. A
beginner who logs in sees realms, clients, scopes, mappers,
authentication flows and policies, without knowing which of these objects
concerns them. They click everywhere, then stumble on an error such as
Invalid parameter: redirect_uri without seeing that they missed a concept,
not a checkbox.
The order of the course starts from the opposite principle: you understand the protocol before configuring the tool. Keycloak is only an implementation of OAuth 2.0 and OpenID Connect; whoever does not know what an authorization code flow is cannot debug an OIDC client, however many tutorials they have followed. The vocabulary and the basics therefore come first, then a first identity provider runs quickly, and each flow is observed before it is detailed.
How is the course organized?
The course follows two levels: connect an application to an identity provider, then operate it and govern access. Keycloak is the reference tool throughout. The detailed program, with your progress lesson by lesson, is on the My path (in French) page; this section gives its thread, and the path page is authoritative for the titles and durations.
Level 1: connect an application to an identity provider
The first level leads from a vocabulary to a connected application. It starts with the module Understanding IAM, which lays down the IAM basics (in French) (identities, authentication, authorization), the authorization models (in French) with their limits, and token cryptography (in French) (signature, JWKS, certificates).
The module First identity provider puts Keycloak in your hands, with PostgreSQL as the database: concepts and architecture (in French), then installation with Docker (in French) on PostgreSQL, and finally the administration (in French) of realms, users, groups and roles. The module OAuth 2 and OpenID Connect explains delegated access with OAuth 2 (in French), authentication with OpenID Connect (in French) and the life of tokens and sessions (in French), then applies them: securing an application (in French), observing the token lifecycle (in French) and protecting an API (in French) with audience and scopes.
The module Federation and directories connects the identity provider to what already exists. It compares SAML 2.0 with OIDC, presents enterprise directories (in French) (LDAP, Active Directory, Kerberos), builds a lightweight directory with LLDAP (in French), federates it in Keycloak (in French), then delegates login to a partner identity provider (in French). It ends with the method for troubleshooting an integration (in French) with OIDC or SAML. The level closes with a challenge with no commands in sight: connecting an application and an API to Keycloak (in French), graded on observable evidence.
Level 2: operate and govern
The second level assumes a running identity provider and looks at what keeps it safe over time. The module Strong authentication covers MFA, WebAuthn and passkeys (in French), what resists phishing and what NIST SP 800-63B-4 requires, then enforces a second factor on the sensitive group only (in French) in Keycloak. The module Lifecycle and governance automates the arrival, mobility and departure of accounts with SCIM provisioning, then has Keycloak enforce them and runs the access review (in French).
The module Plugging in the platform carries workload identity, with the shared lesson Machine identity and workload identity, which keeps its course outline in the Secrets management course, then plugs Kubernetes and Vault into the realm (in French) through groups. The module Securing and operating covers threats, hardening, monitoring and incident response in IAM operational security (in French), then Keycloak in production (in French) (TLS proxy, backup, version upgrade, break-glass account), Keycloak on Kubernetes with the Operator and realm configuration as code (in French). A second challenge, operating and governing an identity provider (in French), ends the course.
authentik, optional
The module authentik (optional) is a discovery, not an alternative to follow in parallel. authentik is a second identity provider. It presents authentik's objects with applications, providers, flows and outposts, then the installation with Docker Compose (in French). It serves to compare a second approach once Keycloak is mastered; nothing in the rest of the course depends on it.
What the course does not cover
Honesty about the limits is worth more than an empty promise. Several neighboring topics have their own guide or fall outside the scope.
- Privileged access (PAM): Teleport (in French) and Vault's SSH certificates (in French) live in the access security section and the Secrets management course. Do not confuse them with the Linux PAM modules (in French).
- The IAM of cloud providers: the cloud IAM (in French) guide covers roles, policies and recertification on the cloud side.
- Keycloak's Java extensions (SPI, custom providers): a profession in itself.
- Keycloak's Authorization Services (UMA, fine-grained policies): powerful but rarely used, often replaced by authorization carried by the application.
- Applications without OIDC behind an authentication proxy: the original scoping planned to connect one, but the course does not cover it. The principle is only mentioned in the lesson on the platform, and each proxy has its own guide: authentication and ForwardAuth with Traefik, Pomerium (in French) and Dex (in French).
- Advanced high availability (Infinispan tuning, multi-site) goes beyond the scope of a general-purpose course.
To place identity within a services architecture, the page Identity and authorization (in French) of the Services architecture course gives the overview.
What are the three pillars of IAM?
IAM rests on three successive steps: identification, authentication, authorization. Identification is the declaration of who you are, through a unique identifier (username, email, badge), with no proof at all. Without it, it is impossible to personalize access or to trace each person's actions. The full vocabulary is laid down in the lesson IAM basics (in French).
Authentication checks that the declaration is true, thanks to one or more factors:
| Factor | What it is | Example |
|---|---|---|
| What you know | Secret knowledge | Password, PIN code |
| What you have | Physical object or secret held | FIDO2 key, TOTP application |
| What you are | Biometrics | Fingerprint, face |
Multi-factor authentication (MFA) combines several of these factors, for example a password and a one-time code from an application (TOTP). A FIDO2 key or a passkey additionally resists phishing, which SMS does not: exposed to SIM swapping, it is a fragile second factor.
Authorization finally determines what the authenticated user can see and do, according to least privilege. RBAC grants permissions by role (admin, editor, reader), ABAC by attributes (department, location, time). A developer can thus access the Git repository but not the production logs; an SRE has access to both. The lesson RBAC, ABAC and authorization policies (in French) details the models.
How has IAM evolved?
Today's tools stack up over three decades. The LDAP directory and the RBAC of the 1990s are still there, beneath the SSO and the MFA of the following years. The table places each building block in time, which explains why a real infrastructure almost always combines several generations.
| Period | Major advance |
|---|---|
| 1990s | LDAP centralizes identities, RBAC structures permissions |
| 2000s | SSO and federation (SAML) spread in the enterprise; MFA then becomes widespread for sensitive access |
| 2010s | OAuth 2 and OpenID Connect carry SSO to the web and APIs |
| Today | Passkeys, Zero Trust, continuous audit |
Which building block for which need?
IAM is not a product but a chain: the directory (source of identity), the IdP/SSO, provisioning, the authorization engine, then the enforcement of decisions (proxy, API gateway, application). The course stops at Keycloak, authentik, LLDAP and SCIM provisioning; the table also places neighboring tools, which you will meet in the enterprise.
| Main need | Tool family | Examples |
|---|---|---|
| OIDC/SAML SSO at scale | Full IdP | Keycloak (in French), authentik, ZITADEL |
| Protect web applications behind a reverse proxy | SSO portal | Authelia, LemonLDAP::NG, Pomerium (in French) |
| Minimal directory (lab, small infrastructure) | Lightweight LDAP | LLDAP (in French) |
| Enterprise directory, replication | LDAP | OpenLDAP, 389 Directory Server |
| Academic federations, pure SAML | SAML IdP/SP | Shibboleth, SimpleSAMLphp |
| Complex application rights (sharing, multi-tenant) | Fine-grained authorization (ReBAC, Zanzibar) | OpenFGA, SpiceDB, Ory Keto |
| Take authorization out of the code | Policy engine | OPA (in French), Cerbos |
| "Composable" CIAM (build your own product) | Headless building blocks | Ory Kratos and Hydra |
Read the first column before the tool names: an SSO portal in front of a reverse proxy and a full IdP do not solve the same problem, even if they both speak OIDC. An application that only speaks SAML immediately rules out the tools limited to OIDC.
Key takeaways
- Identification is not authentication: declaring your identity is not proving it.
- MFA greatly reduces the risk of an account being compromised; SMS is a fragile second factor, while a FIDO2 key or a passkey resists phishing.
- Authorization follows least privilege: grant only the strictly necessary rights.
- IAM is a chain: directory, IdP/SSO, provisioning, authorization engine, enforcement of decisions.
- The course has two levels: connect an application to an IdP, then operate and govern access, with Keycloak as the reference.
- authentik is an optional discovery module; privileged access and cloud IAM have their own guides.