SCIM et SSO pour les outils marketing : ce que la DSI attend vraiment

L'exigence SSO/SCIM arrive de deux façons. Parfois, elle est intégrée à un questionnaire de sécurité : « Votre application prend-elle en charge l'authentification unique SAML 2.0 ou OIDC ? Prend-elle en charge le provisionnement automatisé SCIM 2.0 ? ». Parfois, elle arrive sous forme d'instruction directe de la DSI : tout fournisseur traitant des données personnelles doit s'authentifier via l'IdP de l'entreprise. Pas de connexion par mot de passe autonome, pas d'identifiants partagés, pas d'exceptions.

Dans les deux cas, la conséquence est la même. Votre outil marketing s'intègre au fournisseur d'identité de l'entreprise, ou il est remplacé.

Les outils marketing - raccourcisseurs d'URL, traceurs de campagne, gestionnaires d'UTM - passent désormais cette revue parce que les équipes marketing manipulent des données personnelles dans la couche d'événements de clic. Un lien court qui journalise l'IP d'un utilisateur, son user-agent et son referrer traite des données personnelles. Ce traitement appartient au modèle d'accès gouverné par l'IdP.

Ce billet est la version checklist achats : ce qu'exigent SSO et SCIM, où les SaaS marketing pèchent, et les cinq questions à poser lors de l'appel découverte avec le fournisseur.

TL;DR#

• SAML 2.0 et OIDC servent différentes générations d'IdP - les entreprises historiques utilisent SAML ; les IdP modernes parlent OIDC nativement. Un fournisseur qui ne prend en charge qu'un des deux manque la moitié du marché.
• SCIM 2.0 est la couche de provisionnement : elle crée des comptes, les met à jour et - surtout - les déprovisionne. Le provisionnement JIT crée les comptes à la première connexion mais ne déprovisionne pas. Pour l'audit, SCIM est l'exigence.
• La plupart des outils marketing réservent le SSO à un palier entreprise facturé 500 à 2 000 $/mois au-dessus du plan de base. Les fournisseurs qui incluent le SSO dans un palier Business sans surcoût sont l'exception.
• Les questions d'achat qui comptent : URL des métadonnées SAML, URL du endpoint SCIM, cadence de rotation du bearer token, latence de déprovisionnement et mappage groupe IdP vers rôle.

SAML 2.0 et OIDC : pourquoi les deux existent encore#

SAML 2.0, publié par OASIS en 2005, est un standard de fédération basé sur XML. L'IdP poste une SAML Response signée à l'URL Assertion Consumer Service du SP ; le SP valide la signature avec le certificat de l'IdP, extrait le sujet et les attribute statements, et crée une session.

OIDC, construit sur OAuth 2.0, gère le même travail avec JSON. L'IdP émet un JWT (l'ID token) que le SP vérifie auprès du endpoint JWKS de l'IdP.

Les deux coexistent parce que les IdP d'entreprise historiques - AD FS on-premises, anciennes configurations Okta, Ping Federate - sont principalement SAML. Les IdP cloud-natifs comme Google Workspace et la pile moderne de JumpCloud parlent OIDC nativement et portent SAML en protocole secondaire. Les entreprises mixtes utilisent les deux.

Flux SP-initié vs IdP-initié. Le login SP-initié est le standard : l'utilisateur visite l'application, l'application redirige vers l'IdP, l'IdP authentifie et renvoie. L'IdP-initié saute la redirection SP - l'utilisateur clique sur une tuile dans le tableau de bord Okta ou Entra et l'IdP envoie une assertion non sollicitée directement au SP. Les deux flux doivent fonctionner. L'IdP-initié est plus difficile à implémenter de manière sécurisée (risque d'injection type CSRF si le SP ne valide pas les attributs binding et destination) et les fournisseurs qui ne prennent en charge que le SP-initié échoueront quand la DSI essaiera d'ajouter la tuile de l'application au tableau de bord d'entreprise.

