Αποκωδικοποίηση JSON Web Token (JWT)

αποκωδικοποιεί το JWT token σας (JSON Web Token) και εμφανίζει τις πληροφορίες που περιέχει με αναγνώσιμο και δομημένο τρόπο

Τι είναι ένα JWT (JSON Web Token);

Ένα JSON Web Token, συντομογραφία σε JWT (προφέρεται "jot"), είναι μια μορφή συμπαγής που ορίζεται από το RFC 7519 που επιτρέπει τη μεταφορά μιας σειράς αξιώσεων (αξιώσεις) μεταξύ δύο μερών. Το JWT, ή JWT token, είναι η κυρίαρχη μορφή σήμερα για να μεταφέρετε μια επαληθευμένη ταυτότητα σε ένα API HTTP. Ένα JWT εμφανίζεται ως συμβολοσειρά ASCII αποτελείται από τρία τμήματα που χωρίζονται με σημεία:

header.payload.signature

Κάθε τμήμα κωδικοποιείται στο Base64URL, μια παραλλαγή του Base64 χωρίς padding = και αντικαθιστά το + με - και το / με _ ώστε να μπορεί να ρέει μέσω μιας διεύθυνσης URL ή κεφαλίδας HTTP χωρίς επιπλέον διαφυγή.

Σημαντικό: Ένα JWT ΔΕΝ είναι κρυπτογραφημένο. Η τυπική μορφή JWT (JWS) είναι απλά υπογεγραμμένο: η υπογραφή εγγυάται την ακεραιότητα του περιεχομένου, αλλά δεν παρέχει καμία εμπιστευτικότητα. Οποιοσδήποτε μπορεί να αποκωδικοποιήσει ένα ωφέλιμο φορτίο JWT με ένα απλό αντίστροφο Base64URL, όπως κάνει αυτό το διαδικτυακό εργαλείο jwt decode.

Ανατομία ενός JWT

Ένα json web token αποτελείται από τρία πολύ διαφορετικά μέρη, το καθένα από τα οποία παίζει έναν συγκεκριμένο ρόλο στον μηχανισμό ελέγχου ταυτότητας:

1. Κεφαλίδα

Η κεφαλίδα είναι ένα αντικείμενο JSON που περιγράφει τον τρόπο υπογραφής του διακριτικού. Περιέχει τουλάχιστον:

  • alg (αλγόριθμος): ο αλγόριθμος υπογραφής που χρησιμοποιείται. Τυπικές τιμές: HS256, RS256, ES256, EdDSA.
  • typ (τύπος): ο τύπος του διακριτικού, σχεδόν πάντα "JWT".
  • παιδί (αναγνωριστικό κλειδιού): προαιρετικό, προσδιορίζει ποιο κλειδί πρέπει να χρησιμοποιηθεί για επαλήθευση της υπογραφής. Πρακτικό με την παρουσία ενός περιστρεφόμενου σετ πλήκτρων (JWKS).

2. Ωφέλιμο φορτίο

Το ωφέλιμο φορτίο περιέχει τις αξιώσεις, δηλαδή τις αξιώσεις που κάνει ο εκδότης σχετικά με τον χρήστη ή την περίοδο σύνδεσης. Το RFC 7519 ορίζει επτά τυπικές αξιώσεις (καταχωρισμένες αξιώσεις):

  • iss (εκδότης): ποιος εξέδωσε το διακριτικό, για παράδειγμα "https://accounts.google.com".
  • sub (θέμα): σε ποιον ανήκει το διακριτικό, στην πράξη το αναγνωριστικό χρήστη.
  • aud (κοινό): για ποιον προορίζεται το διακριτικό. Αποφύγετε ένα διακριτικό που εκδίδεται για το API A γίνεται αποδεκτό από το API B.
  • exp (χρόνος λήξης): Χρονική σήμανση Unix μετά την οποία το διακριτικό δεν είναι πλέον έγκυρο.
  • nbf (όχι πριν): χρονική σήμανση πριν από την οποία δεν βρίσκεται το διακριτικό ακόμα ενεργό.
  • iat (έκδοση στις): χρονική σήμανση έκδοσης διακριτικού.
  • jti (JWT ID): μοναδικό αναγνωριστικό του διακριτικού, που χρησιμοποιείται για ανάκληση και αποτροπή επανάληψης.

