Ce trebuie să știți despre OAuth2 și conectarea cu Facebook

În cazul în care vă întrebați ce este OAuth2, este protocolul care permite oricui să se conecteze cu contul său de Facebook. Activează butonul „Conectează-te cu Facebook” în aplicații și pe site-uri web de pretutindeni.

Acest articol vă arată cum funcționează „Log in with Facebook” și explică protocolul din spatele tuturor. Veți afla de ce doriți să vă conectați cu Facebook, Google, Microsoft sau una dintre multele alte companii care acceptă OAuth2.

Acest articol vă arată cum funcționează „Log in with Facebook” și explică protocolul din spatele tuturor. Veți afla de ce doriți să vă conectați cu Facebook, Google, Microsoft sau una dintre multele alte companii care acceptă OAuth2.

Vom analiza două exemple: de ce Spotify folosește Facebook pentru a vă permite să vă conectați la aplicația mobilă Spotify și de ce Quora folosește Google și Facebook pentru a vă permite să vă conectați la site-ul său web.

Citiți suplimentare despre SmashingMag:

• Patru moduri de a construi o aplicație mobilă
• Cum să construiți interfețe de utilizare oneste și să ajutați utilizatorii să ia decizii mai bune
• Păstrarea popularității aplicației dvs. pentru Android după lansare
• Listele de redare Spotify pentru a vă alimenta sesiunile de codare și proiectare
  

Înainte de OAuth2

OAuth2 a câștigat o luptă cu standardele în urmă cu câțiva ani. Este singurul protocol de autentificare acceptat de principalii furnizori. Google recomandă OAuth2 pentru toate API-urile sale, iar API-ul Graph de la Facebook acceptă numai OAuth2.

Cel mai bun mod de a înțelege OAuth2 este să ne uităm la ceea ce a apărut înainte și de ce aveam nevoie de ceva diferit. Totul a început cu Basic Auth.

Autentificare de bază

Schemele de autentificare se concentrează pe două întrebări cheie: Cine ești? Și poți dovedi asta?

Cel mai comun mod de a pune aceste două întrebări este cu un nume de utilizator și o parolă. Numele de utilizator spune cine ești, iar parola o dovedește.

Basic Auth a fost prima schemă de autentificare web. Sună amuzant, dar „Autentificarea de bază” era numele său real în specificația publicată pentru prima dată în 1999.

Basic Auth permite serverelor web să solicite aceste acreditări într-un mod pe care browserele le înțeleg. Serverul returnează un cod de răspuns HTTP de 401 (ceea ce înseamnă că este necesară autentificarea) și adaugă un antet special răspunsului, numit WWW-Authenticate , cu o valoare specială Basic .

Când browserul vede acest cod de răspuns și acest antet, afișează un dialog pop-up de conectare:

Partea grozavă despre Basic Auth este simplitatea sa. Nu trebuie să scrieți un ecran de conectare. Browserul se ocupă de toate acestea și trimite doar numele de utilizator și parola către server. De asemenea, oferă browserului șansa de a gestiona în mod special parola, fie reținându-l pentru utilizator, obținându-l de la un plugin terță parte sau luând acreditările utilizatorului din sistemul său de operare.

Dezavantajul este că nu obțineți niciun control asupra aspectului și simțului ecranului de conectare. Asta înseamnă că nu poți să-l stilizezi sau să adaugi noi funcționalități, cum ar fi „Ați uitat parola?” link sau o opțiune pentru a crea un cont nou. Dacă doriți mai multă personalizare, va trebui să scrieți un formular personalizat de conectare.

Formulare personalizate de conectare

Formularele personalizate de autentificare vă oferă tot controlul pe care vi l-ați putea dori. Scrieți un formular HTML și solicitați acreditările. Apoi trimiteți formularul și gestionați autentificarea în orice mod doriți. Obțineți control total: îl puteți modela, cere mai multe detalii sau adăuga mai multe link-uri.

Unele site-uri web, cum ar fi WordPress, folosesc un formular simplu pentru ecranul de conectare:

LinkedIn permite utilizatorilor să se conecteze sau să creeze un cont pe aceeași pagină, fără a fi nevoie să meargă la o altă parte a site-ului:

Conectarea pe bază de formular este foarte populară, dar are o problemă fundamentală majoră: utilizatorii trebuie să spună site-ului parola lor.

Păstrarea secretelor secrete

În cercurile de securitate, numim o parolă secretă. Este o informație pe care o ai doar tu și care dovedește că ești tu. Secretul poate fi, de asemenea, mai mult decât o parolă; vom vorbi mai multe despre asta puțin mai târziu.

