Open source SSO avec MFA et WebAuthn : mise en place pas à pas

Choisir l’architecture open source : IAM, protocole SSO et stratégie MFA WebAuthn

Pour mettre en place un SSO open source avec MFA et WebAuthn, le point de départ est architectural. Vous devez décider (1) quel IAM auto hébergé servira l’identité, (2) quel protocole de SSO vous utiliserez pour connecter vos applications, et (3) comment vous allez orchestrer la MFA avec WebAuthn sans créer de friction utilisateur ni de failles de sécurité.

1) IAM open source auto hébergé : choisir selon vos besoins SSO

En pratique, vous cherchez un IAM capable de gérer des identités, des sessions, des politiques de sécurité et des facteurs d’authentification. Pour un SSO moderne, les briques les plus courantes sont :

• OIDC (OpenID Connect) pour les applications web et API modernes
• SAML 2.0 pour les applications legacy ou les environnements d’entreprise
• MFA avec WebAuthn (passkeys, clés de sécurité FIDO2)

Un bon choix d’architecture consiste à partir d’un IAM open source auto hébergé, puis à définir vos politiques MFA (par groupe, par application, par risque). Si vous hésitez entre plusieurs options, ce guide vous aide à cadrer le choix et la mise en place : Open source IAM auto hébergé pour SSO moderne : guide pratique (Kerberos, SAML, OIDC).

2) Protocole SSO : OIDC en priorité, SAML si nécessaire

• OIDC est souvent le meilleur point de départ pour les applications récentes (SPA, backends, microservices). Il s’appuie sur OAuth 2.0 et ajoute une couche d’identité (ID Token, claims).
• SAML reste utile pour des outils d’entreprise, des suites SaaS historiques, ou des connecteurs déjà en place.

Un critère concret : si vos applications sont majoritairement en JavaScript moderne, Java, .NET, Go ou Node.js, OIDC réduit généralement la complexité d’intégration. Si vous avez des “gros comptes” legacy (ERP, outils internes plus anciens), prévoyez une stratégie hybride.

3) Stratégie MFA WebAuthn : passkeys, clés et politiques

WebAuthn vous permet d’utiliser des clés de sécurité ou des passkeys (selon les navigateurs et l’écosystème). L’objectif est de :

• exiger WebAuthn pour les rôles sensibles (admin, accès production, console IAM)
• autoriser une transition progressive (par exemple, d’abord WebAuthn en “enrôlement”, puis en “obligation”)
• limiter les contournements (pas de fallback faible)

Exemple de politique réaliste :

• Groupe “Admins” : WebAuthn obligatoire, au moins 1 authentificateur enregistré
• Groupe “Employés” : WebAuthn obligatoire à partir de X jours sans authentification MFA, ou uniquement pour les connexions depuis des pays non habituels (si vous avez une couche de détection)
• Applications sensibles : step-up authentication (demander une MFA fraîche)

Enfin, si vous souhaitez sécuriser en profondeur le flux d’authentification et la partie OAuth, ce guide sur un serveur OAuth2 self-hosted est un excellent complément : OAuth2 serveur self-hosted pour SSO sécurisé : guide complet et bonnes pratiques. Il vous aidera à éviter les erreurs classiques sur les tokens, les scopes et la gestion des sessions.

Mise en place pas à pas : déployer l’IAM, activer WebAuthn et configurer l’authentification

Une mise en place réussie repose sur une séquence claire. L’erreur fréquente consiste à activer WebAuthn “au dernier moment” alors que l’architecture de sessions, de domaines, de redirections et de politiques MFA doit être pensée dès le départ. Ci-dessous, une procédure pas à pas, avec des points de contrôle concrets.

Étape 1 : préparer l’environnement (DNS, TLS, domaines)

Avant de configurer l’IAM :

1. Assurez-vous que le domaine de votre IAM est résolu (exemple : auth.votre-domaine.tld).
2. Configurez TLS avec un certificat valide (Let’s Encrypt ou équivalent).
3. Vérifiez que les URLs de callback et de redirection sont cohérentes.

Point de contrôle chiffré : testez au moins 3 scénarios de navigation avant d’activer WebAuthn :

• connexion depuis un poste “standard”
• connexion depuis un poste “nouveau navigateur” (profil vierge)
• connexion depuis un navigateur en mode privé

Ces tests révèlent rapidement les problèmes de cookies, de SameSite, ou de redirections.

Étape 2 : déployer l’IAM (auto hébergement)

Déployez l’IAM avec une configuration reproductible (Docker Compose, Kubernetes, ou VM). Les éléments à prévoir :

• base de données (PostgreSQL est souvent privilégié)
• stockage des métadonnées d’authentification
• configuration des clients OIDC et des éventuels services SAML

Exemple de clients OIDC à créer :

• client “web-app” : redirect URI https://app.votre-domaine.tld/auth/callback
• client “api” : si vous utilisez un modèle avec tokens pour API, définissez scopes et audience

Bonnes pratiques de sécurité dès le départ :

• limiter les comptes de service
• activer la journalisation (audit logs)
• définir des politiques MFA par défaut

Étape 3 : activer WebAuthn (FIDO2, passkeys, authentificateurs)

L’activation WebAuthn implique généralement :

• configurer les paramètres de domaine (RP ID, origin)
• activer les méthodes d’authentification (clés de sécurité, plateformes)
• définir les exigences d’enrôlement

Concrètement, vous allez :

1. Créer une politique “WebAuthn requis” pour certains groupes.
2. Autoriser l’enrôlement des authentificateurs.
3. Tester l’enrôlement sur au moins 2 types de dispositifs (par exemple, une clé USB FIDO2 et une passkey sur mobile).

