Configurer le SSO avec Keycloak : le guide

Pour une nouvelle intégration, mieux vaut choisir OpenID Connect lorsque l’application le prend en charge ; SAML 2.0 reste adapté aux logiciels existants ou aux produits qui ne proposent que ce protocole. Il faut ensuite renseigner les URI de redirection OIDC ou les points de réception SAML, puis relier l’application aux points d’accès du royaume.

Pour une Direction des Systèmes d’Information (DSI), le SSO résout un besoin quotidien : ouvrir l’accès à tout un parc d’applications à partir d’une seule connexion, sans disperser la sécurité. Keycloak, solution open source de gestion des identités et des accès (Identity and Access Management, ou IAM), y répond en centralisant l’authentification.

Keycloak, fournisseur d’identité central

Keycloak se positionne entre les applications et leurs utilisateurs : ceux-ci s’authentifient auprès de lui et, tant que leur session SSO reste valide, peuvent accéder aux applications raccordées sans ressaisir leurs identifiants. Chaque application fait confiance aux informations d’authentification transmises par Keycloak pour établir sa propre session. Ce fonctionnement est celui d’un fournisseur d’identité (Identity Provider, ou IdP).

Centraliser la connexion présente un intérêt de sécurité concret : d’après l’ENI S A Threat Landscape 2025 (rapport annuel de l’Agence de l’Union européenne pour la cybersécurité), le phishing représente environ 60 % des méthodes d’intrusion initiale observées dans les incidents étudiés. Avec Keycloak, les politiques d’authentification multifacteur peuvent être appliquées au point de connexion commun des applications raccordées. Toutes les formes de MFA n’offrent cependant pas la même protection face au phishing : les passkeys et WebAuthn y résistent par conception, car la clé d’authentification est liée au domaine pour lequel elle a été créée.

Chaque application conserve sa propre session. Dans une intégration OIDC complète, l’application vérifie l’état de la session auprès de Keycloak et peut donc prendre en compte sa fermeture. Certaines applications se limitent toutefois à vérifier localement la signature et la durée de validité du jeton JWT. Dans ce cas, un jeton encore valide peut continuer à être accepté après la fermeture de la session Keycloak ; il s’agit alors d’une authentification fondée sur le JWT plutôt que d’une gestion complète de la session OIDC.

Keycloak prend en charge OpenID Connect (OIDC) et SAML 2.0. Dans un même royaume, des applications récentes et des logiciels existants peuvent ainsi partager la même authentification unique.

Les notions à connaître avant de configurer

Trois objets structurent toute configuration SSO dans Keycloak :

Le royaume (realm)

Un tenant d’administration et de sécurité isolé. Il regroupe les utilisateurs, leurs informations d’identification, les rôles, les groupes, les applications déclarées comme clients et les politiques d’authentification. Chaque royaume gère indépendamment ses utilisateurs et ses applications. Pour un même système d’information, un seul royaume métier suffit généralement.

Le client

La représentation, à l’intérieur du royaume, d’une application qui délègue son authentification à Keycloak. Chaque application à raccorder dispose du sien.

Le protocole

OpenID Connect ou SAML 2.0, choisi lors de la création du client. Un client OIDC et un client SAML ont des configurations différentes, imposées par leur protocole respectif. Ce choix ne peut pas être modifié par la suite : changer de protocole nécessite de créer un nouveau client.

Configurer le SSO avec Keycloak, étape par étape

01

01 Accéder à la console d’administration

Dans la Console Clever Cloud, ouvrez le tableau de bord de votre service, puis cliquez sur Open Keycloak. Les identifiants initiaux figurent dans la section Access. Ils sont également disponibles dans l’application Java à travers les variables CC_KEYCLOAK_ADMIN et CC_KEYCLOAK_ADMIN_DEFAULT_PASSWORD. Lors de la première connexion, Keycloak vous demande de remplacer le mot de passe temporaire.
02

02 Choisir ou créer un royaume

