Auth0 en production haute disponibilité : SLA, uptime et résilience

Auth0 garantit 99.99% d'uptime. Comment architechter votre application pour maintenir une haute disponibilité même lors des rares incidents Auth0 ?

Par Auth0.Expert · 2025-01-22 · 11 min de lecture

Haute disponibilité SLA Production

Auth0 en production haute disponibilité

TL;DR

Auth0 garantit 99.99% d'uptime (plan Enterprise) soit environ 53 minutes d'indisponibilité par an. Ce guide présente comment architecturer votre application pour réduire l'impact des incidents Auth0 à zéro.

---

SLA Auth0 par plan

| Plan | SLA | Downtime annuel max | |------|-----|---------------------| | Free | Pas de SLA | — | | Essentials | 99.9% | 8.7h | | Professional | 99.99% | 53min | | Enterprise | 99.99% + SLA financier | 53min |

Status page : https://status.auth0.com

---

Avant d’appliquer ce pattern, il est important de comprendre l’intérêt du cache de clés publiques (JWKS) pour vérifier les tokens localement, même en cas d’indisponibilité Auth0.

Pattern 1 : Cache des tokens valides

Ce code montre comment mettre en cache les JWKS (clés publiques) d'Auth0 pendant 10 minutes, afin de valider les tokens sans requêtes répétées vers Auth0 — utile pour l’indisponibilité ou la latence.

# Ne pas valider le token à chaque requête via Auth0
# Valider via JWKS (publiées et mises en cache)

from functools import lru_cache
import time
import httpx
from jose import jwt

# Cache JWKS (10 minutes) — si Auth0 est down, le cache fonctionne toujours
@lru_cache(maxsize=1)
def get_jwks_cached(timestamp: int):
    """Cache basé sur le timestamp arrondi à 10 minutes."""
    response = httpx.get(f"https://{AUTH0_DOMAIN}/.well-known/jwks.json", timeout=5)
    return response.json()

def get_jwks():
    # Arrondir à 10 minutes pour le cache
    timestamp = int(time.time() / 600)
    return get_jwks_cached(timestamp)

async def verify_token_offline(token: str) -> dict:
    """Valide le token uniquement avec les clés publiques en cache."""
    try:
        jwks = get_jwks()
        header = jwt.get_unverified_header(token)
        key = next((k for k in jwks["keys"] if k.get("kid") == header.get("kid")), None)
        if not key:
            raise ValueError("Clé publique non trouvée")
        return jwt.decode(token, key, algorithms=["RS256"], audience=API_AUDIENCE)
    except Exception as e:
        raise HTTPException(status_code=401, detail=str(e))

Ce bloc permet de continuer à authentifier les utilisateurs via des tokens valides, même en cas d’incident Auth0.

---

Quand Auth0 devient inaccessible, il est pertinent d’activer une stratégie de dégradation progressive pour ne pas bloquer les utilisateurs connectés.

Pattern 2 : Graceful degradation avec session locale

Ce code Node.js illustre comment permettre la poursuite des sessions basées sur un cookie local lorsque Auth0 ou l’API n’est pas disponible, garantissant une meilleure continuité de service.

// Si Auth0 est inaccessible, permettre aux sessions existantes de continuer
// basées sur un cookie de session signé côté BFF

class AuthMiddleware {
  constructor(options) {
    this.sessionSecret = options.sessionSecret;
    this.auth0Domain = options.auth0Domain;
  }

  async authenticate(req, res, next) {
    // 1. Essayer d'abord la validation Auth0 standard
    try {
      req.user = await this.validateAuth0Token(req.headers.authorization);
      return next();
    } catch (auth0Error) {
      // Auth0 potentiellement indisponible
      console.warn('Auth0 validation failed:', auth0Error.message);
    }

    // 2. Fallback : session cookie locale
    if (req.session?.user && this.isSessionValid(req.session)) {
      console.warn('Using cached session (Auth0 possibly unavailable)');
      req.user = req.session.user;
      req.isFromCache = true;
      return next();
    }

    // 3. Aucune session valide
    res.status(401).json({ error: 'Authentication required' });
  }

  isSessionValid(session) {
    const maxAge = 4 * 60 * 60 * 1000; // 4 heures max en mode dégradé
    return Date.now() - session.created_at < maxAge;
  }
}

Ainsi, vos utilisateurs déjà authentifiés ne sont pas perturbés si Auth0 rencontre une panne temporaire.

---

Pour éviter de surcharger Auth0 lors d’une panne, il est recommandé d’utiliser un circuit breaker autour des appels Management API.

Pattern 3 : Circuit Breaker

Voici un exemple de circuit breaker Python qui bloque temporairement les appels Auth0 après plusieurs échecs consécutifs, ce qui protège votre application et évite d’aggraver la situation lors d’un incident.

# Circuit breaker pour les appels Auth0 Management API
from enum import Enum
from datetime import datetime, timedelta

class CircuitState(Enum):
    CLOSED = "closed"      # Normal
    OPEN = "open"          # Bloqué (trop d'erreurs)
    HALF_OPEN = "half_open"  # Test de récupération