Un site web poate lua toate măsurile de securitate din lume, dar dacă utilizatorul își împărtășește parola, atunci această securitate a dispărut. Hackerii au încălcat site-ul web Gawker în 2010, expunând parolele multor utilizatori. Deși aceasta a fost o problemă pentru Gawker, problema nu s-a oprit aici. Majoritatea oamenilor refolosesc parolele, așa că hackerii au preluat datele scurse de la Gawker și au încercat să se autentifice pe site-uri web mai importante, cum ar fi Gmail, Facebook și eBay. Oricine a folosit o parolă Gawker pentru lucruri mai importante a pierdut mult mai mult decât cea mai recentă bârfă despre sex tape a lui Hulk Hogan.

Asigurarea că utilizatorii dvs. nu reutiliza o parolă pentru mai multe conturi este prima jumătate a problemei - și este imposibil. Atâta timp cât oamenii trebuie să creeze diferite conturi pe tot Internetul, își vor reutiliza parolele.

A doua jumătate a problemei este stocarea în siguranță a parolelor.

Când cineva se conectează la aplicația ta, trebuie să-i verifici parola și asta înseamnă că ai nevoie de o copie pentru a o verifica. Puteți stoca undeva toate numele de utilizator și parolele într-o bază de date, dar acum riscați să pierdeți acele parole sau să fiți piratat. Cea mai bună practică este să utilizați o funcție hash, cum ar fi una dintre funcțiile SHA-2. Această funcție criptează datele într-un mod în care nu le puteți recupera niciodată, dar puteți replica criptarea: „parola mea” va fi hash la ceva de genul bb14292d91c6d0920a5536bb41f3a50f66351b7b9d94c804dfce8a96ca1051f2 fiecare dată.

Și acum am plecat în iarba înaltă: vă spun cum să implementați protocoalele criptografice. În continuare, va trebui să explic cum să adaugi o sare la datele tale și ce manuale să citești despre atacurile man-in-the-middle. Tot ce ai vrut să faci este să scrii o aplicație, iar acum trebuie să devii un expert în securitate. Trebuie să facem un pas înapoi.

OAuth2

Probabil că nu ești un expert în securitate. Chiar dacă ai fi, tot nu aș avea încredere în tine cu parola mea. OAuth2 vă oferă o modalitate mai bună.

De exemplu, folosesc Spotify pe iPad-ul meu. Plătesc companiei 10 USD pe lună pentru a asculta muzică. Spotify îmi oferă acces doar pe trei dispozitive, așa că am nevoie de o parolă pentru a mă asigura că nimeni altcineva nu-mi folosește contul. Contul meu Spotify nu este o mare problemă de securitate. A fi piratat nu ar fi sfârșitul lumii, dar compania are cardul meu de credit, așa că vreau să mă asigur că sunt în siguranță.

Aproape că mă conectez la Spotify, așa că nu vreau să-mi creez un alt cont și trebuie să-mi amintesc altă parolă. Spotify îmi oferă o opțiune mai bună:

Îmi pot folosi contul de Facebook pentru a mă autentifica. Când ating acel buton, Spotify mă trimite pe facebook.com și mă conectez acolo. Acesta poate părea un mic detaliu, dar este cel mai important pas al întregului proces.

Programatorii Spotify ar fi putut să scrie ei înșiși un formular de conectare și apoi să-mi trimită numele de utilizator și parola la Facebook cu un API back-end, dar există două mari motive pentru care nu vreau să facă asta:

• Nu am încredere în Spotify cu parola mea de Facebook. Folosesc Facebook pentru a intra în legătură cu prietenii și nu vreau să fiu piratat. Nu am încredere că Spotify va gestiona corect parola. De asemenea, nu am încredere că va evita tentația de a face ceva amuzant cu el. Poate ar încerca să-l depoziteze pentru a-l putea folosi mai târziu. Poate că are o eroare care îl scrie într-un fișier undeva înainte de a-l trimite pe Facebook, așa că un hacker l-ar putea lua. Îmi pare rău, Spotify; Doar că nu sunt genul de încredere.
• Nu vreau să-l las pe Spotify să facă totul. Vreau ca Spotify să redea muzică. Nu vreau să posteze pe pereții prietenilor mei când ascult Spice Girls. De asemenea, nu vreau să-l las să-mi descarce lista de prieteni și să îi deranjez să se alăture Spotify. Dacă i-am dat Spotify parola mea de Facebook, atunci s-ar putea conecta ca mine pe Facebook; ar putea face orice aș putea face eu.

