SCIM : le provisioning automatique des identités

SCIM automatise le cycle de vie des comptes utilisateurs. Quand un collaborateur arrive, son compte est créé automatiquement dans les applications connectées. Quand il part, ses comptes sont désactivés dans la foulée, sans attendre qu'un administrateur y pense. Sans SCIM, vous gérez manuellement les comptes dans chaque application, avec les risques de sécurité et d'erreurs que cela implique.

Ce que vous allez apprendre

Ce guide vous explique SCIM, le standard pour synchroniser automatiquement les identités entre l'IdP et les applications. À la fin, vous saurez :

• Comprendre pourquoi SCIM est nécessaire (et ses alternatives)
• Maîtriser les opérations SCIM : création, modification, désactivation
• Configurer un offboarding propre (désactiver + révoquer)
• Anticiper les pièges courants d'implémentation

Prérequis : avoir lu Les bases de l'IAM, OpenID Connect et SAML 2.0.

Le problème : les comptes orphelins

Le provisioning est la création et la mise à jour des comptes dans les applications ; son inverse, le déprovisioning, est leur désactivation. Sans provisioning automatique, voici ce qui se passe :

1. Un employé arrive → création manuelle du compte dans chaque application
2. L'employé change de service → modification manuelle des groupes
3. L'employé part → on oublie de désactiver certains comptes

Résultat : des comptes orphelins qui persistent pendant des mois, voire des années. Le risque n'est pas théorique : ces comptes gardent leurs droits, n'apparaissent dans aucune revue puisque personne ne les réclame, et échappent souvent au MFA faute d'un utilisateur pour l'activer. Ils constituent une porte d'entrée idéale, sans propriétaire pour remarquer une connexion suspecte.

Pourquoi c'est fréquent

Les comptes orphelins s'accumulent surtout dans les applications SaaS : aucun inventaire ne les signale tant que le déprovisioning reste manuel.

Les approches de provisioning

Just-in-Time (JIT) provisioning

Le compte est créé au premier login via SSO (OIDC ou SAML).

Comment ça marche :

1. L'utilisateur se connecte pour la première fois
2. L'application reçoit l'assertion SAML ou l'ID Token
3. L'application crée le compte à partir des attributs reçus

Avantages :

• Simple à mettre en place
• Pas de synchronisation à maintenir

Limites :

• Le compte n'existe qu'au premier login
• Pas de pré-configuration (groupes, permissions spécifiques)
• Pas de deprovisioning automatique

SCIM provisioning

L'IdP pousse les changements vers les applications dès qu'il les détecte. La différence de fond avec le JIT tient à ce sens de circulation : ici, l'IdP n'attend pas que l'utilisateur se manifeste, il agit dès que la donnée change côté annuaire. C'est ce qui rend le deprovisioning possible, un départ n'étant jamais suivi d'une connexion qui aurait pu servir de déclencheur.

Comment ça marche :

1. Un utilisateur est créé/modifié/désactivé dans l'IdP
2. L'IdP envoie une requête SCIM à l'application
3. L'application applique le changement

Avantages :

• Comptes pré-créés avant le premier login
• Synchronisation des groupes et attributs
• Deprovisioning automatique

Limites :

• L'application doit supporter SCIM
• Configuration plus complexe

JIT + SCIM = complémentaires

En pratique, on combine souvent les deux :

• SCIM pour le provisioning initial et le deprovisioning
• JIT pour les mises à jour d'attributs au login

SCIM : le protocole

SCIM (System for Cross-domain Identity Management) est défini par deux RFC :

• RFC 7643 : Schéma SCIM (objets User, Group)
• RFC 7644 : Protocole SCIM (API REST)

Cette séparation en deux documents a une conséquence concrète quand vous qualifiez une application : le support de SCIM n'est pas binaire. Un éditeur peut implémenter le schéma de la RFC 7643 tout en ne proposant qu'une partie des opérations de la RFC 7644, typiquement POST et PUT sans PATCH. Demandez toujours la liste des opérations supportées, pas seulement la mention « compatible SCIM 2.0 ».

Architecture SCIM

Le sens des flèches est le point important du schéma, et il surprend souvent : c'est l'IdP qui joue le rôle de client et l'application qui joue le rôle de serveur. Autrement dit, c'est l'annuaire central qui appelle l'API REST exposée par chaque application, et non l'inverse. Cette inversion explique deux contraintes pratiques : l'application doit publier un endpoint SCIM joignable depuis l'IdP, et chaque application détient son propre jeton d'authentification que l'IdP conserve.

