Când vă conectați la o aplicație modernă cu o singură pagină (cum ar fi React sau Vue) sau la o aplicație mobilă, serverul are nevoie de o modalitate de a-și aminti cine sunteți. În mod tradițional, a făcut acest lucru prin stocarea unui „ID de sesiune” într-o bază de date masivă pe server și eliminând un cookie în browser. De fiecare dată când făceai clic pe un buton, serverul trebuia să caute acel ID în baza de date. Aceasta se numește autentificare cu stare.
Cu toate acestea, în era microserviciilor și scalarii în cloud, bazele de date au devenit un blocaj. Pentru a rezolva acest lucru, dezvoltatorii au adoptat Stateless Authentication prin intermediul JSON Web Tokens (JWT). Cu JWT, serverul nu trebuie să-și amintească cine ești — browser-ul tău spune serverului exact cine ești și folosește criptografie pentru a dovedi acest lucru.
Anatomia unui JWT
Dacă inspectați traficul de rețea după ce vă conectați la o aplicație modernă, veți vedea probabil un antet „Authorization: Bearer” urmat de un șir lung de caractere, cu aspect aleator, separate de două puncte. Acesta este un JWT.
Un JWT este format din exact trei părți: Header.Payload.Signature.
1. Antetul
Prima parte este un obiect JSON codificat Base64URL care descrie pur și simplu simbolul. De obicei, conține două proprietăți: tipul de token (JWT) și algoritmul de semnare utilizat (cum ar fi HMAC SHA256 sau RSA).
2. Sarcina utilă (revendicări)
Partea din mijloc este, de asemenea, un obiect JSON codificat Base64URL. Aici locuiesc datele reale. Aceste date se numesc „revenții”. De exemplu, ar putea conține ID-ul dvs. de utilizator, rolul dvs. (de exemplu, „Administrator”) și un marcaj de expirare. Deoarece această sarcină utilă este atașată la fiecare cerere, serverul știe instantaneu cine ești, fără a interoga o bază de date.
AVERTISMENT CRITIC: sarcina utilă este doar codificată, nu criptată. Oricine interceptează un JWT îl poate decoda cu ușurință și poate citi sarcina utilă. Nu stocați niciodată parole, numere de securitate socială sau date sensibile într-o încărcare utilă JWT.
3. Semnătura
Dacă cineva poate citi și edita sarcina utilă, ce oprește un utilizator rău intenționat să își schimbe rolul din „Utilizator” în „Administrator”? Răspunsul este Semnătura.
Pentru a crea semnătura, serverul preia antetul, sarcina utilă și o cheie secretă foarte sigură (cunoscută doar de server) și le rulează printr-un algoritm criptografic (cum ar fi SHA256). Hashul rezultat devine Semnătura.
Când serverul primește un token înapoi de la client, recalculează semnătura folosind cheia secretă. Dacă utilizatorul a modificat încărcătura utilă (chiar schimbând o singură literă), semnătura recalculată nu se va potrivi cu semnătura de pe token, iar serverul va respinge instantaneu cererea ca fiind frauduloasă.
Inspectați jetoanele în siguranță
Trebuie să citiți sarcina utilă a unui JWT pentru a vă depana aplicația? Utilizați decodorul nostru JWT offline pentru a inspecta revendicările instantaneu, fără a trimite simbolul dvs. sensibil la un server la distanță.
Deschideți JWT DecoderDe ce microservicii iubesc JWT-urile
Imaginați-vă o companie ca Netflix. Au un server de autentificare, un server de streaming video și un server de facturare. Dacă ar folosi sesiuni tradiționale, fiecare server ar trebui să comunice constant cu o bază de date centrală pentru a verifica dacă un utilizator este conectat.
Cu JWT, serverul de autentificare semnează jetonul folosind o cheie privată. Apoi utilizatorul transmite acel token direct la serverul video. Deoarece serverul video are cheia publică, poate verifica independent semnătura. Serverul video știe exact cine este utilizatorul fără să vorbească vreodată cu serverul de autentificare sau cu o bază de date. Acest lucru permite infrastructurii să se extindă la infinit, fără blocaje.
Partea întunecată: Invalidarea simbolului
JWT-urile nu sunt perfecte. Cea mai mare putere a lor (a fi apatrid) este și cea mai mare slăbiciune a lor. Deoarece serverul nu păstrează o evidență a indicatoarelor active, nu puteți să vă deconectați cu ușurință un utilizator sau să invalidați un anumit simbol înainte de a expira.
Dacă un hacker fură JWT-ul unui utilizator, hackerul are acces deplin până la expirarea timpului de expirare a simbolului. Pentru a atenua acest risc, inginerii de securitate folosesc un sistem cu două simboluri:
- Jetoane de acces: JWT de scurtă durată (de exemplu, 15 minute) utilizate pentru solicitările API.
- Jetoane de reîmprospătare: jetoane cu durată lungă de viață, cu stare, stocate în siguranță, folosite strict pentru a solicita noi jetoane de acces. Dacă un cont este compromis, serverul revocă Jetonul de actualizare, iar Tokenul de acces al hackerului va muri în mod natural în 15 minute.
Întrebări frecvente (FAQ)
Unde ar trebui să stochez un JWT pe front-end?
Stocarea JWT-urilor în localStorage le face vulnerabile la atacurile Cross-Site Scripting (XSS). Cel mai sigur loc pentru a stoca un JWT într-un browser web este în interiorul unui cookie HttpOnly, care împiedică JavaScript să-l acceseze.
Ce se întâmplă dacă cheia secretă a serverului meu este scursă?
Catastrofă. Dacă un hacker obține cheia dvs. secretă HMAC sau cheia privată RSA, poate genera JWT-uri valide cu orice sarcină utilă pe care o dorește. Ei ar putea crea token-uri oferindu-și privilegii de „Super Admin”, iar serverul tău le-ar accepta ca fiind valide. Trebuie să rotiți cheile imediat.
Sunt JWT-urile mai rapide decât cookie-urile de sesiune?
Nu neapărat. JWT-urile sunt semnificativ mai mari ca dimensiune a fișierului decât un ID de sesiune de 32 de caractere, ceea ce înseamnă că consumă mai multă lățime de bandă de rețea la fiecare solicitare. Avantajul lor de viteză provine în totalitate din ocolirea căutărilor de baze de date pe backend.