Quittez Okta, Auth0 ou Entra sans big-bang.
Une migration d'IdP réussie est une coexistence organisée : les deux fournisseurs tournent en parallèle, chaque application bascule à son rythme, et l'ancien IdP ne s'éteint qu'en dernier. Voici notre méthode, réponse franche sur les mots de passe comprise.
Les trois questions qui bloquent une migration
Réponses franches, avant tout le reste.
Et les mots de passe ?
L'import de hashes de mots de passe n'est pas supporté, et nous préférons vous le dire. Ce qui fonctionne : les deux IdP coexistent, chaque utilisateur est invité dans Obexal et recrée un mot de passe propre au premier login (politique alignée NIST), ou passe directement à une passkey et sort du mot de passe.
Une bascule app par app
Obexal se fédère en OIDC ou SAML à côté de votre IdP actuel. Chaque application bascule individuellement, se teste, puis passe en production. Pas de big-bang, pas d'interruption imposée.
Le provisioning aval continue
Le SCIM sortant provisionne vos applications aval et déprovisionne automatiquement à la suspension, avec échecs audités. Arrivées et départs continuent de circuler pendant toute la transition.
La trajectoire de bascule
Le retour arrière reste disponible tout du long : tant que l'ancien IdP vit, une application peut y repointer en quelques minutes.
Ce que change la bascule
Nous ne notons pas les concurrents : comparez votre situation actuelle avec ce qu'Obexal s'engage à fournir.
| Ce que vous avez aujourd'hui | Avec Obexal | |
|---|---|---|
| Juridiction et hébergement des données | Dépend de votre fournisseur et de votre contrat | UE : hébergé en France, datacenter en région parisienne, résidence des données en UE |
| Standards ouverts et documentés | À vérifier application par application | OIDC, OAuth 2.1, SAML 2.0 et SCIM 2.0, avec contrat OpenAPI 3.1 public |
| Identité des agents IA | Souvent des comptes de service génériques | Identité de premier rang par agent : propriétaire, expiration, plafonds, kill switch |
| Réversibilité | À évaluer avant de signer | Standards ouverts à l'entrée comme à la sortie : vous pouvez repartir comme vous êtes venu |
Un guide par point de départ
Trois origines, un même canevas : inventorier, mapper, basculer.
Depuis Okta
Inventoriez vos applications OIDC et SAML, vos groupes et vos politiques MFA, puis recréez-les dans Obexal application par application. Le guide propose un ordre de bascule.
Depuis Auth0
Même canevas : applications OIDC et SAML, groupes, politiques MFA. Le guide couvre aussi la connexion sociale Google et Microsoft, prise en charge nativement par Obexal.
Depuis Microsoft Entra
Applications OIDC et SAML, groupes et politiques MFA se mappent sur les mêmes standards. Le guide détaille la coexistence avec un annuaire AD via LDAP entrant.
Le plan de coexistence en quatre étapes
Des durées indicatives et prudentes : chaque parc applicatif est différent.
1. Importer l'annuaire
Provisionnez les utilisateurs via SCIM 2.0 entrant (/scim/v2/Users) ou connectez votre annuaire en LDAP ; les groupes se recréent dans l'annuaire Obexal. Comptez quelques heures à quelques jours selon la taille.
2. Fédérer côte à côte
Déclarez Obexal comme fournisseur OIDC ou SAML à côté de l'IdP actuel et basculez une première application pilote. Une journée suffit souvent pour la première app.
3. Inviter les utilisateurs, recréer les accès
Envoyez les invitations (le mot de passe se recrée au premier login sous politique alignée NIST, passkeys proposées) et reconstruisez vos règles d'accès en politiques versionnées, simulées sur 30 jours de connexions réelles avant application.
4. Provisionner l'aval, puis décommissionner
Activez le SCIM sortant, vérifiez le déprovisionnement automatique, basculez les dernières applications, puis éteignez l'ancien IdP. La plupart des migrations s'étalent sur quelques semaines, app par app, sans précipitation.
Qui vous accompagne : Obexal est édité par une société française en cours de structuration ; le fondateur répond directement, du premier inventaire au décommissionnement. Écrivez-nous ou appelez le +33 9 84 25 52 61.
Ce qui se mappe, et comment
- Utilisateurs
- SCIM 2.0 entrant (/scim/v2/Users) ou LDAP/AD entrant
- Groupes
- Recréés dans l'annuaire Obexal, qui gère les groupes nativement
- Applications
- OIDC et SAML 2.0, environ 40 connecteurs plus apps personnalisées
- Mots de passe
- Non importés : recréés au premier login (invitation, politique alignée NIST), passkeys proposées
- Provisioning aval
- SCIM 2.0 sortant, déprovisionnement automatique, échecs audités
- Règles d'accès
- Politiques versionnées, simulation sur 30 jours de connexions réelles, restauration
- MFA
- Passkeys WebAuthn, TOTP, code e-mail, step-up
- Audit
- Journal d'audit immuable, flux temps réel, export
FAQ migration
Pouvez-vous importer nos hashes de mots de passe ?
Non, et nous préférons être clairs : l'import de hashes n'est pas supporté. La méthode qui fonctionne est la coexistence : chaque utilisateur recrée un mot de passe au premier login Obexal via une invitation, sous politique alignée NIST 800-63B (hachage Argon2id, refus des mots de passe compromis vérifié 100 % en local). C'est aussi le meilleur moment pour proposer les passkeys.
Devons-nous tout migrer d'un coup ?
Non. Obexal tourne à côté de votre IdP actuel comme fournisseur OIDC ou SAML. Basculez les applications une à une et ne déplacez la connexion que lorsque vous êtes prêts.
Comment revenir en arrière si un problème survient ?
Tant que l'ancien IdP vit, chaque application peut y repointer en quelques minutes, app par app. C'est exactement pour cela que le décommissionnement est la dernière étape, jamais la première.
Comment les utilisateurs et les groupes arrivent-ils dans Obexal ?
Les utilisateurs par SCIM 2.0 entrant sur /scim/v2/Users, ou par LDAP. Le SCIM entrant couvre la ressource Users ; les groupes se gèrent directement dans l'annuaire Obexal.
Le provisioning aval continue-t-il pendant la transition ?
Oui. Le SCIM sortant provisionne vos applications aval et déprovisionne automatiquement à la suspension, avec échecs audités, pendant toute la période de coexistence.
Combien de temps dure une migration ?
Cela dépend du nombre d'applications et d'intégrations. Une première application pilote bascule souvent en une journée ; la plupart des parcs s'étalent sur quelques semaines. Nous préférons une fourchette prudente à une promesse.
Que change Obexal pour les agents IA ?
Chaque agent reçoit une identité de premier rang : propriétaire humain, expiration, plafond de scopes, TTL maximal, kill switch et délégation via Token Exchange (RFC 8693). Voir Identité des agents IA.
Où nos données sont-elles hébergées, et avec quelles certifications ?
Hébergement en France, datacenter en région parisienne, résidence des données dans l'UE. Aucune dépendance hors UE dans le chemin des requêtes, aucun CDN externe, polices auto-hébergées. Certifications : non certifié ISO 27001, SOC 2 ou HDS à ce jour ; correspondance ISO 27001:2022 documentée ; feuille de route SecNumCloud engagée.
Organisons la bascule.
Décrivez votre parc (applications, annuaire, contraintes) : le fondateur vous répond directement avec un plan de coexistence.