Maîtriser JWT (JSON Web Tokens) : une plongée approfondie-js tutoriel-php.cn

JSON Web Token (JWT) : une solution populaire pour l'authentification inter-domaines

Cet article présente les principes et l'utilisation de JSON Web Token (JWT), la solution d'authentification inter-domaines la plus populaire actuellement.

1. Les défis de l'authentification inter-domaines

Les services Internet sont indissociables de l'authentification des utilisateurs. Le processus traditionnel est le suivant :

L'utilisateur envoie le nom d'utilisateur et le mot de passe au serveur.
Après une authentification réussie du serveur, le rôle de l'utilisateur, l'heure de connexion et d'autres données associées seront enregistrés dans la session en cours.
Le serveur renvoie un session_id à l'utilisateur et l'écrit dans le cookie de l'utilisateur.
Chaque demande ultérieure de l'utilisateur renverra le session_id au serveur via Cookie.
Une fois que le serveur a reçu le session_id, il recherche les données pré-enregistrées pour identifier l'utilisateur.

Ce modèle a une faible évolutivité : un environnement mono-machine convient, mais un cluster de serveurs ou une architecture orientée services inter-domaines nécessite le partage des données de session, et chaque serveur peut lire la session. Par exemple, le site Web A et le site Web B sont des services liés de la même entreprise. Une fois que les utilisateurs se sont connectés à l'un des sites Web, ils peuvent se connecter automatiquement lorsqu'ils visitent l'autre site Web. Une solution consiste à conserver les données de session, à les écrire dans une base de données ou une autre couche de persistance, et à demander les données à la couche de persistance après que chaque service ait reçu la demande. Cette solution a une architecture claire, mais la charge de travail est importante et une défaillance de la couche de persistance entraînera un point de défaillance unique. Une autre option est que le serveur ne sauvegarde pas du tout les données de session, toutes les données sont enregistrées sur le client et renvoyées au serveur à chaque demande. JWT représente cette approche.

2. Principe de JWT

Le principe de JWT est que le serveur génère un objet JSON après vérification et le renvoie à l'utilisateur, par exemple :

<code class="language-json">{"name": "Alice", "role": "admin", "expiration time": "2024年7月1日0:00"}</code>

Copier après la connexion

Plus tard, lorsque l'utilisateur communique avec le serveur, cet objet JSON doit être renvoyé et le serveur détermine complètement l'identité de l'utilisateur en fonction de cet objet. Pour empêcher les utilisateurs de falsifier les données, le serveur ajoute une signature lors de la génération de cet objet (détails décrits plus loin). Le serveur n'enregistre plus aucune donnée de session, c'est-à-dire qu'il devient sans état et plus facile à mettre à l'échelle.

3.Structure des données JWT

Le JWT actuel ressemble à ceci :

Mastering JWT (JSON Web Tokens): A Deep Dive

C'est une longue chaîne séparée en trois parties par des points (.). Notez qu'il n'y a pas de sauts de ligne à l'intérieur du JWT, les sauts de ligne ici sont uniquement destinés à faciliter l'affichage. Les trois parties de JWT sont les suivantes :

En-tête
Charge utile
Signature

Une ligne est exprimée comme suit : Header.Payload.Signature

Mastering JWT (JSON Web Tokens): A Deep Dive

Ces trois parties sont présentées ci-dessous.

3.1 En-tête

La partie Header est un objet JSON décrivant les métadonnées du JWT, généralement comme suit :

<code class="language-json">{"alg": "HS256", "typ": "JWT"}</code>

Copier après la connexion

L'attribut alg représente l'algorithme de signature, la valeur par défaut est HMAC SHA256 (HS256) ; l'attribut typ représente le type de ce jeton et les jetons JWT sont uniformément écrits en JWT. Cet objet JSON est finalement converti en chaîne à l'aide de l'algorithme Base64URL (détails ci-dessous).

3.2 Charge utile

La partie Payload est également un objet JSON utilisé pour stocker les données réelles qui doivent être transmises. JWT définit 7 champs facultatifs officiels :

