Keycloak : moderniser l'authentification d'une application PHP legacy

Quand Hiflow m’a contacté pour mettre en place un IAM centralisé, l’objectif était clair : franchir une étape structurante sur la gestion des identités. Consolider l’authentification sur une brique dédiée, ouvrir la voie au SSO, au MFA, au Social Login - et poser des fondations solides pour accompagner la croissance de la plateforme.

Le contexte : une authentification à centraliser

L’architecture d’Hiflow repose sur plusieurs applications front développées en PHP et Backbone.js, qui consomment toutes une API PHP legacy. L’ensemble est hébergé sur Google Cloud.

Ma mission portait sur l’intégration de Keycloak sur une première application, pour poser les fondations de la solution. L’extension aux autres applications suivra dans un second temps.

Les objectifs définis avec Hiflow étaient les suivants :

Centraliser l’authentification sur une brique dédiée, partagée entre les applications
Activer le SSO : un seul login pour accéder à l’ensemble de la suite applicative
Ajouter le MFA : OTP / TOTP pour renforcer la sécurité des comptes
Intégrer le Social Login : connexion via un compte Google
Disposer d’une gestion centralisée des utilisateurs, des rôles et des politiques de mots de passe

Keycloak : une solution IAM open source éprouvée

Le marché des solutions d’IAM (Identity and Access Management) ne manque pas d’options. Auth0, Okta, FusionAuth - les offres SaaS sont nombreuses et bien packagées. Mais elles partagent un point commun : la dépendance à un fournisseur tiers, avec une facturation souvent indexée sur le nombre d’utilisateurs.

Hiflow avait déjà identifié Keycloak comme la solution adaptée à son contexte. Les raisons sont limpides :

Open source et maintenu par Red Hat (désormais sous l’égide de la CNCF - Cloud Native Computing Foundation)
Auto-hébergeable : pas de dépendance à un SaaS, les données restent chez vous
Protocoles standard : OpenID Connect, OAuth 2.0, SAML 2.0 - interopérabilité garantie
Fonctionnalités IAM complètes : SSO, MFA, Social Login, gestion des rôles, thèmes personnalisables, federation d’identités

Keycloak n’est pas un petit projet communautaire. C’est une brique d’infrastructure utilisée en production par des organisations de toutes tailles, avec une communauté active et une documentation solide.

Le flow d’authentification

Le flow implémenté est l’Authorization Code avec PKCE (Proof Key for Code Exchange) - le standard recommandé par OpenID Connect pour les applications web. L’utilisateur est redirigé vers Keycloak pour s’authentifier, puis revient sur l’application avec un token.

En pratique, deux modes de login coexistent :

La page de login Keycloak (redirect standard) : l’utilisateur est redirigé vers Keycloak, s’authentifie, puis revient sur l’application. C’est le mode recommandé - il supporte l’OTP (One-Time Password), le Google SSO et toutes les fonctionnalités avancées de Keycloak.
Le login direct sur l’application (Resource Owner Password Grant) : l’utilisateur saisit ses identifiants directement dans l’application, qui les transmet à Keycloak en arrière-plan. Plus simple en apparence, mais ce mode ne supporte pas l’OTP ni le Social Login. C’est un compromis accepté pour certains cas d’usage spécifiques.

L’intégration côté applications PHP

L’intégration de Keycloak dans les applications PHP d’Hiflow a nécessité le développement de deux briques principales.

La première : un service d’authentification intégré aux applications front. Ce service gère l’ensemble du flow OAuth 2.0 - la redirection vers Keycloak, la récupération du code d’autorisation, l’échange contre un token JWT, la gestion des sessions et le renouvellement automatique des tokens.

La seconde : un client PHP pour l’Admin API de Keycloak. Keycloak expose une API REST complète pour la gestion des utilisateurs. Ce client permet aux applications d’Hiflow de créer des comptes, mettre à jour des profils, déclencher des réinitialisations de mot de passe par email, et gérer l’attribution des rôles - le tout de manière centralisée via Keycloak, sans toucher directement à la base de données.

Le résultat : la logique d’authentification n’existe plus que dans Keycloak et dans le service d’authentification partagé. La première application est intégrée et sert de référence pour les suivantes.

Personnalisation du thème et des traductions

Keycloak propose un système de thèmes basé sur FreeMarker, le moteur de templates Java. Chaque page - login, inscription, réinitialisation de mot de passe, emails transactionnels - peut être personnalisée via des templates .ftl.

Pour Hiflow, j’ai développé un thème complet :