Créez impérativement un royaume distinct de master, soit avec la variable CC_KEYCLOAK_REALMS, soit depuis l’interface d’administration. Le royaume master doit rester un accès administratif de secours, ou break-glass, utilisé lorsqu’une mauvaise configuration rend le royaume métier indisponible. N’y rattachez aucune application métier. Pour un même système d’information, conservez un seul royaume métier : plusieurs royaumes ne se justifient que lorsque les populations d’utilisateurs sont entièrement indépendantes et ne partagent aucune application. Dans le cas contraire, chaque application doit intégrer plusieurs parcours SSO, ce qui complique inutilement son fonctionnement.
03

03 Déclarer l’application comme client

Dans Clients, Keycloak affiche déjà plusieurs clients intégrés, utilisés pour ses fonctions d’administration et de gestion des comptes. Laissez-les inchangés. Cliquez sur Create client pour créer un client dédié à l’application, puis choisissez OpenID Connect ou SAML. Le protocole fait partie de la définition du client et ne pourra pas être changé ensuite. Si une application SAML fournit ses métadonnées, vous pouvez également utiliser Import client.
04

04 Pour une application OpenID Connect

Configurez précisément ses URI de redirection autorisées et, si elle communique avec Keycloak depuis le navigateur, ses origines web. Activez le flux Authorization Code avec l’option Standard flow. Activez Client authentication pour une application serveur capable de protéger un secret. Pour une application mobile ou exécutée entièrement dans le navigateur, laissez cette option désactivée et imposez PKCE avec la méthode S256.
05

05 Pour une application SAML 2.0

Importez de préférence les métadonnées fournies par le fournisseur de services (Service Provider, ou SP). Vérifiez ensuite que le Client ID correspond à son identifiant d’entité, ainsi que l’URL de réception des assertions (ACS), les paramètres de signature, le format du NameID et les attributs attendus.

Notre article SAML 2.0 : à quoi sert le protocole ? explique le fonctionnement du protocole et l’échange de métadonnées.
06

06 Configurer l’application

En OIDC, indiquez l’identifiant du client et, seulement si Client authentication est activée, son secret. Selon la bibliothèque utilisée, fournissez l’URL du royaume, https:///realms/, ou son URL de découverte : https:///realms//.well-known/openid-configuration. En SAML, importez les métadonnées du fournisseur d’identité Keycloak depuis https:///realms//protocol/saml/descriptor. Après l’authentification, l’application valide les informations reçues avant d’établir sa propre session.
07

07 Tester le parcours complet

Connectez-vous avec un utilisateur autorisé et vérifiez les données transmises à l’application. Si des restrictions d’accès ont été configurées, contrôlez également le refus d’un utilisateur dépourvu des droits requis. Pour tester le SSO lui-même, ouvrez ensuite une seconde application raccordée au même royaume : elle doit reconnaître la session Keycloak sans demander de nouveau les identifiants. Terminez par un test de déconnexion afin de vérifier sa propagation selon la configuration des applications.

La documentation Keycloak de Clever Cloud détaille l’accès au service, la gestion des royaumes, le filtrage des adresses IP, les déploiements en mode Secured Multi Instances et le suivi des métriques. Pour les réglages propres aux clients OIDC et SAML, consultez également la documentation d’administration de Keycloak.

Pour voir le déploiement et l’interface en pratique, retrouvez la démonstration vidéo sur notre page Keycloak as a Service.

SSO en OIDC ou en SAML 2.0 : lequel choisir ?

Pour un nouveau développement, privilégiez OpenID Connect lorsque l’application le prend en charge. Conservez SAML 2.0 pour les applications dont l’intégration repose déjà sur ce protocole ou qui ne prennent pas en charge OIDC :

OpenID Connect pour authentifier les utilisateurs des applications web et mobiles récentes ; OAuth 2.0 et ses jetons d’accès servent à contrôler l’accès aux API.
SAML 2.0 pour les applications existantes et les logiciels d’entreprise qui ne proposent pas d’intégration OIDC.

Keycloak prend en charge les deux protocoles dans un même royaume. Des applications OIDC et SAML peuvent ainsi partager la même authentification unique.

Configurer le SSO sur un Keycloak managé