SCIM 2.0 : la couche de provisionnement#

SCIM 2.0 - RFC 7644 - automatise la gestion du cycle de vie des comptes utilisateurs à travers les applications SaaS. Trois opérations principales :

Provisionnement : POST /Users avec les attributs de l'utilisateur. Le SP crée le compte et retourne le nouvel ID.

Mises à jour : PATCH /Users/:id avec un payload JSON Patch - display name, département, rôle, ce que l'IdP est habilité à gérer.

Déprovisionnement : DELETE /Users/:id (suppression dure) ou PATCH /Users/:id avec { "active": false } (désactivation douce, le pattern d'entreprise le plus courant).

Le déprovisionnement est la pièce critique pour l'audit. Les comptes orphelins - des comptes appartenant à d'anciens employés qui n'ont jamais été clôturés parce que la DSI a oublié, ou parce que le fournisseur ne prend pas en charge le déprovisionnement automatisé - constituent une surface de fuite constante. Le contrôle ISO 27001 A.9.2 et SOC 2 CC6.2 exigent tous deux un processus documenté pour retirer l'accès. Le déprovisionnement manuel échoue de manière prévisible : le ticket de départ est oublié, le compte reste actif. SCIM rend le déprovisionnement automatique et auditable - l'IdP déclenche la requête de désactivation, le SP la journalise, et ce journal est l'artefact d'audit.

Le fossé des outils marketing#

La plupart des catégories de SaaS d'entreprise - RH, CRM, ITSM, hébergement de code - fournissent le SSO sur des plans qu'une équipe mid-market peut réellement acheter. Les outils marketing ont été plus lents. Le pattern que je vois systématiquement : le SSO est listé comme une fonctionnalité « Enterprise », facturé à un palier séparé qui coûte 500 à 2 000 $/mois au-dessus du plan Business. La sous-entendu est que le SSO est un upsell de luxe pour les grandes organisations, pas un contrôle de sécurité de base.

Cette formulation est de plus en plus incompatible avec la façon dont la DSI évalue les fournisseurs. Quand un outil marketing manipule les données de clic d'utilisateurs identifiables, il entre dans le périmètre du programme de gouvernance des accès de l'entreprise, quelle que soit la catégorie. Verrouiller le SSO derrière un palier premium signifie que l'équipe marketing utilise l'outil en dehors de l'IdP - l'exact contraire de ce que la DSI tente d'empêcher.

Les fournisseurs qui incluent le SSO au palier Business sans surcoût séparé sont l'exception. Parmi les raccourcisseurs d'URL : Elido inclut le SSO SAML/OIDC et le provisionnement SCIM sur le plan Business via WorkOS. Bl.ink inclut le SSO dans son plan Team. Loops (automatisation email) et Customer.io fournissent tous deux le SSO sur Business sans verrou Enterprise séparé.

Quand un fournisseur ne liste le SSO que sous « Contactez les ventes pour le tarif Enterprise », vous regardez un workflow de déprovisionnement manuel pour chaque transition d'employé, aussi longtemps que cet outil reste dans la stack.

Paysage IdP et compatibilité#

Six IdP dominent la DSI d'entreprise :

Okta est l'IdP cloud le plus courant en entreprise US. Okta fournit SAML 2.0, OIDC et une interface SCIM raffinée. Un fournisseur listé dans l'Okta Integration Network avec SCIM confirmé signifie que la configuration de l'équipe IT est documentée et testée ; sinon, ils écrivent une intégration sur mesure.

Microsoft Entra ID (anciennement Azure AD) est le défaut des boutiques Microsoft 365. Son agent de provisionnement SCIM poll le endpoint de l'application - l'intervalle par défaut est de 40 minutes, donc le déprovisionnement n'est pas instantané. À mettre en avant lors de la revue achats.

JumpCloud prend en charge SAML 2.0, OIDC et SCIM 2.0. Populaire auprès des équipes mid-market qui veulent un annuaire cloud sans AD on-premises.

Google Workspace utilise OIDC nativement ; SAML 2.0 est disponible pour la compatibilité avec les applications historiques. Les intégrations SCIM tierces suivent le chemin standard RFC 7644.

OneLogin maintient SAML 2.0, OIDC et SCIM. Courant dans les organisations mid-market qui se sont standardisées avant la consolidation du marché par Okta.

WorkOS est une plateforme côté fournisseur (pas un IdP utilisateur final) que les applications SaaS utilisent pour implémenter SSO et SCIM. Un fournisseur qui dit « nous utilisons WorkOS » exprime simultanément une compatibilité avec Okta, Entra, JumpCloud, Google et OneLogin. L'intégration SSO d'Elido est bâtie sur WorkOS. L'implication pratique pour la DSI : si vous pouvez pointer Okta ou Entra vers un endpoint SCIM, l'intégration fonctionne sans configuration spécifique au fournisseur.

Provisionnement JIT vs provisionnement SCIM#

Le provisionnement Just-in-Time crée un compte utilisateur la première fois que l'utilisateur s'authentifie via SSO. Aucune étape de pré-provisionnement n'est requise ; les attributs viennent de l'assertion SAML ou du token OIDC.

Le JIT résout proprement la moitié provisionnement. La moitié déprovisionnement est le problème. Quand l'utilisateur est retiré de l'IdP, sa session SSO cesse de fonctionner - mais le compte dans l'application SaaS persiste. Les tokens API à longue durée de vie peuvent toujours fonctionner. Le compte apparaît dans tout audit des utilisateurs actifs.

Pour les environnements ISO 27001 ou SOC 2, le JIT seul est insuffisant. La question d'audit n'est pas « cet employé peut-il se connecter ? » mais « existe-t-il une trace auditable que l'accès a été clôturé ? ». Le JIT ne génère pas cette trace. SCIM si : l'événement DELETE ou { "active": false } est journalisé à la fois côté IdP et côté SP, horodaté, et requêtable.

Si votre revue fournisseur exige des preuves de déprovisionnement, demandez spécifiquement si le déprovisionnement SCIM 2.0 est pris en charge. Un fournisseur qui répond « oui, nous prenons en charge le SSO » alors que la question portait sur SCIM répond à une question différente.

Mappage des rôles : groupe IdP vers rôle SaaS#

Le pattern standard : l'IdP a deux groupes - marketing-team (tout le personnel) et marketing-leads (les chefs d'équipe). L'application SaaS a deux rôles : Marketer et Admin. L'équipe IT configure le mappage une fois : marketing-team → Marketer, marketing-leads → Admin. Quand quelqu'un change de groupe, la synchronisation SCIM suivante met à jour son rôle automatiquement.