Point de contrôle : vérifiez que l’authentification fonctionne avec :

• navigateur desktop (Chrome/Edge/Firefox selon votre parc)
• navigateur mobile (iOS/Android)
• au moins un mode “nouveau profil” pour valider l’absence de dépendance à des cookies persistants

Étape 4 : configurer l’authentification et les sessions

Une fois WebAuthn activé, configurez :

• la durée de session (et le mécanisme de renouvellement)
• la politique de “step-up” MFA pour les actions sensibles
• la gestion des déconnexions (logout front-channel et back-channel si disponible)

Exemple de politique de session :

• session interactive : 8 heures
• renouvellement : via refresh token (si votre IAM le permet) avec rotation
• step-up : re-demander WebAuthn pour les actions “admin” ou “export de données”

Étape 5 : tests de bout en bout et durcissement

Avant de mettre en production :

• testez la connexion sur toutes les applications cibles
• vérifiez les redirections OIDC (state, nonce)
• contrôlez les logs d’audit

Et surtout, évitez les erreurs de sécurité fréquentes. Pour un checklist utile, lisez : 3 erreurs de sécurité que font tous les développeurs débutants (et comment les éviter). Même si votre projet est “IAM-first”, ces pièges (mauvaise validation des paramètres, gestion laxiste des tokens, absence de contrôle d’accès fin) se retrouvent souvent dans l’intégration SSO.

Intégrer le SSO dans vos applications : OIDC/SAML, gestion des sessions et bonnes pratiques sécurité

Une fois l’IAM opérationnel et WebAuthn activé, l’étape la plus délicate est l’intégration côté applications. Vous devez garantir que le SSO est cohérent, que les sessions sont correctement gérées, et que la sécurité ne se dégrade pas au moment où les tokens circulent entre front, back et services.

1) Intégration OIDC : modèle recommandé pour les applications modernes

Pour une application web moderne, le flux typique est :

1. L’utilisateur clique “Se connecter”
2. Redirection vers l’IAM (authorization endpoint)
3. Retour sur votre application (redirect URI)
4. Échange du code contre des tokens (token endpoint)
5. Validation des tokens et création d’une session applicative

Points techniques à vérifier :

• state et nonce : indispensables pour prévenir les attaques CSRF et replay
• validation de la signature JWT (via JWKS)
• vérification des claims : iss, aud, exp, iat
• gestion stricte des erreurs (pas de “fallback” silencieux)

Exemple concret de mapping de claims :

• sub : identifiant stable
• email : utilisé pour l’affichage
• groups ou roles : utilisé pour autoriser des routes

Bonnes pratiques :

• ne vous fiez pas uniquement au claim côté front
• appliquez l’autorisation côté serveur (RBAC ou ABAC)
• limitez les scopes demandés (principe du moindre privilège)

2) Intégration SAML : cas des applications legacy

Pour les applications qui ne supportent pas OIDC, SAML reste pertinent. L’intégration implique :

• configuration de l’Entity ID (SP)
• ACS URL (Assertion Consumer Service)
• certificat de signature côté IAM
• mapping des attributs (email, nom, rôles)

Point de contrôle : testez le cycle complet “login puis logout” si votre application le permet. Sinon, prévoyez une stratégie de déconnexion applicative qui invalide la session locale, même si la session SSO persiste.

3) Gestion des sessions : éviter les incohérences

Le piège classique est d’avoir :

• une session IAM valide
• une session applicative expirée
• ou l’inverse

Pour éviter cela :

• implémentez un mécanisme de “session check” au moment des requêtes sensibles
• utilisez des cookies sécurisés (HttpOnly, Secure, SameSite adapté)
• mettez en place un renouvellement contrôlé (selon votre modèle)

Exemple de stratégie “cohérente” :

• session applicative : 30 minutes
• si expirée, déclencher une redirection vers l’IAM
• si l’utilisateur a une session IAM active, le SSO réauthentifie sans friction
• si WebAuthn est requis (step-up), l’IAM déclenche la MFA

4) MFA WebAuthn côté applications : comment gérer le “step-up”

Même si WebAuthn est géré par l’IAM, votre application doit être prête à :

• rediriger vers l’IAM pour une authentification renforcée
• gérer des erreurs et retours partiels
• conserver l’intention utilisateur (URL cible) via un paramètre “returnTo” sécurisé

Exemple concret :

• l’utilisateur tente d’accéder à /admin/export
• votre backend détecte que la MFA récente n’est pas présente (selon claim ou indicateur)
• il déclenche une redirection vers l’IAM avec une exigence de niveau d’authentification
• après succès, l’utilisateur revient sur /admin/export

5) Sécurité : checklist opérationnelle (à appliquer avant production)

Voici une checklist pragmatique, orientée “risques réels” :

Enfin, gardez en tête que WebAuthn n’est pas une “option cosmétique”. C’est un pilier de sécurité. Si vous ajoutez des intégrations OIDC/SAML sans discipline (claims mal validés, cookies mal configurés, logout incomplet), vous annulez une partie des bénéfices.

En résumé, l’architecture la plus robuste consiste à :

• centraliser l’identité et la MFA dans l’IAM
• intégrer OIDC en priorité, SAML pour le legacy
• valider strictement les tokens
• gérer les sessions de manière cohérente
• appliquer des politiques MFA et des step-up pour les actions sensibles

Si vous suivez ces principes, votre SSO open source avec MFA et WebAuthn devient un socle fiable pour vos applications, tout en restant maîtrisé, audit-able et évolutif.