Pentru o aplicație web obișnuită, începeți cu sesiuni pe server

Un angajat pleacă din firmă, iar administratorul îi retrage accesul la aplicație. Mesajul de confirmare contează mai puțin decât ce se întâmplă cu o cerere trimisă după aceea folosind vechile date de acces. Acolo se vede dacă aplicația respectă decizia administratorului.

Pentru o aplicație în browser cu un singur server de aplicație, recomandarea este să porniți de la o sesiune păstrată pe server. Browserul primește într-un cookie HttpOnly un identificator aleatoriu, greu de ghicit. JWT merită luat în calcul când un alt serviciu trebuie să verifice independent o informație despre identitate. Echipa trebuie să poată explica și cât timp acceptă informațiile care nu mai sunt actuale.

Privită din noiembrie 2026, discuția reluată în mai 2024 oferă încă un bun punct de plecare pentru evaluarea unei aplicații. Henryk Plötz a publicat pe 26 mai 2024 un articol împotriva folosirii JWT la autentificarea obișnuită. Observația sa utilă privește datele de sesiune pe care sistemul trebuie totuși să le păstreze. Recomandarea de aici este mai restrânsă: și un sistem mic poate avea nevoie de verificare independentă. Mărimea companiei nu decide singură arhitectura.

Unde se păstrează decizia de acces

Cookie și JWT denumesc lucruri diferite. Cookie este un mecanism al browserului pentru păstrarea și transmiterea datelor. JWT este un format pentru informații declarate despre un subiect, de exemplu despre un utilizator. Un JWT poate fi transmis într-un cookie. La rândul său, un identificator de sesiune poate fi transmis și prin alte mijloace.

În varianta recomandată, cookie-ul conține un identificator fără informații despre utilizator, iar serverul caută înregistrarea sesiunii. Într-un sistem care verifică local un JWT semnat, serviciul verifică semnătura și aplică regulile de acceptare. RFC 7519, publicat în mai 2015, definește formatul JWT și câmpuri precum subiectul, destinatarul și expirarea. Semnătura nu ascunde automat conținutul; criptarea este o alegere separată.

Întrebarea de proiectare este ce trebuie să afle serviciul înainte de următoarea cerere. Dacă oricum citește din baza de date permisiunile actuale ale utilizatorului, verificarea independentă a unui JWT s-ar putea să elimine mai puțină muncă decât sugerează schema sistemului. Aceasta este o observație despre arhitectură, nu rezultatul unui test de performanță.

Ce înseamnă că utilizatorul a fost deconectat

Ștergerea unui JWT din browser nu anulează o copie ajunsă în altă parte. Dacă serviciul verifică doar semnătura și expirarea, copia poate rămâne valabilă până la sfârșitul perioadei acceptate. O durată scurtă limitează intervalul. O evidență a valorilor JWT retrase sau o verificare a stării actuale a contului poate opri accesul mai devreme, dar serviciul trebuie să consulte acele informații.

Și mecanismul de reînnoire are nevoie de reguli proprii. Retragerea valorii folosite pentru reînnoire poate opri emiterea unor valori noi pentru acces, fără să anuleze imediat valoarea deja emisă la fiecare serviciu care o verifică independent. RFC 7009, publicat în august 2013, discută variantele de retragere, dificultățile folosirii unor date de acces care conțin informațiile necesare verificării și folosirea unor durate scurte de valabilitate. Existența unei funcții de retragere nu dovedește că accesul se oprește imediat peste tot.

Cu o sesiune pe server, regula se exprimă mai direct: înregistrarea este invalidată, iar cererile următoare sunt respinse la verificarea ei. Implementarea rămâne esențială. O copie temporară a sesiunii poate întârzia efectul, iar o cerere deja autorizată poate ajunge la capăt. Stabiliți dacă promisiunea privește cererea următoare, un export în desfășurare sau o conexiune deja deschisă. Fiecare caz cere o decizie proprie.

Cookie-ul nu înlocuiește măsurile de securitate

Ghidul OWASP pentru securitatea HTML5 recomandă să nu păstrați identificatorii de sesiune în localStorage, unde JavaScript îi poate citi. Un cookie HttpOnly reduce acest risc de extragere. Nu elimină efectele unui atac prin injectarea de cod în pagină: acel cod poate încă executa acțiuni folosind browserul autentificat.

Pentru sesiuni, folosiți mecanismul întreținut al cadrului de dezvoltare, cu atributele Secure și HttpOnly, o politică SameSite potrivită și protecție împotriva falsificării cererilor între site-uri. Schimbați identificatorul după autentificare și după modificările relevante ale privilegiilor. Aplicați expirarea și invalidarea pe server. Aceste măsuri sunt descrise în ghidul OWASP despre sesiuni. Documentația a fost consultată în forma actuală pentru această analiză retrospectivă; nu este prezentată ca o copie din mai 2024.

Nici această recomandare nu justifică un sistem de autentificare construit din fragmente de cod găsite separat. Locul unde păstrați sesiunile trebuie administrat, iar disponibilitatea și consecvența datelor contează. Baza de date existentă poate fi potrivită. Un serviciu suplimentar trebuie justificat prin cerințe, fiindcă aduce și muncă de operare.

Când merită verificarea independentă

Un serviciu poate avea nevoie să verifice o informație despre identitate fără să contacteze emitentul la fiecare cerere. Separarea dintre organizații, conectivitatea intermitentă sau o cerință explicită de disponibilitate pot justifica alegerea. Precizați ce independență este necesară și ce întârziere acceptați înainte ca o permisiune retrasă să nu mai fie recunoscută.

Pentru valorile semnate folosite la autentificare, folosiți o implementare întreținută și reguli clare de verificare. RFC 8725, publicat în februarie 2020, tratează algoritmii acceptați, verificarea emitentului și a destinatarului, precum și separarea tipurilor de JWT. Schimbarea cheilor cere și ea un plan: cum află serviciile cheia nouă și când încetează să o accepte pe cea veche?

Sesiunea din browser poate coexista cu schimbul de informații semnate între servicii. Un furnizor extern de identitate poate participa la autentificare, iar aplicația poate păstra propria sesiune. Niciuna dintre variante nu înlocuiește verificarea permisiunilor. Nicole Tietz-Sokolskaya a explicat pe 27 mai 2024 de ce merită separate autentificarea și permisiunile. Faptul că o identitate este validă nu stabilește dreptul de a citi o anumită factură.

Evaluați aplicația înainte să schimbați formatul

La preluarea unei aplicații, verificați comportamentul după deconectare, suspendarea contului și schimbarea permisiunilor. Stabiliți dacă vechile date de acces mai pot fi folosite din alt browser. Urmăriți expirarea, păstrarea datelor în browser și locul din care se citesc permisiunile actuale. Pentru JWT, verificați și restricțiile privind emitentul, destinatarul și schimbarea cheilor.

Defectele descoperite cer intervenție, dar simpla schimbare a formatului poate lăsa problema intactă. Mutarea unui JWT într-un cookie nu rezolvă automat invalidarea. Înlocuirea unei integrări de identitate care funcționează poate aduce riscuri de migrare fără un câștig justificat.

Pentru aplicația obișnuită, alegeți o sesiune al cărei acces îl puteți retrage și explica. Când aveți nevoie de verificare independentă, documentați ce rămâne valabil după schimbarea accesului sau când emitentul nu poate fi contactat. Arhitectura trebuie să respecte promisiunea făcută administratorului care retrage accesul.