10. Expiration, révocation et incident

Comprendre le mécanisme

Un jeton autonome vérifié localement peut rester accepté jusqu’à expiration si le validateur ne consulte aucun état de révocation. Une opération de révocation chez un fournisseur ne se propage donc pas magiquement à toutes les API. Le système doit choisir entre vérifications d’état, durées courtes, listes ciblées ou autre mécanisme documenté, avec ses coûts de disponibilité et de cohérence.

Raisonner et vérifier

Distinguez logout du navigateur, retrait d’un refresh token et invalidation d’un access token déjà émis. Le délai maximal d’acceptation après désactivation doit être mesuré, pas déduit du mot stateless. Une compromission de clé peut imposer une action plus large qu’une seule session. Testez chronologie, cache et instances avec une horloge contrôlée et des clés de laboratoire.

Acceptation autonome

Un token autonome peut rester accepté jusqu’à exp. Les validateurs doivent recevoir ou consulter un état pertinent. Un validateur qui contrôle seulement signature et exp peut accepter une ancienne copie jusqu’à l’échéance. La suppression dans un navigateur ne change pas les octets ni les règles de ce validateur.

Deux capacités

Retrait de refresh token et d’access token sont distincts. Le mécanisme des serveurs de ressources compte. Retirer le refresh token empêche un renouvellement selon la politique serveur. Les access tokens déjà émis suivent leur propre validation et peuvent rester admis tant qu’aucun mécanisme ne les retire.

Délai mesuré

Le délai de retrait doit être mesuré. Il ne précise pas de propagation de révocation. Définissez un objectif de retrait puis observez les refus sur tous les consommateurs. Une intention dans la documentation ne démontre pas le comportement d’un cache ou d’un worker encore actif.

Liste de retrait

Une liste de retrait ajoute un état à consulter. La cohérence entre consommateurs demande une conception. Une denylist ajoute une consultation d’état et un besoin de disponibilité. Définissez index, expiration des entrées et politique de panne ; cette solution modifie le caractère purement autonome de la validation.

Durées courtes

Des durées courtes peuvent réduire une fenêtre. Le risque accepté et les exigences peuvent imposer davantage. Réduire la durée d’un access token peut limiter l’exposition après vol. Évaluez aussi fréquence de renouvellement, charge et expérience utilisateur ; une durée courte ne rend pas une révocation instantanée.

Clé compromise

Une clé compromise peut concerner plusieurs sessions. La capacité d’émission peut être plus large. Le retrait d’une clé peut toucher de nombreux tokens et utilisateurs. La procédure doit distinguer session isolée et incident global, avec moyen de distribution rapide et résultat de refus vérifiable.

Caches

Les caches doivent entrer dans la mesure de propagation. Il peut conserver des décisions ou états anciens. Incluez caches de clés, état de compte et listes de retrait dans la chronologie. Un cache trop long peut dépasser le délai annoncé même si la base centrale a déjà enregistré la révocation.

Horloge de test

Une horloge de test aide à vérifier le retrait. Le laboratoire peut contrôler le temps sans affecter le service réel. Avec une horloge contrôlée, vérifiez avant et après exp et autour du retrait. Évitez les sleeps ; ils rendent la suite lente et peuvent cacher une interprétation imprécise des bornes.

État du compte

Une désactivation métier peut demander un contrôle d’état. Les états métier et temporels du token sont distincts. Une suspension de compte peut exiger une consultation ou une version de sécurité contrôlée. Écrivez explicitement si le retrait est immédiat ou différé, puis vérifiez le mécanisme choisi.

Diagnostic expurgé

Les traces d’incident doivent rester expurgées. Des identifiants et catégories contrôlés peuvent suffire. Conservez catégorie d’incident, identifiant non sensible et version du mécanisme. Le token brut dans les logs créerait une nouvelle copie exploitable au moment même où vous essayez de retirer l’accès.

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

token:
  exp: 2000
validator_clock: 1500
logout_in_browser: true
validator_checks_revocation: false
signature_and_profile: valid

L’horloge du validateur est antérieure à exp et aucun état de retrait n’est consulté. Le logout local ne change donc pas la décision décrite. Ajoutez une politique serveur si un refus avant exp est exigé, puis mesurez ce refus avec une copie conservée du token.

1500 est inférieur à 2000 dans cet exercice temporel. Le stockage navigateur ne change pas une signature émise. Aucun mécanisme de propagation n’est défini. Le validateur décrit ne consulte aucun état de retrait.

Travail pratique : Désactivez un compte de test pendant qu’un token est encore dans sa période nominale.

Critères de correction : Mesurez les refus sur chaque instance, puis comparez avec le délai annoncé. Documentez séparément ce qui est retiré au logout et ce qui demeure utilisable ailleurs.