Er det sikkert at indsætte min JWT her?

Ja. Afkodning sker udelukkende i din browser - tokenet sendes aldrig til nogen server. JWT'er er dog legitimationsoplysninger - del dem ikke offentligt (i skærmbilleder, Stack Overflow-indlæg osv.), da de kan give adgang til dine konti.

Verificerer dette værktøj JWT-signaturen?

Dette værktøj afkoder og viser tokenindholdet. Signaturbekræftelse kræver den hemmelige nøgle (HMAC) eller den offentlige nøgle (RSA/ECDSA), som skal forblive på din server. Værktøjet viser den anvendte algoritme, men kan ikke bekræfte uden nøglen.

Hvad betyder standard JWT-kravene?

iss = udsteder, sub = emne (bruger-id), exp = udløbstid (Unix-tidsstempel), iat = udstedt på, nbf = ikke før, aud = publikum, jti = JWT ID. Brugerdefinerede krav kan indeholde alle applikationsspecifikke data.

Hvorfor kan nogen afkode en JWT?

JWT'er er kodet, ikke krypteret. Nyttelasten er Base64URL-kodet (ikke krypteret), så alle kan læse den. Signaturen forhindrer manipulation, ikke læsning. Gem aldrig følsomme data (adgangskoder, SSN'er) i JWT-nyttelast.

Hvorfor mangler nogle tokens en signatur?

Tokens med alg: ingen har ingen signatur. De er gyldige JWT'er efter spec, men giver ingen ægthedsgarantier og bør ikke accepteres i produktionen.

Standard JWT-nyttelast er signeret, men ikke krypteret. JWE (JSON Web Encryption, RFC 7516) er et separat format for krypterede tokens. De fleste JWT'er i naturen er JWS (kun underskrevet).

Er mit token uploadet til en server?

Nej. Afkodning sker i din browser; tokenet forlader ikke din enhed.

Hvor lange er JWT'er typisk?

Alt fra et par hundrede til flere tusinde tegn. Længden afhænger af antallet og størrelsen af krav plus signaturlængden (som afhænger af algoritmen).

JWT-token Dekoder | Any-Tools.net

Om dette værktøj

JSON Web Tokens (JWT) er et kompakt, URL-sikkert format til overførsel af krav mellem to parter, defineret af RFC 7519. En JWT er tre base64url-kodede segmenter adskilt af prikker: header (algoritme og token-type), nyttelast (krav) og signatur (kryptografisk bevis på ægthed). Headeren og nyttelasten er JSON, base64url-kodet for URL-sikkerhed; signaturen bruger en af flere algoritmer (HS256, RS256, ES256 og andre) over den kodede header og nyttelast.

Afkodning af en JWT - opdeling af den i segmenter og base64-afkodning af hver - kræver ingen hemmelighed. Alle med token-teksten kan læse dens overskrift og nyttelast. Signaturen kan dog kun verificeres med hemmeligheden (HMAC) eller den offentlige nøgle (asymmetrisk). Afkodning er til inspektion; verifikation er det, der beviser ægthed.

Denne dekoder opdeler tokenet, base64-afkoder hvert segment, parser headeren og nyttelasten som JSON og viser resultatet. Den forsøger ikke signaturbekræftelse, fordi det kræver den hemmelige eller offentlige nøgle, som dekoderen ikke har. Det afkodede output er skrivebeskyttet inspektion - nyttigt til fejlfinding af tokens, men ikke en erstatning for korrekt verifikation i applikationskoden.

Hvorfor afkode JWT'er

Fejlretning af autentificeringsproblemer involverer næsten altid inspektion af tokens. Et token, der ser gyldigt ud i koden, kan have forkerte krav, en uventet algoritme, et udløbet tidsstempel eller publikumsmismatch. Afkodning af tokenet afslører præcis, hvad udstederen producerede.

Det hjælper også at inspicere poletter under integrationsarbejdet. Når du opretter forbindelse til en tredjeparts API eller identitetsudbyder, forstås de faktiske kravnavne, formater og struktur bedst ved at afkode prøvetokens i stedet for at stole på dokumentation, der kan være forældet.

Sådan bruger du det

Indsæt tokenet, få det analyserede indhold.

Indsæt din JWT: Slip hele tokenet (header.payload.signature) i inputområdet. Dekoderen accepterer tokens med eller uden det valgfrie bærerpræfiks.
Undersøg headeren: Overskriften viser signeringsalgoritmen (alg) og tokentypen (typ). Almindelige algoritmer er HS256, RS256 og ES256. Hold øje med alg: ingen, som signalerer et usigneret token og sjældent er sikkert i produktion.
Undersøg nyttelasten: Nyttelasten indeholder kravene: iss (udsteder), sub (emne), aud (publikum), exp (udløb), iat (udstedt på) og eventuelle applikationsspecifikke krav. Standardtidsstempler er Unix-epokesekunder.
Bekræft separat: Dekoderen verificerer ikke signaturen. For at kontrollere ægtheden skal du køre tokenet gennem et JWT-bibliotek med den relevante hemmelige eller offentlige nøgle i din applikationskode.

Almindelige anvendelsestilfælde

