Comment invalider un Access Token JWT ?

Emmanuel Gautier Emmanuel Gautier ·
JWT

Les jetons d’accès (access tokens) et les JSON Web Tokens (JWT) sont largement utilisés dans les applications web modernes comme moyens d’authentification et d’autorisation. Un jeton d’accès est un type de justificatif (credential) qui représente l’autorisation accordée à un client pour accéder à une ressource protégée. Les JWT, quant à eux, sont un type de jeton d’accès utilisé pour transmettre des informations de manière sécurisée entre les parties sous forme d’objet JSON.

Bien que les JWT soient essentiels pour une communication sécurisée entre les clients et les serveurs (ou de serveur à serveur), la gestion de leur cycle de vie et la garantie de leur sécurité peuvent être complexes. En particulier, il est important de disposer de mécanismes pour invalider les jetons d’accès lorsqu’ils ne sont plus nécessaires ou lorsqu’ils sont compromis, afin d’empêcher tout accès non autorisé aux ressources protégées.

Dans cet article, nous explorerons les meilleures pratiques pour invalider les jetons d’accès, y compris la révocation et la rotation des jetons, ainsi que la manière d’implémenter ces mécanismes dans OAuth2 et OpenID Connect. En suivant ces directives, vous pourrez améliorer la sécurité de votre application web et protéger les données sensibles des utilisateurs contre tout accès non autorisé.

Gestion de la durée de vie des jetons d’accès

Une façon de gérer les jetons d’accès consiste à contrôler leur durée de vie (lifetime). Les jetons d’accès ont une durée de vie limitée et expirent après un certain temps, après quoi ils ne sont plus valides. Le temps d’expiration peut être défini par le serveur, comme le fournisseur OpenID Connect (OP), lors de l’émission du jeton, ou mis à jour lors du renouvellement du jeton.

Le contrôle de la durée de vie des jetons d’accès présente plusieurs avantages. Premièrement, cela aide à prévenir l’accès non autorisé aux ressources protégées en limitant la fenêtre de temps pendant laquelle un jeton volé ou compromis peut être utilisé. Cela aide à réduire le risque d’attaques par rejeu (token replay attacks), où un attaquant intercepte un jeton valide et l’utilise pour accéder à des ressources protégées.

Lors de la définition de la durée de vie des jetons d’accès, il est important de trouver un équilibre entre sécurité, coût et utilisabilité. Un jeton qui expire trop rapidement peut poser des problèmes de performance ou de coût, car le client devra rafraîchir le jeton fréquemment, ce qui peut être gourmand en ressources. Vous ne pouvez pas vous permettre d’avoir un renouvellement de jeton lent pendant les pics de trafic, car cela impacterait l’utilisabilité de l’application. À l’inverse, un jeton qui dure trop longtemps peut augmenter le risque d’accès non autorisé.

Les meilleures pratiques pour la gestion de la durée de vie des jetons d’accès incluent la définition d’un délai d’expiration raisonnable basé sur la sensibilité des données consultées, l’utilisation de jetons à durée de vie courte pour les opérations à haut risque, la fourniture d’un mécanisme de renouvellement de jeton (refresh token) et la journalisation de l’utilisation des jetons pour détecter les anomalies et les activités suspectes.

Dans la section suivante, nous explorerons les mécanismes d’invalidation des jetons d’accès lorsqu’ils ne sont plus nécessaires ou lorsqu’ils sont compromis.

Mécanisme de révocation de jeton

Une autre façon de gérer les jetons d’accès est de les révoquer lorsqu’ils ne sont plus nécessaires ou lorsqu’ils sont compromis. La révocation de jeton est le processus d’invalidation d’un jeton avant son expiration, l’empêchant ainsi d’être utilisé pour accéder à des ressources protégées.

Si vous souhaitez révoquer immédiatement un jeton d’accès JWT et garantir que chaque API qui s’appuie sur lui cesse de l’accepter, vous pouvez utiliser ce mécanisme. Cela peut être utile lorsqu’un utilisateur se déconnecte de votre application ou si vous soupçonnez qu’un jeton a été compromis.

Liste noire (Blacklisting)

Pour rendre la révocation possible, vous devez utiliser un mécanisme de liste noire qui consiste à maintenir une liste de jetons révoqués côté serveur. Lorsqu’un jeton doit être révoqué, il est ajouté à la liste noire, et les requêtes ultérieures avec ce jeton seront rejetées.

Il existe différentes approches pour la révocation des jetons, selon le protocole que vous utilisez. Par exemple, dans OAuth 2.0, vous pouvez utiliser le point de terminaison de révocation de jeton (token revocation endpoint) pour révoquer l’accès ou rafraîchir le jeton. Dans OpenID Connect, vous pouvez utiliser la fonctionnalité de déconnexion par canal arrière (backchannel logout) pour initier une déconnexion de tous les clients utilisant actuellement le jeton.

Introspection de jeton (Token Introspection)

L’introspection de jeton est un mécanisme qui permet aux clients d’interroger le serveur pour déterminer si un jeton est toujours valide. Lorsqu’un client a besoin de valider un jeton, il envoie une requête au serveur avec le jeton, et le serveur répond avec des informations sur la validité du jeton.