class Auth0CircuitBreaker:
    def __init__(self, failure_threshold=5, recovery_timeout=60):
        self.state = CircuitState.CLOSED
        self.failure_count = 0
        self.failure_threshold = failure_threshold
        self.recovery_timeout = recovery_timeout
        self.last_failure_time = None

    async def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if self._should_attempt_recovery():
                self.state = CircuitState.HALF_OPEN
            else:
                raise Exception("Circuit ouvert — Auth0 potentiellement indisponible")

        try:
            result = await func(*args, **kwargs)
            self._on_success()
            return result
        except Exception as e:
            self._on_failure()
            raise e

    def _should_attempt_recovery(self):
        return (datetime.now() - self.last_failure_time).seconds > self.recovery_timeout

    def _on_success(self):
        self.failure_count = 0
        self.state = CircuitState.CLOSED

    def _on_failure(self):
        self.failure_count += 1
        self.last_failure_time = datetime.now()
        if self.failure_count >= self.failure_threshold:
            self.state = CircuitState.OPEN

Ce circuit breaker vous aide à automatiser la gestion des pannes et à limiter les appels répétitifs vers Auth0 en période de crise.

---

Pour garantir une disponibilité élevée, il faut aussi surveiller la santé des endpoints Auth0 en continu.

Monitoring de la disponibilité Auth0

Ce code permet d'effectuer des health checks programmés sur les URLs Auth0 critiques depuis votre application, afin de détecter rapidement toute indisponibilité ou dégradation de service.

# Health check : vérifier Auth0 est accessible
import httpx

async def check_auth0_health() -> dict:
    endpoints = [
        f"https://{AUTH0_DOMAIN}/.well-known/openid-configuration",
        f"https://{AUTH0_DOMAIN}/.well-known/jwks.json",
    ]
    results = {}
    for endpoint in endpoints:
        try:
            start = time.time()
            resp = await httpx.AsyncClient().get(endpoint, timeout=5)
            latency = (time.time() - start) * 1000
            results[endpoint] = {
                "status": resp.status_code,
                "latency_ms": round(latency),
                "healthy": resp.status_code == 200,
            }
        except Exception as e:
            results[endpoint] = {"healthy": False, "error": str(e)}
    return results

Ce script offre une surveillance automatisée de la disponibilité Auth0, avec latence et statut détaillés.

---

Les alertes sont essentielles pour être proactif en cas de problème Auth0. Voici comment définir des alertes Datadog adaptées.

Alertes Datadog sur la disponibilité Auth0

Ces exemples de configurations Datadog déclenchent une alerte si le endpoint JWKS d’Auth0 devient indisponible ou si le taux de succès login Auth0 chute sous un seuil critique.

monitors:
  - name: "Auth0 JWKS Endpoint Disponible"
    type: "http check"
    url: "https://YOUR_DOMAIN.auth0.com/.well-known/jwks.json"
    timeout: 5
    tick_every: 60
    assertions:
      - type: statusCode
        operator: is
        target: 200
    notify: "@pagerduty-oncall"
    message: "Auth0 JWKS endpoint inaccessible — impact sur l'authentification"

  - name: "Auth0 Login Success Rate < 95%"
    type: log alert
    query: |
      logs("source:auth0").rollup("count").by("@evt.name").last("5m")
    message: "Taux de succès Auth0 critique"

Avec ces monitors, votre équipe sera immédiatement prévenue en cas de défaillance Auth0.

---

Pour bien choisir la localisation de votre tenant Auth0, il est essentiel de comprendre l’impact sur la latence et la conformité.

Région Auth0 : choisir la bonne

Ce tableau liste les régions proposées par Auth0 et les recommandations associées, un critère clé pour la performance et le respect du RGPD.

US: us.auth0.com (défaut, Amérique du Nord)
EU: eu.auth0.com (Europe — RGPD, latence réduite)
AU: au.auth0.com (Australie)

Recommandation pour les clients EU :
- Utiliser la région EU pour réduire la latence (30-100ms)
- Les données restent en Europe (conformité RGPD)
- Pas de migration possible après création du tenant

---

Un plan de reprise d’activité est indispensable pour organiser la réponse en cas d’incident Auth0 et assurer la continuité de service.

Plan de reprise d'activité (PRA)

Ce runbook propose l’ordre des actions à suivre en cas d’incident Auth0, de l’activation du mode maintenance jusqu’aux mesures d’escalade.

# Runbook en cas d'incident Auth0

Priorité 1 - Auth0 totalement indisponible (< 5 min):
  1. Activer le mode maintenance
  2. Afficher une page "Authentification temporairement indisponible"
  3. Permettre aux sessions actives de continuer (cache)
  4. Monitorer status.auth0.com

Priorité 2 - Auth0 partiellement indisponible (5-60 min):
  1. Activer le fallback session locale
  2. Alerter l'équipe de permanence
  3. Contacter le support Auth0 (Enterprise : SLA 1h)

Priorité 3 - Auth0 indisponible > 1h:
  1. Escalader au management
  2. Communication externe aux utilisateurs
  3. Évaluer le basculement sur un tenant de secours

Ce plan permet d’être prêt à réagir et de limiter l’impact utilisateur lors d’une panne.

---

> 🏗️ Architecture résiliente : nous concevons une architecture d'authentification haute disponibilité avec circuit breaker, cache et graceful degradation.

📧 [email protected]

Auth0 en production haute disponibilité : SLA, uptime et résilience