Cele două token-uri există pentru a rezolva un conflict direct: un token de acces trebuie trimis la fiecare cerere (deci este expus mult), însă vrei totodată sesiuni care durează mult fără a forța autentificări frecvente. Nu poți avea ambele în siguranță într-un singur token — așa că împarți sarcina.
Authorization la fiecare apel API. Deoarece este transmis constant, o scurgere este probabilă; păstrarea lui scurtă înseamnă că unul furat expiră aproape imediat.Login ──▶ access (15m) + refresh (30d)
Fiecare apel API ──▶ trimite access
Access expirat ──▶ trimite refresh ──▶ access nou (+ refresh rotit)
| Un token de acces cu durată lungă | Access + refresh | |
|---|---|---|
| Expunere | Trimis la fiecare cerere, trăiește mult → fereastră mare de furt | Access cu durată scurtă; refresh trimis rar |
| Revocare | Dificilă (un JWT stateless nu poate fi anulat) | Revocă token-ul de refresh; access-ul moare în câteva minute |
| UX | Re-autentificare frecventă dacă e scurt | Rămâi autentificat fără a reintroduce credențialele |
| Raza de impact a scurgerii | Mare | Mică (access-ul expiră rapid) |
httpOnly, în afara razei de acțiune a XSS.Acesta este designul modern standard de autentificare, iar intervievatorii îl întreabă pentru a vedea dacă înțelegi de ce, nu doar cum. Ideea cheie este compromisul: lipsa stării și expunerea scurtă (access) versus sesiuni lungi și revocabilitate (refresh). Greșeala — un token de acces cu durată lungă, fără rotație, refresh stocat în localStorage — transformă un singur token scurs într-o compromitere de cont de lungă durată. A numi împărțirea și ce îți oferă fiecare token este ceea ce se așteaptă să știe un inginer conștient de securitate.
O bibliotecă de întrebări de interviu IT cu răspunsuri detaliate — de la Junior la Senior.
Donează