Auth0 à l'échelle : gérer des millions d'utilisateurs en production

Retour d'expérience sur la gestion de 50M+ utilisateurs avec Auth0 : architectures, optimisations et leçons apprises.

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

Scalabilité Architecture Grandes entreprises

Auth0 à l'échelle de millions d'utilisateurs

TL;DR

Auth0 gère des milliards d'authentifications par mois pour des clients comme Siemens, Pfizer et Mozilla. Ce guide partage les leçons apprises pour opérer Auth0 à grande échelle.

---

Profil : 50M utilisateurs, 2M logins/jour

Ce profil synthétise la volumétrie et les objectifs de performance d’une architecture Auth0 gérant des dizaines de millions d’utilisateurs actifs.

50 000 000 utilisateurs enregistrés
2 000 000 logins/jour (pic : 200 000/heure)
15 000 000 M2M tokens/mois
Latence cible : P95 < 300ms
Disponibilité : 99.99%

---

Architecture mise en place

Ce schéma décrit le parcours d’authentification d’un utilisateur ou d’une application, depuis la requête initiale jusqu’aux tokens délivrés, en détaillant chaque composant clé et ses avantages (scalabilité, personnalisation).

CDN (Cloudflare)
     ↓
Custom Domain (login.company.com) → Auth0 EU
     ↓
Auth0 Organizations (800 orgs client)
     ↓
├── SSO Enterprise (Azure AD, Okta) → 60% des logins
├── Google Social → 25% des logins
└── Email/Password → 15% des logins
     ↓
Auth0 Actions (4 actions, < 100ms total)
     ↓
Access Token (15min) + Refresh Token (30j, rotating)

---

Leçon 1 : Les Actions doivent être ultralégers

Ce code montre d'abord un exemple d'Action trop lente qui appelle des API externes à chaque connexion, puis une version optimisée utilisant un cache en app_metadata pour ne pas ralentir le login utilisateur.

// ❌ Ce que nous faisions (lent : +800ms)
exports.onExecutePostLogin = async (event, api) => {
  const userProfile = await fetch(CRM_API + '/users/' + event.user.user_id);
  const enriched = await userProfile.json();
  const permissions = await calculatePermissions(enriched);
  api.accessToken.setCustomClaim('permissions', permissions);
};

// ✅ Ce que nous faisons maintenant (< 2ms)
exports.onExecutePostLogin = async (event, api) => {
  // Tout est précalculé dans app_metadata par un worker asynchrone
  const meta = event.user.app_metadata || {};
  if (meta.permissions_cache && meta.permissions_cache_at) {
    const cacheAge = Date.now() - new Date(meta.permissions_cache_at).getTime();
    if (cacheAge < 24 * 60 * 60 * 1000) {  // < 24h
      api.accessToken.setCustomClaim('permissions', meta.permissions_cache);
      return;
    }
  }
  // Cache expiré : injecter les permissions de base, worker mettra à jour
  api.accessToken.setCustomClaim('permissions', meta.base_permissions || ['read:own']);
};

Ce code optimise le temps de login en n’exécutant aucune opération lente, tout en garantissant que les permissions utilisateurs sont toujours valides et à jour grâce à un processus de mise en cache.

---

Leçon 2 : Segmenter les tenants par usage

Ici, on illustre une architecture multi-tenant qui isole les usages (B2C, B2B, interne) afin d’offrir performances, sécurité et configuration adaptées à chaque profil.

Tenant PRODUCTION    : Utilisateurs finaux (B2C) — 50M MAU
Tenant ENTERPRISE    : Clients B2B (Organizations) — 5M MAU
Tenant INTERNAL      : Employés et outils internes — 2000 MAU

Avantages :
✅ SLA distinct par tenant
✅ Quotas séparés (rate limits)
✅ Logs isolés
✅ Branding distinct
✅ Configuration indépendante

---

Leçon 3 : Cache distribué pour les tokens M2M

Pour réduire les coûts et la charge sur Auth0, ce code met en place un cache Redis distribué d’accès aux tokens Machine-to-Machine, évitant des millions de requêtes inutiles chaque mois.

