Authentification unique (SSO) avec Microsoft Entra ID ou Google Workspace

L’authentification unique, ou SSO (single sign-on), permet à vos collaborateurs de se connecter une seule fois avec leur compte professionnel Microsoft ou Google, puis d’ouvrir toutes les applications auxquelles ils ont droit sans ressaisir de mot de passe. Techniquement, l’application ne vérifie plus elle-même l’identité : elle la délègue à Microsoft Entra ID ou à Google Workspace, via un protocole standard, SAML 2.0 ou OpenID Connect. Pour une PME ou une ETI, c’est à la fois un gain de confort, de sécurité et de gestion : un départ désactivé dans l’annuaire coupe l’accès partout.

Ce guide explique le fonctionnement, le choix du protocole, les spécificités de chaque fournisseur et les pièges que l’on rencontre dans les projets.

Pourquoi mettre en place l’authentification unique ?

Chaque application métier qui gère ses propres mots de passe crée trois problèmes : des identifiants supplémentaires que les collaborateurs notent, réutilisent ou oublient ; des politiques de sécurité disparates ; et des comptes qui restent actifs après le départ d’un salarié, faute d’avoir été supprimés partout.

Les identifiants volés restent une porte d’entrée majeure des attaques. Le rapport 2025 de Verizon sur les violations de données place l’abus d’identifiants en tête des vecteurs d’accès initial, avec 22 % des violations analysées, devant l’exploitation de vulnérabilités (20 %).

Le SSO répond à ces trois problèmes à la fois :

• Un seul compte à protéger, avec une authentification multifacteur appliquée partout. L’ANSSI recommande l’authentification multifacteur et invite à adapter le niveau d’authentification à la sensibilité du service.
• Une politique unique : règles de mot de passe, détection des connexions suspectes, restrictions par pays ou par appareil, définies une fois dans le fournisseur d’identité.
• Une gestion centralisée des arrivées et des départs : désactiver un compte dans l’annuaire bloque l’accès à toutes les applications fédérées.

Côté utilisateurs, la documentation de Microsoft met aussi en avant la réduction de la charge du support : moins de réinitialisations de mots de passe et de demandes liées aux comptes.

Comment fonctionne le SSO, en quatre étapes

Le principe est le même quel que soit le fournisseur :

1. Le collaborateur ouvre l’application (votre CRM sur mesure, votre intranet, votre extranet).
2. L’application le redirige vers le fournisseur d’identité, Microsoft Entra ID ou Google Workspace.
3. Le fournisseur vérifie son identité : mot de passe, second facteur, règles d’accès. Si une session est déjà ouverte, cette étape est transparente.
4. Le fournisseur renvoie une preuve signée à l’application, qui ouvre la session avec les informations reçues (identifiant, nom, e-mail, groupes).

L’application ne voit jamais le mot de passe. Elle fait confiance à la preuve, à condition d’en vérifier rigoureusement la signature, l’émetteur, le destinataire et la date de validité.

SAML ou OpenID Connect : quel protocole choisir ?

Deux protocoles standards dominent. Les deux fonctionnent avec Microsoft Entra ID et Google Workspace.

Microsoft résume ainsi le choix pour les éditeurs : OIDC est généralement plus simple à intégrer avec des frameworks modernes, tandis que SAML offre une compatibilité plus large avec les systèmes d’entreprise établis. Notre recommandation pour une application sur mesure : OpenID Connect par défaut, et SAML en complément si vos clients grands comptes l’exigent pour se connecter avec leur propre annuaire.

Microsoft Entra ID : ce qu’il faut savoir

Microsoft Entra ID (anciennement Azure Active Directory) est le fournisseur d’identité des entreprises équipées de Microsoft 365. Une application s’y déclare comme « application d’entreprise » ; l’administrateur choisit ensuite qui peut y accéder.

Les points d’attention dans un projet :