Fejlretning af udløbet token-fejl — Afkodning af tokenet afslører exp-kravet. Sammenlign med det aktuelle tidspunkt for at bekræfte, om udløbet er den faktiske årsag.
Forstå kravstrukturen for et tredjepartstoken — Identitetsudbydere (Auth0, Okta, Cognito) udsteder tokens med udbyderspecifikke kravlayouter. Afkodning af prøvetokens viser den faktiske struktur.
Inspicering af tokens under integration — Ved integration af SSO- eller OAuth-flows hjælper afkodningstokens ved hvert trin med at bekræfte, at dataene er formet som forventet.
Revision af tokens indhold for følsomme data — Tokens er ikke krypteret som standard; nyttelasten er læsbar. Afkodning af eksisterende tokens hjælper med at bekræfte, at følsomme data ikke er inkluderet ved et uheld.
Bekræftelse af publikums- og udstederkrav — Forsvar mod tokenforvirring kræver korrekt aud- og iss-håndtering. Afkodning af tokens under test bekræfter, at disse påstande er udfyldt korrekt.

Tekniske detaljer

JWT-formatet er tre segmenter forbundet med prikker. Hvert segment er base64url-kodet - den URL-sikre variant af base64, der bruger - og _ i stedet for + og /, med udfyldning nogle gange udeladt. Afkodning kræver at fortryde de URL-sikre substitutioner, udfyldning af segmentet og base64-afkodning.

Headeren og nyttelasten er JSON efter afkodning. Signatursegmentet er binært (rå signaturbytes) og kan ikke læses af mennesker; det kræver, at verifikationsnøglen er nyttig.

Almindelige krav defineret i RFC 7519: iss (udsteder), sub (emneidentifikator), aud (publikum), exp (udløb som Unix-epokesekunder), nbf (ikke-før-tidsstempel), iat (udstedt-til-tidsstempel), jti (unikt token-id). Applikationsspecifikke krav kan vises med et hvilket som helst navn.

Bedste praksis

Stol aldrig på en ubekræftet JWT — Afkodning afslører kun indholdet; det beviser ikke ægthed. Bekræft altid signaturen med den korrekte nøgle i applikationskoden, før du stoler på påstandene.
Hold øje med alg: ingen — Tokens med alg: ingen har ingen signatur. Ansøgningskode, der accepterer dem, er sårbar over for forfalskning. Kræv altid en specifik algoritme i din verifikationskonfiguration.
Vær forsigtig med følsomme data i nyttelast — JWT-nyttelast kan læses af alle med tokenet. Krypter nyttelasten (brug JWE), hvis den indeholder data, der skal være hemmelige.
Valider exp før behandling — Et udløbet token bør afvises, selvom signaturen er gyldig. JWT-biblioteker kontrollerer typisk exp automatisk; kontroller, at dit bibliotek gør det.

Ofte stillede spørgsmål

Er det sikkert at indsætte min JWT her?: Ja. Afkodning sker udelukkende i din browser - tokenet sendes aldrig til nogen server. JWT'er er dog legitimationsoplysninger - del dem ikke offentligt (i skærmbilleder, Stack Overflow-indlæg osv.), da de kan give adgang til dine konti.
Verificerer dette værktøj JWT-signaturen?: Dette værktøj afkoder og viser tokenindholdet. Signaturbekræftelse kræver den hemmelige nøgle (HMAC) eller den offentlige nøgle (RSA/ECDSA), som skal forblive på din server. Værktøjet viser den anvendte algoritme, men kan ikke bekræfte uden nøglen.
Hvad betyder standard JWT-kravene?: iss = udsteder, sub = emne (bruger-id), exp = udløbstid (Unix-tidsstempel), iat = udstedt på, nbf = ikke før, aud = publikum, jti = JWT ID. Brugerdefinerede krav kan indeholde alle applikationsspecifikke data.
Hvorfor kan nogen afkode en JWT?: JWT'er er kodet, ikke krypteret. Nyttelasten er Base64URL-kodet (ikke krypteret), så alle kan læse den. Signaturen forhindrer manipulation, ikke læsning. Gem aldrig følsomme data (adgangskoder, SSN'er) i JWT-nyttelast.
Hvorfor mangler nogle tokens en signatur?: Tokens med alg: ingen har ingen signatur. De er gyldige JWT'er efter spec, men giver ingen ægthedsgarantier og bør ikke accepteres i produktionen.
Er JWT'er krypteret?: Standard JWT-nyttelast er signeret, men ikke krypteret. JWE (JSON Web Encryption, RFC 7516) er et separat format for krypterede tokens. De fleste JWT'er i naturen er JWS (kun underskrevet).
Er mit token uploadet til en server?: Nej. Afkodning sker i din browser; tokenet forlader ikke din enhed.
Hvor lange er JWT'er typisk?: Alt fra et par hundrede til flere tusinde tegn. Længden afhænger af antallet og størrelsen af krav plus signaturlængden (som afhænger af algoritmen).

JWT-token Dekoder

Relaterede værktøjer

URL-koder / Dekoder

Base64 Encoder / Dekoder

JSON-formater & Validator

XML-formater & Validator

Om dette værktøj

Hvorfor afkode JWT'er

Sådan bruger du det

Almindelige anvendelsestilfælde

Tekniske detaljer

Bedste praksis

Ofte stillede spørgsmål

Related Articles

Essential Developer Tools: JSON, Base64, RegEx, and More

Hashing, Encryption, and Encoding Explained: A Developer's Security Guide

Spreadsheet & Data Conversion Guide: Excel, CSV, JSON, and More

Why Browser-Based Tools Are the Future: No Installs, No Uploads, No Risk