> dekod | inspiser | verifiser <
// Dekod og inspiser JSON Web Tokens (JWT) umiddelbart
Lokal Behandling
100% klientside JWT-dekoding. Tokenene dine forlater aldri nettleseren.
Auto-Dekoding
Dekod JWT-tokens automatisk ved innliming eller skriving.
Full Token-inspeksjon
Vis header, payload og signatur. Sjekk algoritme og utløp.
// OM JWT-DEKODING
JWT-struktur:
En JSON Web Token (JWT) består av tre Base64URL-kodede deler atskilt med punktum: header.payload.signatur. Headeren spesifiserer algoritmen og tokentypen. Payloaden inneholder krav (data). Signaturen verifiserer tokenets integritet.
Eksempel:
eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.signature → {"alg":"HS256"} + {"sub":"1234"}
Vanlige Bruksområder:
- >Feilsøking av autentiseringstokens i webapplikasjoner
- >Inspeksjon av OAuth 2.0 og OpenID Connect-tokens
- >Verifisering av tokenutløp og krav
- >Forståelse av JWT-struktur i henhold til RFC 7519
- >Kontroll av Base64URL-kodingsintegritet
>> ofte stilte spørsmål
S: Hva er en JSON Web Token (JWT)?
S: JWT (JSON Web Token) er en åpen standard (RFC 7519) for sikker overføring av informasjon mellom parter som et JSON-objekt. Den er kompakt, URL-sikker og brukes mye til autentisering.
S: Hva er de tre delene av en JWT?
S: En JWT består av tre deler atskilt med punktum: Header (algoritme og type), Payload (krav og data) og Signatur (verifikasjonshash). Hver del er Base64URL-kodet.
S: Kan en JWT dekodes uten den hemmelige nøkkelen?
S: Ja, headeren og payloaden i en JWT kan dekodes av hvem som helst fordi de bare er Base64URL-kodet (ikke kryptert). Den hemmelige nøkkelen er bare nødvendig for å verifisere signaturen.
S: Hva er forskjellen mellom JWT og sesjonsbasert autentisering?
S: Sesjoner lagrer tilstand på serveren med en sesjons-ID-informasjonskapsel. JWT-er er tilstandsløse — tokenet selv inneholder all nødvendig informasjon.
S: Hvordan fungerer JWT-utløp?
S: exp-kravet i JWT-payloaden spesifiserer utløpstidspunktet som et Unix-tidsstempel. Etter dette tidspunktet bør tokenet anses som ugyldig.
// Vanlige JWT-signaturalgoritmer
Verdien alg i headeren angir hvordan signaturen lages. HS* bruker en delt hemmelighet; RS*, PS*, ES* og EdDSA bruker nøkkelpar.
| alg | Algoritme |
|---|---|
| HS256 | HMAC + SHA-256 |
| HS512 | HMAC + SHA-512 |
| RS256 | RSA PKCS#1 v1.5 + SHA-256 |
| PS256 | RSASSA-PSS + SHA-256 |
| ES256 | ECDSA P-256 + SHA-256 |
| EdDSA | Ed25519 |
// Verifiser JWT i kode
Avkoding alene verifiserer ingenting. Oppgi alltid uttrykkelig tillatte algoritmer ved verifisering.
Node.js (jsonwebtoken) jwt.verify(token, secret, { algorithms: ['HS256'] })
Python (PyJWT) jwt.decode(token, key, algorithms=["HS256"])
PHP (firebase/php-jwt) JWT::decode($token, new Key($key, 'HS256'))
Go (golang-jwt) jwt.Parse(token, keyFunc, jwt.WithValidMethods([]string{"HS256"}))
Java (jjwt) Jwts.parser().verifyWith(key).build().parseSignedClaims(token)
>> Flere spørsmål
S: Hva betyr standardclaims iss, sub, aud, exp, nbf, iat og jti?
S: iss er utstederen, sub subjektet (ofte bruker-ID), aud tiltenkt mottaker, exp utløpstidspunktet, nbf starten på gyldigheten, iat utstedelsestidspunktet og jti en unik token-ID. Tidspunkter er Unix-sekunder.
S: Er en JWT kryptert?
S: En vanlig signert JWT (JWS) er ikke kryptert, bare Base64URL-kodet: alle kan lese innholdet. Signaturen beskytter bare mot manipulering. Ikke legg sensitive data i den, eller bruk en kryptert JWE.
S: Hvordan verifiserer jeg signaturen til en JWT?
S: Du trenger nøkkelen: den delte hemmeligheten for HS256 eller den offentlige nøkkelen for RS256/ES256. Serveren beregner signaturen for Header.Payload på nytt og sammenligner. Denne avkoderen kjører i nettleseren og verifiserer ikke signaturen for deg – bruk et velprøvd bibliotek.
S: Hvilke vanlige sikkerhetsfeil finnes med JWT?
S: Vanlige: å stole på alg fra selve tokenet (særlig none), svake HS256-hemmeligheter, manglende kontroll av exp, iss og aud, sensitive data i payload og langlevde tokens i localStorage.