Révocation de tokens : fermer réellement une session compromise

Un ordinateur portable disparaît, un téléphone est volé ou un mot de passe se retrouve dans une fuite. Le support désactive le compte en quelques secondes et annonce que l’accès est coupé. Pourtant, une application continue d’accepter le jeton déjà présent sur l’appareil. Le compte est bien bloqué pour une prochaine authentification ; la session compromise, elle, fonctionne encore. La douleur et le blocage sont immédiats : exposition de données, fraude possible et support incapable de prouver la coupure.

Cet écart vient rarement d’un appel manquant. Il révèle plutôt une définition trop vague du mot « session ». Un navigateur peut cumuler un cookie local, une session côté serveur, un jeton d’accès OAuth, un refresh token et une session ouverte chez le fournisseur d’identité. Couper un seul de ces éléments ne neutralise pas nécessairement les autres.

Fermer réellement une session demande donc une chaîne cohérente, depuis la décision de sécurité jusqu’au dernier service qui autorise une requête. Le lecteur doit pouvoir choisir entre jetons autonomes et contrôle centralisé, fixer un délai de coupure et construire les preuves nécessaires avant de déclarer l’incident résolu.

En réalité, raccourcir tous les tokens ne suffit pas si une session locale, un cache ou une connexion longue continue d’autoriser l’action. Notre accompagnement en intégration API relie OAuth, OIDC, services consommateurs, monitoring et runbook pour rendre la révocation mesurable de bout en bout.

Pourquoi désactiver un compte ne ferme pas ses sessions

Distinguer compte, session et preuve d’accès

Désactiver l’utilisateur modifie un état dans l’annuaire ou dans le fournisseur d’identité. Cette décision empêche généralement une nouvelle connexion. Elle n’efface pas, par magie, les preuves d’autorisation copiées auparavant dans les navigateurs, les applications mobiles et les caches des API.

Un JWT signé illustre bien le problème. Le serveur de ressources peut en vérifier la signature et la date d’expiration sans contacter l’émetteur. Cette autonomie améliore la disponibilité et réduit la latence, mais elle permet aussi au jeton volé de rester valable jusqu’à son expiration si aucune vérification supplémentaire n’existe. À l’inverse, un jeton opaque vérifié par introspection facilite un contrôle central, au prix d’une dépendance réseau et d’un cache à maîtriser.

Il faut écrire l’objectif sans ambiguïté : « à partir de la décision de révocation, aucune requête protégée provenant de cette session ne doit être acceptée après un délai de X secondes ». Cette phrase impose un délai, un périmètre de session et un résultat observable. « Le compte est désactivé » ne fournit aucune de ces garanties.

Recenser ce qui continue d’autoriser des requêtes

Avant de choisir un mécanisme, l’équipe suit une connexion réelle de bout en bout. Pour chaque preuve d’accès, elle note son émetteur, son détenteur, sa durée de vie, l’endroit où elle est validée et le moyen disponible pour l’invalider. Cet inventaire rencontre souvent six objets différents :

• Le cookie de session, émis par l’application web et relié ou non à un enregistrement côté serveur.
• Le jeton d’accès, souvent bref, présenté aux API pour obtenir une ressource précise.
• Le refresh token, plus durable, qui permet d’obtenir de nouveaux jetons d’accès sans reconnecter l’utilisateur.
• La session du fournisseur d’identité, capable de reconnecter silencieusement l’utilisateur après la fermeture de l’application.
• Les sessions par appareil, utiles pour fermer un téléphone compromis sans déconnecter tous les postes.
• Les secrets d’application ou clés d’API, qui appartiennent à une identité technique et nécessitent une procédure distincte.

L’inventaire doit aussi couvrir les services en aval. Si la passerelle API vérifie le statut du jeton mais qu’un microservice conserve une décision positive pendant dix minutes, ce cache devient le véritable délai de révocation. Même chose pour une connexion WebSocket déjà établie, une file de messages ou une tâche asynchrone lancée au nom de l’utilisateur.

Ce que garantit réellement l’endpoint de révocation

Lire le succès comme une demande, pas comme la preuve finale

La RFC 7009 définit un endpoint auquel un client OAuth peut envoyer un jeton devenu inutile. La requête est authentifiée lorsque le client est confidentiel et transporte le jeton dans un formulaire. Le paramètre token_type_hint peut indiquer s’il s’agit d’un jeton d’accès ou d’un refresh token, mais le serveur reste responsable de la recherche et de l’invalidation.

POST /oauth/revoke HTTP/1.1
Host: identity.example
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <client-credentials>

token=<refresh-token>&token_type_hint=refresh_token

