Renouveler un secret client ou une clé de signature devrait être une opération banale. Dans les faits, c'est souvent l'opération que l'on repousse, parce que la dernière fois, elle a provoqué une interruption : un consommateur a gardé l'ancien secret, une passerelle a gardé l'ancienne clé en cache, et les appels ont échoué pendant de longues minutes.

La stratégie que nous appliquons tient en une idée : ne jamais remplacer une valeur par une autre d'un seul coup, mais les faire coexister le temps de la bascule. Elle s'applique quel que soit le serveur d'autorisation et quelle que soit la passerelle, à condition de vérifier ce que chaque composant supporte.

Les mécanismes décrits ici sont génériques. Les capacités exactes (plusieurs secrets actifs par client, durée de cache des clés, etc.) varient selon les produits et les versions : vérifiez-les sur votre propre environnement avant de planifier une rotation.

Deux rotations différentes

On parle souvent de « rotation OAuth2 » pour désigner deux opérations distinctes :

  1. la rotation du secret d'un client (ou de sa clé privée, s'il s'authentifie par clé ou par certificat) : c'est l'identité de l'application qui demande des jetons ;
  2. la rotation des clés de signature du serveur d'autorisation : ce sont les clés qui signent les jetons, et que les passerelles et les APIs utilisent pour les vérifier.

Les deux suivent le même principe de recouvrement, mais pas avec les mêmes acteurs.

Rotation d'un secret client

Le problème

Un secret client est connu de deux côtés : le serveur d'autorisation, qui le vérifie, et l'application, qui le présente. Si on le change d'abord côté serveur, l'application échoue jusqu'à ce qu'elle soit mise à jour. Si on le change d'abord côté application, c'est le serveur qui la refuse.

La séquence en recouvrement

  1. Créer le nouveau secret sans révoquer l'ancien. Les deux sont acceptés par le serveur d'autorisation. Selon le produit, cela passe par une fonction native de rotation, ou par un second client temporaire si un seul secret actif est possible.
  2. Distribuer le nouveau secret à l'application, idéalement via un coffre-fort de secrets plutôt que par un fichier de configuration.
  3. Vérifier que l'application utilise effectivement le nouveau secret : journaux du serveur d'autorisation, métriques d'obtention de jeton. Ne pas se contenter de « la configuration a été déployée ».
  4. Révoquer l'ancien secret, une fois la bascule confirmée pour toutes les instances.

Les jetons d'accès déjà émis restent généralement valides jusqu'à leur expiration : la rotation du secret ne les invalide pas forcément. Si l'objectif est de couper un accès compromis, il faut aussi traiter les jetons en cours (révocation, durée de vie courte), ce qui est une autre opération.

Les pièges

  • Les instances oubliées : un traitement batch, un environnement de secours, un conteneur qui n'a pas redémarré. Elles échouent au moment de la révocation.
  • Les caches applicatifs : certaines applications lisent le secret au démarrage et ne le relisent jamais. Il faut le savoir avant la rotation, pas après.
  • Les secrets partagés : un même client utilisé par plusieurs applications rend la bascule beaucoup plus difficile à vérifier. Un client par application simplifie tout.

Rotation des clés de signature

Le problème

Les passerelles et les APIs vérifient la signature des jetons à l'aide des clés publiques publiées par le serveur d'autorisation, généralement via un point de publication JWKS. Pour des raisons de performance, elles mettent ces clés en cache. Si le serveur commence à signer avec une nouvelle clé que les vérificateurs ne connaissent pas encore, les jetons sont refusés.

La séquence en recouvrement

  1. Publier la nouvelle clé publique sans l'utiliser. Le JWKS contient désormais l'ancienne et la nouvelle clé, chacune avec son identifiant (kid).
  2. Attendre que tous les vérificateurs aient rafraîchi leur cache. Le délai dépend de la configuration de chaque passerelle et bibliothèque : il faut le connaître et le vérifier sur vos propres composants avant de planifier la rotation.
  3. Commencer à signer avec la nouvelle clé. Les nouveaux jetons portent le nouveau kid ; les vérificateurs le trouvent dans leur cache.
  4. Conserver l'ancienne clé publique dans le JWKS au moins jusqu'à l'expiration des derniers jetons signés avec elle.
  5. Retirer l'ancienne clé.

Les pièges

  • Les clés configurées en dur : certains composants ont été configurés avec une clé publique fixe plutôt qu'avec l'URL du JWKS. Ils ne suivront pas la rotation.
  • Les caches sans rafraîchissement sur kid inconnu : certaines implémentations rafraîchissent le JWKS lorsqu'elles rencontrent un identifiant inconnu, d'autres non. Le comportement doit être vérifié.
  • Les « caches fantômes » : un cache intermédiaire (proxy, CDN, cache applicatif) qui sert un ancien JWKS alors que la source a changé.

Rendre la rotation routinière

Une rotation rare est une rotation risquée, parce que personne ne se souvient de la procédure. Ce qui la rend banale :

  • l'automatiser dans un pipeline, avec les mêmes étapes à chaque fois ;
  • vérifier chaque étape par une observation réelle (jetons obtenus, jetons acceptés), pas par le code retour d'une commande ;
  • la tester en recette sous trafic continu avant de la jouer en production ;
  • la planifier à intervalle régulier plutôt qu'en réaction à un incident.

La rotation se planifie à une fréquence adaptée au risque et aux exigences de sécurité.

Et si on pouvait éviter les secrets partagés ?

Le secret client partagé reste le mode le plus répandu, mais ce n'est pas le seul. L'authentification du client par clé privée (par exemple private_key_jwt) ou par certificat (mTLS) évite de faire circuler un secret connu des deux côtés : seule la clé publique est déposée côté serveur. La rotation suit alors le même principe de recouvrement, appliqué aux clés. C'est une évolution à considérer, sans en faire un préalable.

Ce qu'il faut retenir

Une rotation sans coupure repose toujours sur la même séquence : ajouter la nouvelle valeur, attendre que tout le monde la connaisse, basculer, vérifier, puis retirer l'ancienne. La difficulté n'est pas cryptographique : elle tient à l'inventaire des composants concernés et à la connaissance de leurs caches. C'est vrai sur toutes les passerelles et tous les serveurs d'autorisation que nous avons rencontrés.

À côté du conseil, CAB Ingénierie édite STOA, iPaaS souverain, plateforme d'API et d'intégration.

Parlons de votre projet

Vos rotations de secrets ou de clés provoquent des interruptions, ou vous les repoussez faute de procédure fiable ? Décrivez-nous votre contexte en quelques lignes : cab-ingenierie.com · contact@cab-ingenierie.com