Source · SVG

Échap pour fermer, + et − pour zoomer, défilement pour se déplacer. 100 % − Ajuster + Fermer

L'IdP agit comme SCIM Client (pousse les changements). L'application agit comme SCIM Server (reçoit et applique).

Les objets SCIM

Le schéma RFC 7643 définit deux ressources, User et Group, et une extension standard EnterpriseUser (matricule, service, responsable). La ressource User porte déjà des attributs multivalués roles et entitlements (§4.1.2) : un rôle simple n'exige donc pas d'extension. Seul un attribut vraiment propre à une application (licence, profil maison) passe par une extension de schéma de l'éditeur, déclarée dans le tableau schemas. Lisez donc les exemples ci-dessous en regardant d'abord ce tableau : il indique quelle grammaire l'application doit savoir interpréter.

User

Dans la charge utile ci-dessous, trois champs pilotent tout le cycle de vie : externalId fait le lien avec l'IdP, active porte l'activation ou la désactivation du compte, et userName sert d'identifiant de connexion. Les autres attributs sont du confort d'affichage. Notez que id n'est pas fourni par l'IdP : c'est l'application qui le génère et le renvoie à la création.

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "2819c223-7f76-453a-919d-413861904646",
  "externalId": "alice.martin",
  "userName": "alice.martin@example.com",
  "name": {
    "givenName": "Alice",
    "familyName": "Martin"
  },
  "emails": [
    {
      "value": "alice.martin@example.com",
      "type": "work",
      "primary": true
    }
  ],
  "active": true,
  "groups": [
    {
      "value": "developers",
      "display": "Developers Team"
    }
  ],
  "meta": {
    "resourceType": "User",
    "created": "2024-02-06T10:00:00Z",
    "lastModified": "2024-02-06T10:00:00Z"
  }
}

Attributs clés

Retenez surtout la paire id / externalId : c'est l'une des sources les plus fréquentes d'incidents de synchronisation. Chaque système garde son propre identifiant, et l'IdP doit mémoriser le id renvoyé par l'application pour pouvoir la mettre à jour ensuite. Si cette correspondance est perdue, l'IdP ne sait plus quel compte modifier et recrée des doublons au lieu de désactiver l'existant.

Attribut	Description
id	Identifiant unique côté application
externalId	Identifiant unique côté IdP
userName	Identifiant de login (souvent l'email)
active	Compte actif ou désactivé
emails	Liste des adresses email
groups	Groupes auxquels appartient l'utilisateur

Glissez pour voir

Group

Un objet Group ne contient que son nom d'affichage et la liste de ses membres, référencés par leur id côté application. Conséquence directe : ajouter quelqu'un à un groupe se fait en modifiant le groupe, pas l'utilisateur. Beaucoup d'applications n'implémentent d'ailleurs que la ressource User et ignorent Group, auquel cas les appartenances doivent être gérées autrement, par exemple via un claim transmis au moment de la connexion SSO.

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
  "id": "group-123",
  "displayName": "Developers Team",
  "members": [
    {
      "value": "2819c223-7f76-453a-919d-413861904646",
      "display": "Alice Martin"
    }
  ]
}

Les opérations SCIM

CRUD sur les utilisateurs

Deux lignes de ce tableau méritent votre attention. PUT remplace l'objet entier : tout attribut absent de la charge utile est effacé côté application, ce qui écrase parfois des données que l'IdP ne connaît pas. PATCH ne touche que les chemins listés, c'est donc l'opération à privilégier pour un changement ciblé comme une désactivation. Quant à DELETE, il est marqué « rare » à dessein : la plupart des intégrations ne l'utilisent jamais.

Opération	Méthode HTTP	Endpoint	Usage
Créer	POST	/Users	Nouvel employé
Consulter	GET	/Users/{id}	Vérifier un compte
Lister	GET	/Users?filter=...	Rechercher des utilisateurs
Modifier	PUT	/Users/{id}	Remplacement complet
Modifier partiellement	PATCH	/Users/{id}	Modification ciblée
Supprimer	DELETE	/Users/{id}	Suppression (rare)

Glissez pour voir