# Sans cache : 15M tokens × $0.50/1000 = $7 500/mois
# Avec cache : 500K tokens × $0.50/1000 = $250/mois

from redis import asyncio as aioredis
import json

redis = aioredis.from_url("redis://redis-cluster:6379", decode_responses=True)

async def get_m2m_token_cached(service_name: str, audience: str) -> str:
    cache_key = f"m2m_token:{service_name}:{audience}"

    # Vérifier le cache Redis
    cached = await redis.get(cache_key)
    if cached:
        return json.loads(cached)["token"]

    # Obtenir un nouveau token
    token_data = await fetch_new_m2m_token(service_name, audience)

    # Cacher jusqu'à 5 minutes avant expiration
    ttl = token_data["expires_in"] - 300
    await redis.setex(
        cache_key,
        ttl,
        json.dumps({"token": token_data["access_token"]})
    )

    return token_data["access_token"]

Ce script sécurise et optimise l'obtention des tokens d’accès machine, limitant les appels à Auth0 et maîtrisant significativement les coûts d’infrastructure.

---

Leçon 4 : Gestion de 800 Organizations

Ce script Python automatise l’onboarding d’un nouveau client B2B : création d’Organization, connexion SSO, ajout d’admin, et envoi de l’email de bienvenue.

# Script d'onboarding automatisé pour les nouveaux clients B2B

async def onboard_enterprise_client(
    company_name: str,
    company_domain: str,
    admin_email: str,
    sso_provider: str,  # 'azure-ad', 'okta', 'google-workspace'
    logo_url: str,
):
    # 1. Créer l'Organization
    org = await auth0.create_organization({
        "name": slugify(company_name),
        "display_name": company_name,
        "branding": {"logo_url": logo_url},
        "metadata": {
            "domain": company_domain,
            "sso_provider": sso_provider,
            "created_at": datetime.utcnow().isoformat(),
        }
    })

    # 2. Configurer la connexion SSO
    connection_id = await setup_sso_connection(sso_provider, company_domain)

    # 3. Lier la connexion à l'Organization
    await auth0.enable_organization_connection(
        org["id"],
        connection_id,
        assign_membership_on_login=True
    )

    # 4. Créer le compte admin
    admin = await auth0.create_user({
        "email": admin_email,
        "email_verified": True,
    })

    # 5. Ajouter l'admin à l'Organization
    await auth0.add_organization_member(org["id"], admin["user_id"])
    await auth0.add_organization_member_role(
        org["id"],
        admin["user_id"],
        "org:admin"
    )

    # 6. Envoyer l'email de bienvenue
    await send_enterprise_welcome(admin_email, company_name, org["id"])

    return org

L’automatisation de ce workflow permet d’intégrer des centaines de clients B2B efficacement tout en garantissant cohérence et conformité sur chaque tenant.

---

Leçon 5 : Monitoring proactif

Mettre en place des alertes de monitoring ciblées permet de réagir rapidement à tout incident Auth0 critique ou à tout signal faible, afin d’assurer disponibilité et performance.

# Alertes déclenchées en production
alertes_critiques:
  - "Auth0 success rate < 95% pendant 5min → PagerDuty immédiat"
  - "Actions timeout > 5% → Alert Slack"
  - "M2M quota > 80% du mensuel → Alert email"
  - "Plus de 100 compte bloqués en 1h → Incident sécurité"

alertes_warning:
  - "Latence P95 login > 2s → Enquête"
  - "MAU > 90% du quota → Upgrade Plan"
  - "Certificat SAML expire dans < 30j → Action"

---

Métriques clés

Voici les indicateurs à suivre pour assurer la qualité de service et l’anticipation des incidents sur un tenant Auth0 à grande échelle.

| Métrique | Valeur cible | Alarme | |----------|-------------|--------| | Success rate login | > 99.5% | < 95% | | P95 latence login | < 500ms | > 2s | | Actions execution time | < 100ms | > 500ms | | JWKS cache hit rate | > 95% | < 80% | | M2M token cache hit | > 85% | < 60% |

---

> 🌐 Nous avons migré Auth0 à l'échelle : de la startup (10k MAU) à l'enterprise (50M+ MAU). Partagez votre contexte et nous vous proposerons une architecture adaptée.

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