Există, de asemenea, două mari motive pentru care Spotify nu vrea să facă asta:

• Facebook are mai multe opțiuni pentru a mă conecta ... Mă pot conecta fie cu numele de utilizator și parola, fie cu aplicația Facebook. Îmi pot recupera parola și de pe Facebook sau pot obține ajutor pe care Spotify nu mi-l poate oferi. Dacă aș da doar parola mea Spotify, nu aș primi niciuna dintre aceste opțiuni.
• Secretul meu poate să nu fie o parolă. . O parolă este suficientă securitate pentru contul meu Spotify de 10 USD pe lună, dar s-ar putea să nu fie suficientă pentru banca mea sau ceva și mai important. Există o mulțime de alte secrete pe care le-aș putea oferi: s-ar putea să am un smart card sau s-ar putea să trăiesc într-un film Misiune imposibilă și să folosesc un scaner retinian.

Nu sunt într-un film Misiune imposibilă, dar în lumea reală, multe companii folosesc autentificarea cu doi factori, cum ar fi o parolă plus altceva. Cea mai comună metodă este să vă folosiți telefonul. Când vrei să te autentifici, compania îți trimite un text cu un cod special care durează câteva minute; apoi introduceți codul sau utilizați o aplicație pentru a-l introduce.

Acum compania este sigură că nimeni nu se poate conecta la contul tău fără telefonul tău. Dacă cineva vă fură parola, tot nu se poate conecta. Atâta timp cât nu vă pierdeți telefonul, totul este în siguranță.

Facebook nu este singurul furnizor OAuth2. Când mă conectez la Quora cu contul meu Google, Google îmi spune ce ar dori să facă Quora și mă întreabă dacă este în regulă:

S-ar putea să îmi permită Quora să-mi vadă adresa de e-mail și datele de bază ale profilului, dar nu vreau să-mi gestioneze contactele. OAuth2 îmi arată tot accesul pe care Quora îl dorește, permițându-mi să aleg și să aleg la ce acord acces.

Deci, acestea sunt avantajele OAuth2. Să vedem cum funcționează.

Cum funcționează OAuth2

Facebook, Google și majoritatea celorlalți furnizori OAuth2 tratează clienții nativi în mod diferit față de clienții web. Clienții nativi sunt considerați mai siguri și primesc jetoane și jetoane de reîmprospătare care pot dura luni de zile. Clienții web primesc jetoane mult mai scurte, care de obicei expiră atunci când utilizatorul închide browserul sau nu a făcut clic pe site-ul web o perioadă.

În ambele cazuri, procesul de conectare este același. Diferența constă în cât de des trebuie să treacă utilizatorul prin ea.

Conectarea la OAuth2 urmează acești pași generali:

1. Utilizatorul încearcă să facă ceva care necesită autentificare. Acest lucru ar putea fi la fel de simplu ca deschiderea unei aplicații sau clic pe butonul „Conectare”.
2. Aplicația sau site-ul web stabilește că utilizatorul nu s-a conectat încă și începe procesul de conectare. Face acest lucru deschizând o pagină web și trimițând-o la o adresă URL specială la Facebook, Google sau orice alt site web care vă oferă OAuth2.

Deschiderea unei noi ferestre de browser pentru furnizorul OAuth2 este un pas crucial. Acesta este ceea ce permite furnizorilor să-și arate propriile formulare de conectare și să ceară fiecărui utilizator orice informații de conectare de care au nevoie. Majoritatea aplicațiilor fac acest lucru cu o vizualizare web încorporată.

Împreună cu adresa URL de conectare a furnizorului, trebuie să trimiteți niște parametri URL care îi spun furnizorului cine sunteți și ce doriți să faceți:

• client_id Acesta îi spune furnizorului OAuth2 care este aplicația dvs. Va trebui să vă înregistrați aplicația din timp pentru a obține un ID de client.
• redirect_uri Aceasta îi spune furnizorului unde doriți să mergeți când ați terminat. Pentru un site web, acesta ar putea fi înapoi la pagina principală; o aplicație nativă ar putea accesa o pagină care închide vizualizarea web.
• response_type Acesta îi spune furnizorului ce vrei înapoi. În mod normal, această valoare este fie token , pentru a indica faptul că doriți un simbol de acces, fie code , pentru a indica faptul că doriți un cod de acces. De asemenea, furnizorii pot extinde această valoare pentru a furniza alte tipuri de date.
• domeniul de scope Acesta îi spune furnizorului ce dorește să acceseze aplicația dvs. Acesta este modul în care Google știe că Quora solicită acces pentru a vă gestiona contactele. Fiecare furnizor are un set diferit de domenii.