La réponse mérite une attention particulière. Le serveur renvoie normalement 200 aussi bien pour un jeton révoqué que pour un jeton déjà invalide. Ce comportement évite de transformer l’endpoint en outil de découverte. Il signifie également qu’une réponse positive ne prouve pas que toutes les API ont cessé d’accepter les jetons dérivés. Si le serveur répond 503, le client doit au contraire considérer que le jeton peut toujours exister et retenter selon une politique bornée.

La révocation peut s’étendre aux autres jetons issus de la même autorisation, selon la politique du serveur. Il faut vérifier cette politique dans la documentation du fournisseur et dans un test réel. Révoquer un refresh token n’implique pas automatiquement qu’un jeton d’accès autonome, déjà émis, disparaisse avant sa date d’expiration.

Traiter les jetons d’accès déjà distribués

Arbitrer autonomie, introspection et liste de refus

Quatre familles de réponses existent pour les jetons d’accès encore en circulation. Aucune n’est universellement supérieure ; le choix dépend du niveau de risque, du volume d’appels et du délai de coupure attendu.

• Une durée de vie courte limite naturellement l’exposition. Elle ne donne toutefois pas une coupure immédiate et augmente la fréquence de renouvellement.
• L’introspection demande au serveur d’autorisation si le jeton est encore actif. Elle centralise la décision, mais sa disponibilité et son temps de réponse entrent dans le chemin critique.
• Une liste de refus temporaire conserve l’identifiant du jeton, de la session ou de l’autorisation jusqu’à l’expiration normale. Elle accélère la coupure au prix d’un état distribué supplémentaire.
• Un jeton lié à son émetteur, par mTLS ou DPoP selon le contexte, réduit l’utilité d’un jeton volé parce que l’attaquant doit aussi prouver la possession d’une clé.

Le cache d’introspection constitue un compromis sensible. Avec un cache de cinq minutes, une décision de révocation peut rester invisible cinq minutes même si le fournisseur d’identité l’a appliquée instantanément. La durée du cache doit donc découler du délai de sécurité accepté, et non d’une valeur par défaut choisie pour soulager l’infrastructure.

Détecter le rejeu grâce à la rotation des refresh tokens

Fermer la famille quand une ancienne valeur réapparaît

Un refresh token mérite une protection plus forte qu’un jeton d’accès : il permet de fabriquer de nouveaux accès pendant une période souvent longue. La rotation remplace ce jeton à chaque renouvellement. L’ancien devient inutilisable dès que le nouveau est émis.

Cette mécanique apporte surtout un signal de compromission. Si l’ancien jeton réapparaît après la rotation, deux détenteurs ont probablement utilisé la même chaîne : le client légitime et un tiers. La bonne réaction n’est pas de servir un nouveau jeton au plus rapide. Elle consiste à invalider la famille concernée, demander une nouvelle authentification et consigner l’événement.

La bonne pratique de sécurité OAuth publiée dans la RFC 9700 exige, pour les clients publics, des refresh tokens liés à l’émetteur ou une rotation permettant de détecter leur rejeu. L’implémentation doit néanmoins gérer une course légitime : deux renouvellements presque simultanés dus à un mobile instable ne doivent pas produire un comportement aléatoire. Une courte fenêtre de grâce peut être justifiée, à condition d’être mesurée, bornée et de ne pas masquer un second usage durable.

Fermer aussi les sessions des applications OIDC

OAuth protège l’accès aux ressources ; OpenID Connect ajoute l’authentification et la notion de session chez les clients. Révoquer les jetons d’une application ne ferme pas nécessairement les sessions ouvertes dans trois autres applications reliées au même fournisseur d’identité.

La déconnexion back-channel OpenID Connect permet au fournisseur d’identité de notifier directement les applications concernées, sans dépendre d’un navigateur encore ouvert. Le message de déconnexion identifie la session avec sid ou l’utilisateur avec sub, puis chaque client détruit la session locale correspondante.

L’intérêt du back-channel apparaît pendant un incident : la fermeture ne repose pas sur une redirection frontale que l’attaquant pourrait ne jamais suivre. En contrepartie, chaque application doit exposer un endpoint disponible, valider strictement le jeton de déconnexion et rendre le traitement idempotent. Une notification reçue deux fois ne doit ni échouer ni fermer une session sans rapport.

Fixer un délai maximal de propagation

Chronométrer le dernier accès encore accepté

Une architecture distribuée ne promet pas honnêtement l’instantanéité. Elle peut en revanche borner le temps de propagation. Le chronomètre commence lorsque la décision de révocation est validée, pas lorsque le dernier consommateur la reçoit. Il s’arrête lorsqu’un test avec l’ancien jeton est refusé sur chaque ressource sensible.

