Un administrateur utilise encore un mot de passe seul. Les salariés mémorisent cinq identifiants pour cinq outils. Un client professionnel quitte son entreprise mais conserve un compte local sur le portail. Ces problèmes sont souvent regroupés sous une même réponse — « mettre du SSO » — alors qu’ils relèvent de risques et de responsabilités différents.
Le MFA renforce la preuve présentée lors de l’authentification. Le SSO réduit le nombre de connexions distinctes dans un ensemble de services. La fédération permet à une application de faire confiance à une identité authentifiée par une autre organisation. Les briques peuvent se combiner, mais aucune ne remplace le contrôle d’autorisation ni le cycle de vie des comptes.
Le vrai enjeu est de choisir la première protection qui réduit un risque observable sans déplacer le blocage vers la récupération, le support ou la disponibilité. Pour une application web métier sur mesure, la décision dépend des populations, de la sensibilité des actions, de la maîtrise des postes et de la capacité à exploiter un fournisseur d’identité.
Contre-intuitivement, fédérer tous les comptes dès le départ peut augmenter le risque si les attributs entrants créent des droits trop larges ou si aucune procédure de secours n’existe. Les taux d’adoption, durées de session et seuils d’alerte doivent être établis localement depuis les usages et menaces ; ils ne constituent pas des valeurs universelles.
Distinguer MFA, SSO et fédération
Le MFA demande au moins deux facteurs issus de catégories distinctes ou utilise un authentificateur multifactoriel. Posséder deux mots de passe n’est pas du MFA. Son objectif est de réduire la probabilité qu’un secret volé suffise à ouvrir une session. Il ne garantit pas que l’utilisateur possède le bon rôle une fois connecté.
Le SSO décrit une expérience : une authentification donne accès à plusieurs services liés. La fédération décrit une relation de confiance et des échanges de protocoles entre un fournisseur d’identité et une application. Un SSO interne peut reposer sur une fédération, mais les termes ne sont pas interchangeables. Cette distinction permet de nommer l’owner de l’identité et le système qui porte la décision finale.
Partir des menaces et des populations
L’équipe classe salariés, administrateurs, prestataires, clients individuels, partenaires et comptes techniques. Pour chaque population, elle observe vol de mot de passe, phishing, appareil partagé, départ non révoqué, fraude au support et indisponibilité du fournisseur. Elle sépare lecture courante, export sensible, gestion des droits et opération financière.
Un signal faible apparaît lorsque le support réinitialise régulièrement des mots de passe, lorsque plusieurs comptes utilisent la même adresse ou lorsqu’un départ reste traité par courriel. Ces faits orientent l’ordre : MFA sur les comptes privilégiés, centralisation des salariés, fédération d’un grand partenaire ou nettoyage du cycle de vie. Une technologie ne doit pas masquer un processus d’identité non possédé.
Prioriser le MFA sur les comptes exposés
Le MFA devient prioritaire quand une compromission donne accès à des données sensibles, à une administration, à des exports ou à une action difficilement réversible. Les administrateurs, agents support avec vue transverse et personnes capables d’attribuer des droits forment souvent le premier périmètre. L’exposition externe et la valeur de la session comptent davantage que le nombre total d’utilisateurs.
Une montée en assurance peut aussi être déclenchée à l’action. Une consultation courante conserve la session, mais un changement de coordonnées bancaires ou la création d’un administrateur exige une authentification récente et forte. Cette approche réduit la friction sans traiter toutes les opérations comme équivalentes. Si le risque d’une action est majeur, alors la seule présence d’une session ancienne ne suffit pas.
Choisir des facteurs résistants et utilisables
Les codes à usage unique réduisent certains risques mais peuvent toujours être saisis sur une page de phishing. Les clés de sécurité et passkeys reposant sur WebAuthn lient l’authentification au service attendu et offrent une meilleure résistance au phishing lorsqu’ils sont correctement déployés. Le choix tient compte des appareils, navigateurs, contraintes terrain et moyens de récupération.
La recommandation ne se résume pas à « SMS interdit » ou « passkey partout ». Une population mobile sans smartphone d’entreprise, un centre d’appel sur postes partagés et des administrateurs techniques n’ont pas la même ergonomie. Les lignes directrices du NIST sur l’authentification distinguent niveaux d’assurance et résistance au phishing ; le contexte local détermine le niveau réellement requis.
Sécuriser récupération et enrôlement
Un MFA robuste avec une récupération faible produit une fausse sécurité. L’enrôlement vérifie l’identité, enregistre plusieurs moyens lorsque le contexte le permet et avertit lors d’un ajout. Les codes de secours sont remis une fois, protégés et renouvelés après usage. Le support ne désactive pas un facteur sur la seule connaissance d’informations facilement trouvables.
Le runbook différencie perte d’appareil, appareil remplacé, compte compromis et départ. Une récupération sensible peut demander un second agent ou un délai de refroidissement décidé selon le risque. L’utilisateur reçoit une notification par un canal déjà vérifié. Le délai est un paramètre de sécurité local : trop long, il bloque l’activité ; trop court, il n’offre aucune fenêtre de détection.
Déployer le SSO quand la dispersion coûte cher
Le SSO est utile lorsque des salariés accèdent à plusieurs applications et que l’organisation maîtrise déjà une source d’identité. Il réduit les mots de passe locaux, centralise certaines politiques et accélère la révocation. Il diminue aussi la charge support liée aux oublis, à condition que la récupération du compte central soit correctement dimensionnée.
Il ne supprime pas les comptes applicatifs : l’application conserve un identifiant interne, les relations métier et les traces. Elle doit savoir fusionner ou refuser les collisions d’adresse, gérer un changement d’identifiant et empêcher qu’une reconnexion recrée un compte volontairement suspendu. Le premier login ne doit pas devenir un provisioning sans contrôle.
Fédérer quand un tiers porte l’identité
La fédération prend sens lorsque l’entreprise cliente ou partenaire est mieux placée pour authentifier ses personnes et révoquer leurs comptes. Le portail reçoit une assertion ou un jeton signé, vérifie émetteur, audience, dates et intégrité, puis relie l’identité externe à un compte local. La relation de confiance est configurée par organisation, pas ouverte à n’importe quel domaine de courriel.
Le contrat précise qui gère l’assistance, les attributs transmis, la procédure de changement de certificat ou de clé et la fin de relation. Fédérer ne signifie pas accepter tous les attributs comme vrais pour l’autorisation. Un intitulé de groupe provenant d’un partenaire peut être mappé vers une population locale, mais les capacités sensibles restent approuvées selon la politique de l’application.
Choisir OIDC ou SAML selon l’écosystème
OpenID Connect ajoute une couche d’identité à OAuth 2.0 et convient bien aux applications web et mobiles modernes. SAML reste fréquent dans les environnements d’entreprise et les catalogues SaaS. Le choix dépend du fournisseur, des clients, des bibliothèques maintenues et de la capacité d’exploitation ; réimplémenter les protocoles cryptographiques en interne est à éviter.
Pour OIDC, l’application vérifie notamment issuer, audience, signature, nonce et redirections autorisées selon le flux. Pour SAML, elle vérifie signature, destinataire, audience, conditions temporelles et corrélation de réponse. Les métadonnées et clés suivent un cycle de rotation testé. La spécification OpenID Connect Core reste la source normative pour OIDC.
Synchroniser arrivée, mobilité et départ
L’authentification fédérée ferme une session future après révocation chez le fournisseur, mais elle ne retire pas toujours immédiatement les sessions locales ni les objets attribués. Le cycle de vie nécessite donc une synchronisation ou une procédure : provisioning à l’invitation, mise à jour des appartenances, désactivation et transfert des responsabilités.
SCIM peut standardiser certaines opérations de gestion des utilisateurs et groupes, sans résoudre la politique métier. Un événement de départ ferme les sessions, révoque les jetons, retire les délégations et signale les dossiers encore possédés. Les messages doivent être idempotents : une notification rejouée ne recrée ni compte ni attribution, et un événement ancien ne remplace pas un état plus récent.
Garder les autorisations dans l’application
Le fournisseur d’identité atteste une identité et peut transmettre des attributs. L’application décide si cette personne peut valider une facture, consulter une filiale ou exporter un dossier. Confondre les deux transforme un groupe d’annuaire généraliste en politique métier et rend chaque changement dépendant d’une équipe qui ne connaît pas les ressources.
Le mapping est versionné, limité et observable. Un groupe externe peut donner accès à un rôle de base, mais le périmètre client vient d’une relation locale validée. Si un attribut inattendu apparaît, alors le refus par défaut prévaut. Le contrôle serveur s’applique à chaque requête, y compris API, fichier et traitement différé.
Maîtriser sessions, jetons et déconnexion
La durée de session dépend du risque, de l’appareil et de la capacité à révoquer. Une session administrative peut être plus courte qu’une consultation courante. Les jetons sont stockés selon leur nature, jamais placés dans des journaux, et leur audience est bornée. La rotation des refresh tokens et la détection de réutilisation limitent certains scénarios de vol.
La déconnexion locale ferme la session de l’application ; une déconnexion globale dépend du protocole et des capacités du fournisseur. Le produit explique ce comportement au lieu de promettre qu’un bouton ferme tous les services. Lors d’un incident, le runbook sait révoquer une personne, une organisation ou une clé de confiance sans désactiver inutilement chaque client.
Préparer la panne du fournisseur d’identité
Le SSO centralise un risque de disponibilité. Si le fournisseur ne répond pas, les nouvelles authentifications peuvent échouer alors que les sessions existantes continuent jusqu’à leur expiration. Le mode dégradé est décidé à l’avance : maintien des sessions non privilégiées, blocage des actions sensibles, compte d’urgence fortement contrôlé ou procédure d’accès hors bande.
Un « bypass SSO » permanent annule une partie du bénéfice. L’accès d’urgence est nominatif ou gardé selon une procédure, protégé par MFA, alerté et testé. Son usage déclenche une revue et une rotation. Les seuils d’activation reposent sur l’impact observé et l’état du fournisseur ; ils sont associés à un owner et à un rollback vers le mode normal.
Décider sur un cas concret multi-populations
Une application pilote sert cent quatre-vingts salariés, vingt administrateurs clients et plusieurs milliers d’utilisateurs finaux. Les salariés disposent déjà d’un fournisseur d’identité d’entreprise ; les clients utilisent des comptes locaux ; les administrateurs accèdent à des exports. Les incidents observés concernent surtout les mots de passe salariés oubliés et deux comptes administrateurs partagés.
L’équipe fédère d’abord les salariés, impose un facteur résistant au phishing aux administrateurs du produit et remplace les comptes partagés par des identités nominatives. Les utilisateurs finaux conservent temporairement leur login local, avec MFA adaptatif sur les actions sensibles. Cette séquence traite les risques démontrés sans imposer une migration massive avant de maîtriser la récupération.
Pour ce pilote, une adoption inférieure au seuil local défini après une semaine déclenche un accompagnement, et toute récupération administrateur passe par deux personnes. Ces choix répondent à l’organisation observée ; ils ne sont ni des obligations générales ni des garanties absolues. La recette provoque perte de facteur, départ salarié, panne IdP et rejeu d’un événement de désactivation.
Pour qui ces briques sont prioritaires
Le MFA est prioritaire pour les comptes privilégiés, les accès distants et les opérations dont la compromission a un impact élevé. Le SSO est prioritaire quand de nombreux salariés utilisent plusieurs applications et que le cycle de vie central existe. La fédération est prioritaire quand une organisation tierce possède mieux l’identité de ses membres que le portail.
Une jeune application avec peu d’utilisateurs ne doit pas construire seule un fournisseur d’identité. Elle peut s’appuyer sur un service éprouvé et concentrer son code sur les autorisations. À l’inverse, un portail B2B multi-clients doit anticiper plusieurs configurations d’identité, car le premier grand compte demandera souvent une fédération et des preuves d’exploitation.
Éviter les raccourcis d’identité
- Appeler MFA deux secrets semblables. Deux mots de passe ne constituent pas deux facteurs indépendants.
- Fédérer sur le seul domaine de courriel. La confiance doit viser un émetteur configuré et un contrat vérifié.
- Transformer les groupes externes en droits directs. Les autorisations métier restent possédées par l’application.
- Oublier la récupération. Le support devient le chemin le plus facile pour contourner le facteur.
- Conserver un bypass permanent. Une solution de secours non gouvernée devient la voie normale des attaques.
- Confondre départ et absence de login. Sessions, jetons, délégations et responsabilités doivent être révoqués explicitement.
Arbitrer avec une matrice de décision
Si un mot de passe volé suffit à une action critique, alors prioriser le MFA. Si une personne maintient plusieurs comptes internes et que les départs sont centralisés, alors prioriser le SSO. Si un client doit gérer lui-même ses collaborateurs, alors évaluer la fédération et le provisioning. Si aucun owner ne sait récupérer un compte, alors stabiliser ce processus avant d’élargir.
La matrice compare risque réduit, population, dépendances, expérience, disponibilité, récupération et effort de run. Elle refuse les bénéfices vagues. « Moins de tickets » doit être mesuré sur une baseline locale ; « plus sécurisé » doit nommer le scénario empêché. Le bon arbitrage peut être un déploiement combiné mais ordonné, pas le choix exclusif d’une seule brique.
Mettre en œuvre sans rupture
Le contrat technique définit les entrées — assertion, jeton, attributs et contexte — ainsi que les sorties : identité locale, niveau d’assurance et motif de refus. Il nomme les responsabilités, dépendances, seuils de latence, journalisation et comportement de repli. Les erreurs du fournisseur restent distinctes d’un refus d’autorisation afin que le support choisisse la bonne action.
L’instrumentation relie requête, fournisseur, client et résultat sans enregistrer de jeton. Les webhooks ou événements de cycle de vie arrivent dans une file, utilisent l’idempotence et un retry borné ; une file de reprise reçoit les échecs persistants. Le rollback réactive l’ancien chemin pour la population pilote sans rouvrir les comptes déjà révoqués.
Plan d’action : déployer en six semaines
Semaines 1 et 2 : qualifier et contractualiser
L’équipe inventorie populations, actions sensibles, fournisseurs, méthodes actuelles et incidents. Elle choisit une cohorte pilote et écrit les scénarios : mot de passe volé, facteur perdu, départ, assertion invalide et panne. Sécurité, produit, support et exploitation nomment le propriétaire de chaque décision et les seuils locaux de go.
Semaines 3 et 4 : intégrer et observer
Le développement configure les redirect URI exactes, vérifications de jetons, mapping et sessions. Il construit récupération, révocation et journalisation avant l’ouverture. Les tests utilisent un tenant de recette et couvrent rotation de clés, horloge décalée, erreur d’audience, replay et collision de comptes. Aucun secret de test ne rejoint la production.
Semaines 5 et 6 : ouvrir puis reprendre
La cohorte reçoit un accompagnement et un canal de support. L’équipe suit succès, refus, récupérations, latence et comptes non reliés. Elle provoque la panne, exécute le runbook et vérifie le retour au nominal. L’extension dépend de preuves, pas seulement du pourcentage d’enrôlement.
La revue finale rapproche les incidents du pilote, les comptes encore locaux, les récupérations et les attributs rejetés. Chaque écart obtient un owner et une décision : corriger avant le go, accepter pour cette population ou différer l’extension. Le fournisseur d’identité ne devient la source principale qu’après un test de révocation et de rollback réussi sur les mêmes chemins que la production.
- D’abord, nommer le scénario de menace et la population ; à différer si la brique ne réduit aucun risque précis.
- Ensuite, tester enrôlement et récupération ; si le support peut contourner seul le facteur, alors bloquer le go.
- Puis, contrôler cycle de vie, attributs et autorisations avec des cas contradictoires et une panne réelle.
- Enfin, décider l’extension et conserver un rollback jusqu’à ce que la cohorte soit exploitable sans aide orale.
Relier identité et sécurité applicative
La gestion lisible des rôles et permissions permet de garder l’autorisation indépendante de l’IdP. Elle évite qu’un attribut de fédération décide seul d’une action métier ou d’un périmètre client.
La séparation des accès externes et internes complète le cycle de vie et les accès d’urgence. Pour WebAuthn, la spécification du W3C détaille le modèle d’authentificateur et les vérifications de l’application.
- Qualifier la menace avant de choisir le facteur ou le protocole.
- Tester enrôlement, récupération, départ et panne avec une population réelle.
- Garder les autorisations métier locales et explicables après chaque fédération.
Conclusion : protéger le bon parcours
MFA, SSO et fédération ne sont pas trois niveaux d’une même échelle. Le MFA renforce l’authentification, le SSO simplifie un ensemble d’accès et la fédération partage une confiance entre organisations. Leur valeur dépend du risque traité et du cycle de vie qui les entoure.
La meilleure première étape consiste à prendre une population exposée, provoquer compromission, récupération, départ et panne, puis mesurer les décisions encore manuelles. Cette preuve montre quelle brique mérite d’être priorisée et quelles dépendances doivent être stabilisées.
Dawap peut vous accompagner dans ce cadrage, intégrer les protocoles éprouvés et sécuriser les autorisations, la reprise et l’observabilité. Nous construisons avec vos équipes une trajectoire adaptée à votre application web métier sur mesure, sans surpromesse ni dépendance invisible.
