Le premier client entreprise qui adore votre produit finira par poser une question plus difficile que celle du prix.
Son équipe de sécurité voudra un accès unifié via son propre fournisseur d'identité, une désactivation automatique lorsqu'un collaborateur quitte l'entreprise, ainsi que la preuve de qui avait accès et à quel moment.
Si vos réponses se résument encore à « c'est prévu », la signature est souvent repoussée d'un trimestre, le temps que vous vous organisiez dans l'urgence.
J'ai participé à ce type d'audit des deux côtés. La checklist d'identité ci-dessous correspond aux besoins des équipes SaaS B2B en croissance avant l'arrivée du questionnaire, en s'appuyant sur des standards ouverts.
Les questions que posent réellement les équipes de sécurité des grandes entreprises
Attendez-vous à davantage qu'un simple « Prenez-vous en charge le SSO ? ». Un questionnaire type couvre les points suivants :
- Les employés peuvent-ils se connecter via notre fournisseur d'identité d'entreprise avec SAML 2.0 ou OpenID Connect (OIDC) ?
- Pouvons-nous imposer la MFA au niveau de notre IdP, et votre application respectera-t-elle ce signal sans mettre en place un second parcours MFA ?
- Comment provisionnez-vous et déprovisionnez-vous les utilisateurs ? Prenez-vous en charge SCIM ?
- Quelle est la durée de vie de vos sessions, quelles sont vos politiques concernant les refresh tokens et quels sont vos délais d'expiration après inactivité ?
- Pouvons-nous exporter ou transmettre en continu les journaux d'authentification et d'administration vers notre SIEM ?
- Comment isolez-vous les données, les configurations et les connexions d'identité de notre tenant de celles de tous les autres clients ?
- Si un incident d'identité survient dans votre stack, comment nous prévenez-vous, faites-vous tourner les identifiants et prouvez-vous quels comptes ont été concernés ?
Répondez à chacune de ces questions par un mécanisme concret. « Nous prenons la sécurité au sérieux » ne résiste pas à un appel de suivi avec leur architecte IAM.
Les fondamentaux de SAML et d'OIDC
La plupart des acheteurs de grandes entreprises utilisent déjà SAML 2.0 avec l'IdP de leur personnel. OIDC apparaît plus souvent avec les IdP cloud modernes, les produits fortement orientés API et les clients mobiles. De nombreux produits SaaS prennent en charge les deux et permettent à chaque tenant de choisir.
La configuration repose sur un échange de métadonnées.
- SAML : Vous et le client échangez les identifiants d'entité, les URL de l'Assertion Consumer Service, les points de terminaison de déconnexion globale et les certificats de signature.
- OIDC : Vous échangez les URL de l'émetteur, les identifiants et secrets client (ou les paramètres du client public), les URI de redirection et les emplacements des documents de découverte.
Prévoyez la rotation des certificats et des clés de signature avant la mise en production de la première connexion. Les certificats IdP expirés sont une cause fréquente d'interruption en production.
Sachez faire la différence entre les flux initiés par le SP et ceux initiés par l'IdP.
- Initiation par le SP : Le flux démarre dans votre application et redirige vers l'IdP ; c'est le parcours habituel pour les liens profonds et les invitations.
- Initiation par l'IdP : Le flux démarre depuis le portail applicatif du client et arrive dans votre application avec une assertion ou une connexion non sollicitée.
Prenez en charge les deux si l'équipe qui gère le portail de l'acheteur s'attend à voir une tuile dans son catalogue d'applications.
C'est dans la correspondance des attributs et des claims que se cachent les défaillances silencieuses. Les noms de groupes et les attributs d'adresse e-mail et de service diffèrent selon les IdP. Faites la correspondance explicitement pour chaque tenant.
Lorsqu'un claim requis est absent, refusez l'accès par défaut. Ne revenez pas à un rôle d'administrateur ou de membre par défaut parce qu'un attribut de groupe a été renommé en amont.
Isolation des tenants
Le SSO d'entreprise est par nature multi-tenant. Chaque client a besoin de sa propre connexion IdP, de sa propre liste de domaines et de ses propres correspondances d'attributs.
La vérification du domaine (ou la découverte du domaine d'origine) achemine user@customer.com vers l'IdP de ce client plutôt que vers une page de connexion partagée.
Insérez un identifiant de tenant stable dans chaque token et chaque session, puis vérifiez-le avec l'audience à chaque requête. Un token émis pour le tenant A ne doit jamais permettre d'ouvrir les données du tenant B, même si l'adresse e-mail de l'utilisateur est identique.
Associez-y des valeurs d'audience propres à chaque API (voir les resource indicators de la RFC 8707 lorsque vous les utilisez) afin qu'un token destiné à la facturation ne puisse pas appeler votre API d'administration.
Évitez les connexions IdP partagées « fourre-tout » entre des clients sans lien. Les connexions partagées rendent la correspondance des attributs ambiguë et transforment une seule mauvaise configuration en incident inter-tenant.
Départ des collaborateurs et SCIM
SSO à lui seul empêche un employé parti de se reconnecter. Il ne supprime ni le compte déjà créé dans votre produit, ni les clés d'API, les jetons d'accès personnels, les refresh tokens ou les sessions de longue durée que ce compte détient encore.
SCIM 2.0 (RFC 7643 pour le schéma, RFC 7644 pour le protocole) permet à l'annuaire du client de créer, mettre à jour et désactiver automatiquement les utilisateurs dans votre application.
Lorsque les RH indiquent le départ d'une personne, l'IdP envoie une désactivation. Votre application doit désactiver l'utilisateur, révoquer les refresh tokens et les sessions, et invalider les identifiants d'API liés à cette identité dans le même workflow.
Le provisionnement juste-à-temps (JIT) crée un compte lors de la première connexion SSO. C'est acceptable pour les premiers tenants et les démonstrations. À lui seul, il ne règle ni les départs, ni les changements de rôle, ni le nettoyage des licences.
Préférez SCIM (ou une synchronisation d'annuaire équivalente) dès qu'un client dispose d'une véritable fonction informatique. Si vous ne proposez que le JIT, documentez honnêtement cette lacune : l'acheteur posera la question.
Suivez les bonnes pratiques de sécurité OAuth (RFC 9700) pour la durée de vie et la révocation des tokens. Des tokens d'accès de courte durée associés à des refresh tokens révocables vous donnent un véritable bouton d'arrêt lorsque SCIM indique « désactivé ».
Éléments probants pour l'audit
Les questionnaires de sécurité et les audits de type SOC 2 ou ISO 27001 demandent qui s'est authentifié, qui a modifié les rôles, qui a connecté un IdP et qui a exporté des données.
Vous avez besoin des événements de connexion, d'administration et de provisionnement, avec leur horodatage, l'acteur, la cible, le tenant, le contexte IP ou appareil lorsqu'il est disponible, ainsi que le résultat.
La durée de conservation doit correspondre aux attentes des acheteurs de votre secteur, et les exports doivent pouvoir être produits sans une semaine de travail d'ingénierie. Les téléchargements CSV ou JSON aident les petits acheteurs ; la transmission vers un SIEM via webhook ou par un collecteur de journaux aide les plus grands.
Soyez prêt à répondre à la question « Montrez-moi qui avait accès à ce tenant entre ces deux dates ». Si cette requête nécessite un archéologue des bases de données, corrigez la journalisation avant que l'auditeur ne pose la question.
La place des agents d'IA
Les agents d'IA et les intégrations d'outils de type MCP agissent de plus en plus dans votre produit au nom d'un utilisateur. Traitez-les comme des identités de premier ordre dans votre modèle d'accès.
Préférez des tokens OAuth délégués, limités en portée, de courte durée et liés à l'audience des API que l'agent peut appeler. Dans chaque ligne de journal, distinguez clairement l'identité de l'utilisateur humain de celle de l'agent.
Lorsque vous révoquez un utilisateur, révoquez également toutes les autorisations d'agent, tous les refresh tokens et tous les identifiants d'outil émis pour cet utilisateur. Sinon, le départ semblera traité dans l'interface alors qu'un agent détiendra toujours un token actif.
La même discipline d'audience qui protège les API internes s'applique ici. Une large audience commune à tous les outils d'agent devient une clé passe-partout dès qu'une intégration laisse fuir un token.
Checklist finale
Avant de répondre au prochain questionnaire d'entreprise, vérifiez que vous pouvez cocher chacune des cases suivantes :
- Des connexions SAML 2.0 et/ou OIDC propres à chaque tenant, avec un échange de métadonnées et une rotation des certificats documentés.
- Des parcours de connexion initiés par le SP et par l'IdP, testés avec au moins un IdP client réel.
- Des correspondances explicites d'attributs et de claims, avec un refus d'accès par défaut lorsqu'un claim mappé est absent.
- Une vérification du domaine ou une découverte du domaine d'origine qui achemine les utilisateurs vers le bon IdP.
- Des identifiants de tenant stables dans les tokens, vérifiés avec l'audience à chaque requête.
- Un déprovisionnement SCIM 2.0 (ou équivalent) qui révoque les sessions, les refresh tokens et les identifiants d'API.
- Des journaux d'authentification et d'administration exportables, avec une durée de conservation que vous pouvez justifier lors d'un audit de type SOC 2.
- Un modèle d'accès aux agents et aux outils fondé sur des tokens délégués, limités en portée et révocables, avec des identités de journalisation distinctes.
Le SSO d'entreprise touche à la connexion, à l'autorisation, au cycle de vie, à l'audit et désormais aux acteurs non humains. Construisez ces briques tant que vos acheteurs sont encore des entreprises de taille intermédiaire, et le premier véritable audit de sécurité portera sur le calendrier plutôt que sur une refonte menée sous la pression du contrat.
Pour aller plus loin : Découvrez les meilleurs logiciels de gestion des identités et des accès pour gérer l'authentification, les accès et les cycles de vie des identités.