Authentification unique : comparer les solutions pour une administration
Un agent public jongle souvent avec une dizaine de comptes. L'authentification unique promet de n'en garder qu'un, mieux protégé. Trois familles de solutions s'offrent à une administration, avec des compromis très différents sur la maîtrise, le coût et l'effort.
L’erreur la plus fréquente, dans les projets d’authentification unique des administrations, consiste à commencer par le produit. On compare des démonstrations, on retient la plus convaincante, puis l’on découvre que l’annuaire des agents est incomplet, que la moitié des applications métiers ne parlent aucun protocole standard, et que les prestataires sortants n’ont jamais été désactivés. Les solutions SSO se comparent utilement une fois ces questions posées. Ce comparatif propose les critères, puis applique les mêmes à trois familles de solutions.
DOSOBE n’édite ni ne distribue aucune des solutions citées et ne perçoit aucune commission de leurs éditeurs.
Avant de comparer : trois décisions préalables
L’annuaire de référence. Qui dit qu’une personne est agent, dans quel service, avec quel statut ? Le plus souvent, c’est le système de gestion des ressources humaines, relayé par un annuaire (Active Directory ou annuaire LDAP). Sans cette source fiable, l’authentification unique ne fait qu’ouvrir plus vite les portes à des comptes qui devraient être fermés. Notre guide sur la gestion des arrivées, mobilités et départs traite ce préalable.
Les protocoles. Les applications récentes parlent OpenID Connect ou SAML 2.0. Les plus anciennes s’appuient parfois sur l’authentification intégrée de Windows (Kerberos) ou sur un simple formulaire. L’inventaire des applications, avec leur protocole, détermine l’effort réel du projet bien plus que le choix du produit.
Le niveau d’authentification. L’Agence nationale de la sécurité des systèmes d’information (ANSSI), dans ses recommandations sur l’authentification multifacteur, comme la plupart des autorités de sécurité, pousse vers des facteurs résistants à l’hameçonnage : clés de sécurité et authentificateurs conformes aux normes FIDO2 et WebAuthn. C’est là que se trouve le vrai gain de sécurité de l’authentification unique.
Trois familles de solutions
Les services en nuage des grands éditeurs
Microsoft Entra ID (anciennement Azure Active Directory) et Okta sont les exemples les plus répandus. Le fournisseur d’identité est exploité par l’éditeur, en service. Entra ID est souvent déjà présent dans les administrations qui utilisent Microsoft 365, ce qui simplifie le démarrage. Ces services offrent un large catalogue d’intégrations préconfigurées, l’authentification multifacteur, l’accès conditionnel et le provisionnement automatique des comptes (norme SCIM).
Les logiciels libres auto-hébergés
Keycloak, projet libre soutenu par Red Hat et incubé à la Cloud Native Computing Foundation, et LemonLDAP::NG, logiciel libre né dans l’administration française, sont les plus utilisés dans le secteur public francophone. L’administration (ou son prestataire) les installe et les exploite sur son infrastructure. Ils parlent les protocoles standard, gèrent la fédération d’identité et l’authentification multifacteur, et laissent une maîtrise complète de l’hébergement et des données.
Les fédérations d’identité de l’État
En France, ProConnect, qui a succédé à AgentConnect, permet aux agents de se connecter à des services numériques de l’État avec le compte de leur administration. Ce n’est pas une solution d’authentification unique complète : elle fédère des fournisseurs d’identité existants et s’adresse aux services partagés. D’autres pays ont des dispositifs comparables, ou les construisent. On la combine avec l’une des deux familles précédentes.
Le comparatif, sur les mêmes critères
| Critère | Service en nuage d’un éditeur | Logiciel libre auto-hébergé | Fédération de l’État |
|---|---|---|---|
| Protocoles | OpenID Connect, SAML 2.0, intégrations préconfigurées nombreuses | OpenID Connect, SAML 2.0 ; intégrations à configurer | OpenID Connect ; services partenaires seulement |
| Applications internes anciennes | Possibles via des connecteurs ou des passerelles | Possibles via des modules ou un mandataire inverse | Hors périmètre |
| Authentification multifacteur | Intégrée, y compris clés FIDO2 | Intégrée ou par modules, y compris WebAuthn | Dépend du fournisseur d’identité de l’administration |
| Hébergement des données d’identité | Chez l’éditeur ; localisation et droit applicable à vérifier | Chez l’administration ou un hébergeur choisi | Opérée par l’État |
| Exploitation | Assurée par l’éditeur | À la charge de l’administration ou d’un prestataire | Assurée par l’opérateur public |
| Coût | Abonnement par utilisateur, selon les options | Pas de licence ; coût d’exploitation et de support | Pas de coût direct pour l’administration utilisatrice, en général |
| Réversibilité | À négocier : exports, règles, intégrations | Élevée : code et données maîtrisés | Sans objet : dispositif complémentaire |
| Compétences nécessaires | Administration de la plateforme | Exploitation, mises à jour de sécurité, haute disponibilité | Raccordement des services |
Lecture par famille
- Démarrage rapide, surtout si l’éditeur est déjà présent
- Catalogue d’intégrations et fonctions avancées (accès conditionnel, analyse des connexions)
- Pas d’exploitation technique à assurer
- Données d’identité hébergées par un tiers, parfois soumis à un droit étranger
- Coût récurrent qui croît avec le nombre d’agents et les options
- Dépendance forte : l’identité est la clé de tout le reste
- Maîtrise complète de l’hébergement et du code
- Pas de coût de licence, pas de dépendance à un éditeur unique
- Communautés actives et usage répandu dans le secteur public
- Exploitation exigeante : mises à jour, haute disponibilité, surveillance
- Intégrations à construire une par une
- Dépend des compétences internes ou d’un contrat de support
La fédération de l’État n’a pas de « forces et limites » au même titre : elle n’est pas une alternative, mais un complément. Une administration qui choisit un fournisseur d’identité interne a tout intérêt à le raccorder à la fédération, pour que ses agents accèdent aux services partagés avec le même compte.
Quel choix selon votre situation
Petite administration, sans équipe d’exploitation, déjà équipée de Microsoft 365 : le service d’identité de l’éditeur est souvent le plus réaliste, à condition de négocier les exports, de vérifier l’hébergement et d’activer une authentification multifacteur robuste dès le départ.
Administration de taille moyenne ou grande, avec des exigences de maîtrise : un logiciel libre auto-hébergé, exploité en interne ou avec un prestataire de support, offre la meilleure réversibilité. Le coût se déplace de la licence vers les compétences, qu’il faut budgéter.
Ministère ou opérateur interministériel : la question porte souvent sur l’articulation entre un fournisseur d’identité par administration et une fédération commune. Le choix technique compte moins que la gouvernance : qui attribue les identités, qui décide des niveaux d’accès.
Les pièges d’un projet d’authentification unique
Quelle que soit la famille choisie, les mêmes difficultés reviennent dans les projets d’administrations.
Les comptes qui ne sont pas des personnes. Comptes de service, comptes techniques des applications, boîtes partagées : ils ne passent pas par l’authentification unique et échappent souvent à l’inventaire. Ils doivent être recensés, attribués à un responsable et protégés à part.
Les applications qui résistent. Une application métier ancienne, sans protocole standard, finit souvent en exception permanente. Il faut décider tôt de son sort : passerelle d’authentification devant l’application, remplacement programmé, ou exception documentée et surveillée.
La fatigue des validations. Une authentification multifacteur par simple notification à accepter sur le téléphone peut être contournée par un attaquant qui multiplie les demandes jusqu’à ce que l’agent valide par lassitude. Les facteurs résistants à l’hameçonnage, ou au minimum la saisie d’un code affiché à l’écran, limitent ce risque.
Les comptes de secours. Si le fournisseur d’identité tombe, plus personne ne se connecte, y compris les administrateurs qui devraient le réparer. Des comptes de secours, très protégés, conservés hors ligne et testés, font partie de la conception.
Les journaux. L’authentification unique centralise les traces de connexion : c’est l’un de ses grands atouts pour détecter les usages anormaux. Encore faut-il conserver ces journaux, les relier à l’outil de détection et les consulter.
Méthode et limites
Ce comparatif porte sur des familles de solutions et sur des fonctions documentées publiquement par leurs éditeurs ou leurs communautés. Il ne donne aucune note ni aucun prix : les tarifs varient selon les volumes et les options, et doivent être obtenus par consultation. Avant de choisir, un essai sur trois applications représentatives (une récente, une ancienne, une critique) en dit plus que toute grille.
- L’annuaire de référence est fiable et alimenté par les ressources humaines.
- Les applications sont inventoriées, avec leur protocole d’authentification.
- Le niveau d’authentification visé est écrit, avec des facteurs résistants à l’hameçonnage pour les comptes sensibles.
- L’hébergement des données d’identité et le droit applicable sont connus.
- Les conditions de sortie sont prévues dès le contrat ou le choix du logiciel.
Notre expertise identité numérique accompagne ce type de choix, et notre guide sur l’identité et les habilitations des agents publics détaille la gouvernance des droits qui doit l’accompagner.
- OASIS, Security Assertion Markup Language (SAML) V2.0 ; OpenID Foundation, OpenID Connect Core 1.0.
- W3C, Web Authentication (WebAuthn) ; FIDO Alliance, spécifications FIDO2.
- IETF, RFC 7643 et RFC 7644, System for Cross-domain Identity Management (SCIM).
- ANSSI, Recommandations relatives à l’authentification multifacteur et aux mots de passe.
- Documentation publique de Microsoft Entra ID, Okta, Keycloak, LemonLDAP::NG et ProConnect.
Questions fréquentes
Qu'est-ce que l'authentification unique ?
C'est un dispositif qui permet à un utilisateur de s'authentifier une fois auprès d'un fournisseur d'identité, puis d'accéder à plusieurs applications sans ressaisir de mot de passe. Les applications font confiance au fournisseur d'identité par des protocoles normalisés, principalement SAML 2.0 et OpenID Connect.
L'authentification unique augmente-t-elle le risque si le compte est volé ?
Elle concentre le risque sur un seul compte, ce qui impose de le protéger fortement, par une authentification multifacteur. En contrepartie, elle supprime les mots de passe réutilisés d'une application à l'autre, permet de couper tous les accès d'un coup au départ d'un agent et centralise les journaux. Bien configurée, elle améliore la sécurité.
ProConnect remplace-t-il une solution d'authentification unique interne ?
Pas entièrement. ProConnect, qui a succédé à AgentConnect, fédère les fournisseurs d'identité des administrations pour l'accès des agents à des services de l'État. Il suppose que chaque administration dispose déjà de son propre fournisseur d'identité, et il ne gère pas l'accès à ses applications internes. Les deux sont complémentaires.
Faut-il choisir un logiciel libre ?
Un logiciel libre comme Keycloak ou LemonLDAP::NG offre la maîtrise du code et de l'hébergement, sans coût de licence, mais demande des compétences d'exploitation internes ou un prestataire. Un service en nuage réduit l'effort d'exploitation, au prix d'une dépendance et de questions d'hébergement. Le choix dépend des compétences disponibles et des exigences de souveraineté.