„Un JSON Web Token (JWT), pronunțat ‘jot’, este un compact URL-mijloace sigure de a reprezenta pretinde a fi transferate între două părți. Revendicările într-un JWT sunt codificate ca un obiect JSON care este semnat digital folosind JSON Web Signature (JWS)”.,

Înainte de a intra în JWTs, să aruncăm o scurtă privire la modul în care am folosit pentru a face autentificare:

HTTP este un protocol apatrid. Asta înseamnă că nu-și amintește nimic de la cerere la cerere. Dacă vă conectați pentru o singură Solicitare, veți fi uitat și va trebui să vă autentificați din nou pentru a face o altă solicitare. După cum vă puteți imagina, acest lucru poate deveni foarte enervant rapid.,

soluția old-school a fost de a crea ceea ce se numește o „sesiune”. O sesiune este implementată în două părți:

1. un obiect stocat pe server care își amintește dacă un utilizator este încă conectat, o referință la profilul său etc.
2. un cookie din partea clientului care stochează un fel de ID care poate fi referit pe server împotriva ID-ului obiectului sesiunii.,

bazat pe Cookie-Auth:

Dacă un utilizator accesează o pagină web (face o cerere) și server detectează un cookie de sesiune, se va verifica dacă acesta are în prezent o sesiune stocate cu ID-ul de cookie, și dacă acel obiect este încă valabil (indiferent ce înseamnă asta: nu a expirat, nu au fost revocate, nu pe lista neagră, etc).

dacă sesiunea este încă validă, aceasta va răspunde cu pagina web (sau datele) solicitate., Dacă găsește un obiect de sesiune, acel obiect poate conține date în el și, odată cu acesta, serverul își poate „aminti” cine sunteți și ce faceți (de exemplu, dacă acesta este un magazin de comerț electronic, ce produse ați adăugat în coșul nostru de cumpărături).

dacă sesiunea nu este validă (sau nu a fost detectat niciun cookie de sesiune), aceasta va răspunde cu un fel de mesaj de eroare care spune că solicitarea este „neautorizată”.

sesiunile noi pot fi create de obicei prin trimiterea unei combinații de nume de utilizator/parolă la un anumit punct final dintr-o pagină de conectare., Dacă serverul poate potrivi un utilizator cu acel nume de utilizator și parolă, acesta va genera un nou obiect de sesiune pe server și va seta un cookie pe client cu ID-ul sesiunii pentru orice solicitări viitoare.

dacă un utilizator își oprește computerul și revine pe site-ul web la ceva timp în viitor, acesta se poate conecta din nou automat (dacă există încă un cookie în browser care nu a expirat) sau se poate conecta din nou prin pagina de conectare. Odată conectat, sesiunea utilizatorului poate fi recuperată din nou din datele stocate pe server, iar utilizatorul poate continua activitatea (de ex., continuarea cumpărăturilor după reîncărcarea coșului de cumpărături).acest tip de configurare a funcționat destul de bine pentru noi de când a apărut web-ul și de când am vizitat site-uri web care fac cea mai mare parte a „gândirii” lor pe partea de server. De obicei, aceasta a fost o conversație între browserul front-end al utilizatorului și un server back-end corespunzător într-o relație unu-la-unu.,

Această configurare funcționează încă, dar aceste zile, avem multe situații diferite necesită diferite setari (de exemplu, mobile mai multe aplicații native alături de mari, cu o singură pagină web apps contactarea mai multe backend servicii, care ar putea fi nimic mai mult decât de date json, fără o pagină web, la toate)., În aceste tipuri de scenarii, cookie — ul pe care îl obțineți de la un server nu va corespunde — sau chiar va fi trimis-la un alt server (să nu mai vorbim de problemele create cu CORS).