Le chemin doit être dessiné : interface d’incident, serveur d’autorisation, bus d’événements, passerelles, caches, applications et connexions longues. Pour chaque étape, l’équipe définit un délai, un accusé de traitement et un comportement en cas de panne. Une notification perdue ne peut pas rester invisible ; un consommateur en retard doit exposer l’âge de son dernier événement appliqué.

Le mode dégradé dépend du service. Une consultation peu sensible peut accepter un jeton jusqu’à son expiration courte. Une opération financière ou une modification d’adresse de livraison peut exiger une vérification en ligne, voire refuser l’action si le statut de session n’est pas vérifiable. Cette décision appartient au modèle de risque, pas uniquement au composant IAM.

Conserver juste assez d’état pour pouvoir révoquer

Une révocation par session nécessite un identifiant stable. Le couple utilisateur–application est trop grossier si l’on veut fermer un téléphone tout en conservant le poste de travail. À l’inverse, stocker chaque jeton en clair crée un référentiel sensible et difficile à protéger.

Un modèle raisonnable conserve un identifiant de session non secret, l’utilisateur, le client, l’appareil lorsqu’il est connu, la date de création, la dernière activité, l’état de révocation et la date d’expiration maximale des jetons associés. Pour une liste de refus, l’empreinte d’un identifiant de jeton peut suffire. Les valeurs brutes de jetons ne doivent pas apparaître dans les journaux, les tickets de support ou les traces d’erreur.

{
  "sessionId": "ses_7f2c",
  "subjectId": "usr_1842",
  "clientId": "mobile-app",
  "revokedAt": "2026-08-04T09:42:18Z",
  "reason": "suspected_token_theft",
  "maxTokenExpiry": "2026-08-04T09:47:00Z",
  "correlationId": "inc_2026_0817"
}

La raison et l’identifiant de corrélation servent à l’audit. Ils ne doivent pas être intégrés tels quels dans un jeton présenté au client. Le système de sécurité garde ainsi la preuve de la décision sans divulguer le contexte de l’incident.

Construire un geste d’incident vérifiable

Orchestrer la coupure avec une corrélation unique

Le support ne devrait pas avoir à appeler cinq équipes pour fermer une session. Une action unique, protégée par une autorisation forte, déclenche les opérations prévues : blocage de la chaîne de refresh tokens, révocation auprès du fournisseur, fermeture des sessions locales et diffusion de l’événement. Elle renvoie un identifiant de suivi plutôt qu’un message rassurant mais invérifiable.

Le dossier d’incident affiche ensuite l’état de chaque dépendance : décision enregistrée, jetons de renouvellement invalidés, clients OIDC notifiés, caches purgés, dernière API contrôlée. Si une étape échoue, le support sait laquelle relancer. L’idempotence est essentielle : répéter la même demande avec la même clé ne doit pas créer une nouvelle décision ni restaurer un état antérieur.

Le contrôle final part du point de vue de l’attaquant. L’ancien jeton est présenté à une ressource représentative de chaque niveau de sensibilité. Le résultat attendu est un refus authentifié et corrélé à la révocation. Une simple ligne « endpoint appelé avec succès » n’est pas une preuve de fermeture.

Exercer le runbook sur une session synthétique

Cas concret : le payload d’incident identifie la session ses_7f2c, le client et la raison, puis une clé d’idempotence protège l’entrée. L’orchestrateur écrit la décision, publie un événement dans la queue et collecte les sorties des applications. Le monitoring fixe un seuil de 60 secondes pour les ressources critiques et alerte l’owner si un accusé manque.

Après un timeout, le retry relit le contrat de révocation et les dépendances déjà confirmées ; il ne recrée pas la décision. Le rollback ne réactive jamais la session compromise : il bascule vers un repli plus strict, par exemple introspection obligatoire ou refus temporaire, jusqu’à la restauration du service de propagation. Une sandbox exécute ce scénario sans données réelles avant chaque évolution du contrat.

Pour qui industrialiser la révocation — et quand différer

Le dispositif devient indispensable pour une application B2B, un portail financier ou un environnement multi-applications où un compte compromis peut agir au-delà d’un écran. Il apporte de la valeur lorsque plusieurs API, clients OIDC et appareils doivent respecter une même décision de sécurité avec un délai annoncé.

Il faut différer l’ouverture à de nouveaux clients si l’équipe ne sait pas inventorier les sessions, si les services n’exposent aucune corrélation ou si la stratégie repose sur l’expiration naturelle d’un token long. Le premier lot doit couvrir une application, une API critique et un scénario d’incident repris par le support.

Erreurs fréquentes : courses, pannes et rejeux

Contredire le parcours de déconnexion nominal