Σε αυτές τις τυπικές αξιώσεις προστίθενται γενικά προσαρμοσμένες αξιώσεις που αφορούν συγκεκριμένα την εφαρμογή (ρόλοι, scope, tenant_id, email, άδειες...).

3. Υπογραφή

Η υπογραφή είναι ένα κρυπτογραφικό συμπύκνωμα που υπολογίζεται σε base64url(κεφαλίδα) + "." + base64url(payload) χρησιμοποιώντας ένα κλειδί. Αυτή είναι που το αποδεικνύει ότι κανείς δεν έχει τροποποιήσει την κεφαλίδα ή το ωφέλιμο φορτίο από τη μετάδοση. Οι πιο συνηθισμένοι αλγόριθμοι:

  • HS256 / HS384 / HS512: συμμετρική υπογραφή HMAC-SHA. Ένα κοινό μυστικό κλειδί μεταξύ του εκδότη και του επαληθευτή. Απλό, αλλά ακατάλληλο όταν υπάρχουν περισσότεροι από ένας καταναλωτές.
  • RS256 / RS384 / RS512: ασύμμετρη υπογραφή RSA. Ο πομπός υπογράφει με το κλειδί του ιδιωτικό, οποιοσδήποτε καταναλωτής επαληθεύει με το αντίστοιχο δημόσιο κλειδί. De facto πρότυπο για OAuth2 και OpenID Connect.
  • ES256 / ES384 / ES512: ασύμμετρη υπογραφή ECDSA. Τα ίδια ακίνητα με RS256 αλλά με πολύ μικρότερα κλειδιά και υπογραφές.
  • EdDSA (Ed25519): μοντέρνα, γρήγορη και συμπαγής ασύμμετρη υπογραφή.

Για άλλη μια φορά: η υπογραφή προστατεύει την ακεραιότητα και όχι την εμπιστευτικότητα. Το Το ωφέλιμο φορτίο παραμένει αναγνώσιμο από οποιονδήποτε κατέχει το διακριτικό.

Γιατί να αποκωδικοποιήσετε ένα JWT;

Η λειτουργία jwt token decode καλύπτει πολλές συγκεκριμένες ανάγκες για έναν προγραμματιστή ή μηχανικός ασφαλείας:

  • Εντοπισμός σφαλμάτων ελέγχου ταυτότητας: το API σας επιστρέφει ένα 401 ή 403, που θέλετε να δείτε τι είναι πραγματικά στο ωφέλιμο φορτίο (sub, scope, ρόλοι, exp) αντί να μαντέψετε.
  • Έλεγχος αξιώσεων: επιβεβαιώστε ότι ένα διακριτικό περιέχει την αξίωση αναμένεται (π.χ. tenant_id ή άδειες) πριν από την αναζήτηση αλλού στην αλυσίδα εξουσιοδότησης.
  • Λήξη ανάγνωσης: μετατρέψτε τη χρονική σήμανση exp σε ανθρώπινη ημερομηνία για επιβεβαιώστε ότι ένα διακριτικό έχει λήξει ή, αντίθετα, ότι θα πρέπει να εξακολουθεί να ισχύει.
  • Έλεγχος ασφαλείας: διασφάλιση ότι μια υπηρεσία τρίτου μέρους δεν διαρρέει πληροφορίες ευαίσθητο στο ωφέλιμο φορτίο (email, εσωτερικά αναγνωριστικά, προσωπικά δεδομένα).
  • Εκπαίδευση και κατανόηση: δείτε συγκεκριμένα τι α Το jsonwebtoken βγαίνει από έναν πάροχο OAuth (Google, Auth0, Keycloak, AWS Cognito) για κατανοήστε τη μηχανική χωρίς να βουτήξετε στα έγγραφα.
  • Εξερεύνηση δημόσιων διακριτικών: επιθεωρήστε ένα JWT που βρίσκεται σε αρχεία καταγραφής, σε cookie ή σε υποκλοπή ανταλλαγή OAuth.

Αποκωδικοποιητής εναντίον Επαληθευτή: η κρίσιμη διάκριση