• mai Multe Platforme: Ce se întâmplă dacă aplicația are nevoie pentru a vorbi cu o bază de date backend precum și separate de procesare a imaginii de back-end?, Mai mult și mai mult, lumea noastră digitală este împărțit în separat micro-servicii; când autentificarea cu mai mult de un backend, lucrurile pot deveni complicate (de exemplu, ai putea proxy toate cererile printr-o central aplicație server care ar trebui apoi să știi toate logica de fiecare secundare de servicii, sau fiecare serviciu ar putea pune în aplicare complex inter-server de comunicare (și CORS) pentru a verifica intrare id-Urile de sesiune cu o centrală auth server… in nici un caz suplimentar de încărcare în aplicația server este necesar și mai complexe interconecteaza trebuie să fie menținute).,
• sesiuni: trebuie să fie stocate undeva, fie în memorie, într-o bază de date, sau keyvalue store ca Redis; și trebuie să fie gestionate astfel încât acestea să fie eliminate atunci când expiră sau sunt invalidate în alt mod.
• scalabilitate slabă: magazinul de sesiuni trebuie scalat la scalarea serverului. Magazinul consumă resurse și adaugă complexitate.
• probleme de performanță: când sesiunea trebuie să fie stocată pe server, o mulțime de căutări de baze de date/magazine trebuie să se întâmple la fiecare solicitare care poate bloca serverul.,
• aplicații Native (sau non-browser): browserele gestionează cookie-uri, dar aplicațiile personalizate nu (cel puțin nu ușor), deci este nevoie de un alt tip de mecanism de sesiune.
• CSRF: dacă se utilizează cookie-uri, este necesară o securitate suplimentară pentru a preveni atacurile de solicitare pe mai multe site-uri, Deoarece cookie-ul va fi trimis automat serverului cu orice solicitare făcută de pe site-ul respectiv.
• CORS: Cookies + CORS nu joacă bine în diferite domenii (de fapt, real cross-domain nu funcționează deloc).,

jetoanele JSON Web sunt mai bune

JWTs nu folosesc sesiuni, nu au nicio problemă cu aplicațiile native și de fapt nici nu au nevoie de Protecții CSRF speciale și funcționează ca un farmec cu CORS.

Cu JWT vă înregistrați-vă cu o aplicație, de mult la fel ca tine ar fi cu un vechi-școală de aplicație, și vă conectați cu acreditările dvs. (de exemplu, numele de utilizator/parola, sau 3rd party OAuth)., Dar în loc să faceți o sesiune și să setați un cookie, serverul vă va trimite în schimb un jeton JSON Web. Acum Puteți utiliza acel jeton pentru a face tot ce doriți să faceți cu serverul (pe care aveți autorizația de a face).gândiți-vă la ea ca la o cheie de hotel: vă înregistrați la recepție și vă oferă una dintre acele chei electronice din plastic cu care puteți utiliza pentru a vă accesa camera, piscina și garajul, dar nu puteți deschide camerele altor persoane sau nu puteți intra în biroul managerului. Și, ca o cheie de hotel, când sejurul dvs. s-a încheiat, pur și simplu rămâneți cu o bucată inutilă de plastic (adică., tokenul nu mai face nimic după ce a expirat).

Într-un multi-server configurat, – ai putea imagina, de asemenea, un JWT asemănător cu un „Festival Pass” ca te-ar lua la un film sau un festival de muzică., În cazul în care un bilet individual la film vă va acorda acces la un singur film din care puteți pleca pentru a obține popcorn sau pentru a folosi toaleta și a reveni, un permis de Festival vă va acorda acces la orice film din întregul festival în locații diferite, la momente diferite. În același mod, puteți lua JWT-ul generat de pe un server și îl puteți folosi pentru a vă autentifica cu servere total diferite pe domenii diferite, care împărtășesc aceeași metodă de verificare., Fiecare dintre celelalte servere nu trebuie să „sune acasă” pentru a întreba dacă tokenul este în regulă, deoarece poate pur și simplu să facă un calcul rapid pe token în sine și să verifice semnătura și timpul de expirare direct, fără a suporta o lovitură la baza de date sau o solicitare suplimentară de rețea.

cum funcționează JWT

un JWT este autonom. Când creați unul, acesta are toate piesele necesare de care aveți nevoie pentru a face lucrurile pe care doriți să le faceți pe un server ambalat în interiorul acestuia. Există 3 părți principale, separate de a „.,”:

1. un antet
2. o sarcină
3. o semnătură

