Jeton jwt asymétrique

Jusqu’à présent, nous avons parlé des propriétés techniques des jetons JWT. Cependant, l’utilisation des JWT dans la pratique nécessite un examen attentif des propriétés de sécurité d’un JWT.

Dans la plupart des cas, les JWT sont utilisés sous la forme de jetons au porteur. Un jeton au porteur est un jeton qui peut être utilisé par toute personne qui le possède. Par conséquent, l’obtention d’un JWT suffit pour qu’un attaquant commence à abuser des privilèges associés à ce jeton. Dans cette dernière section, nous allons brièvement mettre en évidence quelques cas d’utilisation.

JWT dans OpenID Connect

Nous avons déjà mentionné l’utilisation de JWT dans OpenID Connect. Le fournisseur émet un jeton d’identité au client. Ce jeton d’identité contient des informations sur l’authentification de l’utilisateur auprès du fournisseur. Le jeton d’identité est un jeton JWT, signé avec la clé privée du fournisseur.

OpenID Connect s’est donné beaucoup de mal pour améliorer les propriétés de sécurité du jeton d’identité. Par exemple, le protocole impose l’utilisation des revendications « exp », « iss » et « aud ». De plus, le jeton comprend un nonce pour empêcher les attaques par rejeu. En raison de ces exigences, l’abus d’un jeton d’identité volé devient difficile, voire impossible.

JWT en tant que jetons d’accès OAuth 2.0 Un

jeton d’accès OAuth 2.0 est un autre bon cas d’utilisation d’un JWT. Un tel jeton d’accès permet à une application cliente d’accéder à une ressource protégée, telle qu’une API. Les jetons d’accès OAuth 2.0 se déclinent en deux types : les jetons de référence et les jetons autonomes.

Un jeton de référence pointe vers les métadonnées côté serveur, conservées par le serveur d’autorisation. Un jeton de référence fonctionne comme un identificateur, un peu comme un identificateur de session traditionnel.

Un jeton autonome se présente sous la forme d’un JWT. Il Contient toutes les métadonnées en tant que charge utile. Pour protéger les données, l’émetteur signe le jeton à l’aide d’une clé privée.

Les tokens OAuth 2.0 traditionnels sont des tokens au porteur. Si l’un d’entre eux est compromis, il peut être utilisé sans restriction par quiconque le possède. Un jeton de référence compromis peut être révoqué par le serveur d’autorisation. Pour les jetons autonomes, la révocation est beaucoup plus délicate.

Par conséquent, il est fortement recommandé de garder la durée de vie des jetons d’accès aussi courte que possible. Les durées de vie des jetons de minutes ou d’heures sont assez courantes. Les durées de vie de jours ou de mois ne sont pas recommandées. Si possible, les jetons d’accès de courte durée doivent être combinés avec des jetons de rafraîchissement pour améliorer la sécurité.

De plus, des ajouts modernes à la spécification abordent les propriétés du jeton porteur en introduisant des mécanismes de preuve de possession.

JWT en tant qu’objets de session

Protocoles tels qu’OpenID Connect et OAuth 2.0 tentent activement de remédier aux faiblesses des JWT. Malheureusement, nous observons également de nombreuses applications qui intègrent des JWT dans leur architecture, sans tenir compte de ces précautions.

Un exemple concret est une application utilisant des JWT pour stocker l’état d’autorisation sur le client. Cela permet l’utilisation d’un backend sans état, ce qui facilite considérablement le déploiement.

Toutefois, un tel jeton côté client est un jeton au porteur. L’absence d’un mécanisme de courte durée de vie ou de révocation en place rend un tel scénario extrêmement vulnérable.

Plonger dans tous ces détails nous mènerait trop loin pour cet article. Si vous souhaitez en savoir plus sur ces problèmes, nous vous recommandons de lire « Arrêter d’utiliser JWT pour les sessions » et « Jetons de référence et introspection ».