Introducere
autentificarea bazată pe Token este proeminentă peste tot pe web în zilele noastre. Cu majoritatea companiilor web care utilizează un API, jetoanele sunt cel mai bun mod de a gestiona autentificarea pentru mai mulți utilizatori.
există câțiva factori foarte importanți atunci când alegeți autentificarea bazată pe token pentru aplicația dvs. Principalele motive pentru jetoane sunt:
- Servere apatride și scalabile
- aplicație mobilă gata
- treceți autentificarea la alte aplicații
- securitate suplimentară
cine folosește Autentificarea bazată pe Token?
orice API sau aplicație web majoră pe care ați întâlnit-o a folosit cel mai probabil jetoane. Aplicații precum Facebook, Twitter, Google+, GitHub și multe altele folosesc jetoane.
să aruncăm o privire la exact cum funcționează.
de ce au apărut jetoanele
înainte de a putea vedea cum funcționează autentificarea bazată pe token și beneficiile acesteia, trebuie să ne uităm la modul în care autentificarea a fost făcută în trecut.
autentificare bazată pe Server (metoda tradițională)
deoarece protocolul HTTP este apatrid, aceasta înseamnă că, dacă autentificăm un utilizator cu un nume de utilizator și o parolă, atunci la următoarea solicitare, aplicația noastră nu va ști cine suntem. Va trebui să ne autentificăm din nou.
modul tradițional de a avea aplicațiile noastre amintesc cine suntem este de a stoca utilizatorul conectat informații pe server. Acest lucru se poate face în câteva moduri diferite în sesiune, de obicei în memorie sau stocate pe disc.
pe măsură ce web-ul, aplicațiile și creșterea aplicației mobile au apărut, această metodă de autentificare a arătat probleme, în special în ceea ce privește scalabilitatea.
problemele cu Autentificarea bazată pe Server
au apărut câteva probleme majore cu această metodă de autentificare.
- sesiuni: De fiecare dată când un utilizator este autentificat, serverul va trebui să creeze o înregistrare undeva pe serverul nostru. Acest lucru se face de obicei în memorie și atunci când există mulți utilizatori care se autentifică, cheltuielile de pe serverul dvs. cresc.
- scalabilitate: deoarece sesiunile sunt stocate în memorie, aceasta oferă probleme cu scalabilitatea. Pe măsură ce furnizorii noștri de cloud încep să reproducă servere pentru a gestiona încărcarea aplicației, având informații vitale în memoria sesiunii ne va limita capacitatea de a scala.
- CORS: Deoarece dorim să ne extindem aplicația pentru a permite utilizarea datelor noastre pe mai multe dispozitive mobile, trebuie să ne facem griji cu privire la partajarea resurselor de origine încrucișată (CORS). Atunci când se utilizează apeluri AJAX pentru a apuca resurse de la un alt domeniu (mobil la serverul nostru API), am putea rula în probleme cu cereri interzise.
- CSRF: vom avea, de asemenea, protecție împotriva cross-site cerere falsificare (CSRF). Utilizatorii sunt susceptibili la atacuri CSRF, deoarece pot fi deja autentificați cu un site bancar și acest lucru ar putea fi profitat atunci când vizitați alte site-uri.
cu aceste probleme, scalabilitatea fiind cea principală, a avut sens să încercăm o abordare diferită.
cum funcționează Token-Based
autentificarea Token-based este apatridă. Nu stocăm nicio informație despre utilizatorul nostru pe server sau într-o sesiune.
acest concept se ocupă singur de multe dintre problemele legate de stocarea informațiilor pe server.
nicio informație despre sesiune nu înseamnă că aplicația dvs. poate scala și adăuga mai multe mașini, după cum este necesar, fără să vă faceți griji cu privire la locul în care este conectat un utilizator.
deși această implementare poate varia, esența acesteia este după cum urmează:
- utilizatorul solicită accesul cu numele de Utilizator / Parola
- aplicația validează acreditările
- Aplicația oferă un jeton semnat clientului
- Clientul stochează acel jeton și îl trimite împreună cu fiecare solicitare
- serverul verifică jetonul și răspunde cu date
fiecare solicitare va necesita jetonul. Acest simbol ar trebui să fie trimis în antetul HTTP, astfel încât să păstrăm ideea cererilor HTTP apatride. De asemenea, va trebui să setăm serverul nostru să accepte cereri din toate domeniile folosind Access-Control-Allow-Origin: *. Ceea ce este interesant despre desemnarea * în antetul ACAO este că nu permite cererilor să furnizeze acreditări precum autentificarea HTTP, certificatele SSL din partea clientului sau cookie-urile.
odată ce ne-am autentificat cu informațiile noastre și avem tokenul nostru, suntem capabili să facem multe lucruri cu acest token.
am putea chiar să creăm un jeton bazat pe permisiune și să transmitem acest lucru unei aplicații terțe (să zicem o nouă aplicație mobilă pe care dorim să o folosim) și vor putea avea acces la datele noastre-dar numai informațiile pe care le-am permis cu acel jeton specific.
beneficiile jetoanelor
apatride și scalabile
jetoanele sunt stocate pe partea clientului. Complet apatrid și gata pentru a fi scalate. Echilibrele noastre de încărcare sunt capabile să transmită un utilizator pe oricare dintre serverele noastre, deoarece nu există informații despre stare sau sesiune nicăieri.
dacă ar fi să păstrăm informații despre sesiune pe un utilizator care a fost conectat, acest lucru ar necesita să continuăm să trimitem acel utilizator la același server la care s-a conectat (numit session affinity).
acest lucru aduce probleme, deoarece unii utilizatori ar fi forțați la același server și acest lucru ar putea aduce un loc de trafic intens.
nu vă faceți griji, deși! Aceste probleme au dispărut cu jetoanele, deoarece tokenul în sine deține datele pentru acel utilizator.
securitate
tokenul, nu un cookie, este trimis la fiecare solicitare și, deoarece nu există niciun cookie trimis, acest lucru ajută la prevenirea atacurilor CSRF. Chiar dacă implementarea dvs. specifică stochează tokenul într-un cookie din partea clientului, cookie-ul este doar un mecanism de stocare în loc de unul de autentificare. Nu există informații bazate pe sesiune pentru a manipula, deoarece nu avem o sesiune!
tokenul expiră, de asemenea, după o perioadă de timp stabilită, astfel încât un utilizator va trebui să se conecteze din nou. Acest lucru ne ajută să rămânem în siguranță. Există, de asemenea, conceptul de revocare a jetoanelor care ne permite să invalidăm un jeton specific și chiar un grup de jetoane bazate pe același grant de autorizare.
extensibilitate (prieten al unui prieten și permisiuni)
jetoanele ne vor permite să construim aplicații care partajează permisiuni cu altul. De exemplu, am conectat conturi sociale aleatorii la cele mai importante, cum ar fi Facebook sau Twitter.
când ne conectăm la Twitter printr-un serviciu (să spunem Buffer), permitem Buffer-ului să posteze în fluxul nostru Twitter.
prin utilizarea jetoanelor, acesta este modul în care oferim permisiuni selective pentru aplicații terțe. Am putea chiar să ne construim propriul API și să înmânăm jetoane speciale de permisiune dacă utilizatorii noștri doreau să ofere acces la datele lor unei alte aplicații.
mai multe platforme și domenii
am vorbit puțin despre CORS mai devreme. Când aplicația și serviciul nostru se extinde, va trebui să oferim acces la tot felul de dispozitive și aplicații (deoarece aplicația noastră va deveni cu siguranță populară!).
având API-ul nostru doar servi date, putem face, de asemenea, alegerea de proiectare pentru a servi active de la un CDN. Acest lucru elimină problemele pe care CORS le aduce după ce am setat o configurație rapidă a antetului pentru aplicația noastră.
Access-Control-Allow-Origin: *datele și resursele noastre sunt disponibile pentru cererile din orice domeniu acum, atâta timp cât un utilizator are un jeton valid.
bazate pe standarde
la crearea token-ul, aveți câteva opțiuni. Ne vom scufunda mai mult în acest subiect atunci când vom asigura un API într-un articol de urmărire, dar standardul de utilizat ar fi jetoanele JSON Web.
această diagramă de depanare și bibliotecă la îndemână arată suportul pentru jetoanele JSON Web. Puteți vedea că are o cantitate mare de sprijin într-o varietate de limbi. Acest lucru înseamnă că ai putea trece de fapt din mecanismul de autentificare, dacă alegeți să facă acest lucru în viitor!
concluzie
aceasta a fost doar o privire asupra modului și motivului autentificării bazate pe token. Așa cum se întâmplă întotdeauna în lumea securității, există mult mai mult pentru fiecare subiect și variază în funcție de caz de utilizare. Ne-am scufundat chiar și în câteva subiecte despre scalabilitate, care merită și propria conversație.
aceasta a fost o privire de ansamblu rapidă la nivel înalt, așa că vă rugăm să nu ezitați să subliniați orice a fost ratat sau orice întrebări pe care le aveți în această privință.
în următorul nostru articol, vom analiza anatomia jetoanelor JSON Web.
notă: adăugarea ACAO header info și CSRF clarificări (datorită Emily Stark pentru info articol)