Page de login aux couleurs de la marque, cohérente avec l’identité visuelle des applications
Templates email personnalisés pour la réinitialisation de mot de passe, la vérification d’adresse email, et les notifications de sécurité
Traductions en 7 langues : chaque message, chaque libellé, chaque instruction est traduit et adapté au contexte métier d’Hiflow

Le thème FreeMarker offre un bon niveau de flexibilité. On peut modifier le HTML, le CSS, la structure des pages, tout en conservant la logique de sécurité de Keycloak sous le capot. L’utilisateur final ne sait pas qu’il est sur Keycloak - il voit une page de login qui ressemble à l’application qu’il utilise.

Plugins Java : des politiques de mots de passe sur mesure

Keycloak intègre nativement des règles de mots de passe classiques : longueur minimale, historique, expiration. Mais Hiflow avait des exigences spécifiques qui allaient au-delà.

J’ai développé des plugins Java en utilisant le système de SPI (Service Provider Interface) de Keycloak. Ces plugins s’intègrent directement dans le moteur de validation des mots de passe et appliquent les règles définies par le client :

Mots interdits : une liste de termes courants ou liés au domaine métier qui ne peuvent pas être utilisés comme mot de passe
Interdiction du prénom et du nom : le mot de passe ne peut pas contenir l’identité de l’utilisateur, même partiellement
Caractères spéciaux obligatoires : des règles de composition précises, définies selon les exigences de sécurité d’Hiflow

Ces plugins sont compilés en JAR et déployés dans Keycloak. Ils s’activent et se configurent via l’interface d’administration, sans redéploiement de l’application.

C’est un des atouts de Keycloak par rapport aux solutions SaaS : le système de SPI permet d’étendre le comportement du serveur sans forker le projet. On reste sur les rails tout en ajoutant des règles métier spécifiques.

Migration des utilisateurs existants

Impossible de déployer un nouvel IAM sans y intégrer les utilisateurs existants. Keycloak propose plusieurs stratégies d’import, mais dans le cas d’Hiflow, la contrainte était claire : les utilisateurs devaient pouvoir se connecter dès le lancement, sans avoir à recréer leur compte.

J’ai développé un script de migration qui importe les comptes existants dans Keycloak. Les profils, les rôles et les métadonnées sont transférés intégralement. La première connexion est accompagnée d’une invitation à définir un nouveau mot de passe conforme aux nouvelles politiques de sécurité - l’occasion pour chaque utilisateur de bénéficier immédiatement du SSO sur l’ensemble des applications.

Hébergement sur Clever Cloud

La stack d’Hiflow est hébergée sur Google Cloud. Pour Keycloak, le choix s’est porté sur l’addon managé Clever Cloud - du Keycloak as a Service. L’addon prend en charge l’infrastructure, la base de données PostgreSQL sous-jacente, et les mises à jour de Keycloak.

C’est un choix pragmatique : pas de Docker à gérer, pas de serveur à provisionner, pas de base de données à maintenir. On déploie les thèmes personnalisés et les plugins Java, Clever Cloud gère le reste. Keycloak tourne de manière isolée, indépendamment de l’infra applicative Google Cloud.

En production, la stabilité est au rendez-vous. L’addon absorbe le trafic d’authentification sans friction, et les mises à jour de sécurité de Keycloak sont appliquées par Clever Cloud.

Gains concrets

Après l’intégration de Keycloak, le bilan pour Hiflow :

SSO effectif : un seul login pour accéder aux applications. L’utilisateur se connecte une fois, c’est terminé.
MFA disponible : OTP / TOTP activable par l’utilisateur ou imposé par l’administrateur. Une couche de sécurité qui n’existait pas du tout auparavant.
Google SSO : connexion via un compte Google, configuré comme Identity Provider dans Keycloak. Moins de friction pour les utilisateurs qui le souhaitent.
Gestion centralisée : les utilisateurs, les rôles, les politiques de mots de passe - tout se gère depuis l’interface d’administration Keycloak. Plus besoin de modifier quatre bases de code pour changer une règle de sécurité.
Maintenance simplifiée : la logique d’authentification est sortie des applications. Les équipes de développement peuvent se concentrer sur le métier, pas sur la plomberie de sécurité.
Tokens JWT : l’API valide des tokens standard au lieu de gérer des sessions maison. Plus propre, plus scalable.

La base est posée. L’intégration sur la première application valide l’architecture et le processus - les autres applications pourront être raccordées à Keycloak en suivant le même modèle, sans repartir de zéro.

Vous avez une application PHP avec une authentification dispersée entre plusieurs briques, ou vous envisagez de centraliser votre gestion d’identité avec Keycloak ? Prenons contact - c’est exactement le type de mission sur lequel j’interviens.