Sistemele de autentificare reprezintă coloana vertebrală a multor site-uri web. Acesta permite utilizatorilor să se conecteze la site-ul dvs. și să păstreze datele între vizite. Este crucial pentru a oferi o experiență robustă utilizatorilor, care îi recompensează pe utilizatorii dvs. pentru furnizarea datelor lor. Autentificările oferă adesea acces la date personale private care, dacă sunt făcute publice, ar putea dăuna utilizatorului dumneavoastră. Pentru a preveni acestea, protocoalele de autentificare au fost create pentru a securiza cererile, permițând în același timp utilizatorilor să se conecteze în continuare în siguranță la sistemul dvs. din orice mediu.

Basic SSL Auth

Basic auth este cea mai simplă formă de autentificare web. Utilizează anteturi HTTP standard în locul unor soluții mai complicate care se bazează pe cookie-uri, identificatori de sesiune și pagini de autentificare. Există foarte puțină securitate încorporată în sistemul de autentificare de bază. Datele de identificare sunt transmise doar cu o codificare Base64 și nu sunt criptate sau hașurate. Din cauza nesiguranței înrădăcinate în sistem, aceste solicitări se fac cel mai adesea prin HTTPS.

Informațiile de autorizare trebuie compilate în următorul format și incluse în antet:

Format:

<!--Authorization: Basic -->

Detalii complete despre protocolul de autentificare de bază pot fi găsite aici: http://www.w3.org/Protocols/HTTP/1.0/spec.html#AA

Digest Auth

Digest Auth funcționează similar cu autentificarea SSL de bază, cu excepția faptului că parola este criptată cu ajutorul unui hash unidirecțional. Utilizează hashing-ul criptografic MD5 cu un nonce (o valoare generată de server care previne atacurile de reluare).

Fluxul tipic al unei cereri Digest Auth este :

1. Un utilizator navighează către o pagină care necesită autentificarea utilizatorului.
2. Serverele răspund cu un mesaj 401 care semnifică faptul că un utilizator nu este în prezent autorizat să acceseze conținutul. În răspuns include, de asemenea, nonce-ul care va fi utilizat în timpul autorizării pentru a preveni atacurile de reluare,
3. Site-ul afișează apoi o interfață de autentificare pentru a aduna detaliile necesare( nume de utilizator și parolă )
4. Detalii furnizate sunt retrimise serverului cu un antet de autentificare inclus în cererea care are un cod de răspuns.
5. Serverul ar verifica apoi datele furnizate și ar accepta autentificarea sau ar returna un mesaj 401 în cazul în care datele sunt incorecte, ceea ce ar face ca utilizatorului să i se solicite din nou interfața de autentificare.

Detalii complete despre protocolul Digest Auth pot fi găsite aici: https://www.ietf.org/rfc/rfc2617.txt

OAuth 1.0

Protocolul OAuth 1.0 se bazează pe existența unui secret partajat între server și site. Acest secret partajat este utilizat pentru a genera o semnătură care este inclusă în cerere. Semnătura generată este utilizată pentru a verifica, pe partea serverului, validitatea cererii de autentificare. Procesul de autorizare a utilizatorului este, în general, gestionat în trei etape („3-legged OAuth”):

1. Site obține Request Token.
2. Utilizatorul autorizează Request Token.
3. Site schimbă Request token cu Access Token.

Procesul de finalizare a unei solicitări OAuth pe trei niveluri va fi, în general, gestionat după cum urmează:

1. Site-ul va trimite o cerere semnată pentru Request token. Această cerere trebuie să conțină următorii parametri:

   1. oauth_consumer_key
   2. oauth_timestamp
   3. oauth_nonce
   4. oauth_signature
   5. outh_signature
   6. outh_signature_method
   7. oauth_version

   .

   8. oauth_callback

Această cerere va fi validată pe server și, dacă este validată, va returna token-ul de cerere în următorul format:

1. oauth_token
2. oauth_token_secret
3. și orice alt parametru suplimentar returnat de serverul dumneavoastră.
4. Postul următor după recuperarea jetonului de cerere este de a solicita utilizatorului dumneavoastră să introducă datele de autentificare. Acestea sunt apoi formatate într-o semnătură cu tokenul de cerere oauth_token și trimise cu o cerere înapoi la server pentru validare. În urma validării cu succes a acestei cereri, serverul va returna următoarele:
5. oauth_token
6. oauth_verifier

Acestea vor fi utilizate în etapa următoare pentru a prelua un jeton de acces.

1. Etapa finală constă în schimbul detaliilor preluate la etapa 2 cu un jeton de acces , care va fi utilizat pentru a accesa resursele serverelor. Pentru a schimba token-ul de cerere cu un token de acces, puteți face o cerere către server cu următoarea cerere semnată
2. oauth_token -revenit de la pasul 2
3. oauth_consumer_key
4. oauth_nonce
5. oauth_signature
6. oauth_signature_method
7. oauth_version
8. oauth_verifier -returnat la pasul 2

Aceasta vă va returna un token de acces care va fi folosit împreună cu secretul dumneavoastră pentru a face cereri de informații de la server.

Puteți găsi detalii complete despre protocolul OAuth 1.0 aici: https://tools.ietf.org/html/rfc5849

OAuth 2.0

Este similar cu protocolul OAuth 1.0, se bazează pe un id și un secret al clientului pentru a formata cererea, dar simplifică o mare parte din procesul complicat de semnare care este inerent în sistemul OAuth 1.0. Procesul de autorizare a unui utilizator cu ajutorul protocolului OAuth 2.0 este după cum urmează:

1. Utilizatorul este direcționat către serviciul pentru autorizare, cu următoarele detalii incluse în URL-ul de autorizare:

   1. client_id
   2. redirect_uri
   3. response_type
   4. scope

2. Utilizatorul se va autentifica apoi cu serviciul și va acorda aplicației accesul la detaliile sale. În cazul unei autentificări reușite, utilizatorul este redirecționat către redirect_uri cu următorii parametri:

   1. code
   2. state

3. Codul returnat la pasul 2 este apoi utilizat de aplicație pentru a face o cerere pentru un token de acces. În această cerere ar trebui să fie incluse:

   1. client_id
   2. client_secret
   3. code
   4. redirect_uri
   5. grant_type – Acesta ar trebui să fie setat la „authorization_code”

Serverele vor verifica aceste detalii și apoi vor returna un token de acces cu un timp de expirare, dacă acestea sunt valide. Acestea sunt în general returnate în următorul format:

1. access_token
2. expires_in
3. refresh_token

Puteți găsi detalii complete despre protocolul OAuth 2.0 aici: http://oauth.net/2/

Protocoalele de autentificare vă permit să vă protejați datele cu diferite niveluri de securitate. În funcție de datele care sunt accesate și de nivelul de securitate dorit, implementarea unuia dintre protocoalele de mai sus vă permite să fiți sigur că datele dvs. sunt în siguranță și că sunt accesate numai de către utilizatorii cărora li se permite accesul la sistemul dvs.

.