La révocation de jeton peut être un mécanisme efficace, en particulier dans les environnements distribués où les clients n’ont pas forcément un accès direct au serveur. Mais elle présente certains inconvénients. Premièrement, elle nécessite une infrastructure côté serveur supplémentaire pour maintenir la liste noire, ce qui peut constituer un goulot d’étranglement pour les performances et la scalabilité. Deuxièmement, la mise sur liste noire n’est efficace que si le jeton est vérifié par rapport à la liste noire à chaque requête via l’introspection du jeton, ce qui peut introduire une latence et une charge supplémentaires, et peut créer un point de défaillance unique (Single Point of Failure - SPoF) dans votre architecture.

Rotation des jetons (Token Rotation)

La rotation des jetons est un mécanisme de gestion des jetons d’accès consistant à émettre régulièrement de nouveaux jetons et à révoquer les anciens. Cela peut aider à atténuer le risque d’attaques par rejeu et à réduire l’impact d’un jeton compromis.

La rotation des jetons implique généralement l’émission d’un nouveau jeton d’accès et d’un nouveau jeton de renouvellement (refresh token) chaque fois qu’un utilisateur se connecte ou rafraîchit son jeton. Les anciens jetons d’accès et de renouvellement sont immédiatement révoqués, et les requêtes ultérieures doivent utiliser les nouveaux jetons.

La rotation des jetons peut être implémentée à l’aide de diverses techniques, notamment la rotation basée sur le temps, la rotation basée sur les événements et les approches hybrides. La rotation basée sur le temps consiste à renouveler les jetons à intervalles réguliers, par exemple toutes les heures ou tous les jours. La rotation basée sur les événements consiste à renouveler les jetons en réponse à des événements spécifiques, par exemple lorsque le mot de passe d’un utilisateur est modifié ou lorsqu’une opération à haut risque est effectuée. Les approches hybrides combinent la rotation basée sur le temps et sur les événements pour offrir un équilibre entre sécurité et utilisabilité.

Révocation et rotation des jetons avec OAuth2 et OpenID Connect

OAuth2 et OpenID Connect offrent plusieurs mécanismes pour la révocation et la rotation des jetons.

Révocation de jeton OAuth2

datatracker.ietf.org/doc/html/rfc7009

OAuth2 définit un mécanisme de révocation de jeton qui permet aux clients de demander la révocation d’un jeton d’accès ou de renouvellement. La demande de révocation est envoyée au point de terminaison de révocation de jeton, qui est un nouveau point de terminaison défini dans la spécification OAuth2. La requête inclut le jeton à révoquer et une raison facultative pour la révocation.

POST /oauth/revoke HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <basic-header>
token=<token>

Déconnexion par canal arrière OpenID Connect (Back Channel Logout)

openid.net/specs/openid-connect-backchannel-1_0

OpenID Connect propose également un canal arrière de déconnexion, qui permet à un utilisateur de se déconnecter de toutes les applications authentifiées via OpenID Connect. La déconnexion par canal arrière est initiée par l’utilisateur ou une application cliente et vise à mettre fin à la session de l’utilisateur dans toutes les applications utilisant OpenID Connect.

Lorsque l’utilisateur initie une demande de déconnexion, l’application cliente envoie une requête au point de terminaison de déconnexion du fournisseur OpenID Connect. Le point de terminaison de déconnexion envoie ensuite des demandes de déconnexion à toutes les applications qui ont une session valide pour l’utilisateur.

Le canal arrière de déconnexion est un mécanisme important pour garantir que les sessions utilisateur sont correctement terminées lorsque l’utilisateur se déconnecte d’une application ou lorsque sa session expire. De cette façon, tous les jetons émis pour la session expirée devraient être révoqués.

Si vous souhaitez vérifier que vos mécanismes de révocation de jetons sont correctement appliqués, VulnAPI est un outil open-source qui peut tester si votre API rejette correctement les jetons révoqués ou expirés.

Conclusion

La gestion des jetons d’accès est un aspect critique de la sécurisation des applications web et des API. Les jetons d’accès, tels que les JSON Web Tokens (JWT), permettent aux utilisateurs d’accéder aux ressources protégées sans avoir à s’authentifier de manière répétée auprès du serveur. Cependant, si les jetons d’accès ne sont pas correctement gérés, ils peuvent devenir un risque pour la sécurité.

Pour atténuer ces risques, les organisations doivent mettre en œuvre les meilleures pratiques de gestion des jetons, telles que le maintien de jetons à durée de vie courte, l’utilisation d’algorithmes de chiffrement et de signature forts, la surveillance de l’activité des jetons et la mise en œuvre de mécanismes de révocation. OAuth2 et OpenID Connect fournissent plusieurs mécanismes pour la révocation et la rotation des jetons, notamment les jetons de renouvellement (refresh tokens), l’introspection de jetons et les points de terminaison de révocation de jetons.

En suivant ces meilleures pratiques et en tirant parti des capacités d’OAuth2 et d’OpenID Connect, les organisations peuvent gérer efficacement les jetons d’accès et protéger leurs utilisateurs ainsi que leurs données contre les accès non autorisés et les attaques malveillantes.