Dekoodaa JSON Web Token (JWT)

Mikä on JWT (JSON Web Token)?

JSON Web Token, lyhennettynä JWT (lausutaan "jot"), on RFC 7519 -standardin mukainen kompakti muoto, joka mahdollistaa väittämien (claims) siirtämisen kahden osapuolen välillä. JWT eli JWT-tokeni on nykyään hallitseva muoto todennetun identiteetin välittämiseen HTTP-rajapinnassa. JWT koostuu ASCII-merkkijonosta, jossa on kolme pisteillä erotettua osaa :

header.payload.signature

Jokainen osa on koodattu Base64URL-muodossa, joka on Base64-muunnos ilman =-täytettä ja jossa + korvataan merkillä - ja / merkillä _, jotta se voi kulkea URL-osoitteessa tai HTTP-otsikossa ilman lisämerkistömuunnoksia.

JWT-tokenin rakenne

JSON Web Token koostuu kolmesta selkeästä osasta, joista jokaisella on tietty rooli todennusmekanismissa :

1. Otsikko (Header)

Otsikko on JSON-objekti, joka kuvailee, miten token on allekirjoitettu. Se sisältää vähintään :

• alg (algoritmi) : käytetty allekirjoitusalgoritmi. Tyypillisiä arvoja : HS256, RS256, ES256, EdDSA.
• typ (tyyppi) : tokenin tyyppi, lähes aina "JWT".
• kid (avaimen ID) : valinnainen, tunnistaa mitä avainta on käytettävä allekirjoituksen vahvistamiseen. Pratique en présence d'un parc de clés en rotation (JWKS).

2. Hyötykuorma (Payload)

Hyötykuorma sisältää väittämät (claims), eli lähettäjän antamat tiedot käyttäjästä tai istunnosta. RFC 7519 määrittelee seitsemän vakioväittämää (registered claims) :

• iss (liikkeeseenlaskija) : kuka on myöntänyt tokenin, esimerkiksi "https://accounts.google.com".
• sub (kohde) : kenelle token kuuluu, käytännössä käyttäjätunnus.
• aud (vastaanottaja) : kenelle token on tarkoitettu. Estää sen, että API A:lle myönnettyä tokenia käytettäisiin API B:ssä.
• exp (vanhenemisaika) : Unix-aikaleima, jonka jälkeen token ei ole enää voimassa.
• nbf (ei ennen) : aikaleima, jota ennen token ei ole vielä aktiivinen.
• iat (myöntämisaika) : tokenin myöntämisajankohta.
• jti (JWT ID) : tokenin yksilöllinen tunniste, jota käytetään peruutuksiin ja toistohyökkäysten estämiseen.

Näiden vakioväittämien lisäksi mukaan lisätään yleensä sovelluskohtaisia mukautettuja väittämiä (roles, scope, tenant_id, email, permissions...).

3. Allekirjoitus (Signature)

Allekirjoitus on kryptografinen tiiviste, joka lasketaan muodosta base64url(header) + "." + base64url(payload) avaimen avulla. Se todistaa, ettei kukaan ole muuttanut otsikkoa tai hyötykuormaa myöntämisen jälkeen. Yleisimmät algoritmit :

• HS256 / HS384 / HS512 : symmetrinen HMAC-SHA-allekirjoitus. Lähettäjän ja tarkistajan välinen jaettu salainen avain. Yksinkertainen, mutta ei sovellu, jos kuluttajia on useita.
• RS256 / RS384 / RS512 : epäsymmetrinen RSA-allekirjoitus. Lähettäjä allekirjoittaa yksityisellä avaimellaan, kuka tahansa kuluttaja voi tarkistaa sen vastaavalla julkisella avaimella. Tosiasiallinen standardi OAuth2- ja OpenID Connect -järjestelmissä.
• ES256 / ES384 / ES512 : epäsymmetrinen ECDSA-allekirjoitus. Samat ominaisuudet kuin RS256:ssa, mutta huomattavasti lyhyemmät avaimet ja allekirjoitukset.
• EdDSA (Ed25519) : nykyaikainen, nopea ja kompakti epäsymmetrinen allekirjoitus.

Vielä kerran : allekirjoitus suojaa eheyttä, ei luottamuksellisuutta. Hyötykuorma on edelleen kenen tahansa tokenin haltijan luettavissa.

Miksi dekoodata JWT?

Toiminto JWT-tokenin dekoodaus vastaa useisiin kehittäjän tai tietoturvainsinöörin käytännön tarpeisiin :

• API-todennuksen debuggaus : rajapintasi palauttaa 401- tai 403-virheen, ja haluat nähdä, mitä hyötykuormassa todella on (sub, scope, roles, exp) arvailun sijaan.
• Väittämien tarkistaminen : varmistaa, että token sisältää odotetun väittämän (esimerkiksi tenant_id tai permissions) ennen kuin etsit muualta valtuutusketjusta.
• Vanhenemisajan lukeminen : muuntaa exp-aikaleima ihmisen luettavaan muotoon varmistaaksesi, että token on todella vanhentunut, tai päinvastoin, että sen pitäisi edelleen olla voimassa.
• Tietoturva-auditointi : varmistaa, ettei kolmannen osapuolen palvelu vuoda arkaluonteisia tietoja hyötykuormassa (sähköpostit, sisäiset tunnisteet, henkilötiedot).
• Koulutus ja ymmärrys : nähdä käytännössä, miltä OAuth-palveluntarjoajalta (Google, Auth0, Keycloak, AWS Cognito) tuleva JSON Web Token näyttää ymmärtääksesi mekanismin ilman dokumentaatioon syventymistä.
• Julkisten tokeneiden tarkastelu : tarkastella lokeista, evästeistä tai kaapatusta OAuth-liikenteestä löytynyttä JWT-tokenia.