Οι δύο λειτουργίες φαίνονται παρόμοιες, αλλά δεν έχουν καμία σχέση όσον αφορά τις εγγυήσεις ασφαλείας:

  • Η αποκωδικοποίηση ενός JWT συνίσταται στον διαχωρισμό της συμβολοσειράς στο . και εφαρμόστε ένα αντίστροφο Base64URL στα δύο πρώτα τμήματα. Είναι μια απλή ανάγνωση, σε κοντινή απόσταση οποιουδήποτε σεναρίου τριών γραμμών. Καμία επαλήθευση υπογραφής δεν έχει γίνει.
  • Η επαλήθευση ενός JWT συνίσταται στον επανυπολογισμό της υπογραφής από την κεφαλίδα, ωφέλιμο φορτίο και ένα κλειδί, συγκρίνοντας στη συνέχεια το αποτέλεσμα με την υπογραφή που υπάρχει στο διακριτικό. Είναι η οποία εγγυάται ότι το διακριτικό δεν έχει παραβιαστεί.

Πρακτικό συμπέρασμα: δεν αξίζει να εμπιστευτείς την αποκωδικοποίηση. Όσο η υπογραφή δεν έχει επαληθευτεί με το σωστό κλειδί, το περιεχόμενο του ωφέλιμου φορτίου μπορεί να είναι εντελώς ψεύτικο. Για το φάση εμπιστοσύνης, χρησιμοποιήστε τον JWT Verifier.

Πώς να το χρησιμοποιήσετε

  1. Επιθεωρήστε το JWT, για παράδειγμα από μια κεφαλίδα Εξουσιοδότηση: Φορέας , από ένα cookie περιόδου λειτουργίας, από το localStorage από το πρόγραμμα περιήγησης ή από ένα αρχείο καταγραφής εφαρμογής.
  2. Επικολλήστε την πλήρη συμβολοσειρά στο πεδίο εισαγωγής. Τα τρία τμήματα πρέπει να διαχωρίζονται με σημεία.
  3. Το εργαλείο εμφανίζει αμέσως την κεφαλίδα αποκωδικοποιημένη σε μορφοποιημένο JSON, με τον αλγόριθμο και τον τύπο.
  4. Το ωφέλιμο φορτίο στη συνέχεια αποκωδικοποιείται και εμφανίζεται. Εκεί βλέπετε όλους τους ισχυρισμούς τυπικό και προσαρμοσμένο.
  5. Το εργαλείο υποδεικνύει επίσης τις πληροφορίες υπογραφής (δηλωμένος αλγόριθμος, μήκος), χωρίς να το ελέγξετε.
  6. Για να επιβεβαιώσετε ότι το διακριτικό δεν έχει παραβιαστεί, μεταβείτε στο δικό μας JWT Verifier με το αναμενόμενο δημόσιο κλειδί ή μυστικό.

Όλη η αποκωδικοποίηση γίνεται στο πρόγραμμα περιήγησής σας σε JavaScript: το διακριτικό σας δεν αποστέλλεται ποτέ στους διακομιστές μας.

JWT και ασφάλεια: παγίδες που πρέπει να αποφευχθούν

ΠΟΤΕ μην αποθηκεύετε ευαίσθητα δεδομένα στο ωφέλιμο φορτίο ενός υπογεγραμμένου JWT.

Κωδικοί πρόσβασης, αριθμοί πιστωτικών καρτών, ιατρικά δεδομένα, μυστικά API, αναγνωριστικά κρίσιμα εσωτερικά: τα πάντα στο ωφέλιμο φορτίο είναιαναγνώσιμα από οποιονδήποτε κατέχει το διακριτικό, συμπεριλαμβανομένου του ίδιου του χρήστη μέσω των εργαλείων προγραμματιστή του το πρόγραμμα περιήγησής του. Η υπογραφή δεν κρύβει τίποτα, απλώς αποδεικνύει ότι ο εκδότης είναι όντως που ισχυρίζεται ότι είναι.

