Introduction aux jetons Web JSON

nouveau: obtenez le manuel JWT gratuitement et apprenez JWTs en profondeur!

Qu’est-ce que JSON Web Token?

JSON Web Token (JWT) est un standard ouvert (RFC 7519) qui définit un moyen compact et autonome de transmettre en toute sécurité des informations entre les parties en tant qu’objet JSON. Ces informations peuvent être vérifiées et approuvées car elles sont signées numériquement. JWTs peut être signé en utilisant un secret (avec l’algorithme HMAC) ou une paire de clés publique/privée en utilisant RSA ou ECDSA.,

bien que les JWT puissent être cryptés pour assurer également le secret entre les parties, nous nous concentrerons sur les jetons signés. Les jetons signés peuvent vérifier l’intégrité des revendications qu’ils contiennent, tandis que les jetons cryptés cachent ces revendications aux autres parties. Lorsque les jetons sont signés à l’aide de paires de clés publiques/privées, la signature certifie également que seule la partie détenant la clé privée est celle qui l’a signée.

Quand devriez-vous utiliser des jetons Web JSON?

Voici quelques scénarios où les jetons Web JSON sont utiles:

• autorisation: c’est le scénario le plus courant pour utiliser JWT., Une fois que l’utilisateur est connecté, chaque requête suivante inclura le JWT, permettant à l’utilisateur d’accéder aux routes, services et ressources autorisés avec ce jeton. L’authentification unique est une fonctionnalité qui utilise largement JWT de nos jours, en raison de sa petite surcharge et de sa capacité à être facilement utilisée dans différents domaines.

• échange D’informations: les jetons Web JSON sont un bon moyen de transmettre des informations en toute sécurité entre les parties. Parce que JWTs peut être signé—par exemple, en utilisant des paires de clés publiques/privées-vous pouvez être sûr que les expéditeurs sont qui ils disent qu’ils sont., De plus, comme la signature est calculée à l’aide de l’en-tête et de la charge utile, vous pouvez également vérifier que le contenu n’a pas été altéré.

Quelle est la structure du jeton Web JSON?

sous sa forme compacte, les jetons Web JSON se composent de trois parties séparées par des points (.), qui sont:

• Header
• Payload
• Signature

Par conséquent, un JWT ressemble généralement à ce qui suit.

xxxxx.yyyyy.zzzzz

nous allons décomposer les différentes parties.,

Header

l’en-tête se compose généralement de deux parties: le type du jeton, qui est JWT, et l’algorithme de signature utilisé, tel que HMAC SHA256 ou RSA.

Par exemple:

{ "alg": "HS256", "typ": "JWT"}

ensuite, ce JSON est encodé en Base64Url pour former la première partie du JWT.

Charge

La deuxième partie de la marque est la charge utile, qui contient les revendications. Les réclamations sont des déclarations concernant une entité (généralement, l’utilisateur) et des données supplémentaires.Il existe trois types de demandes: enregistré, public et privé revendications.,

• revendications enregistrées: il s’agit d’un ensemble de revendications prédéfinies qui ne sont pas obligatoires mais recommandées, afin de fournir un ensemble de revendications utiles et interopérables. Certains d’entre eux sont: iss (émetteur), exp (délai d’expiration), sub (sujet), aud (audience), et d’autres.

  notez que les noms de revendication ne sont que trois caractères car JWT est censé être compact.

• revendications publiques: celles-ci peuvent être définies à volonté par ceux qui utilisent JWTs., Mais pour éviter les collisions, ils doivent être définis dans le registre IANA JSON Web Token OU être définis comme un URI contenant un espace de noms résistant aux collisions.

• revendications privées: ce sont les revendications personnalisées créées pour partager des informations entre les parties qui conviennent de les utiliser et ne sont ni des revendications enregistrées ni publiques.

Un exemple de charge utile pourrait être:

{ "sub": "1234567890", "name": "John Doe", "admin": true}

la charge utile est alors encodée en Base64Url pour former la deuxième partie du jeton Web JSON.,

notez que pour les jetons signés, ces informations, bien que protégées contre la falsification, sont lisibles par n’importe qui. Ne mettez pas d’informations secrètes dans la charge utile ou les éléments d’en-tête d’un JWT à moins qu’elles ne soient cryptées.

Signature

pour créer la partie signature, vous devez prendre l’en-tête codé, la charge utile codée, un secret, l’algorithme spécifié dans l’en-tête et le signer.,

par exemple, si vous souhaitez utiliser L’algorithme HMAC SHA256, la signature sera créée de la manière suivante:

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