• Inscription de l’application : identifiant, adresses de retour autorisées, secret ou certificat. Les secrets expirent : une date d’expiration oubliée peut bloquer toutes les connexions du jour au lendemain. Il faut la superviser.
• Mono-locataire ou multi-locataire : une application interne n’accepte que votre organisation ; un SaaS destiné à plusieurs clients doit accepter les comptes de leurs propres organisations, avec un contrôle explicite des organisations autorisées.
• Groupes et rôles : Entra ID peut transmettre les groupes ou les rôles d’application de l’utilisateur, ce qui permet de piloter les droits depuis l’annuaire.
• Accès conditionnel : selon vos licences, des règles imposent l’authentification multifacteur, un appareil géré ou une localisation pour accéder à l’application.

Microsoft propose aussi un SSO « par mot de passe » pour les applications qui ne gèrent aucun protocole de fédération, ou un simple lien dans le portail Mes applications : ce sont des solutions de transition, pas une authentification unique au sens strict. Pour l’intégration plus large de vos outils avec l’écosystème Microsoft, voir notre page Microsoft 365.

Google Workspace : ce qu’il faut savoir

Google Workspace peut jouer le rôle de fournisseur d’identité de deux façons.

Avec OpenID Connect, via la connexion Google. La documentation de Google contient un avertissement essentiel : pour réserver l’accès aux membres de votre organisation, l’application doit vérifier la revendication hd (domaine hébergé) contenue dans le jeton signé par Google. Le paramètre envoyé par l’application dans la requête n’est qu’une aide à l’affichage, modifiable côté client, qui ne protège rien. Oublier ce contrôle revient à ouvrir l’application à n’importe quel compte Google.

Avec SAML, en déclarant une application SAML personnalisée dans la console d’administration. D’après l’aide Google Workspace, l’administrateur renseigne l’adresse de retour de l’application (obligatoirement en HTTPS) et son identifiant, choisit les attributs transmis, puis active l’application pour tous les utilisateurs ou pour certaines unités organisationnelles ou groupes. Google précise que l’activation peut prendre jusqu’à 24 heures et recommande de tester la connexion initiée des deux côtés.

Les pièges qui reviennent dans les projets SSO

1. Identifier les utilisateurs par leur e-mail. Une adresse change (mariage, fusion, changement de domaine) ; l’identifiant unique et stable fourni par le fournisseur d’identité, lui, ne change pas. C’est lui qui doit servir de clé.
2. Oublier les comptes existants. Avant la bascule, il faut rapprocher chaque compte local de l’application de son identité dans l’annuaire, et traiter les cas sans correspondance.
3. Ne gérer que la connexion, pas le cycle de vie. Le SSO bloque la connexion d’un compte désactivé, mais le compte et ses droits restent dans l’application. Le standard SCIM permet au fournisseur d’identité de créer, modifier et désactiver automatiquement les comptes dans l’application.
4. Confondre authentification et autorisation. Le SSO dit qui est l’utilisateur ; l’application décide ce qu’il a le droit de faire. La gestion des rôles reste indispensable, comme nous l’expliquons dans notre article sur les droits d’accès.
5. Négliger la déconnexion et la durée des sessions. Une session applicative de trente jours annule une partie du bénéfice d’un contrôle d’accès centralisé.
6. Ne prévoir aucun accès de secours. Un ou deux comptes d’administration locaux, protégés par une authentification forte et surveillés, évitent de rester bloqué si la configuration SSO casse.
7. Oublier les utilisateurs externes. Prestataires, clients, fournisseurs : ils n’ont pas de compte dans votre annuaire. Il faut décider s’ils sont invités, fédérés depuis leur propre organisation, ou gérés en comptes locaux avec authentification multifacteur.

Les étapes d’un projet SSO

Le SSO est rarement un projet isolé : il accompagne le lancement d’un intranet, d’un extranet ou d’une application métier. C’est le bon moment pour le faire, car brancher une application sur l’annuaire dès sa conception est bien plus simple que de reprendre des comptes existants. Nous intégrons l’authentification unique dans nos projets d’intégrations et d’API ; pour évaluer votre situation, décrivez vos applications dans notre diagnostic en ligne.