iss (émetteur) : Émetteur
exp (délai d'expiration) : délai d'expiration
sub (sujet) : sujet
aud (audience) : audience
nbf (Pas Avant) : temps effectif
iat (émis à)：Heure d'émission
jti (JWT ID) : numéro de série

En plus des champs officiels, les champs privés peuvent également être personnalisés. Par exemple :

<code class="language-json">{"name": "Alice", "role": "admin", "expiration time": "2024年7月1日0:00"}</code>

Copier après la connexion

Notez que JWT n'est pas crypté par défaut et peut être lu par n'importe qui, alors ne mettez pas d'informations secrètes dans cette section. Cet objet JSON doit également être converti en chaîne à l'aide de l'algorithme Base64URL.

3.3 Signature

La partie Signature est la signature des deux premières parties, utilisée pour empêcher la falsification des données. Tout d’abord, vous devez spécifier un secret. Ce secret n’est connu que du serveur et ne peut pas être divulgué à l’utilisateur. Utilisez ensuite l'algorithme de signature spécifié dans l'en-tête (la valeur par défaut est HMAC SHA256) pour générer une signature selon la formule suivante :

<code class="language-json">{"alg": "HS256", "typ": "JWT"}</code>

Copier après la connexion

Une fois la signature calculée, les trois parties En-tête, Charge utile et Signature sont combinées en une chaîne, et chaque partie est séparée par un "point" (.), qui peut être renvoyé à l'utilisateur.

3.4 URL Base64

Comme mentionné précédemment, l'algorithme de sérialisation de l'en-tête et de la charge utile est Base64URL. Cet algorithme est fondamentalement similaire à l'algorithme Base64, mais présente quelques différences mineures. En tant que jeton, JWT peut parfois être placé dans une URL (telle que api.example.com/?token=xxx. Les trois caractères en Base64, / et = ont des significations particulières dans l'URL et doivent être remplacés : = est). omis et remplacé par Remplacé par -, / est remplacé par _. Il s'agit de l'algorithme Base64URL.

4. Comment utiliser JWT

Une fois que le client a reçu le JWT renvoyé par le serveur, il peut le stocker dans Cookie ou localStorage. Le client doit transporter ce JWT chaque fois qu'il communique avec le serveur. Il peut être placé dans un cookie et envoyé automatiquement, mais cela ne peut pas être effectué entre domaines. Une meilleure approche consiste à le mettre dans le champ Autorisation de l'en-tête de la requête HTTP :

Autorisation : Porteur

Une autre approche consiste à mettre le JWT dans le corps de la requête POST lors du croisement de domaines.

5. Plusieurs caractéristiques de JWT

(1) JWT n'est pas chiffré par défaut, mais peut être chiffré. Une fois le jeton d'origine généré, il peut être à nouveau chiffré avec la clé.

(2) Si JWT n'est pas chiffré, les données secrètes ne peuvent pas être écrites.

(3) JWT peut être utilisé non seulement pour la vérification d'identité, mais également pour l'échange d'informations. Une utilisation efficace de JWT peut réduire le nombre de fois où le serveur interroge la base de données.

(4) Le plus gros inconvénient de JWT est que le serveur ne sauvegarde pas l'état de la session et ne peut pas révoquer un jeton ni modifier les autorisations du jeton pendant son utilisation. Autrement dit, une fois qu'un JWT est émis, il reste valide jusqu'à son expiration, à moins que le serveur ne déploie une logique supplémentaire.

(5) Le JWT lui-même contient des informations d'authentification, et une fois divulgués, n'importe qui peut obtenir toutes les autorisations du jeton. Pour réduire le vol, la période de validité de JWT doit être relativement courte. Pour certaines autorisations plus importantes, les utilisateurs doivent s'authentifier à nouveau lorsqu'ils les utilisent.

(6) Pour réduire le vol, JWT ne doit pas être transmis en texte clair via le protocole HTTP, mais doit être transmis via le protocole HTTPS.

Leapcell : la meilleure plateforme d'hébergement Web sans serveur

Mastering JWT (JSON Web Tokens): A Deep Dive