Le scénario nominal — cliquer sur « déconnecter » puis constater le retour à l’écran de connexion — vérifie peu de choses. La recette utile cherche les endroits où deux états peuvent coexister. Elle inclut au minimum les cas suivants :

• un jeton d’accès volé est utilisé avant, pendant et après la décision de révocation ;
• deux appareils renouvellent simultanément la même chaîne de refresh tokens ;
• un ancien refresh token réapparaît après une rotation réussie ;
• le bus de propagation est indisponible, puis livre les événements dans le désordre ;
• une passerelle conserve un résultat d’introspection positif dans son cache ;
• une notification de déconnexion OIDC est reçue deux fois, puis une fois avec une signature invalide ;
• une connexion WebSocket reste ouverte alors que les requêtes HTTP sont déjà refusées ;
• le service de révocation répond 503 au milieu du traitement.

Pour chaque cas, la fiche de test précise l’état initial, l’action, la limite de temps, la requête de contrôle et les traces attendues. Elle évite les formulations comme « vérifier que tout fonctionne », impossibles à rejouer lors d’un audit.

Mesurer l’effet de sécurité, pas le nombre d’appels

Le taux de réponses 200 de l’endpoint renseigne sur sa disponibilité, pas sur l’efficacité de la coupure. La mesure principale est le temps entre la décision et le dernier accès accepté à tort. Il faut suivre ses percentiles, son maximum et le détail par ressource, car une moyenne peut masquer quelques sessions dangereusement longues.

D’autres indicateurs complètent le tableau : nombre de rejeux de refresh tokens détectés, événements de déconnexion en attente, âge du plus ancien événement non appliqué, refus après révocation, sessions dont l’état est inconnu et recours à une fermeture manuelle. Chaque alerte doit désigner une action et une équipe. Sans procédure associée, elle ajoute du bruit au moment où le support a besoin d’un verdict rapide.

Les journaux associent l’identifiant de session, le client, la ressource, la décision et la corrélation d’incident. Ils excluent le jeton lui-même ainsi que les données personnelles sans utilité opérationnelle. L’audit trail d’une API doit permettre de reconstruire la chronologie sans devenir une nouvelle source de secrets. Le cadrage OAuth, IAM et sécurité des API complète cette lecture pour les scopes et les identités techniques.

Plan d’action : choisir une stratégie adaptée au risque

Pour une API interne peu sensible, des jetons d’accès de quelques minutes et la révocation du refresh token peuvent constituer un compromis acceptable. Pour une opération critique, une vérification en ligne ou une liste de refus distribuée réduit le délai. Pour une suite d’applications connectées par OIDC, la déconnexion back-channel ferme les sessions locales que la seule révocation OAuth ne voit pas.

Trois questions tranchent l’arbitrage : combien de temps un jeton volé peut-il rester utile, quelles ressources doit-il atteindre pour causer un dommage et que fait le système lorsque l’autorité de révocation est indisponible ? Les réponses conduisent aux durées de vie, aux caches, au mécanisme de propagation et au mode dégradé. Elles évitent de choisir une technologie parce qu’elle figure déjà dans la pile.

Lorsqu’un fournisseur externe ne propose ni révocation fine ni notification de session, l’intégration API sur mesure ne peut pas inventer cette capacité. Elle peut documenter la limite, raccourcir les durées, placer un contrôle devant les ressources maîtrisées et organiser une rotation de secrets. Cette transparence vaut mieux qu’une promesse de déconnexion immédiate impossible à tenir.

• À faire d’abord : inventorier cookies, sessions, access tokens, refresh tokens, caches et connexions longues.
• À tester ensuite : révocation, rejeu, indisponibilité du bus, retry et refus sur chaque ressource critique.
• À mesurer : dernier accès accepté, propagation maximale, accusés manquants et sessions d’état inconnu.
• À refuser : toute promesse de coupure plus courte que le cache ou l’expiration réellement observés.

Conclusion : la révocation appartient au système complet

Une session est réellement fermée lorsque les preuves d’accès déjà distribuées ne permettent plus d’obtenir une ressource protégée, dans le délai annoncé. La décision dans l’annuaire, l’appel RFC 7009, la rotation des refresh tokens et la notification OIDC ne sont que des maillons de cette garantie.

Le niveau de confiance vient de la confrontation entre architecture et incident : inventaire de tous les détenteurs, propagation bornée, scénarios de rejeu, mesure du dernier accès accepté et procédure relançable par le support. Tant que cette preuve manque, l’interface peut afficher « session fermée » ; le système, lui, n’a pas encore démontré qu’elle l’était.

Pour cadrer le contrat de session, la propagation, les modes dégradés et la recette d’incident avec vos équipes IAM et support, notre accompagnement en intégration API transforme la révocation en garantie observable, testable et réversible.