Auth0 jwt secret

Dans cet atelier, vous allez :

• Apprendre ce qu’est un JSON Web Token (JWT).
• Comprendre la structure de JWT.
• Découvrez comment décoder une chaîne encodée en base64
• Vérifier la signature d’un JWT.

Qu’est-ce que le jeton Web JSON (JWT) ?

JSON Web Token (JWT) est une norme ouverte (RFC 7519) qui définit une manière compacte et autonome pour transmettre en toute sécurité des informations entre les parties en tant qu’objet JSON. Ces informations peuvent être vérifiées et fiables car elles sont signées numériquement. Les JWT peuvent être signés à l’aide d’un secret (avec l’algorithme HMAC) ou d’une paire de clés publique/privée à l’aide de RSA ou ECDSA.

Bien que les JWT puissent être cryptés pour assurer la confidentialité entre les parties, nous nous concentrerons sur les jetons signés . Les jetons signés peuvent vérifier l'intégrité des revendications, 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 : Il s’agit du scénario le plus courant d’utilisation de JWT. Une fois que l’utilisateur est connecté, chaque demande suivante inclut le JWT, ce qui permet à l’utilisateur d’accéder aux routes, aux services et aux ressources qui sont limités à ce jeton. L’authentification unique est une fonctionnalité qui utilise largement JWT de nos jours, en raison de sa faible surcharge et de sa capacité à être facilement utilisée dans différents domaines.

• Échange d’informations : Les JSON Web Tokens sont un bon moyen de transmettre des informations en toute sécurité entre les parties. Étant donné que les JWT peuvent être signés, par exemple à l’aide de paires de clés publiques/privées, vous pouvez être sûr que les expéditeurs sont bien ceux qu’ils prétendent être. 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é.

Pourquoi utiliser des jetons Web JSON ?

Parlons des avantages des jetons Web JSON (JWT) par rapport aux jetons Web simples (SWT) et aux jetons SAML (Security Assertion Markup Language Tokens).

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

Du point de vue de la sécurité, SWT ne peut être signé symétriquement que par un secret partagé à l’aide de l’algorithme HMAC. Toutefois, les jetons JWT et SAML peuvent utiliser un paire de clés publiques/privées sous la forme d’un certificat X.509 pour la signature. Signer du XML avec XML Digital Signature sans introduire de failles de sécurité obscures 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 sont directement mappés aux objets. À l'inverse, XML n'a pas de mappage naturel document-objet. Cela facilite l’utilisation de JWT que d’assertions 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 plateformes, en particulier les mobiles.

Comparaison de la longueur d’un JWT encodé et d’un SAML encodé

Structure des jetons Web JSON

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

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

Décomposons les différentes parties.

En-tête

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

Par exemple :

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

Si nous supprimons les nouvelles lignes et les espaces, puis encodons l’exemple, le résultat sera le suivant :

La

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

• Revendications enregistrées : Il s’agit d’un ensemble de revendications prédéfinies qui ne sont pas obligatoires mais recommandées pour 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), etc.

• Revendications publiques : Celles-ci peuvent être définies à volonté par ceux qui utilisent les JWT. Mais pour éviter les collisions, ils doivent être définis en le registre de jetons Web JSON de l’IANA ou être défini comme un URI contenant un espace de noms résistant aux collisions.

• Créances privées : Ces créances coutumières permettent le partage d’informations entre les parties qui acceptent de les utiliser et ne sont ni des créances enregistrées ni publiques.

Un exemple de charge utile pourrait être :

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

En encodant la charge utile, comme nous l’avons fait pour l’en-tête, la sortie serait la suivante :

Signature

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

Par exemple, si vous souhaitez utiliser l'algorithme HMAC SHA256, la signature sera créée de la manière suivante :

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 est. Ce qui suit montre un JWT qui a la propriété l’en-tête et la charge utile précédents sont encodés, et il est signé avec un secret :

la sortie est constitué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 basées sur XML telles que SAML.

Dans les sections suivantes, vous allez 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.

Maintenant

que vous avez appris les bases de la structure et du fonctionnement d’un JSON Web Token (JWT), mettons toutes ces connaissances en pratique en jouant à un puzzle :

Un JWT a été brisé en plusieurs morceaux. Votre objectif est d’assembler correctement ces pièces pour former un JWT valide avec une signature vérifiée. Vous allez vous entraîner à former un en-tête JWT et une charge utile valides. Vous vous exercerez à déchiffrer le secret pour vérifier un Signature JWT.

Commençons !

Choisissons le premier morceau, , et utilisons la commande sur macOS et Linux pour le décoder :

Sous Windows, vous pouvez utiliser la commande pour décoder un fichier.

Créons un fichier nommé , puis mettons-le à l'intérieur.

Le résultat doit être le suivant :

Maintenant, vous pouvez décoder d’autres éléments et construire un en-tête et une charge utile en suivant la structure expliquée précédemment.

Vous pouvez également créer un programme simple avec le langage de votre choix pour automatiser le décodage.

Passons à la section suivante pour vérifier la signature d'un JWT.

Dans

cette section, nous allons voir comment vérifier la signature d’un JWT à l’aide du débogueur jwt.io.

Supposons que vous ayez réussi à assembler les pièces pour obtenir le JWT suivant :

Si vous ouvrez le jwt.io sur votre navigateur et collez le JWT dans la section, vous verrez Signature non valide .

En effet, le secret par défaut (dans ce cas) sur la page ne correspond pas au secret réel.

Le secret de ce JWT est " useauth0byoktatobuildyourcustomidentitypipeline " (pas d’espace, pas de point, toutes en petites lettres).

Si vous entrez un secret correct, vous verrez sign sur la page.

félicitations! Vous avez vérifié la signature de ce labo en trouvant un secret valide !

Annexe : Comment fonctionnent les jetons Web JSON travail?

Lors de l’authentification, un jeton Web JSON sera renvoyé lorsque l’utilisateur se connectera avec succès à l’aide de ses informations d’identification. Étant donné que les jetons sont des informations d’identification, il faut faire très attention à prévenir 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 de 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 :

Il peut s’agir, dans certains cas, d’un mécanisme d’autorisation sans état. Les routes protégées du serveur vérifient la présence d'un JWT valide dans l'en-tête et, s'il est présent, l'utilisateur est 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.

Notez que si vous envoyez des jetons JWT via des en-têtes HTTP, vous devez essayer d’éviter qu’ils ne deviennent trop volumineux. Certains serveurs n'acceptent pas plus de 8 Ko dans les en-têtes. Si vous essayez d'incorporer trop d'informations dans un jeton JWT, par exemple en incluant toutes les autorisations de l'utilisateur, vous aurez peut-être besoin d'une solution alternative, comme Auth0 Fine-Grained Authorization.

Le diagramme suivant montre comment un JWT est obtenu et utilisé pour accéder aux API ou aux ressources :

1. L’application ou le client demande l’autorisation au serveur d’autorisation. Cette opération s’effectue par le biais de l’un des différents flux d’autorisation. Par exemple, une application Web standard compatible OpenID Connect passera par le point de terminaison à l’aide du flux de code d’autorisation.
2. Lorsque l’autorisation est accordée, le serveur d’autorisation 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.

Dans

cet atelier, vous avez appris :

• Apprenez ce qu’est un jeton Web JSON (JWT).
• Apprenez la structure de JWT.
• Découvrez comment vérifier la signature sur jwt.io

Si vous souhaitez en savoir plus sur JWT, vous pouvez télécharger un manuel JWT.