Guide
SSO d'un outil IA : SAML ou OIDC, et quoi vérifier
Brancher un outil d'IA sur votre annuaire : SAML 2.0 ou OpenID Connect, domaine vérifié, SSO imposé, création des comptes. L'exemple de Claude.
Mis à jour le
L'authentification unique, ou SSO (single sign-on), permet à vos salariés de se connecter à un outil d'IA avec leur compte professionnel, celui de votre fournisseur d'identité (Microsoft Entra ID, Google Workspace, Okta…). Deux protocoles dominent : SAML 2.0 et OpenID Connect (OIDC). Pour un outil d'IA, le choix du protocole compte moins que trois vérifications : l'outil impose-t-il le SSO à tout votre domaine, crée-t-il et supprime-t-il les comptes automatiquement, et attribue-t-il les rôles selon vos groupes ?
Ce que le SSO change pour un outil d'IA
Sans SSO, chaque salarié crée un compte avec un mot de passe, et l'entreprise ne voit pas qui utilise quoi. Avec le SSO, Microsoft résume le fonctionnement en quatre temps : l'utilisateur ouvre l'application, l'application le renvoie vers le fournisseur d'identité, celui-ci vérifie ses identifiants professionnels, puis confirme son identité à l'application, qui donne l'accès. L'application ne gère plus de mot de passe.
Pour l'entreprise, Microsoft cite une sécurité plus forte (connexion centrale, mêmes règles partout), une gestion des accès depuis un seul endroit et moins de demandes au support.
SAML ou OIDC
La documentation de Microsoft Entra ID décrit ainsi les deux protocoles :
| SAML 2.0 | OpenID Connect | |
|---|---|---|
| Nature | Standard mûr, fondé sur XML, très répandu en entreprise | Protocole moderne fondé sur OAuth 2.0, avec des jetons JSON |
| Convient à | Applications web classiques, besoin d'attributs utilisateur détaillés | Applications web modernes, mobiles, API qui ont besoin d'authentification et d'autorisation |
| Pour l'éditeur | Compatibilité plus large avec les entreprises | Plus simple à construire avec les frameworks actuels |
Côté administrateur, Microsoft précise que les deux fonctionnent avec votre infrastructure d'identité, SAML s'accordant parfois mieux aux systèmes déjà en place. En pratique : prenez celui que l'outil d'IA propose et que votre fournisseur d'identité gère bien. Si l'outil propose les deux, OIDC est souvent plus simple à mettre en place pour une application récente.
Les quatre vérifications avant de signer
1. Le domaine est-il vérifié et le SSO imposé ?
Le SSO n'a d'intérêt que s'il est obligatoire. Chez Claude, par exemple, la vérification du domaine est un préalable, et l'obligation de passer par le SSO s'applique par domaine de messagerie. La documentation précise que même le propriétaire principal de l'organisation n'en est pas dispensé si son adresse est sur un domaine soumis au SSO.
2. Comment les comptes sont-ils créés ?
| Mode | Fonctionnement | Limite |
|---|---|---|
| Invitation | Un administrateur invite chaque personne | Manuel |
| JIT (just-in-time) | Le compte est créé à la première connexion par SSO | Ne retire jamais un compte automatiquement |
| SCIM (synchronisation d'annuaire) | Les comptes sont créés et retirés selon les affectations dans le fournisseur d'identité, sans attendre une connexion | Demande une offre qui le prend en charge |
Chez Claude, ce sont les trois modes proposés ; le JIT est disponible pour les offres Team et Enterprise et les organisations Console, le SCIM pour les organisations Enterprise et Console, sous conditions, mais pas pour Team. Le détail de SCIM est sur la page SCIM : l'approvisionnement automatique.
3. Les rôles suivent-ils vos groupes ?
Un outil d'IA a souvent plusieurs niveaux : administrateur, membre, type de siège. L'idéal est de les piloter par des groupes de votre annuaire. Claude permet de créer des groupes dans le fournisseur d'identité et de les associer à des rôles et à des types de siège. Attention à l'avertissement de sa documentation : en mode SCIM, les utilisateurs non affectés à l'application dans le fournisseur d'identité sont retirés. Affectez tout le monde avant d'enregistrer.
4. Votre fournisseur d'identité est-il pris en charge ?
Claude publie des guides pour Okta, Microsoft Entra ID, Google, OneLogin et JumpCloud. Vérifiez la même chose chez tout éditeur d'outil d'IA, et demandez s'il passe par un intermédiaire technique pour le SSO ou le SCIM.
Le SSO et l'intégration technique
Le SSO couvre l'accès des personnes à l'outil. Il ne règle pas l'accès de l'outil à vos données : quand l'assistant lit un CRM ou une boîte mail, c'est une autre autorisation (une application inscrite, des permissions, une clé d'API), traitée sur les pages Microsoft Graph et délégation au niveau du domaine. Pour un serveur MCP, l'autorisation centralisée par le fournisseur d'identité est décrite sur Cercle IA Tech · MCP.
Microsoft le rappelle dans sa documentation sur l'approvisionnement : SCIM, combiné à SAML ou OIDC, donne aux administrateurs une gestion des accès entièrement fondée sur des standards.
Questions fréquentes
Quelle différence entre SAML et OIDC ?
SAML 2.0 est un standard ancien, fondé sur XML, adapté aux applications web classiques et aux attributs détaillés. OpenID Connect repose sur OAuth 2.0 et des jetons JSON, et convient aux applications web modernes, mobiles et aux API. Les deux fonctionnent avec Microsoft Entra ID.
Le SSO suffit-il à retirer l'accès d'un salarié qui part ?
Il l'empêche de se connecter, mais son compte peut rester dans l'outil. La suppression automatique des comptes relève de l'approvisionnement, par SCIM. Chez Claude par exemple, le mode JIT crée les comptes à la première connexion mais n'en retire jamais automatiquement.
Sources
Pages consultées pour écrire cet article :