Grija de clienții săi, echipa de service Invola a implementat o conexiune directă la e-mail folosind tehnologia OAuth 2.0.

În acest articol vă vom spune ce este, cum funcționează și cum afectează securitatea datelor utilizatorilor.
Vom renunța la rând puncte tehnice, care transmite esența tehnologiei într-un limbaj simplu și ușor de înțeles pentru utilizatorii obișnuiți.

Utilizatorii obișnuiți ai serviciului știu cum a fost uneori Este incomod să folosești un e-mail duplicat, uitând adesea să-i trimită o altă scrisoare. Am primit scrisori în care ne solicitau să revizuim algoritmul de primire a facturilor și a celor comerciale în favoarea conexiune directa la Oficiul poștal.

După câteva săptămâni de muncă fructuoasă a programatorului și a specialistului în securitate algoritm de autorizare implementat si acum este principala metodă de conectare clienții la serviciu.

Ce este OAuth?

Vorbind într-un limbaj tehnic uscat, acesta este un protocol de autorizare care vă permite să emiteți un singur serviciu (în în acest caz, Invola) drepturi de acces la resursele utilizatorului pe alt serviciu (acces la e-mail).

Utilizatorul are mai multe motive să aibă încredere în aplicație, deoarece utilizatorul poate fi sigur că acces neautorizat accesul la datele sale personale este imposibil. Fără a avea login și parola utilizatorului, aplicația va putea efectua doar acelea actiuni cu date pe care utilizatorul le-a permis, și nu altele.

Pentru a spune simplu, putem spune asta: serviciul Invola se conectează la poșta dumneavoastră pentru a primi facturi și oferte comerciale, fără a solicita autentificare și parolă, dar solicitând dreptul de acces. Dacă confirmați, aplicația primește acces până când este revocată de utilizatorul însuși sau atât timp cât aplicația există și este activă.

În comunicarea dintre Invola și server de mail jeton folosit acces acces token (pasul 4-5), care expiră automat după o oră și este actualizat după cum este necesar (automat, fără intervenția utilizatorului, software Invola).

Acum să vorbim despre securitate și de ce Autorizarea OAuth este de preferată autentificarea de conectare/parolă.

Atunci când furnizați oricărui serviciu un login și o parolă pentru a vă accesa contul (mail.ru, gmail.com), de fapt furnizați o parolă pentru întregul cont(în acest fel puteți accesa, de exemplu, un disc, albume foto și alte date personale).

Acordarea accesului prin OAuth tu însuți alegeți ce resurse să accesați cont dai acces. Adică, utilizatorul însuși controlează la ce resurse este dispus să acorde acces. Să ne uităm la un exemplu de drepturi solicitate la conectarea la Invola:

"Vizualizați și gestionați e-mailurile" - Pentru primire automată conturi și CP, " vizualizați adresa"- pentru obținere casuță de e-mail, "Vezi profil„ – pentru a obține un nume de utilizator (necesar în etapa de înregistrare).

Din pacate, nu toate serverele de mail(inclusiv corporativ) autorizație de sprijin prin tehnologie OAuth, în special serviciu popular Yandex Mail. Dacă e-mailul dvs. este pe Yandex, conectați-vă la serviciul nostru în acest moment Puteți utiliza doar parola de conectare.

Un pic despre securitate.

Înțelegem foarte bine cât de critică este scurgerea de date confidențiale sau accesul neautorizat la date despre clienți, tranzacții financiare, corespondență personală. Securitatea datelor este una dintre prioritățile principale ale activității noastre.

Jetoanele de acces, precum și parolele pentru accesarea e-mailului, sunt stocate pe un server de baze de date securizat, folosind o schemă criptografică bazată pe chei dinamice.

Drept urmare, este de remarcat faptul că angajații noștri nu au acces la serverele de e-mail și la corespondența utilizatorilor noștri sub nicio circumstanță.

Toate comunicațiileîntre utilizator și serviciu, precum și între serviciu și serverul de e-mail efectuate pe un canal SSL securizat, cu alte cuvinte, toate datele transmise în ambele direcții sunt criptate cu un algoritm criptografic puternic.

Dacă aveți o afacere și trimiteți o mulțime de facturi și propuneri clienților dvs., atunci pur și simplu trebuie să încercați sistemul nostru. Invola trimite alerte automate dacă nu a existat niciun răspuns pe factură și, de asemenea, urmărește reacția clienților dvs. la facturi (costisitoare, termen lung rechizite etc.). Ca urmare primești o creștere a ponderii facturilor plătiteși, de asemenea, aveți posibilitatea de a colecta statistici privind performanța managerilor dvs., motive comune refuzuri.

OAuth 2 este un protocol de autorizare care oferă aplicațiilor acces HTTP limitat la conturile de utilizator. Transmite autentificarea utilizatorului serviciului care găzduiește conturile și le autorizează aplicații terță parteș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 OAuth 2 folosind OAuth 2.

