| OAuth | |
|---|---|
| Nume | OAuth |
| Fișiere media la Wikimedia Commons | |
OAuth este un protocol de autorizare deschis (schemă) care oferă unei terțe părți acces limitat la resursele protejate ale utilizatorului fără a-i transfera un login și o parolă (terțul) [1] [2] .
Lucrările la protocol au început în noiembrie 2006, iar cea mai recentă versiune a OAuth 1.0 a fost aprobată pe 4 decembrie 2007. Ca o dezvoltare ulterioară, protocolul OAuth 2.0 a apărut în 2010, cea mai recentă versiune a căruia a fost publicată în octombrie 2012 ca RFC 6749 .
Una dintre problemele de autentificare și securitatea informațiilor este că utilizatorii folosesc de obicei mai multe servicii diferite (de exemplu, pe Google, Twitter, Apple etc.) și, în consecință, mai multe conturi cu propriile autentificări și parole. Astfel, utilizatorii trebuie să stocheze și să protejeze multe date de conectare și parole. Deoarece fiecare dintre servicii are propriul sistem de securitate cu propriile vulnerabilități și deficiențe, toate acestea sunt dăunătoare pentru confortul și securitatea utilizatorilor. De exemplu, dacă utilizatorii folosesc aceleași parole pentru diferite servicii, atunci după ce au acces la unul dintre conturi, procedura de hacking pentru alte conturi pentru atacatori este mult simplificată [3] .
Autentificarea în doi pași (de exemplu , Google Authenticator ) poate fi utilizată pentru a crește securitatea, atunci când un alt serviciu de utilizator este utilizat pentru confirmare (de exemplu, atunci când un cod trimis la un telefon mobil este necesar pentru autentificare pe un site web ). Cu această abordare, probabilitatea de hacking este semnificativ redusă. Caracteristica cheie a utilizării OAuth este că, dacă utilizatorul are un cont bine protejat, atunci cu ajutorul acestuia și al tehnologiei OAuth, se poate autentifica la alte servicii, în timp ce utilizatorul nu trebuie să-și dezvăluie parola principală. De exemplu, un utilizator care dorește să ofere unui serviciu de imprimare foto online acces la fotografiile din contul său de Facebook nu trebuie să furnizeze serviciului parola pentru acel cont. În schimb, transmite autorizația către Facebook, care (cu permisiunea utilizatorului sau a administratorului de servicii) oferă deja serviciului de printare online accesul necesar la fotografii [3] .
OAuth a apărut în noiembrie 2006, în timpul dezvoltării protocolului OpenID pentru serviciul de microblogging Twitter de către Blaine Cook . Împreună cu Chris Messina , el căuta o modalitate de a folosi OpenID pentru a oferi acces la API -ul Twitter fără a oferi serviciului o parolă. În colaborare cu co-creatorul OpenID, David Recordon , au analizat funcționalitatea OpenID, precum și protocoalele de autorizare proprietare , cum ar fi Flickr Auth , Google AuthSub și Yahoo! BBAuth , după care au ajuns la concluzia că este nevoie de un nou protocol deschis [4] .
În aprilie 2007, un grup de ingineri a fost format pentru a lucra la crearea acestuia. Angajații Google și AOL (care și-au introdus în același timp propriul protocol OpenAuth ) au luat parte la activitatea sa. Versiunea finală a nucleului de protocol OAuth 1.0 a fost lansată pe 4 decembrie 2007. În 2008, s-au desfășurat lucrări de standardizare a protocolului în Internet Engineering Council [4] .
Pe 15 aprilie 2009, Twitter a oferit utilizatorilor săi o soluție care permite site-urilor și serviciilor terților să-și acceseze conturile. Se numea „Conectează-te cu Twitter” și se baza pe OAuth. Acest eveniment a declanșat primul studiu amplu de vulnerabilitate al protocolului, iar câteva zile mai târziu a fost descoperită o potențială vulnerabilitate care afectează toate implementările OAuth existente. După aceea, pe 23 aprilie, comunitatea de dezvoltatori a lansat prima adăugare de securitate la protocol, care a fost inclusă în specificația actualizată OAuth Core 1.0 Revision A, publicată pe 24 iunie. În aprilie 2010, a fost lansată cartea albă RFC 5849 privind standardul OAuth [4] .
În 2010, au început lucrările la o nouă versiune a protocolului OAuth 2.0 care nu era compatibilă cu OAuth 1.0 [1] . În octombrie 2012, cadrul pentru OAuth 2.0 a fost publicat în RFC 6749 și utilizarea purtătorului de token în RFC 6750 .
Au existat mai multe cerințe preliminare pentru crearea OAuth 2.0. În primul rând, OAuth este destul de netrivial de utilizat pe partea clientului. Unul dintre obiectivele dezvoltării noului OAuth este de a facilita dezvoltarea aplicațiilor client. În al doilea rând, în ciuda implementării a trei metode (numite fluxuri) declarate în standard pentru obținerea unui token (identificator unic) pentru autorizare: pentru aplicații web, clienți desktop și clienți mobili, de fapt, toate cele trei metode sunt îmbinate într-una singură. Și, în al treilea rând, protocolul s-a dovedit a fi slab scalabil. Pe lângă noile fluxuri, [5] [6] au fost adăugate la acesta :
În prezent, OAuth 2.0 este utilizat de un număr mare de servicii, cum ar fi Google , Instagram , Facebook , VKontakte și altele.
În iulie 2012, Eran Hammer, actualul editor al standardului OAuth 2.0, și-a anunțat demisia după trei ani de lucru la noul standard și a cerut ca numele său să fie eliminat din specificații. El a vorbit despre opiniile sale pe site-ul său [7] și mai târziu a ținut o conferință [8] . David Recordon și -a șters mai târziu numele din specificații fără a oferi motive [ 9] . Dick Hardt a devenit editorul standardului OAuth2.0 și, în ciuda opiniilor lui Eran Hammer, cadrul OAuth 2.0 a fost publicat în RFC 6749 în octombrie 2012 [1] .
Când folosește autorizarea OAuth , utilizatorul nu își transferă login-ul și parola către resursele protejate direct în aplicație [3] . De aceea:
În cazul autorizării fără utilizarea protocolului OAuth, utilizatorul trebuie să-și trimită login-ul și parola. Această metodă are dezavantaje suplimentare [3] :
Deși OAuth și OpenID au multe în comun, OAuth este un protocol în sine și nu are nimic de-a face cu OpenID [10] :
Concepte de bază utilizate în protocoale și exemple de utilizare a acestora.
OAuth 1.0 definește trei roluri: client, server și proprietar de resurse. Aceste trei roluri sunt prezente în orice operațiune OAuth, în unele cazuri clientul este și proprietarul resursei. Versiunea originală a specificației folosește un set diferit de termeni pentru aceste roluri: consumator (client), serviciu (server) și utilizator (proprietar de resurse) [11] . În protocolul OAuth 2.0, a existat o separare a rolurilor de server: un server de autorizare și un server care stochează resurse protejate sunt alocate separat [6] .
OAuth acceptă 3 metode de semnătură utilizate pentru semnarea și validarea cererilor: PLAINTEXT , HMAC - SHA1 și RSA - SHA1 . PLAINTEXT este simplu de utilizat și necesită mult mai puțin timp pentru a calcula, dar poate fi sigur numai prin HTTPS sau canale securizate similare. HMAC - SHA1 oferă un algoritm simplu și generic care este disponibil pe majoritatea platformelor, dar nu pe toate dispozitivele vechi și utilizează o cheie partajată simetrică. RSA - SHA1 oferă securitate îmbunătățită cu o pereche de chei, dar este mai complex și necesită generarea de chei [12] .
Pentru a preveni amenințarea de reutilizare a solicitărilor, OAuth folosește un nonce și un marcaj de timp . Termenul „nonce” este folosit pentru a se referi la un cod unic, care este un set aleatoriu de litere și numere și este conceput pentru a identifica în mod unic o solicitare. Având un identificator unic într-o solicitare, furnizorul de servicii poate împiedica reutilizarea acestuia. Această abordare este implementată prin generarea unui șir unic pentru fiecare cerere trimisă către server de către client. Pentru a preveni reutilizarea cererilor, serverul TREBUIE să stocheze non-urile primite [12] .
Cu toate acestea, stocarea tuturor non-urilor primite poate fi foarte costisitoare pentru server. Pentru a preveni supraîncărcarea excesivă de stocare în OAuth, la fiecare solicitare se adaugă un marcaj de timp, ceea ce permite serverului să stocheze nonce doar pentru o perioadă limitată de timp specificată. La primirea unei cereri cu o etichetă mai devreme decât este permis, serverul o respinge [12] .
OAuth 1.0 și OAuth 2.0 utilizează trei tipuri de autorizare: acreditări de client ( cheie de consumator și secrete sau acreditări de client ) , acreditări temporare ( token de solicitare și acreditări secrete sau temporare ) și token-uri ( token de acces și secrete sau acreditări de simbol în engleză ) [13] [ 3] .
Acreditările clientului sunt folosite pentru autentificarea clientului. Serverul poate oferi clienților servicii speciale, cum ar fi limitarea accesului liber sau furnizarea proprietarului resursei informații mai detaliate despre clienții care încearcă să acceseze resursele protejate. În unele cazuri, acreditările clientului nu sunt sigure și pot fi utilizate doar în scopuri informaționale, cum ar fi în aplicațiile desktop.
Jetonul este folosit în locul numelui și parolei proprietarului resursei. Proprietarul resursei nu dezvăluie acreditările sale clientului, dar permite serverului să emită un token către client - o clasă specială de acreditări care oferă clientului unele capacități limitate. Clientul folosește jetonul pentru a accesa o resursă protejată fără a cunoaște parola proprietarului resursei. Jetonul constă dintr-o semnătură digitală, de obicei (dar nu întotdeauna) un set aleatoriu de litere și numere care este unic și puternic criptografic și o cheie pentru a proteja jetonul împotriva utilizării neautorizate. Token-ul este limitat în ceea ce privește autoritatea și durata și poate fi revocat în orice moment de către proprietarul resursei, fără a afecta token-urile emise altor clienți [13] .
Procesul de autorizare OAuth utilizează, de asemenea, un set de acreditări temporare care sunt utilizate în timpul etapei de solicitare a autorizației. Pentru a satisface diferite tipuri de clienți (interfață web, desktop, mobil etc.), permisiunile temporare oferă flexibilitate și securitate suplimentară [13] .
Să explicăm cum funcționează protocolul OAuth 1.0 folosind un exemplu [13] . Să presupunem că un utilizator (proprietar de resurse) dorește să-și imprime fotografiile (resursele) încărcate pe photos.example.net (server) folosind serviciul de imprimare „printer.example.net” (client).
Protocolul OAuth 2.0 nu este compatibil cu protocolul OAuth 1.0 [1] . În loc să completeze OAuth 1.0, a fost luată decizia de a dezvolta un protocol diferit [10] . Prin urmare, modul în care funcționează OAuth 1.0 și OAuth 2.0 este diferit. Deci, în standardul OAuth 2.0 sunt descrise următoarele fluxuri (scenarii de interacțiune a părților) [1] :
OAuth acceptă două metode de autentificare a mesajelor de la client: HMAC - SHA1 și RSA - SHA1 . Este posibil să trimiteți mesaje fără semnătură, apoi „ text simplu ” este indicat în câmpul tip semnătură. Dar în acest caz, conform specificației, conexiunea dintre client și server trebuie să fie stabilită prin protocolul SSL sau TLS [13] .
| Protocoale de autentificare și schimb de chei | |
|---|---|
| Cu algoritmi simetrici | |
| Cu algoritmi simetrici si asimetrici | |
| Protocoale și servicii utilizate pe Internet | |