Exemples de requêtes

Les trois échanges ci-dessous couvrent l'essentiel d'une intégration : créer, désactiver, rechercher. Un détail les relie : le type de contenu application/scim+json, exigé par la RFC 7644. Beaucoup d'applications renvoient une erreur 415 Unsupported Media Type si vous envoyez un simple application/json, et c'est la première chose à vérifier quand un provisioning échoue sans message clair.

Créer un utilisateur :

POST /scim/v2/Users
Content-Type: application/scim+json
Authorization: Bearer <token>

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "alice.martin@example.com",
  "name": {
    "givenName": "Alice",
    "familyName": "Martin"
  },
  "emails": [{"value": "alice.martin@example.com", "primary": true}],
  "active": true
}

Désactiver un utilisateur (PATCH) :

PATCH /scim/v2/Users/2819c223-7f76-453a-919d-413861904646
Content-Type: application/scim+json

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [
    {
      "op": "replace",
      "path": "active",
      "value": false
    }
  ]
}

Rechercher des utilisateurs :

GET /scim/v2/Users?filter=userName eq "alice.martin@example.com"

Le cycle de vie complet

Les trois moments qui suivent portent un nom dans le vocabulaire IAM : Joiner, Mover, Leaver. C'est le même flux de données à chaque fois, seule l'opération SCIM change. Le point de départ est toujours le système RH, jamais l'IdP : si un compte est créé directement dans l'annuaire, il sortira du cycle et deviendra un compte orphelin.

Onboarding (arrivée)

L'étape 4 est celle qu'on oublie de vérifier. Tant que l'IdP n'a pas mémorisé le id retourné par l'application, il ne pourra ni modifier ni désactiver ce compte ensuite. Un onboarding qui « fonctionne » mais dont la réponse n'a pas été enregistrée produit un compte que personne ne pourra fermer au départ du collaborateur.

1. Création dans le système source

   Le service RH enregistre l'arrivant dans son outil de référence (Workday, annuaire Active Directory...).

2. Synchronisation vers l'IdP

   L'IdP central (Keycloak, Okta) reçoit l'utilisateur.

3. Provisioning SCIM

   L'IdP pousse l'utilisateur vers les applications configurées.

4. Confirmation

   Chaque application retourne un id SCIM que l'IdP stocke pour les futures mises à jour.

Changement de poste (Mover)

Le changement de poste est le scénario le plus mal traité en pratique, parce qu'il exige un retrait de droits, pas seulement un ajout. Un PATCH qui ajoute le nouveau groupe sans retirer l'ancien laisse la personne cumuler les accès de ses deux postes. Au bout de quelques mobilités internes, ce cumul donne des comptes plus privilégiés que ceux des administrateurs.

1. Modification des groupes dans l'IdP

   L'utilisateur change d'équipe, ses groupes sont mis à jour.

2. PATCH SCIM vers les applications

   L'IdP envoie les modifications de groupes : ajout du nouveau, retrait de l'ancien.

3. Mise à jour des permissions

   L'application ajuste les accès selon les nouveaux groupes.

Offboarding (départ)

Suivez bien l'ordre des quatre étapes : elles vont de la source vers les extrémités. La désactivation dans l'IdP ne coupe rien toute seule, elle ne fait que déclencher les PATCH vers les applications. C'est l'étape 3, la révocation des tokens, qui met réellement fin aux accès en cours, et c'est justement celle que beaucoup d'applications n'implémentent pas.

1. Désactivation dans l'IdP

   Le compte est marqué active: false dans l'IdP, qui refuse dès cet instant toute nouvelle authentification.

2. PATCH SCIM : désactiver

   L'IdP envoie { "active": false } à toutes les applications.

3. Révocation des tokens

   Les applications invalident les sessions et tokens existants.

4. Audit

   L'IdP et chaque application journalisent la désactivation, pour pouvoir la prouver ensuite.

Désactiver ≠ Supprimer les sessions

Désactiver le compte empêche les nouveaux logins. Mais les sessions existantes peuvent persister ! Assurez-vous que l'application révoque aussi les tokens/sessions actifs.

Offboarding propre

Un offboarding est dit propre quand aucune des cinq garanties ci-dessous ne manque. Le critère de validation est simple à énoncer et rarement testé : quelques minutes après la désactivation dans l'IdP, plus aucune requête authentifiée au nom de cette personne ne doit aboutir, ni depuis un navigateur déjà ouvert, ni depuis un jeton d'API encore valide.