Roluri OAuth

Există patru roluri în OAuth:

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

Să ne uităm la fiecare rol mai detaliat.

Proprietarul resursei: utilizator

Proprietarul resursei este utilizatorul care se autentifică la aplicație pentru a obține acces la contul său.

Aplicația restricționează accesul la contul de utilizator folosind permisiuni (adică drepturile de a efectua o anumită 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 îndeplinește rolurile de server de resurse și de server de autorizare. În cele ce urmează, ne vom referi la aceste roluri ca un serviciu sau un 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 obține acces la resursele de serviciu.
• Dacă utilizatorul este autorizat la solicitarea aplicației, aplicația primește permisiuni.
• Aplicația solicită un token de acces de la serverul de autorizare (API).
• Dacă aplicația este autentificată și acreditările sale sunt valide, serverul de autorizare (API) îi emite un token de acces. Autorizarea este completă.
• Aplicația solicită o resursă de la serverul 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 aplicației;
• URL sună din nou 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 gestiona codurile de autorizare sau jetoanele 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 de identificare client și secret client. ID-ul clientului este un șir public care este utilizat de API-ul serviciului pentru a identifica aplicația; este, de asemenea, utilizat pentru a crea adrese URL de autorizare. Client Secret permite API-ului serviciului să autentifice o aplicație atunci când solicită acces la un cont de 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 cazuri diferite:

1. Cod de verificare: Folosit în aplicațiile pe partea serverului.
2. Acces implicit: utilizat în web și mobil aplicații (aplicații care rulează pe dispozitivul utilizatorului).
3. Furnizarea unei parole clientului: utilizată în avans aplicații securizate(de exemplu, în aplicațiile deținute de serviciu).
4. Privilegii client: acces la API-ul aplicației.

cod de confirmare

Codul de verificare este cel mai obișnuit tip de acreditări, optimizat pentru aplicațiile de pe server unde sursă este închis și Client Secret nu este accesibil celor 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 de cod de confirmare arată astfel:

1. Utilizatorul primește un link către un cod de confirmare.
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 verificare și date de autorizare, inclusiv secretul clientului.
5. Aplicația primește un token de acces dacă autorizația este validă.

Flux de acces implicit

Se utilizează fluxul de acces implicit aplicatii mobile sau aplicații web în care confidențialitatea secretului clientului nu poate fi garantată. Acest flux este, de asemenea, bazat pe redirecționare, dar agentul utilizator primește jetonul de acces și apoi îl transmite aplicației. În acest fel, poate fi vizibil pentru utilizator sau pentru alte aplicații de pe dispozitivul utilizatorului. În plus, acest flux nu autentifică aplicația, o face folosind URI-ul (care a fost înregistrat la serviciu).

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

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

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 pentru a prelua jetonul 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. Autorizarea este completă.

Furnizarea 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. În plus, ar trebui utilizat numai dacă aplicația poate fi de încredere (de exemplu, aparține unui serviciu sau sistem de operare utilizator).

După ce a primit acreditările 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. Autorizarea este completă.

Acreditările clientului

Acest tip permite unei aplicații să se conecteze propriul cont serviciu. Acest 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. Autorizarea este completă.

Utilizarea jetoanelor de acces

Odată ce o aplicație primește un token de acces, îl poate folosi pentru a accesa contul utilizatorului prin API.

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

Flux cu jeton reîmprospătabil

Odată ce simbolul de acces expiră, 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 autentificare
2. Utilizatorului i se cere să confirme că au fost acordate drepturile.
3. Dacă utilizatorul este de acord, browserul este redirecționat către o pagină stub din fragmentul (după #) al cărui 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ă permisiuni, apare o redirecționare către o pagină 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 și să obțină de la adresă jeton de accesși folosiți-l pentru a accesa resurse protejate.

Autorizare prin autentificare și parolă

Exemplu

Restabilirea autorizației anterioare

Exemplu

Un protocol popular care permite social serviciile se integrează între ele și permit cale sigura schimb valutar Informații personale. OAuth poate conecta 2 servicii, fiecare dintre ele având propriile sale servicii baza de utilizatori- în acest caz le numesc „sociale”. Când începeți să lucrați cu OAuth, primul sentiment este că protocolul este foarte complex ș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 pe 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.
• Resursa protejata: date personale; contacte din agenda de adrese de pe Gmail (adică resursele furnizorului de servicii).
• API-ul furnizorului: API-ul GMail care permite oricărui script să preia contacte dintr-o agendă de adrese 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 vă puteți conecta la serviciu fără a introduce o parolă, fiind autorizat „undeva”). De exemplu, dacă aveți un cont pe Yandex, îl puteți utiliza pentru a „conecta” la orice serviciu care acceptă autorizarea OpenID.
2. OAuth este un protocol pentru acces autorizat la API-uri terțe. 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 la implementarea „manuală” a autorizației î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 în sine pentru importarea contactelor din GMail: Apoi, le vom cere dezvoltatorilor GMail să se asigure că atunci când un utilizator navighează la URI /auth.php, i se oferă un formular de autorizare (în veloworld, 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, în plus, în URL trebuie transmisă o cheie secretă, 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 din scriptul /import.php ne vom întoarce la API-ul GMail, vom trece cheia Y49xdN0Zo2B5v0RR în el ș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

A doua greblă: „a asculta cu urechea” la cheia secretă

Rake numărul trei: prea multe redirecționări

Rake numărul patru: identificare slabă a consumatorului

Fundația OAuth

Aplicație = Consumer + acces API

Token = Cheie + Secret

Deci, dacă Consumatorul și Furnizorul sunt de acord într-un fel asupra unui Secret Partajat, ei pot schimba în mod deschis Cheile corespunzătoare din URL fără teama ca acele chei să fie interceptate. Dar cum să protejăm adresele URL cu chei de falsificare?

Mesaj = Document + Semnătură digitală

De asemenea, la un bloc de date se adaugă o semnătură digitală pentru a se asigura că persoana care a generat datele nu se uită la altcineva. O semnătură digitală nu criptează un document, doar îi garantează autenticitatea! Același Secret Partajat, care este cunoscut destinatarului și expeditorului, dar nimeni altcineva, vă permite să semnați.

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

1. Consumatorul adaugă o semnătură digitală la mesaj, în 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, tot ce rămâne este să comparați valoarea rezultată $signatureToMatch cu ceea ce era în datele primite $signature și să raportați un fals dacă valorile nu se potrivesc.

Demonstrare a modului în care funcționează OAuth folosind o aplicație simplă ca exemplu

1. Script care implementează parte client 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 OAuth de testare pe care putem experimenta. În acest scop, este convenabil să utilizați RuTvit: 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, nu trebuie să specificați adresa URL de returnare în formular - încă o transmitem din scriptul de testare.)

Puteți insera acest widget în orice site web PHP prin simpla copiere a codului și ajustând aspectul. Sunt afișate toate tweet-urile din serviciul RuTvit etichetate cu eticheta hash specificată și este, de asemenea, posibil să adăugați tweet-uri noi (aici intră în joc OAuth). Widgetul folosește API-ul RuTvit și autorizarea OAuth, care, apropo, coincid cu standardul Twitter API. 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-vă noua 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 oferă 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ă Secretul Consumatorului 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ă ne uităm la ele.

1. Procesarea trimiterii formularului. Aceasta nu face parte din OAuth, ci face parte din aplicația noastră. Înainte de a accesa Furnizorul API, trebuie să primim o comandă de lucru de la utilizator pentru această acțiune. Iată un exemplu de astfel de „comandă”:
2. Preluare token de solicitare (cerere internă).
   • Accesează scriptul Consumer Solicitați adresa URL a simbolului Furnizor: de exemplu, api.rutvit.ru/oauth/request_token. Solicitarea conține cheia Consumatorului - „autentificarea aplicației”, 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 nevoie de el mai târziu, așa că trebuie să îl stocăm undeva - de exemplu, în variabila de sesiune $S_REQUEST_TOK.
3. Redirecționare către Autorizare (prin redirecționare în 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 unul special 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 indicăm acest lucru în parametrul oauth_callback.
4. Preluare Jeton 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 pentru 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 îi cere să-i dea un Token de acces în loc de Tokenul de solicitare pe care îl are. Cererea este semnată semnatura digitala bazat pe secretul Tokenului de solicitare.
   • Furnizorul generează și returnează un token de acces plin cu gunoi. De asemenea, notează în tabelele sale că acest Token de acces are permisiunea de a accesa API-ul. Aplicația noastră trebuie să păstreze Tokenul de acces dacă va folosi API-ul în viitor.
5. Apel 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 conține Cheia Token de Acces și este semnată folosind Secretul Partajat al acestui Jeton.
   • Furnizorul procesează apelul API și returnează datele aplicației.

Sfârșitul scriptului: ieșire widget

Link-uri utile pe OAuth

• rutvit

1. Deschiderea browserului încorporat cu pagina de autentificare
2. Utilizatorului i se cere să confirme că au fost acordate drepturile.
3. Dacă utilizatorul este de acord, browserul este redirecționat către o pagină stub din fragmentul (după #) al cărui 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ă permisiuni, apare o redirecționare către o pagină 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 și să obțină de la adresă jeton de accesși folosiți-l pentru a accesa resurse protejate.

Autorizare prin autentificare și parolă

Exemplu

Restabilirea autorizației anterioare

Exemplu