Les tokens Web JSON, éléments constitutifs de la sécurité du cloud

La première ébauche des tokens Web JSON date déjà de plus de 10 ans (elle remonte à décembre 2010). Elle précise : « Le token Web JSON (JWT) définit un format de token qui encode des informations (appelées « claims ») échangées entre deux parties. Les informations que contient un JWT sont encodées sous forme d’objet JSON signé numériquement. »

Dans sa dernière version, IETF RFC 7519, il a été étendu comme suit : «Le JSON Web Token (JWT) est un moyen compact et sécurisé pour les URL de représenter des revendications à transférer entre deux parties. Les demandes dans un JWT sont encodées sous forme d'objet JSON utilisé comme charge utile d'une structure JSON Web Signature (JWS) ou comme texte brut d'une structure JSON Web Encryption (JWE), ce qui permet de signer numériquement les demandes ou de protéger leur intégrité à l'aide d'un code d'authentification de message (MAC) et/ou de les crypter. »

La nouvelle description fait référence à deux représentations d'un JWT (souvent prononcé « jot »), à savoir une structure JSON Web Signature (JWS) ou une structure JSON Web Encryption (JWE). JWS est défini dans RFC 7515, JWE dans RFC 7516. Il existe encore d’autres normes de sécurité, basées sur JSON, toutes définies par un groupe de travail appelé JOSE : JSON Object Signing and Encryption.

OAuth 2.0 est une norme industrielle dans le domaine de l’autorisation. Sans entrer dans les détails, il propose un flux d’autorisation et des concepts fondamentaux, notamment ce que l’on appelle le « token d’accès » et le « token d’actualisation ». Leur utilisation n’est pas obligatoire, mais les JWT sont généralement utilisés de nos jours. Comme indiqué, OAuth se concentre sur l’autorisation et a parfois été utilisé à mauvais escient pour gérer l’identification.OpenID Connect comble cette lacune et introduit le jeton d’identité ou jeton d’identification. Ce dernier est représenté sous forme de JWT.

Compte tenu de ce contexte historique et de certaines normes, comment pouvons-nous traiter le JWT ci-dessus et quelles informations contient-il ?

Le JWT ci-dessus se compose de trois parties, séparées chacune par un point (« . ») :

1. En-tête : eyJhbGciOiJIUzI1 NiIsInR5cCI6IkpXVCJ9
2. Charge utile : eyJzdWIiOiIxMjM0NTY3ODkwQUJDIiwibmFtZSI6IkhlbnJpayBMb2VzZXIiLCJpYXQiOjE2MTExNDA0MDAsImV4cCI6MTYxMTIzNDU2N30
3. Signature : _iVbBcypdse-9sjrxp9iOrGsXKBWrBB3mrHgBtukcfM

L’en-tête et la charge utile sont tous deux encodés en base64url et, sans tenir compte d’un éventuel remplissage, peuvent être décodés comme suit :

henrik@home> base64 -d <<< eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
{"alg":"HS256","typ":"JWT"}

henrik@home> base64 -d <<< eyJzdWIiOiIxMjM0NTY3ODkwQUJDIiwibmFtZSI6IkhlbnJpayBMb2VzZXIiLCJpYXQiOjE2MTExNDA0MDAsImV4cCI6MTYxMTIzNDU2N30
{"sub":"1234567890ABC","name":"Henrik Loeser","iat":1611140400,"exp":1611234567}base64: invalid input

L’en-tête contient des informations sur l’algorithme utilisé (« alg »), ici HS256 (HMAC SHA256). La charge utile dépend du type de token (accès, actualisation, identification/…) et est composée de claims. Ces champs et d’autres champs d’en-tête et de charge utile JOSE prédéfinis sont gérés par l’IANA. Dans l’exemple ci-dessus, les champs et les claims sont « sub » (objet), « name » (nom), « iat » (émis à) et « exp » (délai d’expiration).

La signature est calculée en appliquant l'algorithme indiqué à la concaténation de l'en-tête, du « . » et de la charge utile, puis en encodant le résultat en base64url. Par la suite, les trois parties séparées par un point constituent le JWT. Les détails sur la façon dont les signatures sont dérivées sont définis dans la RFC 7515.

Vous pouvez accéder au JWT ci-dessus dans ce débogueur en ligne sur JTW.io. D’abord, il affichera un message « Signature non valide ». Vous pouvez résoudre ce problème en remplaçant le secret par défaut affiché par !!!mon-très-long-secret-256-bits-!!!.

Étant donné qu'IBM Cloud propose de nombreux services dans son catalogue et qu'il s'agit d'une application Internet comportant de nombreux composants propres, il utilise largement les tokens, y compris les JWT. Vous avez probablement utilisé l’interface IBM Cloud Command Line (CLI) et la commande ibmcloud iam oauth-tokens:

Elle imprime les tokens porteurs OAuth (tokens d’accès) pour la session CLI actuelle, implémentés sous forme de JWT. Ces tokens IAM sont utilisés pour accéder aux services cloud compatibles IAM.

Si vous souhaitez intégrer des utilisateurs externes à votre compte cloud, là encore des JWT sont utilisés. Les tokens d’identité et les claims qu’ils contiennent sont échangés à des fins d’authentification afin d’identifier l’utilisateur. De nombreuses solutions utilisent le service de sécurité IBM Cloud App ID. Il permet d’authentifier les utilisateurs et de protéger les ressources. Il exploite les normes OAuth 2.0 et OpenID Connect mentionnées ci-dessus et gère donc les tokens d’accès, d’identification et d’actualisation.

L’un de mes services préférés (et des vôtres) est watsonx Assistant pour créer un chatbot. Si vous souhaitez sécuriser les chats sur la page Web (c’est-à-dire pour protéger davantage les messages échangés et certifier l’origine des messages), les JWT viennent à votre rescousse.

Il existe bien sûr de nombreux autres exemples d’utilisation des JWT pour échanger facilement des claims (de sécurité) et renforcer ainsi la sécurité d’une solution cloud.

Les JWT constituent un moyen simple et autonome d’échanger des claims entre deux parties. Il s’agit d’une structure de données omniprésente, dans le cloud et sur site. Nous espérons que cette introduction vous aura intéressé (si vous ne l’étiez pas déjà !).

Si vous souhaitez examiner et manipuler vous-même les JWT, nous vous recommandons d’utiliser un outil en ligne tel que https://jwt.io/ pour commencer. Si vous souhaitez approfondir le sujet, utilisez un outil de surveillance réseau ou les outils de développement de votre navigateur pour observer les JWT. Amusez-vous bien et consultez nos tutoriels IBM Cloud, notamment ceux consacrés à la sécurité.

Si vous avez des commentaires, des suggestions ou des questions concernant cet article, n’hésitez pas à me contacter sur X (@data_henrik) ou LinkedIn.