1. Le compte est désactivé (plus de nouveaux logins)
2. Les sessions actives sont terminées
3. Les tokens (access, refresh) sont révoqués
4. Les accès API sont bloqués
5. Les données sont conservées ou archivées selon la politique

Implémentation

Le tableau se lit en colonnes : la partie gauche est ce que l'IdP déclenche, la partie droite ce que l'application doit effectivement faire pour que la promesse tienne. Le N/A de la ligne 2 n'est pas un détail : SCIM n'a aucune opération pour tuer une session. Si l'application ne coupe pas ses sessions d'elle-même à la réception de active: false, la personne reste connectée jusqu'à expiration naturelle du cookie.

Étape	Action IdP	Action Application
1. Désactivation	active: false dans l'IdP	SCIM PATCH reçu
2. Sessions	N/A	Invalider toutes les sessions du user
3. Tokens	Révoquer les refresh tokens	Supprimer les tokens stockés
4. Audit	Logger le deprovisioning	Logger la désactivation

Glissez pour voir

Gestion des données

Le sort des données de la personne partie ne se décide pas au cas par cas au moment du départ : c'est une politique écrite à l'avance, sinon chaque offboarding devient une négociation. Les trois options ci-dessous s'excluent rarement, elles se combinent le plus souvent par type de donnée : conserver les traces d'audit, anonymiser les données personnelles au titre du RGPD, supprimer les brouillons personnels sans valeur.

Option	Quand l'utiliser
Conserver	Conformité, historique, audit
Anonymiser	RGPD, données personnelles
Supprimer	Demande explicite, données non critiques

Glissez pour voir

Pièges courants

Ces cinq pièges se manifestent tous à la conception de l'intégration, pas à l'exploitation. Ils se traitent donc avant la mise en production, dans l'ordre du tableau : commencez par vérifier que l'application supporte réellement SCIM (beaucoup annoncent « SSO » sans provisioning), puis validez le mapping des identifiants, puis seulement testez les scénarios. Les erreurs de la section « Erreurs fréquentes », en fin de page, apparaissent, elles, une fois le système en service.

Piège	Conséquence	Solution
L'app ne supporte pas SCIM	Provisioning manuel	Vérifier avant intégration
externalId vs id confondus	Échec des mises à jour	externalId = IdP, id = application
DELETE au lieu de désactiver	Perte d'historique	Toujours préférer active: false
Pas de révocation des sessions	Accès persistant après départ	Implémenter la révocation côté app
Mapping d'attributs incorrect	Données manquantes	Tester le mapping en pre-prod

Glissez pour voir

Configuration Keycloak + SCIM

Depuis Keycloak 26.8.0 (1er octobre 2026), l'API SCIM native est passée de préversion à supportée, et sa fonctionnalité est activée par défaut sur le serveur. Keycloak y joue le rôle de serveur SCIM : un système externe (plateforme de gouvernance des identités, SIRH, autre IdP) crée, lit, modifie et supprime les utilisateurs et les groupes d'un realm par les points d'accès standard de la RFC 7644, sous /realms/<realm>/scim/v2, sans passer par l'API REST d'administration propriétaire. Il faut en plus activer l'option SCIM API realm par realm (Realm settings, onglet General) et présenter un jeton porteur disposant des permissions voulues.

Cette API couvre le sens vers Keycloak. La documentation officielle ne décrit pas Keycloak en client SCIM qui pousserait ses comptes vers vos applications : ce second sens, celui du schéma de cette page, reste à vérifier version par version. Les Workflows, supportés depuis la 26.6, automatisent des étapes du cycle de vie (par exemple l'envoi d'un e-mail d'invitation à la création d'un compte) sans se substituer à un client SCIM. Si vous devez pousser des comptes vers des applications tierces, une extension communautaire comme celle ci-dessous reste une option, à condition de vérifier sa compatibilité avant chaque montée de version majeure : vous confiez alors le cycle de vie de vos comptes à un composant tiers dont le rythme de mise à jour ne suit pas forcément celui de Keycloak.

Avec l'extension scim-for-keycloak