Dekooderi vs. vahvistaja : kriittinen ero

Nämä kaksi toimintoa vaikuttavat läheisiltä, mutta ne ovat täysin erilaisia tietoturvatakuun kannalta :

• JWT-tokenin dekoodaus tarkoittaa merkkijonon jakamista .-merkkien kohdalta ja käänteisen Base64URL-muunnoksen soveltamista kahteen ensimmäiseen osaan. Se on pelkkää lukemista, johon pystyy mikä tahansa kolmen rivin skripti. Allekirjoituksen vahvistusta ei tehdä.
• JWT-tokenin vahvistaminen tarkoittaa allekirjoituksen laskemista uudelleen otsikon, hyötykuorman ja avaimen perusteella, ja tuloksen vertaamista tokenissa olevaan allekirjoitukseen. Tämä takaa, ettei tokenia ole väärennetty.

Käytännön johtopäätös : dekoodaus ei tarkoita luottamusta. Ennen kuin allekirjoitus on vahvistettu oikealla avaimella, hyötykuorman sisältö voi olla täysin keksittyä. Luottamuksen varmistamiseksi käytä JWT-vahvistajaamme.

Miten sitä käytetään

1. Hanki tarkistettava JWT, esimerkiksi Authorization: Bearer <jwt> -otsikosta, istuntoevästeestä, selaimen localStorage-muistista tai sovelluslokista.
2. Liitä koko merkkijono syöttökenttään. Kolmen osan on pysyttävä pisteillä erotettuina.
3. Työkalu näyttää välittömästi dekoodatun otsikon muotoiltuna JSON-muotona, sisältäen algoritmin ja tyypin.
4. Sen jälkeen hyötykuorma dekoodataan ja näytetään. Näet siinä kaikki vakio- ja mukautetut väittämät.
5. Työkalu ilmoittaa myös allekirjoitustiedot (ilmoitettu algoritmi, pituus) niitä kuitenkaan vahvistamatta.
6. Varmistaaksesi, ettei tokenia ole väärennetty, siirry JWT-vahvistajaamme ja käytä odotettua julkista avainta tai salaisuutta.

Kaikki dekoodaus tapahtuu selaimessasi JavaScriptillä : tokeniasi ei koskaan lähetetä palvelimillemme.

JWT ja tietoturva : vältettävät sudenkuopat

Muutamia kultaisia sääntöjä JWT:n käyttöön tuotannossa :

• Vahvista allekirjoitus aina palvelinpuolella ennen kuin myönnät mitään oikeuksia. JWT-vahvistajamme havainnollistaa juuri tätä toimintoa.
• Käytä mieluummin RS256- tai ES256-algoritmia HS256:n sijaan julkisissa rajapinnoissa. Epäsymmetrinen allekirjoitus välttää salaisuuden jakamisen lähettäjän ja jokaisen kuluttajan välillä.
• Noudata aina väittämää exp. JWT ilman vanhenemisaikaa tai liian pitkällä vanhenemisajalla on aikapommi vuodon sattuessa.
• Vahvista iss ja aud palvelinpuolella välttääksesi sen, että toiselle palvelulle myönnetty laillinen token hyväksyttäisiin vahingossa.
• Hylkää alg: "none" tarkistusvaiheessa. Tämä on klassinen haavoittuvuus, jonka avulla hyökkääjä voi väärentää minkä tahansa hyötykuorman.
• Pidä elinkaaret lyhyinä (esimerkiksi 15 minuuttia) ja käytä niitä yhdessä pidemmän, mutta palvelinpuolella peruutettavissa olevan päivitystokenin (refresh token) kanssa.

Esimerkki dekoodatusta JWT-tokenista

Tässä on tyypillinen JWT :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjMiLCJuYW1lIjoiSm9obiIsImlhdCI6MTUxNjIzOTAyMn0.jrU9j8LZcRK2_BZjqXjU7lEpJbkqmXfTQIu9vT45j-I

Dekoodattuna sen sisältö on seuraava :

// Otsikko
{
  "alg": "HS256",
  "typ": "JWT"
}

// Hyötykuorma
{
  "sub": "123",
  "name": "John",
  "iat": 1516239022
}

// Allekirjoitus (binäärinen, koodattu Base64URL-muodossa)
HMACSHA256(
  base64url(header) + "." + base64url(payload),
  secret
)

Mistä löytää kopioitava JWT?

Käytännössä dekoodattava JWT on yleensä peräisin jostakin näistä paikoista :

• HTTP-eväste : avaa kehitystyökalut (F12), välilehti Application tai Storage, ja sieltä Cookies. Etsi eväste, jonka nimi on access_token, jwt, session tai vastaava.
• localStorage / sessionStorage : sama paneeli, osio Local Storage. Monet SPA-sovellukset tallentavat tokeninsa tänne avaimella token tai auth.
• Authorization-otsikko : välilehti Network, valitse rajapintapyyntö, lue otsikko Authorization: Bearer <jwt>. Kopioi vain osa, joka tulee sanan Bearer jälkeen.
• Palvelinloki : JWT saattaa joskus näkyä yhdyskäytävän tai käänteisen välityspalvelimen lokeissa (vältettävä tuotannossa, mutta hyödyllinen debugauksessa).

Usein kysytyt kysymykset

Pyyntöesimerkki

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

Syöteskeema

Päätepisteet

• GET https://cdrn.fr/api/v1/tools - listaa kaikki saatavilla olevat työkalut
• GET https://cdrn.fr/api/v1/tools/jwt-decoder - hakee tämän työkalun skeeman
• POST https://cdrn.fr/api/v1/tools/jwt-decoder/execute - suorittaa tämän työkalun JSON-payloadilla