Les termes authentification et fédération d’identité sont souvent utilisés l’un pour l’autre. Ils sont liés, mais ce n’est pas la même chose. Si vous développez des applications ou gérez des utilisateurs à travers plusieurs systèmes, il est important de connaître la différence. Les confondre peut conduire à de mauvais choix de conception et à des risques de sécurité.
D’abord, qu’est-ce que l’authentification ?
Commençons par les bases. L’authentification consiste à répondre à une question simple : êtes-vous vraiment la personne que vous prétendez être ?
Cela passe généralement par :
- Un mot de passe
- Une empreinte digitale ou une reconnaissance faciale
- Un téléphone qui reçoit une notification push ou un code à usage unique
Si vous avez déjà saisi votre email et votre mot de passe sur une page de connexion, ou utilisé Face ID pour ouvrir une application, vous avez été authentifié.
Et qu’est-ce que la fédération d’identité ?
La fédération va plus loin. Il ne s’agit pas seulement de prouver l’identité de quelqu’un, mais de faire confiance à un autre système pour le faire à votre place, et parfois même de construire une vision partagée de l’identité de cette personne entre plusieurs systèmes.
Concrètement, cela peut ressembler à ceci :
- Vous vous connectez à Google.
- Puis vous ouvrez votre application et cliquez sur « Se connecter avec Google ».
- L’application ne vous demande pas de vous reconnecter. Elle fait confiance à Google pour se porter garant de vous.
C’est ça, la fédération : deux systèmes (Google et l’application) ont une relation de confiance. L’un gère l’authentification, l’autre fait confiance au résultat.
Mais il ne s’agit pas seulement d’authentifier des personnes. La fédération implique souvent de :
- Créer un enregistrement utilisateur dans le système de destination la première fois que quelqu’un se connecte via un fournisseur d’identité (Identity Provider) de confiance.
- Lier les identités entre différents systèmes, pour qu’une même personne soit reconnue d’une plateforme à l’autre.
- Synchroniser des attributs d’identité comme le nom, l’email ou l’appartenance à un groupe ou à un rôle, à des fins d’autorisation.
- Éventuellement, mettre à jour l’enregistrement utilisateur à chaque connexion pour garder les données synchronisées.
Pourquoi c’est important (du point de vue de l’architecture)
Quand vous construisez un site web, un produit SaaS ou une application mobile, vous devez aller au-delà de « comment les utilisateurs se connectent-ils ? » et raisonner en termes d’architecture d’identité.
La fédération n’est pas seulement un moyen de se connecter. C’est une façon de gérer l’identité. L’authentification est « simple » : vous vérifiez les identifiants d’un utilisateur et vous le laissez entrer. La fédération, elle, touche l’ensemble du cycle de vie des identités dans votre architecture :
- Elle vous permet de déléguer l’authentification à un tiers (comme Google, Facebook ou un IdP d’entreprise).
- Mais vous créez et gérez tout de même vos propres enregistrements d’identité dans votre système.
- Vous décidez quelles données utilisateur stocker, comment lier les identités et à quelle fréquence synchroniser les attributs (rôles, permissions, informations de profil).
Ainsi, même si la fédération commence par une authentification externe, elle finit souvent par vous rendre propriétaire de l’identité utilisateur, car c’est ce qui vous permet d’appliquer le contrôle d’accès, de stocker les préférences et d’auditer l’activité.
Architecture et sécurité
Contrairement à l’authentification classique, la fédération n’est pas toujours une solution prête à l’emploi. Elle nécessite des relations de confiance et un traitement sécurisé côté backend.
La fédération implique un échange de tokens (via OIDC ou SAML) entre des parties de confiance. Cela suppose :
- Des redirections, des assertions signées et la validation des tokens
- Des secrets client protégés et de la logique côté backend
- Un système capable de vérifier les tokens d’identité
Cela ne fonctionne pas bien directement dans des applications publiques comme :
- Les Single Page Applications (SPA) écrites en JavaScript
- Les applications mobiles natives
Pourquoi ? Parce qu’il est impossible de stocker des secrets en toute sécurité ni de valider des tokens signés uniquement côté client. Il faut un composant backend, souvent appelé token broker ou backend-for-frontend (BFF), pour gérer les flows de fédération de manière sécurisée.
Gestion du cycle de vie
La fédération oblige aussi à réfléchir à la façon et au moment où les identités sont créées, mises à jour et parfois supprimées d’un système à l’autre. Lorsqu’un utilisateur se connecte via Google, vous pouvez créer un nouvel enregistrement utilisateur dans votre système et le lier à son compte Google. Ce processus de création ou de modification d’identité doit être piloté avec soin, en particulier si vous synchronisez des attributs ou des rôles. Le moment où vous créez ou mettez à jour un enregistrement d’identité est lui aussi important.
Voici comment cela se passe généralement :
- L’utilisateur se connecte via un IdP tiers (comme Google).
- Votre système crée un nouvel enregistrement utilisateur ou met à jour un enregistrement existant. Ce nouvel utilisateur possède, dans votre système, un identifiant unique (comme un UUID) lié à son compte Google.
- Vous synchronisez les attributs (comme l’email, le nom ou les rôles) de l’IdP vers votre système.
- Vous devez créer une nouvelle session ou un nouveau token pour l’utilisateur dans votre système, indépendamment de l’IdP.
Ce processus étant sensible, votre système doit pouvoir gérer ces événements de façon sûre et efficace, sans exposer de données sensibles ni créer de failles de sécurité. C’est pourquoi vous devez toujours vous appuyer sur un backend sécurisé pour les traiter. C’est là qu’un token broker ou un BFF (pour les frontends publics) devient utile.