Cum se utilizează jetoanele pentru autentificare în api

De la sesiunile clasice la care a fost refuzat API-ul.

Serverul primește cererea, vede că a apărut token, îl împarte prin colon la input_id și input_val. Selectează un token din baza de date cu intrarea input_id, primește valoarea token_val și secrete din baza de date. Compară input_val și token_val. Dacă există un jeton cu idul dorit în baza de date și valorile val sunt egale, este timpul să verificăm valabilitatea cererii.







În afară de token, clientul a trimis un semn, care a fost format (de exemplu) secret + api_path + query_param. Pe partea de server, știți api_path și api_param, iar secretul este selectat din baza de date. Eliminarea semnăturii se face prin hmac ().

În plus față de token și semnătura, puteți trece timpul și, de asemenea, pune-l în semn, iar pe partea de server, cererile de tăiere care sunt mai mari de 60 de secunde.

Dacă cineva vă ascultă canalul, nu va putea să falsifice cererile (și, prin urmare, să compromită) și din cauza verificării duratei de interogare, interogarea nu poate primi întotdeauna date privind solicitarea interceptată o singură dată.







Și în jetoanele bazei de date pot fi stocate până când clientul însuși solicită distrugerea acestora și salvează timpul ultimului acces prin jeton și șterge token-urile care nu au fost folosite mai mult de 60 de zile.

Normalizarea D. Acest mecanism protejează împotriva falsificării cererii, iar dvs. nu.
După ce ați interceptat tokenul (apropo, pentru ce id și val?) Și secret, putem sculpta orice cerere.
Prin semn de captură = RSA (sha256 (pass + parametri)) nu vom decripta șirul fără a avea o cheie privată. Fără cunoașterea parolei, nu putem scrie o altă solicitare.
Iar parola poate fi furată în a ta, iar în cazul meu, chiar nu salvează nimic, numai aici furnizorul de API nu va fi vinovat în acest caz.

Artem. utilizați o cheie principală pentru toți utilizatorii - drum direct ------> mergeți acolo.
Nu vă deranjează acolo unde nu este necesar. Dacă sunteți într-adevăr sensibil la datele de interceptare, ar trebui să vă uitați la o soluție mai persistentă (a se vedea implementarea protocolului de telegramă).

Dacă nu doriți să vă deranjez prea mult și așa cum este RSA, atunci merită să generați chei publice / private separate pentru fiecare utilizator și să descărcați manual cheia publică printr-o altă sursă manuală, atunci nimeni nu va intercepta și nu va putea răni.

Artem. "Apropo, pentru ce id și val?", Numai pentru a selecta din baza de date prin INT și pe el același indice de făcut. La urma urmei, fiecare cerere adresată API-ului, este o verificare token. Indexul pe un câmp numeric este mai ușor decât indicele varchar.







Articole similare

Trimiteți-le prietenilor: