Migrer d'Okta vers Auth0 : stratégie, risques et exécution

Comment migrer votre IAM de Okta vers Auth0 ? Comparaison des fonctionnalités, stratégie de migration des utilisateurs et gestion des SSO existants.

Par Auth0.Expert · 2025-05-02 · 13 min de lecture

Okta Migration IAM

Migrer d'Okta vers Auth0 : guide complet

TL;DR

Depuis le rachat d'Auth0 par Okta en 2021, certaines organisations veulent clarifier leur position. D'autres migrent d'Okta vers Auth0 pour des raisons de DX, de prix ou de fonctionnalités. Ce guide présente la stratégie.

---

Pourquoi migrer d'Okta vers Auth0 ?

Ce tableau synthétise les principales raisons techniques et business pour passer d'Okta à Auth0.

| Raison | Détail | |--------|--------| | DX supérieure | Auth0 a des SDKs plus modernes, des docs plus claires | | Prix | Auth0 peut être moins cher pour les cas d'usage SaaS | | Flexibilité | Actions vs Okta Workflows : Auth0 est plus developer-first | | Multi-tenant | Auth0 Organizations > Okta Multi-tenancy | | API-first | Auth0 Management API plus complète |

---

Comparaison fonctionnelle Okta vs Auth0

Voici les différences clés entre Okta et Auth0 sur les fonctionnalités IAM importantes.

| Fonctionnalité | Okta | Auth0 | |----------------|------|-------| | Universal Login | ✅ (Okta-hosted) | ✅ (Universal Login) | | Custom domain | ✅ | ✅ | | MFA | ✅ Complet | ✅ Complet | | WebAuthn | ✅ | ✅ | | SAML SP/IdP | ✅ | ✅ | | OIDC | ✅ | ✅ | | Organizations | Okta SaaS | Auth0 Organizations (meilleur) | | Actions/Workflows | Okta Workflows | Auth0 Actions (plus simple) | | API Management | ✅ (avec API AM) | ✅ Native | | Attack Protection | ✅ ThreatInsight | ✅ Attack Protection | | Log streaming | ✅ | ✅ | | Terraform | ✅ | ✅ |

---

Phase 1 : Inventaire et cartographie

Avant tout, il est essentiel d'exporter la liste des applications et des connexions SSO d'Okta pour préparer la migration et cartographier les dépendances.

# Exporter la liste des applications Okta
# Via Okta Management API
curl https://YOUR_OKTA_DOMAIN/api/v1/apps   -H "Authorization: SSWS YOUR_OKTA_API_TOKEN" |   jq '[.[] | {id, label, status, signOnMode}]'

# Exporter les connexions SSO (IdPs Okta)
curl https://YOUR_OKTA_DOMAIN/api/v1/idps   -H "Authorization: SSWS YOUR_OKTA_API_TOKEN" |   jq '[.[] | {id, name, type, status}]'

---

Phase 2 : Migrer les utilisateurs

Ces scripts permettent d'extraire les utilisateurs actifs d'Okta puis de transformer leur format pour un import dans Auth0, en conservant les attributs essentiels.

# Exporter les utilisateurs Okta
import requests

def export_okta_users(okta_domain: str, api_token: str) -> list:
    users = []
    url = f"https://{okta_domain}/api/v1/users?limit=200&status=ACTIVE"
    headers = {"Authorization": f"SSWS {api_token}"}

    while url:
        resp = requests.get(url, headers=headers)
        users.extend(resp.json())

        # Pagination via Link header
        links = resp.headers.get('Link', '')
        next_link = None
        for link in links.split(','):
            if 'rel="next"' in link:
                next_link = link.split(';')[0].strip()[1:-1]
        url = next_link

    return users

# Transformer le format Okta → Auth0
def transform_user(okta_user: dict) -> dict:
    profile = okta_user['profile']
    return {
        'email': profile.get('email') or profile.get('login'),
        'email_verified': True,  # Okta vérifie les emails
        'given_name': profile.get('firstName'),
        'family_name': profile.get('lastName'),
        'name': f"{profile.get('firstName', '')} {profile.get('lastName', '')}".strip(),
        'phone_number': profile.get('mobilePhone'),
        'user_metadata': {
            'department': profile.get('department'),
            'title': profile.get('title'),
            'manager': profile.get('manager'),
        },
        'app_metadata': {
            'okta_id': okta_user['id'],
            'okta_status': okta_user['status'],
            'migrated_at': datetime.utcnow().isoformat(),
        }
    }