SCIM porte l'appartenance au groupe via la ressource Groups (GET /Groups, POST /Groups, PATCH /Groups/:id). Toutes les implémentations SCIM ne prennent pas en charge la synchronisation des groupes - certains fournisseurs implémentent uniquement le provisionnement utilisateur, ce qui signifie que le mappage des rôles requiert toujours une configuration manuelle par utilisateur. Demandez au fournisseur spécifiquement si le push de groupes SCIM est pris en charge et si le mappage des rôles est configurable par l'admin sans ticket de support.

Pour les organisations basées dans l'UE, les données d'appartenance au groupe IdP qui circulent via SCIM peuvent elles-mêmes constituer des données personnelles au sens de l'article 4(1) du RGPD. L'article résidence des données dans l'UE pour le marketing couvre ce que votre DPA doit dire sur la couche de données d'identité. Votre fournisseur SaaS est sous-traitant pour ces données, et le DPA doit l'aborder explicitement.

Ce qu'il faut demander aux achats#

Cinq questions qui déterminent si l'intégration SSO/SCIM d'un outil marketing est une demi-journée de configuration IT ou un projet de plusieurs semaines :

URL des métadonnées SAML. Le fournisseur peut-il fournir une URL statique pointant vers ses métadonnées SP (entity ID, URL ACS, certificat de signature) ? C'est ce que vous collez dans Okta ou Entra. La saisie manuelle de métadonnées par client est un signal d'alarme.

