Kas iš tiesų yra JWT ir kodėl vis dar apie jį kalbame
JSON Web Token, arba tiesiog JWT – tai ne naujiena. Šis autentifikacijos mechanizmas IT pasaulyje gyvuoja jau gerą dešimtmetį, tačiau 2026-aisiais vis dar kelia diskusijų. Ir ne be reikalo. Kol vieni kūrėjai JWT laiko patogiu ir elegantiškiu sprendimu, kiti įžvelgia jame saugumo spragų šaltinį.
Esmė paprasta: JWT – tai kompaktiškas, URL-saugus būdas perduoti informaciją tarp šalių kaip JSON objektą. Tokenas susideda iš trijų dalių, atskirtų taškais: antraštės (header), naudingosios apkrovos (payload) ir parašo (signature). Būtent tas parašas ir turėtų garantuoti, kad niekas pakeliui nepasikeistė duomenų. Teoriškai.
Praktikoje matome, kad daugelis programuotojų JWT naudoja kaip „nustatyk ir pamiršk” sprendimą. Sukuriamas tokenas, įdedamas į localStorage, ir viskas – autentifikacija veikia. Bet čia ir prasideda problemos. 2026 metais, kai kibernetiniai išpuoliai tampa vis sudėtingesni, toks požiūris yra tiesiog nepateisinamas.
Kodėl JWT saugumas nėra automatinis
Viena didžiausių klaidų, kurią matau projektuose – prielaida, kad JWT pats savaime yra saugus. Tai tarsi sakyti, kad automobilis su oro pagalvėmis automatiškai apsaugo nuo avarijų. Oro pagalvės padeda, bet vairuoti vis tiek reikia mokėti.
JWT saugumas priklauso nuo daugelio faktorių: kaip jis saugomas kliento pusėje, kaip ilgai galioja, kokiu algoritmu pasirašytas, ar naudojamas refresh token mechanizmas. Ir štai čia prasideda tikrasis darbas.
Viena iš populiariausių pažeidžiamumų – algoritmo manipuliavimas. Klasikinis pavyzdys: serveris tikisi RS256 algoritmo (asimetrinis), bet užpuolikas pakeičia antraštę į HS256 (simetrinis) ir naudoja viešąjį raktą kaip slaptą. Jei serveris netinkamai validuoja algoritmą – bum, saugumo skylė. 2026-aisiais vis dar randame tokių pažeidžiamumų gamybinėse sistemose.
Kitas skaudus taškas – jokio tokeno atšaukimo mechanizmo. JWT yra stateless pagal dizainą, o tai reiškia, kad serveris nepalaiko sesijos būsenos. Puiku našumui, bet kas nutinka, kai reikia nedelsiant atšaukti vartotojo prieigą? Pavyzdžiui, darbuotojas atleidžiamas, bet jo JWT dar galioja 24 valandas. Ne idealus scenarijus.
Kur saugoti JWT 2026 metais
Šis klausimas vis dar kelia aršiausias diskusijas Stack Overflow ir Reddit forumuose. Ir atsakymas, kaip dažnai būna, yra: „tai priklauso”.
LocalStorage – patogus, bet pažeidžiamas XSS (Cross-Site Scripting) atakų. Jei užpuolikas įterpia kenkėjišką JavaScript kodą į jūsų puslapį, jis gali lengvai pasiekti localStorage turinį. 2026-aisiais XSS vis dar yra viena iš TOP 10 OWASP pažeidžiamumų.
SessionStorage – šiek tiek saugesnis už localStorage, nes duomenys išvalomi uždarius naršyklės langą, bet vis tiek pažeidžiamas tų pačių XSS atakų.
Cookies su HttpOnly ir Secure flag’ais – šiuo metu laikomas saugiausiu variantu. HttpOnly užtikrina, kad JavaScript negali pasiekti cookie, o Secure garantuoja perdavimą tik per HTTPS. Pridėkite SameSite atributą, ir turite gana tvirtą apsaugą nuo CSRF (Cross-Site Request Forgery) atakų.
Bet ir čia yra niuansų. 2026-aisiais matome vis daugiau organizacijų naudojančių hibridinį požiūrį: trumpalaikis access token (5-15 minučių) saugomas atmintyje (memory), o ilgalaikis refresh token – HttpOnly cookie. Taip, sudėtingiau implementuoti, bet saugumo lygis kyla eksponentiškai.
Refresh token strategija: būtinybė, ne prabanga
Jei 2026-aisiais vis dar naudojate ilgalaikius JWT be refresh token mechanizmo – rimtai, sustokite ir permąstykite savo pasirinkimus.
Refresh token strategija veikia taip: vartotojui prisijungus, serveris išduoda du tokenus. Access token – trumpalaikis (pvz., 15 minučių), naudojamas API užklausoms. Refresh token – ilgalaikis (pvz., 7 dienos), naudojamas gauti naują access token, kai senasis baigiasi.
Kodėl tai svarbu? Jei access token nutekintas, užpuolikas turi tik 15 minučių langą jį panaudoti. Refresh token, saugomas HttpOnly cookie ir naudojamas tik specifiniame endpoint’e, yra daug sunkiau pasisavinti.
Bet čia svarbu ir refresh token rotation. Kiekvieną kartą naudojant refresh token naujam access token gauti, serveris turėtų išduoti ir naują refresh token, o seną – invaliduoti. Taip užtikrinama, kad net jei refresh token nutekintas, jo pakartotinis naudojimas bus aptiktas.
Implementuojant tai, reikia duomenų bazės arba Redis cache, kur saugomi aktyvūs refresh tokenai. Taip, tai prideda state’o, bet saugumas to verta. Galite naudoti tokią struktūrą:
{
"tokenId": "unique-token-id",
"userId": "user-123",
"issuedAt": "2026-01-15T10:30:00Z",
"expiresAt": "2026-01-22T10:30:00Z",
"deviceInfo": "Chrome on Windows",
"ipAddress": "192.168.1.1"
}
Taip galite ne tik atšaukti tokenus, bet ir stebėti įtartiną veiklą – pavyzdžiui, jei tas pats refresh token naudojamas iš skirtingų IP adresų.
Algoritmai ir raktų valdymas
2026-aisiais turėtumėte naudoti tik RS256 arba ES256 algoritmus gamybinėse sistemose. HS256 (HMAC su SHA-256) yra simetrinis algoritmas, reiškiantis, kad tas pats raktas naudojamas ir pasirašymui, ir verifikavimui. Tai sukuria riziką, nes kiekvienas servisas, galintis verifikuoti tokeną, gali ir sukurti naują.
RS256 (RSA su SHA-256) naudoja asimetrinę kriptografiją: privatus raktas pasirašymui, viešas – verifikavimui. Tai reiškia, kad mikroservisai gali verifikuoti tokenus neturėdami galimybės jų sukurti. ES256 (ECDSA su P-256 ir SHA-256) panašus, bet naudoja elipsines kreives – efektyvesnis ir saugesnis.
Raktų valdymas – tai atskira tema. Privatus raktas niekada neturėtų būti hardcode’intas kode ar saugomas Git repository. Naudokite aplinkos kintamuosius arba, dar geriau, specializuotas raktų valdymo sistemas kaip AWS KMS, Azure Key Vault ar HashiCorp Vault.
Be to, implementuokite raktų rotaciją. Kas 3-6 mėnesius keiskite pasirašymo raktus. Tai reiškia, kad JWT antraštėje turėtumėte naudoti „kid” (key ID) lauką, nurodantį, kuris raktas buvo naudotas. Serveris gali palaikyti kelis viešuosius raktus verifikavimui, bet naudoti tik naujausią pasirašymui.
Claims validavimas ir saugumo best practices
JWT payload gali turėti bet kokius duomenis, bet yra standartiniai claims, kuriuos privalote validuoti:
- exp (expiration time) – tokeno galiojimo pabaiga. Visada tikrinkite ir niekada nenaudokite tokenų be exp claim.
- iat (issued at) – išdavimo laikas. Naudinga aptikti laikrodžio sinchronizacijos problemas.
- nbf (not before) – laikas, nuo kurio tokenas galioja. Naudinga atidėtiems tokenams.
- iss (issuer) – tokeno išdavėjas. Validuokite, kad atitinka jūsų serverį.
- aud (audience) – kam skirtas tokenas. Užtikrina, kad tokenas naudojamas tinkamam servisui.
2026-aisiais matau per daug projektų, kur validuojamas tik exp. Tai nepakanka. Pilnas validavimas turėtų atrodyti taip:
// Pseudokodas
function validateToken(token) {
const decoded = verifySignature(token);
if (decoded.exp < currentTime()) {
throw new Error('Token expired');
}
if (decoded.iss !== 'https://your-domain.com') {
throw new Error('Invalid issuer');
}
if (!decoded.aud.includes('your-api')) {
throw new Error('Invalid audience');
}
if (decoded.nbf && decoded.nbf > currentTime()) {
throw new Error('Token not yet valid');
}
return decoded;
}
Dar vienas svarbus aspektas – jautrios informacijos nedėjimas į payload. JWT payload nėra šifruojamas, tik pasirašomas. Tai reiškia, kad bet kas gali dekoduoti ir perskaityti turinį. Nedėkite slaptažodžių, kreditinių kortelių numerių ar kitų jautrių duomenų. Dėkite tik tai, kas būtina autorizacijai – vartotojo ID, roles, permissions.
Monitoring ir anomalijų aptikimas
Saugumas nėra vienkartinis veiksmas – tai procesas. 2026-aisiais turėtumėte turėti sistemą, stebinčią JWT naudojimą ir aptinkančią įtartiną veiklą.
Ką stebėti:
- Nepavykusios autentifikacijos bandymai – daug bandymų iš vieno IP gali reikšti brute force ataką.
- Token reuse patterns – jei tas pats refresh token naudojamas iš skirtingų vietų, tai raudonas signalas.
- Neįprastas geografinis aktyvumas – vartotojas prisijungė iš Lietuvos, o po 5 minučių iš Kinijos? Įtartina.
- Expired token usage attempts – daug bandymų naudoti nebegaliojančius tokenus gali reikšti replay ataką.
- Algoritmo nesutapimai – bandymai naudoti netikėtus algoritmus.
Implementuokite rate limiting ne tik API endpoint’uose, bet ir autentifikacijos procesuose. Jei vartotojas bando atnaujinti access token 100 kartų per minutę – kažkas ne taip.
Naudokite logging ir SIEM (Security Information and Event Management) sistemas. Elasticsearch, Splunk ar panašios platformos gali padėti identifikuoti šablonus, kuriuos žmogus praleistų.
Praktiniai patarimai realiam pasauliui
Teorija teorija, bet kaip tai pritaikyti realiame projekte? Štai keletas konkrečių rekomendacijų, kurias galite implementuoti šiandien:
1. Naudokite patikrinta biblioteka
Nerašykite JWT implementacijos patys. Naudokite gerai žinomas ir auditintas bibliotekas: jsonwebtoken (Node.js), PyJWT (Python), jose (JavaScript), java-jwt (Java). Jos jau turi įtaisytas apsaugas nuo žinomų pažeidžiamumų.
2. Trumpinkite token galiojimo laiką
Access token – maksimum 15-30 minučių. Taip, tai reiškia dažnesnį refresh, bet saugumo požiūriu verta. Refresh token – ne ilgiau nei 7-14 dienų. Jei reikia „remember me” funkcionaliteto, implementuokite atskirą mechanizmą.
3. Implementuokite token blacklist
Nors JWT yra stateless, kritiniais atvejais (vartotojo atjungimas, saugumo incidentas) turite galėti nedelsiant invaliduoti tokenus. Redis puikiai tinka blacklist’ui – saugokite invaliduotų tokenų JTI (JWT ID) su TTL, atitinkančiu ilgiausią galimą token galiojimo laiką.
4. HTTPS visur
2026-aisiais tai turėtų būti savaime suprantama, bet vis dar matau projektų su HTTP. JWT be HTTPS yra kaip durų spyna be durų. Naudokite TLS 1.3, išjunkite senesnes versijas.
5. Implementuokite CORS teisingai
Jei jūsų API naudoja JWT, CORS konfigūracija kritiškai svarbi. Nenaudokite wildcard (*) Access-Control-Allow-Origin. Nurodykite konkrečius dominus. Naudokite Access-Control-Allow-Credentials: true tik kai būtina.
6. Testuokite saugumo pažeidžiamumus
Reguliariai vykdykite penetration testing. Naudokite įrankius kaip OWASP ZAP, Burp Suite. Testuokite specifines JWT pažeidžiamumus: algoritmo manipuliavimą, none algoritmo atakas, weak secrets.
Kas toliau: JWT ateitis ir alternatyvos
Žvelgiant į ateitį, JWT niekur nedingsta, bet matome evoliuciją. Pasaka (Platform Agnostic Security Tokens) ir GNAP (Grant Negotiation and Authorization Protocol) bando spręsti kai kurias JWT problemas, bet adopcija lėta.
Viena įdomesnių tendencijų 2026-aisiais – session-based autentifikacija grįžimas. Taip, skamba kaip žingsnis atgal, bet su moderniomis technologijomis (Redis, distributed caching) sesijų valdymas nebėra toks skausmingas. Kai kurios organizacijos renkasi hibridinį modelį: sesijos kritinėms operacijoms, JWT – mažiau jautriems API endpoint’ams.
Kita tendencija – OAuth 2.1 ir OpenID Connect standarizacija. Vietoj custom JWT implementacijų, vis daugiau projektų naudoja pilnus autentifikacijos sprendimus kaip Auth0, Keycloak, AWS Cognito. Tai sumažina riziką daryti klaidas implementuojant saugumą patiems.
Zero Trust architektūra taip pat keičia požiūrį į JWT. Vietoj ilgalaikių tokenų, matome short-lived credentials, nuolatinę re-autentifikaciją kritinėms operacijoms, context-aware autorizaciją (įskaitant device fingerprinting, behavioral analysis).
Dar viena įdomi sritis – passwordless autentifikacija. WebAuthn ir FIDO2 standartai leidžia naudoti biometriją ar hardware tokens vietoj slaptažodžių. JWT vis dar naudojamas, bet autentifikacijos procesas tampa saugesnis.
Galiausiai, kvantinė kriptografija jau beldžiasi į duris. Nors pilnai funkcionuojantys kvantiniai kompiuteriai dar toli, post-quantum kriptografiniai algoritmai jau standartizuojami. NIST jau paskelbė pirmuosius PQC (Post-Quantum Cryptography) standartus. JWT bibliotekos turės adaptuotis, ir tai turėtų įvykti artimiausiais metais.
Taigi, ar JWT saugus 2026-aisiais? Atsakymas: taip, jei žinote, ką darote. JWT pats savaime nėra nei saugus, nei nesaugus – viskas priklauso nuo implementacijos. Trumpalaikiai tokenai, tinkamas saugojimas, refresh token strategija, algoritmo validavimas, raktų rotacija, monitoring – visa tai kartu sukuria tvirtą saugumo lygį. Bet jei ignoruojate šiuos principus ir tiesiog copy-paste’inate kodą iš Stack Overflow – tuomet taip, JWT gali tapti saugumo problema. Pasirinkimas jūsų.