Ce code automatise l'extraction et la transformation des utilisateurs Okta, facilitant leur réimport dans Auth0 dans un format compatible.

---

Phase 3 : Migrer les applications SSO

Lors de la migration, il est important de traiter individuellement chaque application SSO pour reproduire les configurations SAML dans Auth0.

SAML Applications (Okta → Auth0)

Ce code structure la migration des applications SAML d'Okta vers Auth0 en référençant chaque app et ses nouvelles valeurs de mapping.

# Pour chaque application SAML dans Okta,
# créer l'équivalent dans Auth0

saml_apps = {
    "Salesforce": {
        "okta_entity_id": "https://yourco.my.salesforce.com",
        "auth0_settings": {
            "audience": "https://yourco.my.salesforce.com",
            "recipient": "https://yourco.my.salesforce.com/sso/saml/login",
            "mappings": {
                "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
            }
        }
    },
    "Zendesk": {
        "okta_entity_id": "yourco.zendesk.com",
        "auth0_settings": {
            "audience": "yourco.zendesk.com",
            "recipient": "https://yourco.zendesk.com/access/saml",
        }
    }
}

Ce code permet de mapper les paramètres SAML entre Okta et Auth0 pour chaque application à migrer.

---

Phase 4 : Migration des mots de passe (sans reset forcé)

La migration des hashs de mot de passe permet aux utilisateurs de conserver leur mot de passe sans réinitialisation, ce qui simplifie leur expérience.

// Auth0 Migrations : importer les hashs de mot de passe
// Nécessite d'avoir exporté les hashs depuis Okta
// (contact Okta support pour l'export)

const users = [
  {
    "email": "[email protected]",
    "custom_password_hash": {
      "algorithm": "bcrypt",
      "hash": {
        "value": "$2y$10$...",
        "encoding": "utf8"
      }
    }
  }
];

// Import via Auth0 Jobs API
const job = await fetch('https://YOUR_DOMAIN.auth0.com/api/v2/jobs/users-imports', {
  method: 'POST',
  headers: {
    Authorization: `Bearer ${MGMT_TOKEN}`,
    'Content-Type': 'multipart/form-data',
  },
  body: formData, // users JSON + connection_id
});

Ce script illustre le processus d'import des utilisateurs avec leur mot de passe existant dans Auth0 via l’API Jobs.

---

Phase 5 : Cut-over plan

Pour une migration IAM sans interruption, il est primordial de suivre un plan détaillé avec tests et rollback.

Semaine 1-4  : Configuration Auth0 (tenant, apps, connexions)
Semaine 5-6  : Migration utilisateurs (import en masse)
Semaine 7    : Tests d'intégration toutes les applications
Semaine 8    : Migration progressive (10% → 50% → 100%)
              Feature flag : nouveau login Auth0 pour 10%
Semaine 9    : Cut-over complet
              DNS change : login.yourco.com → Auth0
Semaine 10   : Désactivation Okta (après validation)

Ce plan détaille chaque étape de migration pour garantir une transition progressive et sécurisée.

---

Risques et mitigations

Il est important d'identifier les risques de migration Auth0 et de prévoir des actions correctives.

| Risque | Probabilité | Mitigation | |--------|-------------|------------| | Perte d'accès SSO | Moyen | Garder Okta actif 30j après cut-over | | Mots de passe non migrés | Élevé | Migration flow avec reset optionnel | | Applications SAML incorrectes | Élevé | Test exhaustif en staging | | Utilisateurs bloqués | Faible | Rollback plan + support 24/7 |

---

> 🔄 Migration Okta → Auth0 : nous avons migré plusieurs organisations de Okta vers Auth0 avec zéro interruption de service. Contactez-nous pour un plan de migration personnalisé.

📞 +33 1 23 45 67 89 · 📧 [email protected]