antetul conține în mod normal de două lucruri: de tip token-ului (cât de utilă poate fi interpretat), și numele de algoritmul folosit pentru a face semnătură (de exemplu, {typ: ‘JWT’, alg: ‘HS256’}). Acest lucru devine codificat în base64.

semnătura este un hash al antetului codificat, sarcina utilă codificată și o cheie „secretă” pe care o furnizați (stocată în siguranță pe server) folosind algoritmul definit în antet.la sfârșit, obțineți un șir care arată ceva de genul ” xxxxxxxx.AAAA.,zzzzzzzz „unde” x „este antetul codificat,” y „este sarcina utilă codificată, iar” z ” este semnătura criptată.

antetul și sarcina utilă pot fi ușor decodate pe front-end sau back-end pentru a prelua orice informație doriți acolo (este doar base64). Rețineți acest lucru, deoarece aceste valori sunt în esență „publice”, așa că nu puneți informații private acolo, cum ar fi un număr de card de credit sau o parolă sau ceva.

ori de câte ori faceți o solicitare către server, trimiteți tokenul cu solicitarea dvs. De obicei, acest lucru se face în antetul de autorizare, cum ar fi „autorizare: purtător xxxxxx.,AAAA.zzzzzz”. Dar ar putea fi, de asemenea, trecut într-un corp POST sau în URL-ul în sine ca parametru de interogare. Când serverul vede tokenul, îl decodează și compară semnătura cu secretul pe care l-a stocat, care ar fi fost folosit pentru a genera tokenul în primul rând. Dacă totul se potrivește, cererea este autentică și răspunde cu date, altfel trimite înapoi un mesaj de eroare.

Iată un exemplu real de Jetoane. Puteți folosi acest serviciu frumos jwt.io pentru a inspecta cu ușurință token-ul dacă doriți să vedeți ce se află în interiorul acestuia.,

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOi8vZXhhbXBsZS5v
cmciLCJhdWQiOiJodHRwOi8vZXhhbXBsZS5jb20iLCJpYXQiOjEzNTY5OTk1MjQsIm5iZ
iI6MTM1NzAwMDAwMCwiZXhwIjoxNDA3MDE5NjI5LCJqdGkiOiJpZDEyMzQ1NiIsInR5cC
I6Imh0dHBzOi8vZXhhbXBsZS5jb20vcmVnaXN0ZXIiLCJjdXN0b20tcHJvcGVydHkiOiJ
mb28iLCJuYW1lIjoiUm9iIE1jTGFydHkiLCJpZCI6Nzh9.-3BnaA1XRiKh8e7zy9ZRTET
f8VngoypqrVW98oQnH4w

serverul preia informații din sarcina utilă a tokenului (de exemplu, ca un” userId”) și își construiește răspunsul în consecință. Acesta este modul în care serverul „își amintește” utilizatorul, deoarece poate folosi ID-ul pe care îl găsește pentru a verifica numele utilizatorului și alte informații de profil împotriva contului său din Baza de date (sau poate folosi pur și simplu ce date se află în sarcina utilă direct, fără a lovi baza de date deloc). Dacă utilizatorului i s-au acordat drepturi speciale de acces, acestea pot fi preluate și din token (de exemplu, privilegii de administrator).,

cheia (destinată jocului) pentru toate acestea este șirul „secret” care este stocat pe server. Aceasta este o informație pe care numai serverul o știe care este folosită pentru a face noi jetoane și pentru a le valida pe cele existente. Deoarece serverul este singurul lucru care cunoaște secretul, acesta împiedică accesul neautorizat al atacatorilor, deoarece ar fi prea dificil din punct de vedere tehnic să decripteze o semnătură capturată sau să ghicească secretul pentru a falsifica o semnătură contrivată înainte de expirarea unui token emis. Amintiți-vă să nu împărtășiți niciodată secretul dvs. cu nimeni și să îl trimiteți serverului dvs. pe o linie sigură (de ex., utilizarea SSH).de asemenea, puteți configura alte servere pentru a utiliza același secret, astfel încât un token creat de un server să poată fi folosit și pentru a se autentifica cu un server complet diferit (client la server sau server la server)., Setari mai avansate pot fi de asemenea create folosind Jwa (algoritmi web JSON) unde un server auth Central stocheaza un singur secret si serverele terte primesc o cheie publica generata din acel secret si folosesc cheia publica pentru a solicita servicii de autentificare de la serverul auth atunci cand serverul tert primeste o cerere (este suficient sa spunem, exista o multime de moduri diferite de a configura lucrurile; este foarte flexibil).

