OAuth2 este un cadru de autorizare care permite aplicațiilor să primească acces limitat la conturile de utilizator prin HTTP, ca Facebook, GitHubși DigitalOcean. Funcționează prin delegarea identității utilizatorului către serviciul care găzduiește contul de utilizator și către autoritatea de autorizare. aplicații terță parte având acces la cont utilizator. OAuth2 oferă fluxuri de autorizare pentru desktop, aplicații web și dispozitive mobile.

Acest ghid de informații se adresează dezvoltatorilor de aplicații și oferă o prezentare generală a rolurilor OAuth2, tipuri de permisiuni autorizate, situatii si fluxuri utilizate.

Să începem cu rolurile OAuth2!

Roluri

oauth definește 4 roluri:

• Proprietarul resursei
• Client
• server de resurse
• Server de autorizare

Vom discuta fiecare rol în următoarele subsecțiuni.

Proprietarul resursei: Utilizator

Proprietarul resursei este utilizatorul care folosește aplicația pentru a accesa contul. Accesul aplicației la contul utilizatorului este limitat la zona permisiunilor de autorizare (de exemplu, citire sau scriere).

Server de resurse/autorizare: API

Serverul de resurse stochează conturi de utilizator securizate, iar serverul de autorizare verifică identitatea utilizatorului și apoi emite jetoane de acces la aplicație.

Din punctul de vedere al dezvoltatorilor de aplicații, API-ul serviciului îndeplinește atât rolul de server de resurse, cât și de server de autorizare. Vom redirecționa către ambele roluri combinate, atât rolul de serviciu, cât și rolul API.

Client: Aplicație

Clientul este aplicația care dorește să acceseze contul utilizatorului. Înainte de a face acest lucru, trebuie să fie autorizat de utilizator, iar autorizarea trebuie să fie verificată de API.

Acum că aveți o idee despre rolurile OAuth, să aruncăm o privire la o diagramă a modului în care acestea interacționează, practic, unele cu altele:

Iată o explicație mai detaliată a pașilor din diagramă:

1. Aplicația cere utilizatorului permisiunea de a accesa resursele serviciului
2. Dacă utilizatorul a permis cererea, atunci aplicația primește acordarea de autorizare
3. Aplicația solicită un token de acces de la serverul de autorizare (service API) furnizând autentificarea și acordând autorizație
4. Dacă identitatea aplicației este autentică și acordarea de autorizare este validă, atunci serverul de autorizare (API) emite un jeton de acces la aplicație. Autorizare finalizată.
5. Aplicația solicită o resursă de la un server de resurse (API) și oferă un token de acces pentru autentificare
6. Dacă jetonul de acces este valid, serverul de resurse (API) transmite resursa aplicației

Fluxul real al acestui proces va diferi în funcție de tipul de acordare de autorizare utilizat - aceasta este o idee generală. Vom studia tipuri diferite prevedere în secțiunea următoare.

Înregistrarea aplicației

Inainte de folosind OAuthîn aplicația dvs., trebuie să vă înregistrați aplicația la serviciu. Acest lucru se face prin intermediul formularului de înregistrare din secțiunea Dezvoltator sau API a site-ului web de servicii unde veți furniza următoarea informație(și probabil informatii detaliate despre aplicația dvs.):

• numele aplicatiei
• Site de aplicare
• URI de redirecționare sau URL de apel invers

URI-ul de redirecționare este utilizat în cazul în care serviciul va redirecționa utilizatorul după ce aplicația dvs. este autorizată sau refuzată, de unde partea aplicației dvs. care va gestiona codurile de autorizare sau jetoanele de acces.

ID client și cod secret client

Odată ce aplicația dvs. este înregistrată, serviciul va emite o „acreditare de client” sub forma unui ID de client și a unei parole de client. ID-ul clientului este un șir public care este utilizat de API-ul serviciului pentru a identifica aplicația și este, de asemenea, folosit pentru a construi adrese URL de autorizare care sunt prezentate utilizatorilor. Codul de acces al clientului este utilizat pentru a autentifica aplicația la API-ul serviciului atunci când aplicația solicită acces la un cont de utilizator și trebuie păstrat secret între aplicație și API.

Acordarea Autorizatiei

LA flux de protocol abstract mai sus, primii patru pași descriu obținerea unui acord de autorizare și a unui jeton de acces. Tipul de acordare a autorizației depinde de metoda utilizată de aplicație pentru a solicita autorizarea și de tipurile de grant acceptate de API. OAuth 2 definește 4 tipuri de grant, fiecare dintre acestea fiind util în diferite situații:

• Cod de autorizare: utilizat împreună cu aplicațiile server-side

• Implicit (ascuns): utilizat împreună cu aplicații mobile sau aplicații web (aplicații care rulează pe dispozitivul utilizatorului)

• : utilizat împreună cu aplicații de încredere, cum ar fi cele deținute de serviciul însuși

• Acreditările clientului: utilizat cu aplicațiile de acces API

Vom descrie acum tipurile de granturi mai detaliat, cazurile de utilizare și fluxurile acestora, în secțiunile următoare.

Tip de grant: Cod de autorizare

Tipul de acordare a codului de autorizare este cel mai utilizat, deoarece este optimizat pentru aplicațiile de pe server unde sursă nu este afișat public și codul secret al clientului poate fi păstrat confidențial. Acesta este un flux de redirecționare, ceea ce înseamnă că aplicația trebuie să poată interacționa cu agentul utilizator (adică browserul utilizatorului) și să primească codurile de autorizare API care sunt direcționate prin agentul utilizator.

Pasul 1: Legătura codului de autorizare

• https://cloud.digitalocean.com/v1/oauth/authorize - punctul final de autorizare API
• response_type=code - specifică faptul că aplicația dvs. solicită furnizarea unui cod de autorizare
• client_id=CLIENT_ID - identificatorul clientului aplicației (valoarea prin care API-ul determină aplicația)
• redirect_uri=CALLBACK_URL - locul unde serviciul redirecționează browserul după ce este furnizat codul de autorizare
• scope=read - definește nivelul de acces pe care îl solicită aplicația