Există câmpuri suplimentare care pot adăuga mai multă securitate sau pot ajuta la stocarea în cache. Unii furnizori ajung să adauge și mai multe câmpuri, dar acestea patru sunt cele importante.

Odată ce aplicația dvs. deschide vizualizarea web, furnizorul preia controlul. S-ar putea să solicite doar un nume de utilizator și o parolă simple sau ar putea prezenta mai multe ecrane care solicită orice, de la numele profesorului tău preferat până la numele de fată al mamei tale. Asta depinde de ei. Partea importantă este că, atunci când furnizorul termină, acesta vă va redirecționa înapoi și vă va oferi un simbol.

Totul este despre jetoane

Când procesul se încheie, furnizorul vă va oferi un simbol și un tip de simbol. Există două tipuri de jetoane: jetoane de acces și jetoane de reîmprospătare. Tipul de client pe care îl aveți va determina ce tipuri de jetoane aveți voie să solicitați.

Când mă conectez la aplicația mea Spotify, pot rămâne conectat luni de zile, deoarece se presupune că telefonul meu este folosit doar de mine. Facebook are încredere în aplicația Spotify pentru a gestiona jetoanele, iar eu am încredere în aplicația Spotify pentru a nu pierde jetoanele.

Când indicativul de acces expiră (de obicei, în una sau două ore), Spotify poate folosi jetonul de reîmprospătare pentru a obține unul nou.

Jetonul de reîmprospătare durează luni de zile. În acest fel, trebuie să mă conectez pe telefon doar de câteva ori pe an. Dezavantajul este că, dacă pierd acel token de reîmprospătare, altcineva ar putea folosi contul meu luni de zile. Jetonul de reîmprospătare este atât de important încât iOS oferă un breloc pentru token-uri, unde se asigură că le criptează și le stochează în siguranță.

Utilizarea OAuth2 într-o aplicație web funcționează în același mod. În loc să utilizați o vizualizare web, puteți deschide cererea de conectare OAuth2 într-un cadru, un iframe sau o fereastră separată. De asemenea, îl puteți deschide pe pagina curentă, dar acest lucru v-ar face să pierdeți toată starea aplicației JavaScript ori de câte ori cineva trebuie să se autentifice.

Când mă conectez la Quora cu browserul meu web, nu primesc un jeton de reîmprospătare. Ei doresc ca simbolul să expire și să mă solicite să mă conectez din nou când ies din browser sau chiar plec la prânz. Clienții neîncrezători nu pot reîmprospăta indicativul, deoarece nu pot fi de încredere să păstreze indicativul de reîmprospătare important. Este mai sigur, dar mai puțin convenabil, deoarece vă vor solicita să vă conectați din nou mult mai des.

Utilizarea OAuth2 în aplicația dvs

Acum știți cum funcționează OAuth2, dar probabil că nu doriți să implementați propriul dvs. client OAuth2. Puteți citi întreaga specificație OAuth 2.0 de 75 de pagini dacă aveți probleme cu somnul, dar nu este necesar. Există câteva biblioteci grozave pe care le puteți utiliza.

iOS are suport încorporat pentru OAuth2. Corrina Krych are un tutorial foarte util despre utilizarea OAuth 2.0 cu Swift. Vă arată cum să obțineți un token, cum să integrați vizualizările în aplicația dvs. și unde să vă stocați token-urile.

Android are și suport încorporat pentru OAuth2. Trebuie să recunosc că nu sunt la fel de familiarizat cu el pentru că mă concentrez pe iOS, dar există câteva secțiuni bune în documentație pentru a vă arăta exemple și câteva biblioteci open-source pentru a face și mai ușor.

JavaScript nu are suport încorporat pentru OAuth2, dar există clienți pentru toate bibliotecile principale JavaScript. React acceptă pe deplin OAuth2. AngularJS are suport terță parte pentru OAuth2.0 pentru multe proiecte. Chiar am scris unul dintre ele.

Odată ce aveți un client OAuth2, va trebui să alegeți un furnizor.

În cine ai încredere?

Principala presupunere aici este că am mai multă încredere în Facebook decât în ​​Spotify. Nu am niciun motiv bun pentru asta. Facebook nu își face publică securitatea internă și nu există nicio modalitate bună de a o audita. Nici Spotify. Nu există rapoarte pentru consumatori pentru securitatea OAuth2. Practic am încredere în Facebook pentru că este mai mare. Am încredere în Facebook pentru că au alții.

