Résumé

  • Le NIST a publié la version définitive d’IR 8587 le 15 septembre 2026, à l’intention des agences fédérales et de leurs fournisseurs cloud. La conformité reste volontaire sauf si une politique ou un accord contraignant en décide autrement.
  • Avec des jetons sans état, la révocation instantanée et générale peut être impossible avant expiration. Le fournisseur doit exposer la portée et les méthodes de révocation ; l’agence doit apprécier les scénarios et leurs conséquences selon les termes de conformité du rapport.
  • Le projet de décembre 2025 imposait la propagation du statut aux systèmes associés. Le texte final recommande un moyen de propagation ; il exige le refus des jetons révoqués et la clôture des sessions par les services destinataires si cette capacité est disponible.

Dans une réponse à incident, deux horodatages semblent parfois n’en faire qu’un : l’instant où le fournisseur accepte une demande de révocation et celui où une application refuse réellement le jeton présenté. Pourtant un jeton d’accès sans état, déjà émis et encore valide, peut être contrôlé localement par un service distant. Fermer la voie de renouvellement diminue le risque futur ; cela ne retire pas nécessairement ce jeton déjà en circulation. Aucun incident précis n’est allégué ici : il s’agit de l’écart que le NIST demande de comprendre.

Le rapport final, intitulé Protecting Tokens and Assertions from Forgery, Theft, and Misuse, traite de l’émission, de la vérification et du cycle de vie des jetons d’identité et d’accès. Son tableau d’exemple pour le logiciel fourni comme service répartit le cœur de la gestion des identités et la signature des jetons du côté du fournisseur, la configuration des politiques et l’accès aux applications du côté du client. La réponse à incident, la surveillance continue et la révocation figurent dans les deux colonnes. C’est une illustration, pas une attribution contractuelle universelle : le modèle de service et les capacités exposées déplacent la frontière.

Le passage technique décisif se trouve dans la section consacrée à la révocation. Le NIST écrit qu’une révocation globale immédiate n’est pas toujours réalisable pour une architecture sans état avant la fin de la période de validité. Des jetons d’accès courts, associés à un contrôle du renouvellement ou à une nouvelle authentification, peuvent réduire la fenêtre. Le document recommande une validité d’au plus une heure pour les jetons d’identité et d’accès, tout en recommandant aux fournisseurs de permettre un réglage adapté au risque de l’agence.

Cela ne prouve ni qu’un fournisseur particulier applique cette durée ni qu’il sait invalider instantanément les jetons déjà émis.

La comparaison avec le projet initial évite un faux récit de nouveauté. Le texte de décembre 2025 signalait déjà la difficulté des jetons sans état. Il demandait déjà au fournisseur de décrire ses moyens de révocation et à l’agence d’en mesurer le risque. En revanche, il disait que les services émetteurs MUST assurer la propagation du statut de révocation aux systèmes connectés associés. Dans la version définitive, ils SHOULD fournir un moyen d’acheminer ce statut aux services destinataires. Si la capacité est disponible, les destinataires connectés MUST rejeter les jetons révoqués et mettre fin aux sessions correspondantes. Le changement n’est pas une exemption générale ; c’est une condition technique rendue explicite, qui appelle un inventaire de la couverture réelle.

La version définitive décrit l’introspection, les listes d’état et les signaux partagés, puis mentionne Shared Signals Framework et Continuous Access Evaluation Profile. Elle ne certifie pas qu’un service donné participe à ces mécanismes. Elle qualifie également IETF Token Status List de projet Internet adopté par le groupe OAuth et Global Token Revocation de projet individuel : ce ne sont pas des normes finales. Les possibilités offertes par ces pistes restent distinctes de leur déploiement effectif.

Le document emploie MUST et SHOULD pour définir sa propre conformité ; le NIST précise que cette conformité est volontaire tant qu’une politique ou un accord contraignant n’en modifie pas la portée. La bonne question pour un acheteur public n’est donc pas « le fournisseur possède-t-il un bouton ? », mais « quels jetons, quelles applications et quelles sessions ce bouton atteint-il, et quel délai résiduel l’agence accepte-t-elle ? » Aucun retard observé ni défaut d’un fournisseur nommé n’est inféré.

Sources