JWT-dekoder
Lim inn en JSON Web Token og les header og payload som formatert JSON, med utløps- og utstedelsestid vist som datoer og en merknad om tokenet er gyldig akkurat nå. Dekodingen skjer helt i nettleseren din, noe som er viktig når tokenet er en aktiv legitimasjon.
0 tegn · 0 ord · 0 linjer
0 tegn · 0 ord · 0 linjer
Kjører helt i denne nettleserfanen. Teksten din lastes aldri opp eller lagres.
Registrerte claims
De syv claim-navnene definert i RFC 7519 §4.1. Alle er valgfrie; tidspunkter er sekunder siden 1970-01-01 UTC.
| Claim | Betydning |
|---|---|
iss | Utsteder: hvem som opprettet og signerte tokenet |
sub | Subjekt: brukeren eller enheten tokenet gjelder |
aud | Målgruppe: hvem tokenet er ment for |
exp | Utløpstidspunkt: avvis tokenet etter dette tidspunktet |
nbf | Ikke før: avvis tokenet før dette tidspunktet |
iat | Utstedt: når tokenet ble opprettet |
jti | JWT-ID: unik identifikator, brukt for å hindre gjenbruk |
Vanlige alg-verdier
| alg-verdi | Betydning |
|---|---|
HS256 | HMAC med SHA-256; én delt hemmelighet signerer og verifiserer |
RS256 | RSA PKCS#1 v1.5-signatur med SHA-256; privat nøkkel signerer, offentlig nøkkel verifiserer |
PS256 | RSA-PSS med SHA-256 |
ES256 | ECDSA på P-256-kurven med SHA-256; korte signaturer |
EdDSA | Ed25519- eller Ed448-signaturer |
none | Usignert token; servere bør avvise det |
Slik er en JSON Web Token bygd opp
JWT er definert i RFC 7519 (mai 2015), som foreslår å uttale det som det engelske ordet «jot». Den vanlige signerte formen er tre Base64url-strenger skilt med punktum: header.payload.signature. Headeren angir signeringsalgoritmen i alg, for eksempel HS256 eller RS256, og ofte en nøkkel-ID i kid. Payloaden inneholder claims, JSON-felt som sub (brukeren), iss (utstederen), aud (tiltenkt mottaker) samt exp, nbf og iat, som er tidspunkter i sekunder siden 1. januar 1970 UTC. Dekoderen konverterer disse tre til lokal tid og ISO 8601, og forteller om tokenet har utløpt, ikke er gyldig ennå eller er innenfor gyldighetsperioden.
Base64url er en koding, ikke kryptering, så alle som har et token kan lese payloaden akkurat slik denne siden gjør. Legg aldri passord, kortnumre eller andre hemmeligheter i claims. Et token med fem deler skilt med punktum er en JWE, et kryptert token. Innholdet kan ikke leses uten nøkkelen, og dekoderen sier fra om det. Et innledende «Bearer » kopiert fra en Authorization-header fjernes automatisk.
Hvorfor signaturen ikke verifiseres her
Signaturen beviser at headeren og payloaden er laget av noen som har nøkkelen, og at de ikke er endret siden. For å sjekke den trengs nøkkelen: den delte hemmeligheten for HMAC-algoritmer som HS256, eller utstederens offentlige nøkkel for RS256, ES256 eller EdDSA. Det er en dårlig idé å lime inn en signeringshemmelighet fra produksjon på en nettside, og en dekoder som later som den kan garantere for et token uten nøkkel, ville gitt falsk trygghet. Derfor viser dette verktøyet signaturen, men verifiserer den ikke. Se på det du ser som en påstand tokenet kommer med, ikke som fakta.
Verifisering hører hjemme på serveren din, med et vedlikeholdt bibliotek og den forventede algoritmen låst. To historiske feil forklarer hvorfor: å godta alg «none», som lar hvem som helst forfalske et usignert token, og algoritmeforveksling, der en server som forventer RS256 lures til å sjekke en HS256-signatur med den offentlige nøkkelen som HMAC-hemmelighet. En dekoder er til feilsøking: å se hvilke claims en leverandør utsteder, oppdage feil audience eller finne ut at en økt feilet fordi exp utløp for et minutt siden. For å lese Base64url-segmentene rått kan du bruke Base64-dekoderen.
Ofte stilte spørsmål
- Er det trygt å lime inn et ekte tilgangstoken i en JWT-dekoder?
- På denne siden forlater tokenet aldri nettleseren din. Likevel fungerer et gyldig token som et passord til det utløper, så bruk helst utløpte eller test-tokens, og hold aktive tokens utenfor skjermbilder og chatter.
- Hvorfor vises tokenet mitt som utløpt når det nettopp ble utstedt?
- Sjekk klokken på enheten først. Noen utstedere gir access-tokens en levetid på bare noen få minutter, og et token kopiert fra en logg kan være eldre enn det ser ut til. En exp skrevet i millisekunder i stedet for sekunder gir det motsatte og havner tusenvis av år frem i tid.
- Kan noen endre payloaden i JWT-en min?
- De kan redigere og kode det på nytt, men signaturen stemmer da ikke lenger. En server som verifiserer signaturer med riktig nøkkel og algoritme avviser det endrede tokenet.
- Hva er forskjellen på JWS og JWE?
- En JWS (RFC 7515) er signert, har tre deler, og alle kan lese den. En JWE (RFC 7516) er kryptert, har fem deler, og bare den som har nøkkelen kan lese payloaden.
- Blir en JWT ugyldig når man logger ut?
- Ikke i seg selv. Et signert JWT forblir gyldig til exp med mindre serveren har en sperreliste eller sjekker en øktpost, og derfor får access-tokens vanligvis kort levetid.