Auth0 Machine-to-Machine (M2M) : sécuriser les communications entre microservices

Comment authentifier vos microservices entre eux avec Auth0 ? Client Credentials Flow, scopes par service, rotation des secrets et gestion des tokens.

Par Auth0.Expert · 2025-03-25 · 9 min de lecture

M2M Microservices Client Credentials

Auth0 M2M : authentification inter-microservices

TL;DR

Les communications entre microservices doivent être authentifiées. Auth0 M2M avec le Client Credentials Flow élimine les API keys statiques et apporte expiration automatique, scopes granulaires et audit logs.

---

Problème : les API keys statiques

Voici un exemple typique d'échange entre microservices avec une clé API statique.

Service A → Service B avec X-API-Key: sk_live_abcd1234...

Problèmes :

---

Solution : Client Credentials avec Auth0

Ce schéma montre comment remplacer une clé statique par un flow OAuth 2.0 sécurisé, avec un token d'accès temporaire.

Service A → POST /oauth/token → Access Token (15 min)
Service A → GET /api/data + Bearer Token → Service B valide → ✅

---

Créer une app M2M dans Auth0

Cette démarche détaille comment déclarer votre microservice dans Auth0 pour gérer les droits d'accès via OAuth.

  1. Dashboard → Applications → Create Application → Machine to Machine
  2. Autoriser l'API Resource Server cible
  3. Sélectionner les scopes nécessaires (ex: read:orders, write:notifications)

---

Obtenir et mettre en cache le token

Ce code Python illustre comment automatiser la génération et le cache d’un token M2M Auth0, pour limiter les requêtes et améliorer les performances.

import httpx
import time
from dataclasses import dataclass

@dataclass
class TokenCache:
    token: str
    expires_at: float

_cache: dict[str, TokenCache] = {}

async def get_m2m_token(client_id: str, client_secret: str,
                         audience: str, domain: str) -> str:
    cache_key = f"{client_id}:{audience}"
    cached = _cache.get(cache_key)

    if cached and time.time() < cached.expires_at - 60:  # 60s de marge
        return cached.token

    async with httpx.AsyncClient() as client:
        resp = await client.post(
            f"https://{domain}/oauth/token",
            json={
                "client_id": client_id,
                "client_secret": client_secret,
                "audience": audience,
                "grant_type": "client_credentials",
            },
        )
    data = resp.json()
    token = data["access_token"]
    expires_in = data.get("expires_in", 900)

    _cache[cache_key] = TokenCache(
        token=token,
        expires_at=time.time() + expires_in,
    )
    return token

Ce bloc gère toute la logique d'obtention, rafraîchissement et mise en cache locale du token OAuth 2.0 pour vos microservices.

---

Architecture de scopes par microservice

Une organisation claire des scopes permet de limiter et d'auditer les accès par microservice.

Resource Server: https://api.myapp.com

Scopes:
  read:users       → service-analytics peut lire les users
  write:orders     → service-frontend peut créer des commandes
  send:emails      → service-orders peut déclencher des emails
  read:inventory   → service-orders peut consulter le stock

Ce code vérifie côté serveur que le token du service consommateur inclut bien le scope attendu avant d'autoriser l’action.

// Service B vérifie que Service A a le bon scope
async function requireScope(token, requiredScope) {
  const payload = await verifyToken(token);
  if (!payload.scope?.split(' ').includes(requiredScope)) {
    throw new Error(`Scope manquant: ${requiredScope}`);
  }
  return payload;
}

---

Rotation des secrets M2M

La rotation régulière des secrets limite l'impact d'une fuite de credentials. Voici la commande curl à utiliser via l’API Auth0.

# Rotation via Management API
curl -X POST   "https://YOUR_DOMAIN.auth0.com/api/v2/clients/CLIENT_ID/rotate-secret"   -H "Authorization: Bearer $MGMT_TOKEN"

Stratégie zero-downtime :

  1. Créer un nouveau secret
  2. Déployer le nouveau secret dans Service A (variable d'env)
  3. Attendre que les anciens tokens expirent (max 15 min)
  4. Supprimer l'ancien secret

---

Kubernetes : stocker les secrets M2M

Dans Kubernetes, les credentials M2M doivent être stockés de façon sécurisée. Ces exemples illustrent l’utilisation des objets Secret, puis d’ExternalSecret pour l’intégration avec AWS Secrets Manager.

# Secret Kubernetes pour M2M
apiVersion: v1
kind: Secret
metadata:
  name: auth0-m2m-credentials
type: Opaque
stringData:
  AUTH0_CLIENT_ID: "your_client_id"
  AUTH0_CLIENT_SECRET: "your_client_secret"

---
# ExternalSecret (External Secrets Operator + AWS Secrets Manager)
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: auth0-m2m
spec:
  secretStoreRef:
    name: aws-secretsmanager
    kind: ClusterSecretStore
  target:
    name: auth0-m2m-credentials
  data:
    - secretKey: AUTH0_CLIENT_SECRET
      remoteRef:
        key: prod/auth0/m2m
        property: client_secret

---

Monitoring des tokens M2M

Surveillez la santé des échanges M2M grâce aux logs Auth0, en vérifiant les taux de succès/échecs du flow.

type:scce  → Client Credentials Exchange (succès)
type:fce   → Client Credentials Exchange (échec)

Alerte si ratio d'échec > 5% → secret expiré ou révoqué.

---

> 🔧 Architecture microservices sécurisée : nous concevons votre stratégie d'authentification inter-services de A à Z, avec rotation automatique et monitoring intégré.

📧 [email protected]

Autres articles