Μερικοί χρυσοί κανόνες για τη σωστή χρήση του JWT στην παραγωγή:

  • Ελέγχετε πάντα την υπογραφή από την πλευρά του διακομιστή πριν εκχωρήσετε οποιαδήποτε δικαιώματα. Ο JWT Verifier απεικονίζει ακριβώς αυτήν τη λειτουργία.
  • Προτιμήστε το RS256 ή το ES256 από το HS256 για δημόσια API. Η υπογραφή Το asymmetric αποφεύγει να μοιράζεται ένα μυστικό μεταξύ του πομπού και κάθε καταναλωτή.
  • Να σέβεστε πάντα τον ισχυρισμό exp. Ένα JWT χωρίς λήξη ή με Η εκπνοή πολύ μακριά είναι ωρολογιακή βόμβα σε περίπτωση διαρροής.
  • Επικυρώστε iss και aud από την πλευρά του διακομιστή, για να αποτρέψετε Το νόμιμο διακριτικό που εκδόθηκε για άλλη υπηρεσία γίνεται αποδεκτό κατά λάθος.
  • Απόρριψη alg: "none" στην πλευρά επαλήθευσης. Αυτό είναι ένα κλασικό ελάττωμα που επιτρέπει σε έναν εισβολέα να πλαστογραφήσει οποιοδήποτε ωφέλιμο φορτίο.
  • Διατηρήστε τη διάρκεια ζωής μικρή (15 λεπτά για παράδειγμα) και συνδυάστε με Ανανέωση διακριτικού μεγαλύτερη αλλά με δυνατότητα ανάκλησης από την πλευρά του διακομιστή.

Παράδειγμα αποκωδικοποιημένου JWT token

Ακολουθεί ένα τυπικό JWT:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiSm9obi IsImlhdCI6MTUxNjIzOTAyMn0.jrU9j8LZcRK2_BZjqXjU7lEpJbkqmXfTQIu9vT45j-I

Μόλις αποκωδικοποιηθεί, ακολουθεί το περιεχόμενό του:

// Κεφαλίδα
{
  "alg": "HS256",
  "type": "JWT"
}

// Ωφέλιμο φορτίο
{
  "sub": "123",
  "όνομα": "Γιάννης",
  "iat": 1516239022
}

// Υπογραφή (δυαδικό, Base64URL κωδικοποιημένο)
HMACSHA256(
  base64url(κεφαλίδα) + "." + base64url (ωφέλιμο φορτίο),
  μυστικό
)

Πού να βρείτε ένα JWT για αντιγραφή;

Στην πράξη, ένα JWT για αποκρυπτογράφηση (με την έννοια της αποκωδικοποίησης) προέρχεται τις περισσότερες φορές από ένα από αυτά τοποθεσίες:

  • Cookie HTTP: ανοίξτε τα εργαλεία ανάπτυξης (F12), καρτέλα Εφαρμογή ή Αποθηκευτικός χώρος και μετά Cookies. Εντοπίστε ένα cookie με όνομα access_token, jwt, συνεδρία ή παρόμοια.
  • localStorage / sessionStorage: ίδιο πλαίσιο, ενότητα Τοπικός χώρος αποθήκευσης. Πολλά SPA αποθηκεύουν το διακριτικό τους εκεί κάτω από ένα κλειδί token ή auth.
  • Κεφαλίδα
  • Εξουσιοδότηση: καρτέλα Δίκτυο, επιλέξτε ένα Αίτημα API, διαβάστε την κεφαλίδα Authorization: Bearer . Αντιγράψτε μόνο το μέρος μετά το Φορέας .
  • Αρχεία καταγραφής διακομιστή: ένα JWT εμφανίζεται μερικές φορές στα αρχεία καταγραφής μιας πύλης ή μιας πύλης αντίστροφος διακομιστής μεσολάβησης (που πρέπει να αποφεύγεται στην παραγωγή, αλλά είναι χρήσιμος στον εντοπισμό σφαλμάτων).

Συχνές ερωτήσεις

Le JWT est-il chiffré ou en clair ?

Un JWT signé (format JWS) est seulement encodé en Base64URL, pas chiffré. Toute personne qui intercepte un token peut lire le payload en quelques secondes. Si vous devez transporter des données vraiment confidentielles dans le token, il faut utiliser le format JWE (JSON Web Encryption), qui ajoute une couche de chiffrement par-dessus la signature. En pratique, le JWE reste rare : on préfère ne pas mettre de données sensibles dans un jeton et conserver les informations critiques en base côté serveur.

Comment révoquer un JWT avant son expiration ?