Endpoint SCIM et méthode d'authentification. Quelle est l'URL de base SCIM ? Le bearer token est le standard ; OAuth 2.0 client credentials est plus complexe. Quelle est la cadence de rotation du token ? Un token statique qui ne tourne jamais est une responsabilité.

Latence de déprovisionnement. Quand l'IdP envoie PATCH /Users/:id { "active": false } ou DELETE, à quelle vitesse l'accès est-il clôturé ? L'intervalle de provisionnement d'Entra est par défaut de 40 minutes côté IdP. Le fournisseur doit s'engager sur une fenêtre de traitement une fois la requête arrivée. La combinaison des deux latences est ce sur quoi votre auditeur SOC 2 vous interrogera.

Support du push de groupes. Le push de groupes SCIM est séparé du provisionnement utilisateur SCIM. Si le fournisseur n'implémente que la synchronisation utilisateur, le mappage des rôles nécessite une configuration manuelle par utilisateur. Demandez spécifiquement.

Support de tuile IdP. L'application peut-elle être ajoutée comme tuile dans le tableau de bord Okta ou Entra et prend-elle en charge le login IdP-initié ?

La couche de conformité#

Le contrôle A.9.2 de l'Annexe A d'ISO 27001 exige que les droits d'accès des utilisateurs soient accordés, revus et clôturés selon un processus documenté. A.9.3 exige que les utilisateurs s'authentifient uniquement avec des identifiants qui leur sont attribués. SCIM est le mécanisme opérationnel qui connecte « offboarding RH » à « accès SaaS révoqué » sans étapes manuelles.

SOC 2 CC6.2 exige que les entités enregistrent et autorisent les utilisateurs avant d'accorder l'accès. CC6.3 exige une revue d'accès périodique et un retrait. Le journal de déprovisionnement SCIM - un enregistrement horodaté du moment où l'IdP a demandé à l'application SaaS de désactiver ou supprimer un utilisateur - est l'artefact d'audit qui démontre la conformité CC6.3 pour chaque application dans le périmètre.

Elido est certifié ISO 27001. SOC 2 Type II est en cours, cible H2 2026. La posture d'identité - SAML/OIDC via WorkOS, déprovisionnement SCIM 2.0, mappage des rôles basé sur les groupes - est documentée sur la page trust et le mémo solutions/enterprise. Des BAA sont disponibles sur le plan Business pour les workflows HIPAA-adjacents.

L'article cornerstone RGPD pour les raccourcisseurs d'URL couvre l'article 28 et l'article 32 en intégralité. SSO et SCIM sont les contrôles techniques de l'article 32 - authentification via SSO, déprovisionnement via SCIM - pas des fonctionnalités autonomes. Ce sont des composants de la posture de sécurité que votre DPO évalue lors de la revue article 32.

/pricing présente la répartition des plans et où apparaissent SSO/SCIM. /solutions/compliance est le résumé orienté équipe achats. La conversation sur les preuves de déprovisionnement appartient au même appel d'achat que le DPA, la liste des sous-traitants et l'engagement de résidence des données - ce sont les questions qui déterminent si un outil marketing passe la revue de sécurité.

NIST SP 800-63-3 Digital Identity Guidelines, consulté le 2026-05-12, est le cadre de référence pour les niveaux d'assurance et les types d'authentificateurs qui sous-tendent de nombreuses exigences de politique IdP d'entreprise. La section fédération - 800-63C - est directement pertinente pour la configuration de l'intégration SAML et OIDC.