Când un utilizator face clic (face clic pe) un link, trebuie mai întâi să se conecteze (se conecteze) la serviciu pentru a-și verifica identitatea (cu excepția cazului în care, desigur, este deja autentificat). Serviciul le va cere apoi confirmarea pentru a permite sau a refuza accesul aplicației la contul lor. Iată un exemplu de solicitare de acces la un cont de către o aplicație:

Autorizație de aplicare

Prezentare generală a permisiunilor(permisiuni)

• Citind

Autorizați cererea interzice

Dacă utilizatorul face clic pe „Authorize Application”, serviciul redirecționează browser-ul către URI-ul de redirecționare al aplicației care a fost specificat la înregistrarea clientului, împreună cu un cod de autorizare. Redirecționarea va arăta astfel (presupunând că adresa aplicației este „dropletbook.com”):

Pasul 4: aplicația primește un token de acces

Aplicația solicită un jeton de acces de la API prin transmiterea unui cod de autorizare la punctul final al jetonului API, împreună cu informatii detaliate despre identificare, inclusiv codul secret al clientului. Iată un exemplu de solicitare POST către punctul final al jetonului DigitalOcean:

Pasul 5: aplicația primește un token de acces

("access_token":"ACCESS_TOKEN","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":( "name":"Mark E. Mark","email":" [email protected] «}}

Acum aplicația este autorizată! Poate folosi jetonul pentru a accesa contul utilizatorului prin API-ul serviciului, cu restricții de acces până când tokenul expiră sau este revocat. Dacă a fost transmis un token de reîmprospătare, atunci acesta poate fi utilizat pentru a solicita noi token-uri de acces dacă tokenul original a expirat.

Tip de grant: Implicit (ascuns)

Tipul de grant implicit este folosit pentru aplicatii mobileși aplicații web (adică aplicații care rulează într-un browser) în care confidențialitatea codului de acces al clientului nu este garantată. Tipul de acordare implicit este, de asemenea, redirecționare bazată pe flux, dar jetonul de acces este dat browserului pentru a fi transmis aplicației, astfel încât să poată fi accesat atât de utilizator, cât și de alte aplicații de pe dispozitivul utilizatorului. De asemenea, acest flux nu autentifică identitatea aplicației și se bazează pe URI-ul de redirecționare (care a fost înregistrat la serviciu) pentru a servi acestui scop.

Tipul de acordare implicită nu acceptă jetoane de reîmprospătare.

Fluxul de acordare implicită funcționează în principiu astfel: utilizatorului i se solicită să autorizeze aplicația, apoi serverul de autorizare transmite jetonul de acces înapoi browserului, care la rândul său îl transmite aplicației. Dacă sunteți interesat de detalii, citiți mai departe.

Cu tipul de acordare implicit, utilizatorului i se oferă un link de autorizare care solicită un token de la API. Acest link arată ca un link de cod de autorizare, cu excepția faptului că solicită un token în loc de un cod (rețineți că tipul de solicitare este „token”):

Notă

Când un utilizator face clic pe un link, trebuie mai întâi să se conecteze la serviciu pentru a-și autentifica identitatea (dacă nu este deja autentificat). Serviciul le va solicita apoi să permită sau să interzică accesul aplicației la contul lor. . Iată un exemplu de solicitare de acces la un cont de către o aplicație:

Autorizație de aplicare

Thedropletbook dorește permisiunea de a vă accesa contul

Prezentare generală a permisiunilor(permisiuni)

• Citind

Autorizați cererea interzice

Putem vedea că „Thedropletbook App” cere permisiunea de a citi contul „ [email protected] ”.

Pasul 3: Browserul primește un token de acces cu URI de redirecționare

Pasul 4: Browserul urmează URI-ul de redirecționare

Browserul urmează redirecționarea URI, dar păstrează simbolul de acces.

Pasul 5: Aplicația trimite jetonul de acces la scriptul de preluare

Aplicația returnează o pagină care conține un script care poate extrage un token de acces din întregul URI de redirecționare pe care l-a stocat browserul.

Pasul 6: Jetonul de acces este transmis aplicației

Browserul rulează scriptul furnizat și transmite jetonul de acces preluat aplicației.

Notă: DigitalOcean nu acceptă timp oferit un tip de acordare implicită, astfel încât linkul să trimită către un server de autorizare imaginar la „oauth.example.com”.

Tip de grant: Proprietarul resursei parolei acreditării

Cu tipul de acordare a proprietarului resursei de parolă de autentificare, utilizatorul oferă acreditările de serviciu (nume de utilizator și parolă) direct în aplicație, care le folosește pentru a obține un token de acces de la serviciu. Acest tip de grant ar trebui să fie activat pe serverul de autorizare numai dacă alte fluxuri nu sunt viabile. De asemenea, ar trebui să fie utilizat dacă aplicația este de încredere de către utilizator (de exemplu, dacă aparține unui serviciu sau sistem de operare calculator).

Fluxul parolelor de acreditări

După ce utilizatorul și-a furnizat acreditările către aplicație, aplicația trebuie să solicite un token de acces de la serverul de autorizare. Solicitarea POST ar putea arăta cam așa:

Dacă acreditările utilizatorului sunt validate, serverul de autorizare returnează un token de acces la aplicație. Acum aplicația este autorizată!

Notă: DigitalOcean nu acceptă în prezent tipul de parolă de autentificare, așa că linkul indică un server de autorizare imaginar la „oauth.example.com”.

Tip de grant: Acreditările clientului

Tipul de acordare a acreditării clientului oferă unei aplicații o modalitate de a le accesa cont personal serviciu. Exemple de cazuri în care acest lucru ar putea fi util dacă o aplicație dorește să-și actualizeze descrierea înregistrată sau URI de redirecționare sau să acceseze alte date stocate într-un cont de serviciu prin intermediul API-ului.

Fluxul de acreditări ale clientului

Aplicația solicită un token de acces trimițând acreditările sale, ID-ul de client și codul de acces al clientului, către serverul de autorizare. Exemplu Solicitare POST ar putea arata asa:

Dacă acreditările clientului sunt validate, serverul de autorizare returnează un token de acces la aplicație. De acum încolo, aplicația are voie să-și folosească propriul cont!

Notă: DigitalOcean nu acceptă în prezent tipul de acordare a acreditării clientului, așa că linkul indică un server de autorizare imaginar la „oauth.example.com”.

Exemplu de jeton de acces

Odată ce o aplicație are un token de acces, poate folosi tokenul pentru a accesa contul utilizatorului prin API, cu restricții de acces, până când tokenul expiră sau este revocat.

Iată un exemplu de utilizare a cererii API răsuci. Rețineți că include un token de acces:

curl -X POST -H "Autorizare: Purtător ACCESS_TOKEN" "https://api.digitalocean.com/v2/$OBJECT" ;

Presupunând că jetonul de acces este valid, API-ul va procesa cererea în conformitate cu acesta specificații. Dacă jetonul de acces a expirat sau in caz contrar este invalid, API-ul va returna o eroare „bad_request”.

Actualizează fluxul de jetoane

Odată ce un jeton de acces a expirat, folosirea acestuia pentru a face o solicitare API va avea ca rezultat o eroare „Invalid token”. În această etapă, dacă un jeton de reîmprospătare a fost inclus în cerere când a fost emis jetonul de acces inițial, acesta poate fi utilizat pentru a solicita un jeton de acces nou de la serverul de autorizare. Aici Exemplu POST o solicitare care folosește un jeton de reîmprospătare pentru a obține un nou jeton de acces:

Concluzie

Aceasta încheie ghidul nostru pentru OAuth 2. Acum ar trebui să înțelegeți bine cum funcționează OAuth 2 și când ar trebui utilizat un anumit flux de autorizare.

Dacă doriți să aflați mai multe despre OAuth 2, consultați aceste resurse utile:

• Cum să utilizați autentificarea OAuth cu DigitalOcean ca utilizator sau dezvoltator
• Cum să utilizați API-ul DigitalOcean versiunea 2
• Cadrul de autorizare

Un protocol popular care permite social servicii să se integreze între ele și oferă cale sigura schimb valutar informatii personale. OAuth poate conecta 2 servicii, fiecare cu propriile sale baza de utilizatori- în ei mă aflu acest caz Eu numesc „social”. Când începeți să lucrați cu OAuth, prima impresie este că protocolul este foarte complicat și redundant. În acest articol, voi încerca să explic elementele de bază ale OAuth limbajul uman.

Exemplu de autorizare încrucișată

• consumator: consumator; script pentru procesarea formularului de import de contacte într-o rețea socială.
• Furnizor de servicii: furnizor de date; Gmail care conține date din agenda de adrese de interes pentru Consumator.
• utilizator: Un utilizator care are un cont atât la Consumator, cât și la Furnizorul de servicii.
• resursă protejată: date personale; contacte din agenda de adrese de pe Gmail (adică resursele furnizorului de servicii).
• API-ul furnizorului: Un API GMail care permite oricărui script să obțină contacte din agenda GMail.

Prin ce diferă OAuth de OpenID?

1. OpenID este un protocol pentru înregistrarea accelerată. OpenID permite utilizatorului să obțină un cont pe orice serviciu fără a introduce o parolă dacă este deja înregistrat în altă parte pe Internet. (Și apoi puteți intra în serviciu fără a introduce o parolă, fiind autorizat „undeva”.) De exemplu, dacă aveți un cont Yandex, îl puteți folosi pentru a vă „conecta” la orice serviciu care acceptă autorizarea OpenID.
2. OAuth este un protocol pentru acces autorizat la un API terță parte. OAuth permite unui script Consumer să obțină acces limitat API la datele unui Furnizor de servicii terță parte dacă Utilizatorul acordă aprobarea. Acestea. este un mijloc de a accesa API-ul.

Schița acestui articol

1. Să luăm în considerare problemele care apar în timpul implementării „manuale” a autorizării încrucișate.
2. Să vorbim despre ce este o „aplicație” și cine este un Consumator.
3. Să atingem elementele de bază ale criptografiei.
4. Să notăm aplicația demo pe care o vom scrie în acest articol.
5. Să decidem asupra unui server OAuth de testare pe care vom experimenta.
6. Să parcurgem toți pașii protocolului OAuth și să furnizăm sursele de script.

Despre inventarea bicicletelor

Mai întâi, să scriem formularul de importare a contactelor GMail în sine: Apoi, le vom cere dezvoltatorilor GMail să facă astfel încât, atunci când un utilizator navighează la URI /auth.php, să i se ofere un formular de autorizare (în lumea noastră de ciclism, Gmail este scris în PHP). După introducerea cu succes a parolei, utilizatorul trebuie redirecționat către site-ul a cărui adresă URL este specificată în parametrul retpath. De asemenea, o cheie secretă trebuie să fie transmisă în URL, care poate fi deja folosită pentru a accesa API-ul GMail.

Deci, după introducerea parolei, utilizatorul se va întoarce pe site-ul nostru la următoarea adresă: Și vom apela la API-ul GMail din scriptul /import.php, îi vom trece cheia Y49xdN0Zo2B5v0RR și vom încărca contactele: Ei bine, haideți acum numărați grebla (pentru că denivelările va fi prea târziu pentru a număra).

Primul rake: înlocuirea adresei de retur retpath

Cea de-a doua grebla: „ascultarea cu urechea” a cheii secrete

Al treilea rake: prea multe redirecționări

Rake Four: Identificarea slabă a consumatorului

Fundația OAuth

Aplicație = Consumer + acces API

Token = Cheie + Secret

Așadar, dacă Consumatorul și Furnizorul sunt de acord într-un fel între ei cu privire la Secretul Partajat, ei pot schimba în mod deschis cheile corespunzătoare (Cheie) în URL fără teama că interceptarea acestor chei va fi periculoasă. Dar cum să protejăm adresa URL cu cheie de falsificare?

Mesaj = Document + Semnătură digitală

În mod similar, la un bloc de date este adăugată o semnătură digitală, care atestă că persoana care a generat aceste date nu se uită la alta. O semnătură digitală nu criptează un document, doar îi garantează autenticitatea! Semnarea permite același Secret Partajat, care este cunoscut destinatarului și expeditorului, dar nimeni altcineva.

Cum functioneaza? Lăsați $sharedSecret-ul nostru = 529AeGWg și îl șoptăm la urechea părții care o primește. Dorim să transmitem mesajul „Telefonul meu este 1234567” cu protecție garantată împotriva falsificării de către un atacator.

1. Consumatorul adaugă o semnătură digitală la mesaj, vedere generala- $transfer = $mesaj . "-" . md5($mesaj . $sharedSecret); // $transfer = "Telefonul meu este 1234567" . "-" . md5(„Telefonul meu este 1234567” . „529AeGWg”)
2. Furnizorul de servicii preia datele, le împarte înapoi în 2 părți - $message și $signature - și face exact aceeași operațiune: $signatureToMatch = md5($message . $sharedSecret); // $signatureToMatch = md5("Telefonul meu este 1234567" . "529AeGWg"); Apoi, rămâne doar să comparați valoarea rezultată $signatureToMatch cu ceea ce a fost în datele primite $signature și să raportați un fals dacă valorile nu s-au potrivit.

Demonstrație a modului în care funcționează OAuth cu o aplicație simplă

1. Script care implementează partea clientului protocol. Am scris un script PHP atât de mic (link la arhiva zip). Acesta este un widget care poate fi inserat în site-urile PHP.
2. Un server de testare OAuth unde putem experimenta. În acest scop, este convenabil să utilizați RuTwit: există o pagină http://rutvit.ru/apps/new , care vă permite să adăugați o aplicație de testare în 30 de secunde. (Apropo, URL-ul de returnare din formular poate fi omis - îl transmitem în continuare din scriptul de testare.)

Puteți încorpora acest widget pe orice site PHP prin simpla copiere a codului său și modificarea aspectului. Sunt afișate toate tweet-urile din serviciul RuTwit marcate cu eticheta hash specificată și este, de asemenea, posibil să adăugați tweet-uri noi (aici intră în joc OAuth). Widgetul utilizează API-ul RuTwit și autorizarea OAuth, care, apropo, sunt identice cu standardul API-ul Twitter. Puteți rula acest script pe serverul dvs. de testare. Pentru a face acest lucru, trebuie să efectuați trei pași:

1. Descărcați codul de script și implementați-l în orice director convenabil de pe serverul web.
2. Înregistrați o nouă aplicație de testare pe serverul OAuth.
3. După înregistrarea aplicației, înlocuiți parametrii OA_CONSUMER_KEY și OA_CONSUMER_SECRET din script cu valorile primite de la server.

Înregistrarea și setările aplicației

După înregistrarea aplicației, vi se dau 5 parametri care sunt necesari pentru a funcționa cu OAuth. Iată cum ar putea arăta:

Aici cheia consumatorului și secretul consumatorului sunt un fel de „login + parolă” a aplicației dvs. (vă amintiți conversația de mai sus despre token-uri? acesta este doar unul dintre ele). Permiteți-mi să vă reamintesc că un secret de consumator este un secret partajat, cunoscut doar de expeditor și destinatar, dar de nimeni altcineva. Cele 3 valori rămase specifică adrese URL de servicii, a căror semnificație o vom lua în considerare acum.

OAuth = Preluare Token de solicitare + Redirecționare către Autorizare + Preluare Token de acces + API de apelare

Și am descoperit o serie de probleme de securitate, ceea ce sugerează că ar trebui să existe mai multe provocări. Iată ce se întâmplă în OAuth: mai multe solicitări intermediare sunt adăugate din scriptul Consumer către Furnizor, care operează cu token-uri. Să aruncăm o privire la ele.

1. Procesarea trimiterii formularului. Nu face parte din OAuth, ci face parte din aplicația noastră. Înainte de a accesa API-ul Furnizorului, trebuie să primim o comandă pentru această acțiune de la utilizator. Iată un exemplu de astfel de comandă:
2. Preluare token de solicitare (cerere internă).
   • Apelează scriptul Consumer Solicitați adresa URL a simbolului Furnizor: de exemplu, api.rutvit.ru/oauth/request_token . Solicitarea transmite cheia Consumatorului - „autentificare aplicație”, iar cererea în sine este semnată folosind Secretul Consumatorului - „parola aplicației”, care o protejează de fals.
   • Ca răspuns, Furnizorul generează și returnează un token plin de gunoi numit Request Token. Vom avea în continuare nevoie de el, așa că trebuie să îl salvăm undeva - de exemplu, în variabila de sesiune $S_REQUEST_TOK.
3. Redirecționare către Autorizare (prin redirecționare browser). Acum aplicația noastră are un Request Token unic. Este necesar să obțineți permisiunea utilizatorului pentru a utiliza acest token, de exemplu. intreaba-l autorizați Request Token.
   • Consumatorul redirecționează browserul către un anumit Autorizați adresa URL Furnizor: de exemplu, api.rutvit.ru/oauth/authorize . Cheia Token de solicitare este transmisă în parametri.
   • Furnizorul afișează un formular de autorizare pentru utilizatorul său și, dacă acesta este autorizat, redirecționează browserul înapoi. Unde exact? Și specificăm acest lucru în parametrul oauth_callback.
4. Preluare Token de acces (cerere internă). Deci, browserul a revenit la aplicația noastră după o serie de redirecționări. Aceasta înseamnă că autorizarea Furnizorului a avut succes și că Tokenul de solicitare este permis să funcționeze. Cu toate acestea, în OAuth, din motive de securitate, fiecare token are propriul său scop, strict limitat. De exemplu, Request Token este folosit doar pentru a primi confirmarea de la utilizator și nimic altceva. Pentru a accesa resurse, trebuie să obținem un nou token - Access Token - sau, după cum se spune, „schimbă Request Token for Access Token”.
   • Consumatorul se referă la Adresa URL a simbolului de acces- de exemplu, api.rutvit.ru/oauth/access_token , - și cere să-i dea un Token de acces în loc de Jetonul de solicitare. Cererea este semnată semnatura digitala pe baza secretului Request Token.
   • Furnizorul generează și returnează un token de acces plin cu gunoi. De asemenea, notează în tabelele sale că pentru aceasta Jeton de acces Acces API permis. Aplicația noastră trebuie să păstreze Token-ul de acces dacă va folosi API-ul în viitor.
5. Call API (cerere internă). Ei bine, acum avem un Access Token și îi putem transmite cheia atunci când apelăm metode API.
   • Consumatorul generează o solicitare către API-ul Furnizorului (de exemplu, folosind o solicitare POST conform ideologiei REST). Solicitarea trece Cheia Token de acces și este semnată folosind Secretul Partajat al acestui token.
   • Furnizorul gestionează apelul API și returnează date aplicației.

Sfârșitul scriptului: ieșire widget

Link-uri utile pe OAuth

• rutvit

OAuth 2 este un cadru de autorizare care permite aplicațiilor să aibă acces limitat la conturile de utilizator pe servicii HTTP precum Facebook, GitHub și DigitalOcean. Funcționează pe principiul delegării autentificării utilizatorului către serviciul care găzduiește contul utilizatorului, permițând unei aplicații terțe să acceseze contul utilizatorului. OAuth 2 funcționează pe web, desktop și aplicații mobile.

Acest articol este destinat dezvoltatorilor de aplicații și oferă o prezentare generală a rolurilor, a tipurilor de autorizare și a cazurilor de utilizare tipice pentru OAuth 2.

Să începem cu rolurile OAuth!

Roluri

OAuth definește patru roluri:

• Proprietarul resursei
• Client
• server de resurse
• Server de autorizare

Proprietarul resursei: Utilizator

Proprietarul resursei este utilizator care autorizează Apendice pentru a vă accesa contul. Accesul aplicației la contul de utilizator este limitat de „sfera” drepturilor de autorizare acordate (de exemplu, acces de citire sau scriere).

Server de resurse/autorizare: API

Serverul de resurse stochează direct datele securizate ale conturilor de utilizator, iar serverul de autorizare verifică autenticitatea informațiilor furnizate utilizator, apoi creează jetoane de autorizare pentru aplicatii, cu care aplicația va accesa datele utilizatorului.

Din punctul de vedere al dezvoltatorului de aplicații, serviciul API îndeplinește simultan atât rolul de server de resurse, cât și rolul de server de autorizare. În cele ce urmează, vom considera aceste două roluri ca unul și le vom numi Serviciu sau API.

Client: Aplicație

Clientul este Apendice care dorește să acceseze contul utilizator. Înainte ca accesul să poată fi acordat, aplicația trebuie să fie autorizată de utilizator, iar autorizarea trebuie să fie aprobată de API.

Acum că avem o idee despre rolurile folosite în OAuth, să ne uităm la o diagramă a modului în care interacționează între ele.

Luați în considerare descrierea secvenței de pași din această diagramă:

1. Aplicație se intreaba de la utilizator autorizarea de a accesa serverul de resurse.
2. În cazul în care un utilizator autorizează cererea, Apendice primește un acord de autorizare.
3. Aplicație solicită un jeton de autorizare de la server de autorizare(API) prin furnizarea de informații despre sine și permisiunea de autorizare din partea utilizatorului.
4. Dacă autenticitatea cererii este confirmată și permisiunea de autorizare este valabilă, server de autorizare(API) creează un token de acces pentru aplicație. Procesul de autorizare a fost finalizat.
5. Aplicație solicită o resursă de la server de resurse(API), oferind în același timp un token de acces pentru autentificare.
6. Dacă simbolul este valid, server de resurse(API) furnizează resursa solicitată aplicarea.

Ordinea reală a pașilor din acest proces poate varia în funcție de tipul de autorizare utilizat, dar, în general, procesul va fi așa cum este descris. În continuare, ne vom uita la diferitele tipuri de permisiuni de autorizare.

Înregistrarea aplicației

Înainte de a putea începe să utilizați OAuth în aplicația dvs., trebuie să vă înregistrați aplicația la serviciu. Acest lucru se face prin înregistrarea în secțiunea „dezvoltator” sau „API” a site-ului serviciului, unde trebuie să furnizați următoarele informații (poate inclusiv câteva detalii despre aplicația dvs.):

• numele aplicatiei
• Site de aplicare
• Adresă URL de redirecționare sau URL de apel invers

Adresa URL de redirecționare este adresa URL către care serviciul va redirecționa utilizatorul după autorizarea (sau refuzul autorizării) aplicației dvs.

ID-ul clientului și secretul clientului

După înregistrarea aplicației, serviciul va crea acreditările clientului - un client ID (client ID) și un client secret (client secret). ID-ul clientului este un șir accesibil public care este utilizat de API-ul serviciului pentru a identifica aplicația și este, de asemenea, folosit pentru a genera adrese URL de autorizare pentru utilizatori. Secretul clientului este folosit pentru a autentifica identitatea aplicației la API-ul serviciului atunci când aplicația solicită acces la contul utilizatorului. Secretul clientului ar trebui să fie cunoscut doar de aplicație și de API.

permisiunea de autorizare

LA descriere abstractă a protocolului mai sus, primii patru pași se referă la crearea unei permisiuni de autorizare și a unui token de acces. Tipul de permisiuni de autorizare depinde de metoda folosită de aplicație pentru a solicita autorizarea, precum și de tipurile de permisiuni acceptate de API. OAuth 2 definește patru tipuri diferite, fiecare dintre acestea fiind util în situații specifice:

• Cod de autorizare: utilizat cu aplicații de pe partea serverului.
• Implicit: Folosit de aplicații mobile sau web (aplicații care rulează pe dispozitivul utilizatorului).
• Acreditările parolei proprietarului resursei: Folosit de aplicații de încredere, cum ar fi aplicațiile care fac parte din serviciul în sine.
• Acreditările clientului: utilizat atunci când aplicația accesează API-ul.

Tip permisiunea de autorizare: Cod de autorizare

Cod de autorizare este unul dintre cele mai comune tipuri de permisiuni de autorizare, deoarece este potrivit pentru aplicatii server, unde codul sursă al aplicației și secretul clientului nu este disponibil pentru străini. Procesul în acest caz se bazează pe redirecționare, ceea ce înseamnă că aplicația trebuie să poată interacționa cu agent utilizator(user-agent), cum ar fi un browser web, și primiți coduri de autorizare API redirecționate prin agentul utilizator.

Să descriem procesul într-o diagramă:

Pasul 1: Conectați cu codul de autorizare

• https://cloud.?response_type=code&client_id=CLIENT_ID &redirect_uri=CALLBACK_URL &scope=read

• : punctul final de autorizare API.
• client_id=CLIENT_ID: identificatorul client al aplicației (folosind acest identificator, API-ul înțelege ce aplicație solicită acces).
• redirect_uri=CALLBACK_URL: URL-ul către care serviciul va redirecționa agentul utilizator (browser) după emiterea codului de autorizare.
• tip de răspuns=cod: Indică faptul că aplicația solicită acces cu un cod de autorizare.
• scope=citeste: Setează nivelul de acces al aplicației (în acest caz, acces de citire).

Pasul 3: Aplicația primește un cod de autorizare

Dacă utilizatorul selectează „Autorizare aplicație”, serviciul redirecționează agentul utilizator (browser) către adresa URL de redirecționare care a fost setată în timpul pasului de înregistrare a clientului (împreună cu Cod de autorizare). Linkul va arăta astfel (în acest exemplu, aplicația se numește „dropletbook.com”):

• https://dropletbook.com/callback?code=AUTHORIZATION_CODE

Pasul 4: Aplicația solicită un token de acces

Aplicația solicită un jeton de acces de la API, trimițând un cod de autorizare și informații de autentificare (inclusiv secretul clientului) serviciu. Mai jos este un exemplu de solicitare POST pentru a primi un token DigitalOcean:

• https://cloud.?client_id=CLIENT_ID &client_secret=CLIENT_SECRET &grant_type=authorization_code&code=AUTHORIZATION_CODE &redirect_uri=CALLBACK_URL

Pasul 5: Aplicația primește un token de acces

• ("access_token":"ACCESS_TOKEN ","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN ","scope":"read","uid":100101,"info":( "name":"Mark E. Mark","email":" [email protected]"}}

Acum aplicația este autorizată! Poate folosi jetonul pentru a accesa contul de utilizator prin API-ul serviciului cu restricții de acces setate până când jetonul expiră sau jetonul este revocat. Dacă un token a fost creat pentru a reîmprospăta un token de acces, acesta poate fi folosit pentru a obține noi token-uri de acces atunci când vechiul token expiră.

Tip de permisiune de autorizare: implicit

Tipul de autorizare implicită este folosit de aplicațiile mobile și web (aplicații care rulează într-un browser web) în cazul în care confidențialitatea secretul clientului nu poate fi garantat. Tipul de permisiune implicită se bazează, de asemenea, pe redirecționarea agentului utilizator, prin care jetonul de acces este transmis agentului utilizator pentru transmitere ulterioară către aplicație. Aceasta, la rândul său, face ca tokenul să fie disponibil utilizatorului și altor aplicații de pe dispozitivul utilizatorului. De asemenea, acest tip de permisiune de autorizare nu autentifică autenticitatea aplicației, iar procesul în sine se bazează pe adresa URL de redirecționare (înregistrată mai devreme în serviciu).

Procesul este următorul: aplicația cere utilizatorului să se autorizeze, apoi serverul de autorizare transmite jetonul de acces agentului utilizator, care transmite jetonul aplicației. În continuare, descriem procesul în detaliu.

Pasul 1: Link de autorizare implicită

Cu un tip de permisiune de autorizare implicită, utilizatorului i se oferă un link care solicită un token de la API. Acest link arată aproape la fel cu linkul pentru metoda anterioară (cu un cod de autorizare), cu excepția faptului că este solicitat jetonîn loc de cod (rețineți că tip de răspuns"jeton"):

• https://cloud.?response_type=token&client_id=CLIENT_ID &redirect_uri=CALLBACK_URL &scope=read

Pasul 2: Utilizatorul autorizează aplicația

Când un utilizator dă clic pe un link, trebuie mai întâi să se conecteze pentru a-și verifica identitatea (dacă nu este deja autentificat, desigur). După aceea, serviciul va solicita utilizatorului să autorizeze sau să refuze autorizarea aplicației pentru a accesa contul utilizatorului. Un exemplu de astfel de dialog este prezentat mai jos:

Pasul 3: agentul utilizator primește jetonul de acces de la URI-ul de redirecționare

• https://dropletbook.com/callback#token=ACCESS_TOKEN

Pasul 4: agentul utilizator urmează URI-ul de redirecționare

Agentul utilizator urmează URI-ul de redirecționare păstrând tokenul de acces.

Pasul 5: Aplicația execută scriptul de extragere a jetonului de acces

Aplicația returnează o pagină web care conține un script pentru a extrage jetonul de acces din URI-ul complet de redirecționare stocat de agentul utilizator.

Pasul 6: Tokenul de acces este transmis aplicației

Agentul utilizator rulează scriptul de extragere a jetonului de acces și apoi transmite jetonul extras aplicației.

Acum aplicația este autorizată! Poate folosi jetonul pentru a accesa contul de utilizator prin API-ul serviciului cu restricții de acces setate până când jetonul expiră sau jetonul este revocat.

Tip de permisiune de autorizare: acreditările proprietarului resursei

Cu acest tip de permisiune de autorizare, utilizatorul furnizează direct aplicației datele de autorizare în serviciu (nume de utilizator și parolă). Aplicația, la rândul său, folosește acreditările primite de utilizator pentru a obține un token de acces de la serviciu. Acest tip de permisiune de autorizare ar trebui utilizat numai atunci când nu sunt disponibile alte opțiuni. De asemenea, acest tip de permisiune ar trebui folosit numai atunci când aplicația este de încredere de către utilizator (de exemplu, face parte din serviciul în sine sau din sistemul de operare al utilizatorului).

Proces cu acreditările proprietarului resursei

După ce utilizatorul își trimite acreditările către aplicație, aplicația va solicita un jeton de acces de la serverul de autorizare. Un exemplu de solicitare POST ar putea arăta astfel:

• https://oauth.example.com/token?grant_type=password&username=USERNAME &password=PASSWORD &client_id=CLIENT_ID

Atenţie: DigitalOcean nu acceptă în prezent tipul de autorizare a acreditării proprietarului resursei, așa că linkul de mai sus duce la un server de autorizare imaginar „oauth.example.com”.

Tip de autorizare: Acreditări client

Tipul de permisiune de autorizare care utilizează acreditările clientului permite aplicației să acceseze propriul cont de serviciu. Acest lucru poate fi util, de exemplu, atunci când o aplicație dorește să-și actualizeze propriile informații de înregistrare a serviciului sau să redirecționeze URI sau să acceseze alte informații stocate în contul de serviciu al aplicației prin API-ul serviciului.

Proces cu acreditările clientului

Aplicația solicită un token de acces trimițând acreditările sale, ID-ul de client și secretul clientului către serverul de autorizare. Un exemplu de solicitare POST ar putea arăta astfel:

• https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID &client_secret=CLIENT_SECRET

Atenţie: DigitalOcean nu acceptă în prezent tipul de autorizare a acreditării clientului, așa că linkul de mai sus duce la un server de autorizare imaginar „oauth.example.com”.

Un exemplu de utilizare a unui token de acces

După ce o aplicație primește un jeton de acces, poate folosi acest jeton pentru a accesa contul de utilizator prin intermediul API-ului de serviciu cu restricțiile de acces specificate până când jetonul expiră sau jetonul este revocat.

Mai jos este un exemplu de solicitare API folosind curl . Rețineți că conține un token de acces:

• curl -X POST -H "Autorizare: Purtător ACCESS_TOKEN ""https://api.site/v2/$OBJECT "

Dacă jetonul de acces este valid, API-ul va procesa solicitarea primită. Dacă jetonul de acces a expirat sau jetonul este invalid, API-ul va returna o eroare „invalid_request”.

Refresh Access Token

După ce simbolul de acces a expirat, toate solicitările către API-ul care îl utilizează vor returna o eroare „Eroare de simbol invalid”. Dacă la crearea unui token de acces a fost creat și un jeton de reîmprospătare, acesta din urmă poate fi folosit pentru a obține un nou token de acces de la serverul de autorizare.

Următorul este un exemplu de solicitare POST care utilizează un jeton pentru a reîmprospăta un jeton de acces pentru a obține un nou jeton de acces:

• https://cloud.?grant_type=refresh_token&client_id=CLIENT_ID &client_secret=CLIENT_SECRET &refresh_token=REFRESH_TOKEN

Concluzie

Aceasta încheie prezentarea noastră de ansamblu asupra OAuth 2. Acum aveți o înțelegere de bază a modului în care funcționează OAuth 2, precum și când și cum să utilizați tipurile de permisiuni de autorizare existente.

Dacă doriți să aflați mai multe despre OAuth 2, vă recomandăm să consultați următoarele articole.

OAuth 2 este un protocol de autorizare care oferă aplicațiilor acces HTTP limitat la conturile de utilizator. Externalizează autentificarea utilizatorilor către serviciul care găzduiește conturile și autorizează aplicații terțe și le oferă acces la contul de utilizator. OAuth 2 oferă autorizare pentru aplicații web și dispozitive mobile.

Acest ghid vă va prezenta rolurile, tipurile de autorizare, fluxurile și cazurile de utilizare OAuth 2.

Roluri

Există patru roluri în OAuth:

1. Proprietarul resursei
2. Client
3. server de resurse
4. Server de autorizare

Să aruncăm o privire mai atentă la fiecare rol.

Proprietarul resursei: utilizator

Proprietarul resursei este utilizatorul care se autentifică cu aplicația pentru a-și accesa contul.

Aplicația restricționează accesul la contul de utilizator cu ajutorul permisiunilor (adică drepturile de a efectua o acțiune: citire, scriere etc.).

Server de resurse și autorizare: API

Serverul de resurse stochează conturi de utilizator securizate, iar serverul de autorizare verifică acreditările utilizatorului și apoi emite jetoane de acces la aplicație.

Din punctul de vedere al dezvoltatorului de aplicații, API-ul serviciului acționează atât ca server de resurse, cât și ca server de autorizare. În cele ce urmează, ne vom referi la aceste roluri ca serviciu sau API.

Client: aplicație

Un client este o aplicație care dorește să acceseze contul unui utilizator. Înainte de a putea face acest lucru, utilizatorul trebuie să fie autorizat în aplicație, iar API-ul trebuie să confirme autorizarea.

Fluxuri de protocol

Rolurile OAuth interacționează între ele după cum urmează:

• Aplicația solicită autorizarea utilizatorului pentru a accesa resursele de serviciu.
• Dacă utilizatorul este autorizat la cererea aplicației, aplicația primește autorizarea.
• Aplicația solicită un token de acces de la un server de autorizare (API).
• Dacă aplicația este autentificată și acreditările sale sunt valide, serverul de autorizare (API) emite un jeton de acces la aceasta. Autorizare finalizată.
• Aplicația solicită o resursă de la un server de resurse (API) și oferă un token de acces pentru autentificare.
• Dacă jetonul de acces este valid, serverul de resurse (API) servește resursele pentru aplicație.

Înregistrarea aplicației

Înainte de a putea utiliza OAuth într-o aplicație, trebuie să înregistrați aplicația. Acest lucru se face prin intermediul formularului de înregistrare din secțiunea Dezvoltator sau API a site-ului web al serviciului, unde trebuie să furnizați următoarele informații:

• Numele aplicatiei;
• Site-ul de aplicare;
• Adresa URL de apel invers sau URI de redirecționare (aici serviciul va redirecționa utilizatorul după ce a trecut (sau a eșuat) autorizarea; această parte a aplicației va procesa coduri de autorizare sau jetoane de acces).

ID-ul clientului și cheia secretă

După înregistrarea aplicației, serviciul vă va furniza acreditările aplicației, care pot fi găsite în câmpurile identificator client și secret client. ID-ul clientului este un șir public care este utilizat de API-ul serviciului pentru a identifica aplicația; de asemenea, creează adrese URL de autorizare. Client Secret permite API-ului serviciului să autentifice o aplicație atunci când solicită acces la contul unui utilizator. Aceste date sensibile sunt stocate între aplicație și API.

Permisiuni de autorizare

Permisiunile de autorizare depind de metoda pe care o folosește aplicația pentru a solicita autorizarea, precum și de tipurile de permisiuni acceptate de API. OAuth 2 definește patru tipuri de permisiuni, fiecare dintre acestea fiind utilă în moduri diferite:

1. Cod de confirmare: utilizat în aplicațiile pe partea serverului.
2. Acces implicit: utilizat în aplicații web și mobile (aplicații care rulează pe dispozitivul utilizatorului).
3. Furnizarea unei parole clientului: utilizat în aplicații despre care se știe că sunt sigure (de exemplu, aplicații deținute de un serviciu).
4. Autoritate client: acces la API-ul aplicației.

Codul de confirmare

Codul de confirmare este cel mai comun tip de autoritate, optimizat pentru aplicațiile server-side unde codul sursă este închis și Secretul Clientului nu este disponibil pentru cei din afară. Acest flux se bazează pe redirecționare, ceea ce înseamnă că aplicația trebuie să poată interacționa cu agentul utilizator (adică browserul web al utilizatorului) și să primească coduri de autorizare API care sunt direcționate prin agentul utilizator.

Fluxul cu codul de confirmare arată astfel:

1. Utilizatorul primește un link către un cod de verificare.
2. Utilizatorul este autorizat. Făcând clic pe link, utilizatorul confirmă autenticitatea datelor. În cazul în care datele furnizate sunt incorecte, utilizatorului i se va refuza autorizarea.
3. Aplicația primește un cod de verificare. Serviciul redirecționează agentul utilizator către URI-ul care a fost specificat la înregistrarea clientului, împreună cu un cod de verificare.
4. Aplicația solicită un token de acces de la API, furnizând un cod de confirmare și date de autorizare, inclusiv un secret al clientului.
5. Aplicația primește un token de acces dacă autorizația este validă.

Fir cu acces implicit

Fluxul de acces implicit este utilizat de aplicațiile mobile sau aplicațiile web unde confidențialitatea secretului clientului nu poate fi garantată. Acest flux se bazează și pe o redirecționare, dar agentul utilizator primește jetonul de acces, după care este transmis aplicației. Astfel, poate fi vizibil pentru utilizator sau pentru alte aplicații de pe dispozitivul utilizatorului. De asemenea, acest flux nu autentifică aplicația, folosește URI-ul (care a fost înregistrat la serviciu).

Tokenurile de reîmprospătare nu sunt acceptate cu acces implicit.

Fluxul de acces implicit funcționează în principiu astfel: utilizatorului i se cere să autorizeze în aplicație, serverul de autorizare transmite jetonul de acces agentului utilizator, care îl transmite aplicației. Acest proces arată astfel mai detaliat:

1. Utilizatorul primește un link de acces implicit care solicită un token de la API.
2. Utilizatorul este autorizat făcând clic pe link. Dacă utilizatorul nu se poate autentifica, i se va refuza accesul.
3. Agentul utilizator primește un token de acces și un URI de redirecționare.
4. Agentul utilizator urmează URI-ul de redirecționare.
5. Aplicația trimite un script de recuperare a jetonului de acces. Aplicația returnează o pagină web cu un script care poate extrage jetonul de acces din URI-ul de redirecționare.
6. Aplicația primește un token de acces. Autorizare finalizată.

Oferirea unei parole clientului

Acest tip implică faptul că utilizatorul transmite acreditările direct către aplicație, care le folosește pentru a obține un token de acces. Acest tip ar trebui să fie acceptat numai pe serverul de autorizare. De asemenea, ar trebui folosit doar dacă aplicația poate fi de încredere (de exemplu, aparține unui serviciu sau sistemului de operare al utilizatorului).

După primirea acreditărilor utilizatorului, aplicația solicită un token de acces de la serverul de autorizare. Dacă acreditările sunt corecte, serverul de autorizare va furniza un token de acces. Autorizare finalizată.

Autoritatea Clientului

Acest tip permite aplicației să se conecteze la propriul cont de serviciu. Un astfel de flux este util dacă o aplicație dorește să își actualizeze descrierea înregistrată sau să redirecționeze URI sau să acceseze alte date stocate într-un cont de serviciu.

Aplicația solicită un token de acces trimițând acreditările, ID-ul clientului și secretul clientului. . Dacă acreditările sunt corecte, serverul de autorizare va furniza un token de acces. Autorizare finalizată.

Utilizarea jetoanelor de acces

După ce a primit un token de acces, aplicația îl poate folosi pentru a accesa contul utilizatorului prin intermediul API-ului.

Dacă simbolul este valid, API-ul procesează cererea. Dacă simbolul este invalid, API-ul va genera o eroare invalid_request.

Flux de jetoane reîmprospătabile

După expirarea simbolului de acces, API-ul va genera o eroare invalid_request. Dacă aplicația a primit un jeton de reîmprospătare împreună cu jetonul de acces, acum îl poate folosi pentru a solicita un nou jeton de acces de la serverul de autorizare.

Acum sunteți familiarizat cu elementele de bază ale OAuth 2.

1. Deschiderea browserului încorporat cu pagina de autorizare
2. Utilizatorului i se cere să confirme acordarea drepturilor
3. Dacă utilizatorul este de acord, browserul va redirecționa către pagina stub din fragmentul (după #) a cărui adresă URL este adăugată jeton de acces
4. Aplicația interceptează redirecționarea și primește jeton de acces de la adresa paginii

Exemplu

După ce utilizatorul acordă drepturile, apare o redirecționare către pagina stub standard, pentru Mail.Ru aceasta este connect.mail.ru/oauth/success.html:
< HTTP/1.1 302 Found < Location: http://connect.mail.ru/oauth/success.html#access_token=FJQbwq9&token_type=bearer& expires_in=86400&refresh_token=yaeFa0gu

Aplicația trebuie să intercepteze ultima redirecționare, să obțină de la adresă jeton de accesși folosiți-l pentru a accesa resurse protejate.

Autorizare autentificare și parolă

Exemplu

Restabilirea unei autorizații anterioare

Exemplu