L'installation passe par le mécanisme de providers de Keycloak : un fichier JAR déposé dans /opt/keycloak/providers/, puis un kc.sh build qui reconstruit l'image de démarrage. Ce build est obligatoire, un simple redémarrage ne charge pas l'extension. Sur un Keycloak déployé en conteneur, la conséquence pratique est qu'il faut reconstruire l'image ou monter le JAR dans un volume persistant, sinon l'extension disparaît au prochain redéploiement.

1. Installer l'extension

   # Ajouter le provider SCIM à Keycloak
   cp scim-for-keycloak.jar /opt/keycloak/providers/
   /opt/keycloak/bin/kc.sh build

2. Configurer le endpoint SCIM

   Dans Keycloak Admin → Realm Settings → SCIM

3. Configurer l'application cliente

   Entrer l'URL SCIM de l'application et le token d'authentification

4. Tester le provisioning

   Créer un utilisateur dans Keycloak et vérifier sa création dans l'application

Okta et Microsoft Entra ID (ex-Azure AD)

Ces IdP intègrent SCIM nativement, ce qui déplace la difficulté : le protocole n'est plus le sujet, le mapping des attributs le devient. C'est l'étape 4 qui prend le plus de temps, parce que chaque application attend ses champs sous un nom qui lui est propre. Passer par le catalogue d'applications plutôt que par une configuration SCIM générique vous évite ce travail : le connecteur embarque déjà le mapping validé par l'éditeur.

1. Ajouter l'application depuis le catalogue
2. Activer le provisioning
3. Entrer l'URL SCIM et le token de l'application
4. Mapper les attributs
5. Tester

SCIM vs autres approches

Le critère de choix n'est pas la qualité technique de chaque approche, c'est ce que l'application en face sait faire. Lisez la dernière colonne en premier : elle vous dit dans quel monde vous êtes. Une seule ligne devrait vous alerter, celle du JIT seul : sans deprovisioning, elle vous garantit des comptes orphelins à terme, et doit donc s'accompagner d'une revue d'accès périodique manuelle.

Approche	Avantages	Inconvénients	Usage
SCIM	Standard, quasi temps réel, deprovisioning	L'app doit le supporter	SaaS modernes
JIT (SSO)	Simple, pas de config	Pas de deprovisioning	Apps sans SCIM
LDAP sync	Robuste, mature	Plus complexe, polling	Apps on-prem
API custom	Flexible	Sur-mesure, maintenance	Legacy, cas spéciaux

Glissez pour voir

Erreurs fréquentes

Contrairement aux pièges de conception vus plus haut, ces quatre erreurs surviennent une fois l'intégration en service, et elles ont un point commun : elles ne produisent aucun message d'erreur visible. Un provisioning SCIM qui échoue le fait silencieusement, du côté de l'IdP, sur un compte qui n'existe pas encore et que personne ne cherche. D'où la ligne « Pas de monitoring » : sans alerte sur les échecs SCIM, vous découvrez le problème le jour d'un audit.

Erreur	Conséquence	Solution
Pas de test de deprovisioning	Comptes orphelins au premier départ	Tester le flow complet en pre-prod
Token SCIM en clair	Compromission possible	Stocker dans un vault
Pas de monitoring	Échecs silencieux	Alerter sur les erreurs SCIM
Mapping incomplet	Attributs manquants	Documenter et valider le mapping

Glissez pour voir

À retenir

Les 8 points clés

1. SCIM synchronise automatiquement les identités IdP → applications
2. L'IdP est SCIM Client, l'app est SCIM Server
3. Désactiver (active: false) plutôt que supprimer (préserve l'historique)
4. Un offboarding propre = désactiver + révoquer sessions + révoquer tokens
5. JIT crée au premier login, SCIM pré-crée et synchronise en continu
6. Tester le deprovisioning avant la mise en production
7. Surveiller les erreurs SCIM (échecs silencieux = comptes orphelins)
8. Keycloak 26.8 expose une API SCIM native en serveur : pour pousser des comptes vers des applications, il faut une extension

Contrôle de connaissances

Six questions tirées sur huit : la limite du JIT, qui est serveur SCIM, le couple id et externalId, PATCH contre PUT, l'erreur 415, le scénario Mover et ce que la désactivation ne coupe pas.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

Références

• RFC 7643, SCIM Core Schema
• RFC 7644, SCIM Protocol
• SCIM 2.0 Overview (simplecloud.info)

×

📖 Voir la documentation →