La configuration du SSO ne représente qu’une partie du travail : un serveur Keycloak doit ensuite être maintenu, mis à jour, supervisé et sauvegardé. C’est cette charge d’exploitation qu’une offre managée absorbe.

Keycloak as a Service, l’offre de Clever Cloud opérée avec l’expertise de Please Open It, déploie un Keycloak infogéré et hébergé en France en quelques clics. Les équipes conservent la maîtrise de l’ensemble des réglages (royaumes, clients et protocoles) et confient l’exploitation de l’infrastructure à Clever Cloud : mises à jour continues, monitoring intégré et sauvegardes régulières. Lorsque le service est déployé en mode clusterisé Secured Multi-Instances, plusieurs nœuds assurent la répartition de charge et renforcent la continuité de service. Indépendamment de cette architecture, le SLA de 99,99 %, l’astreinte téléphonique 24/7 et les délais d’intervention et de résolution garantis relèvent de l’offre Premium pour les services éligibles. L’import et l’export de royaumes facilitent la reprise d’une instance existante. Enfin, pour protéger une application qui n’intègre pas nativement l’authentification, un proxy d’authentification comme OAuth2-Proxy place la connexion en amont, sans modifier le code applicatif.

« Keycloak est un produit Red Hat, mais Red Hat ne fournit pas de version LTS de Keycloak en open source et les correctifs de sécurité ne sont pas rétroportés : il est donc primordial de rester sur la dernière version, ce que facilite largement un déploiement Keycloak as a Service sur Clever Cloud. Un seul royaume, distinct de master, suffit bien souvent ; plusieurs ne se justifient que lorsque les populations d’utilisateurs sont entièrement indépendantes, sans application commune ou avec des déploiements distincts. Keycloak rend enfin l’ajout de facteurs d’authentification indépendant des applications, ce qui permet de proposer les facteurs les plus modernes à toutes les applications intégrées. »

— Loïc Mercier des Rochettes, Co-fondateur et CTO chez Please Open It

Vous évaluez une solution IAM ? Notre checklist 11 questions à poser avant de choisir une solution de gestion des identités réunit les critères à vérifier avant de vous engager.

FAQ

Keycloak permet-il de faire du SSO ?

Oui. Keycloak est une solution open source de gestion des identités qui agit comme fournisseur d’identité central : les applications lui délèguent la connexion et l’utilisateur ne s’authentifie qu’une fois. Il prend en charge OpenID Connect et SAML 2.0.

Faut-il utiliser OIDC ou SAML pour le SSO avec Keycloak ?

Les deux conviennent. OpenID Connect vise les applications web récentes, mobiles et les API ; SAML 2.0 reste la référence pour l’existant applicatif d’entreprise. Keycloak pilote les deux protocoles en parallèle.

Comment connecter une application à Keycloak ?

On crée un client dans le royaume concerné, puis on le configure selon le protocole utilisé par l’application. En OpenID Connect, on renseigne notamment ses URL de redirection et on lui fournit l’identifiant du client, l’URL de découverte du royaume et, uniquement si elle peut le protéger, un secret. En SAML 2.0, on configure l’identifiant de l’application, son URL de réception des assertions et l’échange des métadonnées avec Keycloak.

Doit-on héberger Keycloak soi-même pour mettre en place le SSO ?

Non. Un Keycloak auto-hébergé impose de gérer installation, mises à jour, sécurité et disponibilité. Une offre managée, comme Keycloak as a Service de Clever Cloud, prend en charge cette exploitation ; les équipes restent responsables des clients, des utilisateurs, des droits et des politiques d’authentification.

Peut-on sécuriser une application existante sans modifier son code ?

Oui. Un proxy d’authentification comme OAuth2-Proxy, relié à Keycloak, peut imposer une connexion avant de transmettre les requêtes à l’application, sans modifier son code. Cette approche convient notamment aux back-offices et aux outils internes qui n’intègrent pas d’authentification, à condition que l’application ne soit pas accessible directement en contournant le proxy. Les éventuelles règles d’autorisation propres à l’application restent à définir.

Configurer le SSO avec Keycloak