Kun kirjaudut moderniin Single Page -sovellukseen (kuten React tai Vue) tai mobiilisovellukseen, palvelin tarvitsee tavan muistaa kuka olet. Perinteisesti se teki tämän tallentamalla "istuntotunnuksen" valtavaan tietokantaan palvelimella ja pudottamalla evästeen selaimeesi. Joka kerta kun napsautit painiketta, palvelimen piti etsiä kyseinen tunnus tietokannastaan. Tätä kutsutaan tilapitoiseksi todentamiseksi.
Kuitenkin mikropalvelujen ja pilviskaalauksen aikakaudella tietokannoista tuli pullonkaula. Tämän ratkaisemiseksi kehittäjät ottivat käyttöön valtiottoman todennuksen JSON Web Tokensin (JWT) kautta. JWT:ssä palvelimen ei tarvitse muistaa kuka olet – selaimesi kertoo palvelimelle tarkalleen, kuka olet, ja käyttää salausta sen todistamiseen.
JWT:n anatomia
Jos tarkastelet verkkoliikennettä kirjautumisen jälkeen nykyaikaiseen sovellukseen, näet todennäköisesti "Authorization: Bearer" -otsikon, jota seuraa pitkä, satunnaisen näköinen merkkijono kahdella pisteellä erotettuna. Se on JWT.
JWT koostuu tarkalleen kolmesta osasta: Header.Payload.Signature.
1. Otsikko
Ensimmäinen osa on Base64URL-koodattu JSON-objekti, joka yksinkertaisesti kuvaa tunnuksen. Se sisältää yleensä kaksi ominaisuutta: tunnuksen tyypin (JWT) ja käytetyn allekirjoitusalgoritmin (kuten HMAC SHA256 tai RSA).
2. Hyötykuorma (vaatimukset)
Keskiosa on myös Base64URL-koodattu JSON-objekti. Täällä todellinen data elää. Näitä tietoja kutsutaan "vaatimuksiksi". Se voi esimerkiksi sisältää käyttäjätunnuksesi, roolisi (esim. "Järjestelmänvalvoja") ja vanhenemisaikaleiman. Koska tämä hyötykuorma on liitetty jokaiseen pyyntöön, palvelin tietää välittömästi kuka olet ilman kyselyä tietokannasta.
KRIITTINEN VAROITUS: Hyötykuorma on vain koodattu, ei salattu. Jokainen, joka sieppaa JWT:n, voi helposti purkaa sen ja lukea hyötykuorman. Älä koskaan säilytä salasanoja, sosiaaliturvatunnuksia tai arkaluonteisia tietoja JWT-hyötykuorman sisällä.
3. Allekirjoitus
Jos kuka tahansa voi lukea ja muokata hyötykuormaa, mikä estää pahantahtoista käyttäjää vaihtamasta rooliaan "Käyttäjästä" "Järjestelmänvalvojaksi"? Vastaus on allekirjoitus.
Allekirjoituksen luomiseksi palvelin ottaa otsikon, hyötykuorman ja erittäin turvallisen Salaisen avaimen (joka tietää vain palvelin) ja suorittaa ne salausalgoritmin (kuten SHA256) kautta. Tuloksena olevasta hashista tulee allekirjoitus.
Kun palvelin vastaanottaa tunnuksen takaisin asiakkaalta, se laskee allekirjoituksen uudelleen käyttämällä salaista avainta. Jos käyttäjä peukaloi hyötykuormaa (jopa vaihtaisi yhtä kirjainta), uudelleen laskettu allekirjoitus ei vastaa tunnuksessa olevaa allekirjoitusta ja palvelin hylkää pyynnön välittömästi vilpillisenä.
Tarkasta Tokenit turvallisesti
Haluatko lukea JWT:n hyötykuorman sovelluksesi virheenkorjausta varten? Käytä offline-tilassa olevaa JWT-dekooderiamme tarkastaaksesi väitteet välittömästi lähettämättä arkaluonteista tokeniasi etäpalvelimelle.
Avaa JWT-dekooderiMiksi mikropalvelut rakastavat JWT:itä
Kuvittele Netflixin kaltainen yritys. Heillä on todennuspalvelin, videon suoratoistopalvelin ja laskutuspalvelin. Jos he käyttäisivät perinteisiä istuntoja, jokaisen yksittäisen palvelimen olisi jatkuvasti kommunikoitava keskustietokannan kanssa tarkistaakseen, onko käyttäjä kirjautunut sisään.
JWT:illä todennuspalvelin allekirjoittaa tunnuksen yksityisellä avaimella. Tämän jälkeen käyttäjä välittää tunnuksen suoraan videopalvelimelle. Koska videopalvelimella on julkinen avain, se voi tarkistaa allekirjoituksen itsenäisesti. Videopalvelin tietää tarkalleen kuka käyttäjä on puhumatta koskaan todennuspalvelimelle tai tietokantaan. Tämä mahdollistaa infrastruktuurin skaalaamisen äärettömästi ilman pullonkauloja.
Pimeä puoli: Tokenin mitätöinti
JWT:t eivät ole täydellisiä. Heidän suurin vahvuutensa (valtiottomuus) on myös heidän suurin heikkoutensa. Koska palvelin ei pidä kirjaa aktiivisista tunnuksista, et voi helposti kirjata käyttäjää ulos tai mitätöidä tiettyä tunnusta ennen kuin se vanhenee.
Jos hakkeri varastaa käyttäjän JWT:n, hakkerilla on täysi käyttöoikeus, kunnes tunnuksen vanhenemisaikaleima loppuu. Tämän riskin pienentämiseksi tietoturvainsinöörit käyttävät kahden merkin järjestelmää:
- Pääsytunnukset: lyhytikäiset JWT:t (esim. 15 minuuttia), joita käytetään API-pyyntöihin.
- Päivitä tunnukset: Pitkäikäiset, tilalliset tunnukset, jotka on tallennettu turvallisesti ja joita käytetään tiukasti uusien käyttöoikeuksien pyytämiseen. Jos tili vaarantuu, palvelin peruuttaa Refresh Tokenin ja hakkerin Access Token luonnollisesti kuolee 15 minuutissa.
Usein kysytyt kysymykset (FAQ)
Missä minun pitäisi säilyttää JWT käyttöliittymässä?
JWT:iden tallentaminen localStorageen tekee niistä alttiita Cross-Site Scripting (XSS) -hyökkäyksille. Turvallisin paikka JWT:n tallentamiseen verkkoselaimeen on HttpOnly-eväste, joka estää JavaScriptiä pääsemästä siihen.
Mitä tapahtuu, jos palvelimeni salainen avain vuotaa?
Katastrofi. Jos hakkeri saa HMAC-salaisen avaimesi tai yksityisen RSA-avaimesi, hän voi luoda kelvollisia JWT:itä millä tahansa hyötykuormalla. He voivat luoda tunnuksia antaen itselleen "Super Admin" -oikeudet ja palvelimesi hyväksyisi ne kelvollisiksi. Avaimet on käännettävä välittömästi.
Ovatko JWT:t nopeampia kuin istuntoevästeet?
Ei välttämättä. JWT:t ovat tiedostokooltaan huomattavasti suurempia kuin 32-merkkinen istuntotunnus, mikä tarkoittaa, että ne kuluttavat enemmän verkon kaistanleveyttä jokaisella pyynnöstä. Niiden nopeusetu tulee kokonaan tietokantahakujen ohittamisesta taustajärjestelmässä.