De asemenea, am mai multă încredere în Facebook de fiecare dată când dau clic pe butonul „Conectează-te cu Facebook”. Dacă Facebook îmi pierde parola, atunci hackerii vor avea acces nu doar la contul meu de Facebook, ci și la contul meu Spotify și la orice alt serviciu la care m-am conectat cu contul meu de Facebook. Avantajul este că există un singur loc în care trebuie să-mi resetați parola pentru a remedia problema.

Nu trebuie să am încredere în Facebook, dar trebuie să am încredere în cineva. Cineva trebuie să mă autentifice. Trebuie să aleg furnizorul în care am încredere.

Alegerea unui furnizor OAuth2

Wikipedia menține o listă de furnizori OAuth, dar nu ți-ar păsa de majoritatea acestora. Cele mai mari sunt Facebook și Google. Poate doriți să vă uitați și la Amazon sau Microsoft.

Toate cele patru sunt mari și ușor de integrat. Facebook oferă instrucțiuni pentru înregistrarea unei aplicații. Google are pași similari. Ideea de bază este că creați un cont de dezvoltator și apoi creați un ID de aplicație. Furnizorul vă oferă apoi un ID de client pe care îl puteți utiliza pentru a face solicitări.

De asemenea, puteți alege mai mulți furnizori. Quora vă permite să vă conectați cu Facebook sau Google; deoarece ambele folosesc OAuth2, puteți folosi același cod pentru ambele.

Ce lipsește din OAuth2

OAuth2 face o treabă foarte bună de a rezolva o problemă complexă, dar îi lipsesc câteva lucruri:

• Standardul nu este complet standard. Nu am reușit niciodată să scriu un singur client OAuth2 care să se poată conecta atât la Facebook, cât și la Google fără câteva declarații if . Fiecare interpretează specificația în mod diferit și există puține detalii diferite pentru fiecare. De asemenea, au întotdeauna idei diferite cu privire la domeniile de aplicare să ofere. Utilizarea unei biblioteci pentru a se integra cu OAuth2 ajută foarte mult la această problemă, dar nu va fi niciodată 100% transparentă în codul aplicației dvs.
• Deconectarea este dificilă. . Fiecare aplicație sau site web care utilizează OAuth2 are un buton de deconectare, dar majoritatea vor uita pur și simplu jetoanele fără a le invalida. Aplicația va uita de toate jetoanele dvs. actuale și va permite altcuiva să se conecteze, dar jetoanele dvs. sunt încă valabile. Dacă un hacker ți-a furat jetonul, l-ar putea folosi și să se conecteze ca tine.

Există o specificație separată pentru invalidarea token-urilor OAuth2, dar nu a fost preluată de mulți dintre furnizorii importanți. OAuth2 nu oferă o modalitate de recuperare dacă un hacker obține indicativul de reîmprospătare; chiar dacă puteți șterge copia locală a jetonului, hackerul o va avea în continuare. Mulți furnizori vă oferă o modalitate de a vă suspenda contul, dar nu există o modalitate standard de a face acest lucru.

În apărarea OAuth2, aceasta este o problemă dificilă, deoarece mulți furnizori folosesc criptografia cu cheie publică pentru a crea token-uri fără stat. Aceasta înseamnă că serverul nu își amintește jetoanele pe care le-a creat, așa că nu le poate uita mai târziu.

Cealaltă problemă majoră cu OAuth2 este că sunteți dependent de furnizorul dvs. Când Facebook se defectează, face și butonul „Conectează-te cu Facebook” din aplicația ta. Dacă Google decide să înceapă să vă taxeze pentru a accepta OAuth2 sau vă cere să vă împărțiți profitul cu acesta, nu puteți face nimic. Aceasta este sabia cu două tăișuri a încrederii într-un furnizor: fac multe pentru tine, dar au control asupra utilizatorilor tăi.

OAuth2 conduce lumea

Chiar și cu câteva funcții lipsă și o dependență mare, OAuth2 este încă o alegere excelentă. Le permite utilizatorilor să se conecteze cu ușurință la aplicația dvs., să nu fie nevoiți să-și amintească o parolă pentru fiecare site web și să aibă încredere în securitatea dvs. OAuth2 este o alegere foarte populară. Domină industria. Niciun alt protocol de securitate nu se apropie de adoptarea OAuth2.

Acum știi de unde vine OAuth2 și cum funcționează. Faceți alegeri inteligente despre cine să aveți încredere, nu mai citiți articole despre stocarea în siguranță a parolelor criptate și petreceți mai mult timp scriind aplicația uimitoare.