dacă un atacator încearcă să manipuleze datele sarcinii utile (de ex., drepturi de administrator), semnătura corespunzătoare nu se va potrivi (deoarece semnătura a fost generată din datele originale din sarcina utilă) și, ca atare, tokenul nu va fi considerat valabil pe server și orice solicitări făcute cu acesta vor fi respinse. Singura modalitate de a crea un jeton autentic este cu secretul (care ar trebui să fie doar pe server și niciodată publicat).

un JWT poate include și alte informații utile în sarcina sa utilă, numite „revendicări”. Cel mai important este o dată de expirare., Dacă este inclusă o dată de expirare, token – ul va deveni automat invalid atunci când data respectivă a trecut.

revendicări standard JWT

există un set de proprietăți standard pe care le puteți utiliza în sarcina dvs. utilă pentru a gestiona diferite cazuri de utilizare în aplicație. Revendicări de acest fel pot fi folosite pentru a crește securitatea sistemului dvs. pentru a preveni o serie de tipuri diferite de atacuri. Asigurați-vă că verificați ce este disponibil în biblioteca pe care o alegeți.,

• iss: emitentul jetonului
• sub: subiectul jetonului
• aud: publicul jetonului
• exp: aceasta va fi probabil cererea înregistrată cel mai des utilizată. Aceasta va defini expirarea ca Numărvaloare de dată. Expirarea trebuie să fie după data/ora curentă.
• nbf: definește timpul înainte de care JWT nu trebuie acceptat pentru procesare
• iat: momentul în care JWT a fost emis. Poate fi folosit pentru a determina vârsta JWT
• jti: identificator unic pentru JWT. Poate fi folosit pentru a preveni JWT de a fi redate., Acest lucru este util pentru un jeton de Utilizare o singură dată.

Exemplu de sarcină utilă:

Cum de a Anula o JWT

Cea mai tare parte de o JWT este că afirmațiile sale pot include de expirare setări și pentru că semnătura este o funcție hash de aceste setări, toate server trebuie sa faci este a verifica expirarea informații atunci când verifică biletul și-l respingă dacă acesta a expirat. Ce înseamnă asta este că nu trebuie să vă faceți griji prea mult despre asta. După emiterea unui jeton, lăsați-l în sălbăticie și lăsați-l să moară singur.evident, nu fiecare aplicație își poate permite să facă acest lucru., Uneori, a avea un jeton valid în aer liber chiar și pentru o zi este potențial prea lung (de exemplu, poate să acorde unui utilizator acces la contul său dacă și-a uitat parola). Uneori este posibil să doriți ca un token să fie utilizat o singură dată (de exemplu, pentru o resetare a parolei). Alteori este posibil să aveți un utilizator rău intenționat înregistrat în sistemul dvs. pe care doriți să îl interziceți cu totul, astfel încât toate jetoanele pe care le-au creat deja să nu mai poată fi utilizate pentru a accesa sistemul.aceste scenarii pot fi gestionate (dacă este necesar) printr-o combinație de revendicări JWT și mecanisme de server-side., Păstrați următoarele opțiuni în minte atunci când se analizează semn de invalidare și a expirării:

• a elimina token-ul de la client
• a menține un semn neagră
• ține ori de expirare scurt

prima opțiune pur și simplu „arunca” token-ul și vă permite să expire pe cont propriu.

a doua opțiune este un pic mai implicată în faptul că urmărește jetoanele reale stocate pe server (de exemplu, într-o bază de date sau într-un magazin de chei/valori) și folosește această listă în timpul verificării tokenului pentru a verifica dacă un token a fost listat negru., Acest lucru este un fel de opus de magazine sesiune, dar este încă mai performant, deoarece ca token-uri expiră în mod natural, ele pot fi pur și simplu eliminate din lista neagră. Lista neagră este necesară doar pentru a invalida un jeton care nu a expirat încă.,

