JWT place les revendications dans un jeton signé, ce qui permet au serveur de vérifier sans stockage de session

Lorsqu'un utilisateur se connecte, le serveur génère généralement un identifiant de session et stocke l'utilisateur dans une table ; chaque requête consulte ensuite cette table. Cela fonctionne sur une seule machine, mais une flotte de serveurs API sans état ne peut pas partager une table en mémoire sans cache ni sessions persistantes.

JWT déplace les revendications de l'utilisateur dans le jeton lui-même. Le jeton est une charge utile JSON compacte et compatible URL, signée de sorte qu'elle ne puisse être falsifiée. Le serveur vérifie la signature et lit les revendications directement dans le jeton.

Le résultat est une authentification sans état : tout serveur qui connaît la clé publique peut vérifier n'importe quel utilisateur sans stockage de session partagé. Les revendications et la preuve voyagent ensemble, ce qui explique pourquoi JWT est devenu la solution par défaut pour l'authentification des API et l'authentification unique.

Placez les revendications dans le jeton ; la signature est la preuve.

Parce que le jeton est autonome, un vérificateur n'a besoin d'aucun appel à une base de données, de sorte que le chemin de la requête reste simple et rapide.

La signature, et non la session, est l'ancre de confiance, de sorte que tout serveur sans état disposant de la clé peut vérifier n'importe quel jeton.

Sa structure en trois parties header.payload.signature est simple à implémenter pour chaque langage d'un écosystème web.

Il se compose avec OAuth et OpenID Connect, de sorte que le même jeton fonctionne à travers de nombreux services et produits.

Si la preuve voyage avec la revendication, vous pouvez vérifier n'importe où et mettre à l'échelle le vérificateur horizontalement, car l'identité devient autonome plutôt qu'une recherche.

JWT a été normalisé sous le nom RFC 7519 en mai 2015, avec une famille JWS/JWE complète. Il est devenu la solution par défaut pour l'authentification des applications monopages, les passerelles API et les microservices. Ses faiblesses connues sont la révocation (un jeton ne peut pas être invalidé avant son expiration sans liste de refus) et les bogues de confusion d'algorithme, ainsi qu'une surcharge de taille par rapport aux sessions opaques.