la signature est utilisée pour vérifier que le message n’a pas été modifié en cours de route, et, dans le cas de jetons signés avec une clé privée, elle peut également vérifier que l’expéditeur du JWT est bien celui qu’il dit être.

ensemble

la sortie est composée de trois chaînes D’URL Base64 séparées par des points qui peuvent être facilement transmises dans les environnements HTML et HTTP, tout en étant plus compactes par rapport aux normes XML telles que SAML.,

ce qui suit montre un JWT qui a l’en-tête et la charge utile précédents encodés, et il est signé avec un secret.

Si vous voulez jouer avec JWT et mettre ces concepts en pratique, vous pouvez utiliser jwt.io débogueur pour décoder, vérifier et générer des JWT.

Comment faire JSON Web Jetons de travail?

dans l’authentification, lorsque l’utilisateur se connecte avec succès à l’aide de ses informations d’identification, un jeton Web JSON sera renvoyé. Étant donné que les jetons sont des informations d’identification, un grand soin doit être pris pour éviter les problèmes de sécurité., En général, vous ne devez pas conserver les jetons plus longtemps que nécessaire.

Vous ne devez pas non plus stocker les données de session sensibles dans le stockage du navigateur en raison d’un manque de sécurité.

chaque fois que l’Utilisateur souhaite accéder à une route ou à une ressource protégée, l’agent utilisateur doit envoyer le JWT, généralement dans l’en-tête Authorization à l’aide du schéma Bearer. Le contenu de l’en-tête doit ressembler à ce qui suit:

Authorization: Bearer <token>

Il peut s’agir, dans certains cas, d’un mécanisme d’autorisation sans état., Les routes protégées du serveur vérifieront un JWT valide dans l’en-tête Authorization, et s’il est présent, l’Utilisateur sera autorisé à accéder aux ressources protégées. Si le JWT contient les données nécessaires, la nécessité d’interroger la base de données pour certaines opérations peut être réduite, bien que ce ne soit pas toujours le cas.

Si le jeton est envoyé dans l’en-têteAuthorization, le partage de ressources D’origine croisée (cors) ne sera pas un problème car il n’utilise pas de cookies.,

le schéma suivant montre comment un JWT est obtenu et utilisé pour accéder aux API ou aux ressources:

1. l’application ou le client demande une autorisation au serveur d’autorisation. Ceci est effectué par l’un des différents flux d’autorisation. Par exemple, une application web compatible OpenID Connect typique passera par le point de terminaison /oauth/authorize à l’aide du flux de code d’autorisation.
2. Lorsque l’autorisation est accordée, l’autorisation de serveur renvoie un jeton d’accès à l’application.,
3. L’application utilise le jeton d’accès pour accéder à une ressource protégée (comme une API).

notez qu’avec les jetons signés, toutes les informations contenues dans le jeton sont exposées aux utilisateurs ou à d’autres parties, même s’ils ne peuvent pas les modifier. Cela signifie que vous ne devez pas mettre d’informations secrètes dans le jeton.

Pourquoi devrions-nous utiliser des jetons Web JSON?

parlons des avantages des jetons Web JSON (JWT) par rapport aux jetons Web simples (SWT) et aux jetons de langage de balisage D’Assertion de sécurité (SAML).,

comme JSON est moins verbeux que XML, lorsqu’il est codé, sa taille est également plus petite, ce qui rend JWT plus compact que SAML. Cela fait de JWT un bon choix pour être transmis dans les environnements HTML et HTTP.

sur le plan de la sécurité, SWT ne peut être signé symétriquement que par un secret partagé à l’aide de l’algorithme HMAC. Cependant, les jetons JWT et SAML peuvent utiliser une paire de clés publique/privée sous la forme d’un certificat X. 509 pour la signature. Signer XML avec la Signature numérique XML sans introduire de trous de sécurité obscurs est très difficile par rapport à la simplicité de la signature JSON.,

Les analyseurs JSON sont courants dans la plupart des langages de programmation car ils correspondent directement aux objets. Inversement, XML n’a pas de mappage naturel de document à Objet. Cela facilite le travail avec les assertions JWT que SAML.

en ce qui concerne l’utilisation, JWT est utilisé à L’échelle D’Internet. Cela met en évidence la facilité de traitement côté client du jeton Web JSON sur plusieurs plates-formes, en particulier mobile.,

comparaison de la longueur d’un JWT codé et D’un SAML codé

Si vous souhaitez en savoir plus sur les jetons Web JSON et même commencer à les utiliser pour effectuer une authentification dans vos propres applications, accédez à la page de destination du jeton Web JSON