11. Refresh tokens, réutilisation et protocole OAuth

Comprendre le mécanisme

Un refresh token permet d’obtenir de nouveaux tokens selon un contrat avec le serveur d’autorisation. Sa valeur n’a pas besoin d’être un JWT pour être sensible. La rotation et la détection de réutilisation peuvent limiter certains scénarios de vol ; leur efficacité dépend du suivi serveur et de la gestion des accès concurrents. Une course légitime et une réutilisation hostile ne se distinguent pas par la longueur du texte.

Raisonner et vérifier

Les recommandations OAuth actuelles demandent une analyse du type de client et du flux. PKCE protège le code d’autorisation dans son contexte, sans remplacer TLS ni toute validation de redirection. Ne mélangez pas ces garanties avec celles d’une signature JWT. Planifiez perte de réponse lors d’une rotation, plusieurs onglets et incident de refresh token avec une politique explicite et testée.

Capacité durable

Un refresh token donne une capacité de renouvellement. Sa possession peut permettre l’obtention de nouveaux tokens. Le refresh token peut permettre d’obtenir de nouveaux access tokens. Protégez-le comme une capacité de longue durée, avec politique de stockage, durée et retrait distincte de celle d’un token d’accès.

Format indépendant

Le format refresh peut être opaque. Le rôle ne fixe pas cette représentation. Un refresh token peut être opaque et résolu dans un état serveur. Son rôle ne dépend pas du nombre de segments ; ne lui appliquez pas automatiquement un validateur destiné aux JWT d’accès.

Rotation suivie

La rotation demande un suivi serveur. Le cycle doit être appliqué par le serveur. Après échange de R1 contre R2, le serveur conserve assez d’état pour reconnaître une réutilisation de R1. Émettre simplement une nouvelle chaîne sans suivi ne démontre pas cette détection.

Famille de tokens

Une réutilisation peut déclencher une politique de famille. La rotation et la détection ont précisément un autre but. Une réutilisation peut déclencher le retrait de la famille selon la politique retenue. Définissez précisément quels descendants cessent de fonctionner et comment l’utilisateur légitime rétablit sa session.

Réponse perdue

Une perte de réponse peut compliquer le renouvellement. Il faut distinguer risque et concurrence légitime selon le contrat. Le serveur peut consommer R1 puis perdre la réponse contenant R2. Une reprise du client ressemble alors à une réutilisation ; la politique doit traiter ce scénario sans inventer une acceptation illimitée de l’ancien secret.

Onglets concurrents

Plusieurs onglets peuvent créer des courses. Des clients concurrents peuvent agir sur la même famille. Deux onglets peuvent renouveler simultanément la même session. Coordonnez les demandes ou définissez une règle serveur explicite, puis testez les courses plutôt que supposer un navigateur avec un seul appelant.

Rôle de PKCE

PKCE protège un aspect du flux de code. Les mécanismes ont des garanties complémentaires. PKCE lie un échange de code à une preuve du client initiateur selon le flux. Il ne remplace pas TLS, validation des redirections, contrôle d’émetteur ou autres protections requises par le protocole.

Types de clients

Les types de clients influencent les exigences du protocole. Un client public et un client confidentiel diffèrent. Un client public ne peut pas protéger un secret distribué comme un backend confidentiel. Appliquez les exigences correspondant à ce rôle réel, sans traiter un secret embarqué dans JavaScript comme confidentiel.

Logs

Les valeurs refresh ne doivent pas être copiées dans les logs. Des références et événements minimisés peuvent servir à la détection. Enregistrez événements de rotation et de réutilisation avec références non sensibles. La copie des valeurs refresh dans une trace ou un ticket distribuerait précisément la capacité de renouvellement à protéger.

Incident utilisateur

Le scénario d’incident doit prévoir l’utilisateur légitime. Le traitement peut interrompre une session et demander une reprise. Prévoyez reconnexion, information et suivi après retrait de famille. La détection doit produire une réaction vérifiable tout en permettant de distinguer les courses normales des signes d’un vol selon la politique.

Atelier guidé : lire, expliquer et vérifier le code

refresh_policy: rotate_and_detect_reuse
history:
  - R1 accepted, R2 issued
  - R1 presented again

L’historique montre R1 accepté puis représenté alors que la politique exige rotation et détection de réutilisation. Il faut appliquer la réaction prévue à la famille, pas seulement émettre encore un token. Ajoutez au test une réponse perdue et deux onglets pour vérifier la politique dans les cas ambigus.

La politique annoncée ne donne pas ce cycle illimité. Perte de réponse ou concurrence doivent aussi entrer dans l’analyse. Le serveur doit appliquer la réaction prévue pour la famille. Le scénario porte sur le renouvellement applicatif.

Travail pratique : Simulez une rotation réussie, la perte de sa réponse puis la réutilisation de l’ancien token depuis deux clients locaux.

Critères de correction : Vérifiez les événements et le traitement de la famille de tokens selon le contrat retenu. Ne journalisez aucune valeur brute. Documentez les effets sur un utilisateur légitime lors d’un incident.