în cele din Urmă, în general, ar trebui să țină un simbol ori de expirare scurt oricum (ca în 24 de ore; poate doar 1 sau 2 ore), astfel încât, în cel mai rău caz, un atacator are mai puțin de o zi pentru a profita, care este, probabil, nu suficient timp pentru brute-force semnătura de criptare, chiar și cu un super-computer… juriul este încă pe computerele cuantice.

avantajele JWTs

• fără sesiune de gestionat (apatrid): tokenul are tot ce aveți nevoie pentru a identifica utilizatorii, iar restul stării aplicației dvs. poate fi stocat în spațiul de stocare local din partea clientului., Nu este nevoie de un obiect de sesiune stocat pe server.
• portabil / omogen: un singur token poate fi folosit cu mai multe backend-uri, chiar și pe diferite domenii.
• nu sunt necesare cookie-uri: puteți stoca tokenul oricum dorim: în localStorage, indexDB sau într-un magazin nativ (sau cookie-uri, dacă doriți cu adevărat).
• Mobile Friendly: dezvoltarea de aplicații native( iOS, Android, Windows 8, etc) este dificilă și greoaie cu cookie-urile (trebuie să vă ocupați de containerele cookie), dar adoptarea unei abordări bazate pe token simplifică foarte mult acest lucru.,
• Expirare încorporată: JWT are revendicări standard care pot fi setate în sarcina utilă atunci când este creat un nou token. Nu mai trebuie făcut nimic.
• nu trebuie să vă deconectați: aruncați jetonul când ați terminat, acesta va expira singur. De obicei vreau să dau un scurt timp de expirare, dar dacă doriți cu adevărat să, puteți urmări o „listă neagră” de jetoane pe care sunt marcate ca „invalid” pe server care ar putea fi adăugate la o explicită logout, sau de un administrator marcarea unor jetoane ca invalid.,
• funcționează cu CORS: o abordare auth bazată pe token vă permite să efectuați apeluri AJAX către orice server, pe orice domeniu, deoarece puteți utiliza un antet HTTP pentru a transmite informațiile utilizatorului.
• Leverage CDN: puteți servi toate activele pentru aplicația dvs. dintr-un CDN (de exemplu, javascript, HTML, imagini etc.), iar partea serverului dvs. poate fi doar un API apatrid.
• ușor de depanare: JWT-urile pot fi inspectate și datele lor revizuite (în timp ce sesiunile sunt stocate pe server și sunt mult mai greu de văzut și înțeles).
• decuplat / descentralizat: tokenul poate fi generat oriunde., Autentificarea se poate întâmpla pe serverul de resurse sau poate fi ușor separată în propriul server sau „auto-emisă” sau poate fi externalizată complet.
• CSRF nu contează: pentru că dacă nu aveți un token, nu puteți face nimic. Deoarece nu este necesar să vă bazați pe cookie-uri, nu este necesar să vă protejați împotriva solicitărilor încrucișate ale site-urilor (de ex., aceasta nu ar fi posibil să<iframe> site-ul dvs., de a genera o cerere POST, și re-utilizați existente autentificare cookie pentru că nu va fi nici unul) de la JWT trebuie să fie incluse în mod explicit în cererea antet, și nu se seta automat ca un cookie.
• Bună Performanță: O rețea tur-retur (de exemplu, găsirea o sesiune în baza de date, deserializing, apoi extragerea de informații sunteți interesat în a) este probabil să ia mai mult timp decât în calcul o HMACSHA256 pentru a valida un semn și analiza conținutul său.,
• Bazat pe standarde: Citește spec: RFC 7519 susținută de mai multe backend biblioteci (.NET, Ruby, Java, Python, PHP, Javascript), și companiile de sprijinul lor în infrastructură (de exemplu, Firebase, Google, Microsoft, Zendesk).

asta este! Du-te mai departe și eliberează-te de opresorii tăi cookie! Și apoi lăsați-ne un comentariu pentru a ne anunța cât de bine se simte libertatea și împărtășiți eliberarea cu prietenii dvs. trimițând acest articol în felul lor.

Scris de: Rob McLarty

Acest articol a fost publicat inițial pe http://robmclarty.com/blog