C'est l'un des points faibles du JWT : par construction, le serveur n'a pas besoin de stocker l'état du token, donc il ne sait pas non plus comment le marquer comme révoqué. Trois approches existent. Liste de révocation : maintenir côté serveur la liste des jti invalidés, et la consulter à chaque requête. Durées de vie courtes : émettre des access tokens valides 5 à 15 minutes, et utiliser un refresh token révocable côté serveur pour en générer de nouveaux. Rotation de clé de signature : invalider toute une génération de tokens en changeant la clé. La deuxième approche est de loin la plus répandue.

Quelle différence entre un JWT et une session classique ?

Une session classique stocke un identifiant opaque côté client (généralement dans un cookie) et conserve toutes les données associées (utilisateur, droits, expiration) en mémoire ou en base côté serveur. Un JWT, au contraire, transporte directement ces données dans le token signé. Avantage du JWT : le serveur n'a pas besoin de stocker de session, ce qui simplifie le scaling horizontal et l'architecture microservices. Inconvénients : la révocation est plus complexe, le token est plus volumineux à chaque requête, et la moindre fuite expose le payload.

Différence entre JWT, JWS et JWE ?

JWT (RFC 7519) est un format de jeton générique. Il peut être implémenté de deux manières concrètes : JWS (RFC 7515, JSON Web Signature) qui se contente de signer le payload, et JWE (RFC 7516, JSON Web Encryption) qui le chiffre. En pratique, quand on parle de "JWT" sans précision, on parle presque toujours d'un JWS : un token signé mais lisible par tous. Le JWE est utilisé dans les contextes où la confidentialité du payload est indispensable, par exemple dans certains scénarios OpenID Connect avancés.

Mon JWT n'est pas accepté par l'API, pourquoi ?

Les causes classiques sont, par ordre de fréquence : token expiré (vérifiez le claim exp), signature invalide (clé secrète ou clé publique ne correspond pas à celle utilisée par l'émetteur), mauvais aud (le token a été émis pour un autre service), mauvais iss (l'émetteur déclaré n'est pas celui attendu), algorithme refusé (l'API exige par exemple RS256 et reçoit un HS256), horloges désynchronisées entre l'émetteur et le vérificateur (joue sur exp et nbf). Décoder le token avec cet outil permet déjà d'éliminer la moitié des hypothèses en lisant directement les claims.

Comment générer un JWT ?

La plupart des langages disposent d'une bibliothèque dédiée : jsonwebtoken en Node.js, PyJWT en Python, lcobucci/jwt ou firebase/php-jwt en PHP, jjwt en Java, golang-jwt/jwt en Go. Toutes prennent en entrée un objet payload, une clé et un algorithme, et retournent la chaîne header.payload.signature prête à être envoyée. Il est fortement déconseillé d'implémenter la génération à la main : la cryptographie comporte trop de pièges (comparaisons non constantes, gestion incorrecte de alg: none, etc.).

Le decoder accepte-t-il un JWT expiré ?

Oui. Le decoder se contente d'afficher le contenu du token sans porter de jugement sur sa validité temporelle. Il n'évalue ni exp, ni nbf, ni la signature. C'est utile pour comprendre pourquoi un token a été rejeté par une API : on peut comparer la valeur de exp à l'heure actuelle pour confirmer qu'il est bien expiré.

Mon JWT est-il valide si le decoder l'affiche correctement ?

Non. L'affichage prouve uniquement que la chaîne est bien formée (trois segments séparés par des points, encodage Base64URL correct, JSON valide dans le header et le payload). Cela ne dit rien de l'authenticité du token. Un JWT entièrement falsifié peut s'afficher sans erreur dans un decoder, c'est précisément pour cela qu'on doit le passer à un verifier.

Παράδειγμα αιτήματος

curl -X POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute \
  -H "Content-Type: application/json" \
  -d '{"token":"..."}'

Σχήμα εισόδου

Πεδίο Τύπος Απαιτείται Προεπιλογή
token text

Σημεία πρόσβασης

  • GET https://cdrn.fr/api/v1/tools - εμφανίζει όλα τα διαθέσιμα εργαλεία
  • GET https://cdrn.fr/api/v1/tools/jwt-decoder - ανακτά το σχήμα αυτού του εργαλείου
  • POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute - εκτελεί αυτό το εργαλείο με payload JSON