Outils de développement · Décodeur JWT
Base64 vs Base64url : pourquoi un JWT échoue dans un décodeur Base64 standard
· Comment ça marche
jwt base64 codage
Collez un segment JWT dans un décodeur base64 ordinaire et il peut se plaindre de caractères ou de remplissage. Cet article explique les mandats JWS de la variante base64url et comment effectuer la conversion entre les deux.
Caractère invalide, remplissage incorrect : les erreurs qui apparaissent lorsque base64 rencontre base64url
Un message « caractère invalide » ou « remplissage incorrect » signifie souvent qu'un segment JWT a été attribué à un décodeur qui attend du Base64 ordinaire. Le jeton peut être copié correctement. Sa représentation suit les conventions base64url, tandis que l'utilitaire récepteur accepte un alphabet apparenté mais non identique ou insiste sur un remplissage explicite.
ToolAcre évite cette inadéquation entre l'en-tête et la charge utile. Son décodeur d'octets supprime les espaces, traduit les symboles sécurisés pour les URL, restaure le remplissage omis lorsque la longueur le permet, puis convertit les octets en UTF-8 strict. L'échec à n'importe quelle étape devient une erreur INVALID_JWT plutôt qu'une exception brute du navigateur.
Deux alphabets : plus et barre oblique par rapport au trait d'union et au trait de soulignement, et pourquoi les URL ont forcé le changement
Standard Base64 utilise plus et slash pour ses deux dernières positions alphabétiques. Base64url attribue un trait d'union et un trait de soulignement à ces mêmes positions. Les valeurs sous-jacentes à six bits ne changent pas, donc la traduction de `-` en `+` et de `_` en `/` préserve chaque octet décodé ; seule l'orthographe de sécurité pour le transport change.
Ces substitutions sont importantes dans les canaux où le plus ou la barre oblique a déjà une syntaxe. Une orthographe sécurisée pour les URL réduit les interprétations accidentelles lors du traitement du formulaire ou du chemin. Cela n’ajoute pas de secret, d’intégrité ou d’authenticité. Toute personne recevant un segment peut inverser les substitutions et récupérer les mêmes octets sans clé cryptographique.
Remplissage - pourquoi JWS supprime les signes égal et comment les restaurer pour un décodeur strict
ToolAcre accepte le remplissage omis. Après normalisation alphabétique, il examine la longueur du segment modulo quatre. Un reste de deux nécessite deux signes égal et un reste de trois en nécessite un. Un reste de un est impossible pour une valeur Base64 complète et est rejeté comme une chaîne tronquée plutôt que deviné.
La récupération du rembourrage est un encadrement mécanique, pas une réparation symbolique. L'ajout de signes égal ne peut pas restaurer les caractères perdus lors de la copie, et un décodage d'octets réussi ne montre pas que les octets proviennent d'un émetteur. L'implémentation reconstruit simplement la longueur canonique requise par le décodeur du navigateur avant d'appeler `atob`.
Décoder l'intégralité du jeton en une seule fois – l'erreur de ne pas diviser d'abord par points
Un jeton signé compact doit être divisé en points avant qu'un segment ne soit décodé. Passer `header.payload.signature` à une fonction Base64 introduit des points qui appartiennent à la sérialisation JWT, et non à l'un ou l'autre de l'alphabet Base64. ToolAcre nécessite exactement trois segments pour cette entrée en forme de JWS et rapporte le nombre observé lorsque cette structure est absente.
Le cas en cinq parties reçoit un message JWE distinct car la sérialisation compacte chiffrée n'est pas le même objet. Deux ou quatre parties suggèrent plutôt une troncature ou une mauvaise saisie. Cette vérification structurelle intervient avant l'interprétation de JSON, gardant une erreur de copie distincte du texte codé mal formé ou du JSON mal formé.
Exemple pratique : conversion d'un segment de base64url en base64, remplissage et décodage en JSON
Pour une conversion réussie, prenez `eyJhbGciOiJIUzI1NiJ9`. Il ne contient aucun caractère alphabétique qui diffère selon les variantes, mais son remplissage manquant illustre toujours le pipeline. Sa longueur permet la restauration du rembourrage ; le décodage donne UTF-8 octets pour `{"alg":"HS256"}`, et l'analyse JSON produit un objet avec une propriété `alg`.
Un segment contenant un trait d'union ou un trait de soulignement suit la même séquence avec les deux remplacements de symboles en premier. ToolAcre effectue ces opérations dans `base64ToBytes`, puis `decodeSegment` analyse le texte résultant. L'algorithme affiché est celui déclaré par l'en-tête non vérifié ; elle n'est pas sélectionnée comme politique de vérification.
Unicode dans les revendications — pourquoi les octets décodés doivent être lus comme UTF-8 pour afficher correctement les noms
Les revendications peuvent contenir des accents, des caractères CJK ou des emoji. Base64 fonctionne sur des octets, donc traiter chaque octet décodé comme un caractère indépendant corrompt le texte multi-octets. Le chemin correct est constitué de symboles codés en octets, puis d'un décodeur UTF-8. ToolAcre construit `TextDecoder` avec le mode fatal, donc UTF-8 invalide échoue bruyamment.
Les tests couvrent une charge utile contenant `Zoë 世界 🙂` et attendent la chaîne exacte après décodage. Ce résultat prouve que le pipeline octet-texte a conservé cette valeur de test. Cela ne dit toujours pas si la personne nommée par la charge utile existe, si l'émetteur a approuvé la réclamation ou si le jeton a été modifié.
Ce que cela ne couvre pas : le segment de signature, qui décode en octets plutôt qu'en texte et a besoin d'une clé pour signifier quoi que ce soit.
Le segment de signature se trouve en dehors du chemin JSON. ToolAcre conserve sa forme codée d'origine et essaie uniquement de mesurer la longueur d'octet décodée. La signature invalide Base64 produit un avertissement mais n'empêche pas l'inspection de l'en-tête et de la charge utile ; un troisième segment vide produit un avertissement différent indiquant qu'aucun octet de signature n'est présent.
Aucun des deux résultats n'est un résultat de vérification. Une validation de signature significative nécessite un matériel de clé fiable, un algorithme autorisé choisi indépendamment des entrées contrôlées par l'attaquant et des contrôles d'application. Un nombre d'octets est utile pour diagnostiquer la forme, mais zéro ou trente-deux octets mesurés ne peuvent pas autoriser une demande ou établir un émetteur.
À retenir : utilisez un décodeur qui parle base64url – le décodeur ToolAcre JWT gère l'alphabet et le remplissage pour l'en-tête et la charge utile.
Utilisez un décodeur qui comprend l'url base64 lorsque la tâche immédiate inspecte JSON. ToolAcre gère l'alphabet, le remplissage omis, le UTF-8 strict et le JSON objet uniquement pour les deux premiers segments. Il rejette également les longueurs impossibles et enveloppe les échecs d'analyse dans des messages qui identifient si l'en-tête ou la charge utile a échoué.
Arrêtez-vous à cette limite. Un décodage propre signifie que la chaîne contenait des octets récupérables et des objets JSON appropriés. Cela ne signifie pas que ses affirmations sont dignes de confiance, authentifiées, autorisées ou non modifiées. Seul un vérificateur configuré séparément peut répondre à ces questions, et cet outil de navigation n'expose délibérément aucune opération de vérification.