OAuth: o descriere a protocolului într-un limbaj simplu și ușor de înțeles.

Există multe modalități de distribuire spam rău intenționat pe VKontakte. Dar dăunătorii nu dorm, le vin din ce în ce mai mulți în cap idei interesante. Și s-a dovedit a fi foarte util. Escrocii au învățat să-l folosească pentru a ocoli pagina de avertizare despre site-urile rău intenționate.

Și totul a început când într-o zi a apărut următorul mesaj pe peretele meu:


Din curiozitate, am urmat linkul și am ajuns pe un alt site de phishing. Dar linkul în sine mi s-a părut ciudat, arăta ca (jumătate din caractere în ASCII):
vkontakte.ru/away.php ? la=http%3A%2F%2FApi.vKontakte.Ru%2F%2Fo%2561u%2574%...

Aici începe distracția...

Să ne uităm la al doilea link în părți:

Ce înseamnă fiecare parametru:

• client_id - ID-ul aplicației care necesită autorizare;
• redirect_uri - adresa la care va fi trimis access_token-ul (prin redirecționare);
• afișaj - tipul ferestrei de autorizare (pagină, pop-up, atingere și wap).

De fapt, redirect_uri conținea adresa site-ului de phishing. Deoarece a existat o eroare în parametrul de afișare (conținea gunoi „?390852”), fereastra de autorizare nu a fost afișată, ci a fost imediat redirecționată către un site de phishing cu următorii parametri: error=invalid_request&error_description=Invalid+display+passed

Acesta este scopul de a ocoli lista neagră a site-urilor VKontakte rău intenționate. Apare doar o alertă despre trecerea la api.vk.com. Și, ca urmare a tranziției, mergem direct la un site de phishing care se află pe lista neagră. Când urmați linkul vkontakte.ru/away.php?to=vgostivk.dyndns**:

După cum s-a dovedit, aplicația care presupunea că necesita autorizare era suspendată de utilizatorul piratat:

Și site-ul de phishing în sine a fost proiectat destul de interesant. Designul, ca de obicei, a fost de tip contact și a cerut să se autentifice. M-am autentificat folosind un e-mail și o parolă aleatoare și am înghițit bine falsul. Ce s-a întâmplat în continuare a fost și mai interesant; știrile de la „Pavel Durov” au apărut pe pagina principală:

După ce ați făcut clic pe butonul „Creați un contor personal”, a urmat o bară de progres minunată. Apoi vi s-a cerut să indicați numărul dvs. și să trimiteți un SMS:

În teorie, după „activare” cu succes, ar fi trebuit să fie redirecționat către pagina activ.php, dar nu am putut ajunge acolo. Extrase din scripturile JS ale unui site de phishing:

...
dacă (req.status == 200) (
// dacă starea este 200 (OK) - dați un răspuns utilizatorului
dacă (req.responseText == „ok” ) (
//statusElem.innerHTML = "Totul bâzâie!";
get_activation();
}
dacă (req.responseText == „nu” ) (statusElem.innerHTML = „Cod de activare nevalid”;}
//statusElem.innerHTML = "Răspunsul serverului: "+req.responseText;
...
funcția get_activation() (
document .location="activ.php" ;
}

* Acest cod sursă a fost evidențiat cu Sursa de evidențiere a codului.

Concluzie: Fraudatorii folosesc OAuth 2.0 pentru a ocoli avertismentele, pentru a obține parola și e-mailul utilizatorului și chiar pentru a încerca să fraudeze trimiterea de sms(cel mai probabil folosind un sistem de abonament).

În 2010, lucrările au început complet versiune noua Protocolul OAuth 2.0, care nu va fi compatibil cu OAuth 1.0. În octombrie 2012, cadrul OAuth 2.0 a fost publicat în RFC 6749, iar utilizarea purtătorului de token în RFC 6750, ambele standarde de urmărire a solicitărilor de comentarii. RFC-uri suplimentare sunt încă în curs de dezvoltare.

Au existat mai multe premise pentru crearea OAuth 2.0. În primul rând, OAuth este destul de netrivial de utilizat pe partea clientului. Unul dintre obiectivele noastre atunci când dezvoltăm noul OAuth este de a simplifica dezvoltarea aplicații client. În al doilea rând, în ciuda implementării a trei metode (numite fluxuri) menționate în standard pentru obținerea unui token (identificator unic) pentru autorizare: pentru aplicații web, clienți desktop și clienții mobili, de fapt, toate cele trei metode sunt îmbinate într-una singură. Și în al treilea rând, protocolul s-a dovedit a fi slab scalabil. Se plănuiește adăugarea:

• 6 fluxuri noi.

Flux de agent utilizator - pentru clienții care rulează în interiorul unui agent de utilizator (de obicei, un browser web). Flux server web ( Server Web Flow - pentru clienții care fac parte dintr-o aplicație web server, accesibilă prin solicitări HTTP. Device Flow - Potrivit pentru clienții care rulează pe dispozitive restricționate, dar în care utilizatorul final are acces separat la un browser de pe alt computer sau dispozitiv. Flux de nume de utilizator și parole (Nume de utilizator și Parolă Flux - Folosit în cazurile în care utilizatorul are încredere în client pentru a-și gestiona acreditările, dar tot nu ar fi de dorit să se permită clientului să stocheze numele de utilizator și parola. Acest flux este potrivit doar atunci când există un grad ridicat de încredere între utilizator și client. Fluxul de acreditări ale clientului - clientul își folosește acreditările pentru a obține un token. Fluxul de aserție - clientul trimite o aserțiune, cum ar fi o aserțiune SAML, la serverul de autorizare în schimbul unui simbol. Aplicații care rulează calculator desktop sau dispozitiv mobil poate fi implementat folosind firele de mai sus.

• Jeton de purtător.

Metoda de autorizare este similară metoda existenta autorizare folosind cookie-uri. În acest caz, token-ul este folosit direct ca secret (însuși faptul de a avea token-ul autorizează clientul) și este transmis prin HTTPS. Acest lucru vă permite să accesați API-ul prin scripturi simple(de exemplu folosind cURL).

• Semnătură simplificată.

Semnătura a fost mult simplificată pentru a elimina necesitatea analizelor speciale, a codificării și a sortării parametrilor.

• Jetoane de scurtă durată cu autorizare pe termen lung.

În loc să emită un jeton cu viață lungă (care perioadă lungă de timp poate fi compromis), serverul oferă acces pe termen scurt și capacitatea pe termen lung de a actualiza jetonul fără interacțiunea utilizatorului.

• Separarea rolurilor.

Diferite servere pot fi responsabile pentru autorizare și pentru furnizarea accesului la API.

Este de remarcat faptul că, deși standardul OAuth 2.0 nu a fost încă aprobat, acesta este deja folosit de unele servicii. De exemplu, Graph Social API Facebook acceptă numai OAuth 2.0.

Diferența dintre OAuth și OpenID

Există o concepție greșită că OAuth este o extensie a protocolului OpenID. De fapt, acest lucru nu este adevărat. Deși OpenID și OAuth au multe asemănări, acesta din urmă este un protocol independent care nu are nicio legătură cu OpenID.

Marca temporală și Nonce

Pentru a preveni amenințarea cererilor reutilizare OAuth folosește un nonce și un timestamp. Termenul „nonce” înseamnă că, timp dat folosit o singură dată și este un șir unic aleatoriu de litere și numere care are scopul de a identifica în mod unic fiecare cerere semnată. Având un ID unic pentru fiecare cerere, furnizorul de servicii va putea preveni solicitările de reutilizare. Aceasta înseamnă că clientul generează un șir unic pentru fiecare solicitare pe care o trimite către server, iar serverul ține evidența tuturor non-urilor utilizate pentru a preveni utilizarea a doua oară.

Utilizarea non-urilor poate fi foarte costisitoare pentru server, deoarece necesită stocarea permanentă a tuturor non-urilor primite. Pentru a ușura implementarea, OAuth adaugă un marcaj de timp la fiecare solicitare, ceea ce permite serverului să stocheze nonce doar pentru o perioadă limitată de timp. Când o solicitare sosește cu un marcaj de timp care este mai devreme decât ora stocată, este respinsă deoarece serverul nu mai are un nonce din acel moment.

Acreditări și jetoane

OAuth utilizează trei tipuri de autoritate: acreditările clientului (consumator cheie și acreditări secrete sau de client), acreditări temporare (semnal de solicitare și acreditări secrete sau temporare) și token-uri (jeton de acces și acreditări secrete sau simboluri).

Acreditările clientului sunt utilizate pentru autentificarea clientului. Acest lucru permite serverului să colecteze informații despre clienți. Folosind serviciile sale, serverul oferă niște clienți tratamente speciale, cum ar fi reglementarea accesului gratuit sau oferirea proprietarului resursei cu mai multe informatii detaliate despre clienții care încearcă să-și acceseze resursele protejate. În unele cazuri, este posibil ca acreditările clientului să nu fie sigure și pot fi utilizate numai pentru scopuri informative, de exemplu, în aplicațiile desktop.

Jetonul este folosit în locul numelui și parolei proprietarului resursei. Proprietarul resursei nu își partajează acreditările cu clientul, ci mai degrabă autorizează serverul să emită clientului un token - o clasă specială de acreditări care reprezintă acordarea accesului. Clientul folosește jetonul pentru a accesa resursa protejată fără a cunoaște parola proprietarului resursei.

Un jeton constă dintr-un identificator, de obicei (dar nu întotdeauna) un set aleatoriu de litere și numere care este unic și greu de ghicit și o cheie pentru a proteja jetonul împotriva utilizării persoane neautorizate. Token-ul este limitat în domeniul de aplicare și durată și poate fi revocat în orice moment de către proprietarul resursei, fără a afecta alte simboluri emise altor clienți.

Procesul de autorizare OAuth utilizează, de asemenea, un set de acreditări temporare care sunt utilizate pentru a determina cererea de autorizare. Pentru a găzdui diferite tipuri de clienți (web, desktop, mobil etc.), acreditările temporare oferă un plus de flexibilitate și securitate.

Cum funcționează OAuth

Cum funcționează protocolul OAuth

Să explicăm funcționarea protocolului OAuth folosind un exemplu. Să presupunem că un utilizator (proprietar de resurse) dorește să-și printeze fotografiile (resursele) încărcate pe site-ul „photos.example.net” (server) folosind serviciul de imprimare „printer.example.net” (client).

1. Clientul, folosind protocolul HTTPS, trimite o solicitare către server care conține identificatorul clientului, un marcaj de timp, o adresă de apel invers la care trebuie returnat jetonul, tipul de semnătură digitală utilizată și semnătura în sine.
2. Serverul recunoaște cererea și răspunde clientului cu un token de acces ( Jeton de acces) și o parte a secretului partajat.
3. Clientul transferă jetonul către proprietarul resursei (utilizator) și îl redirecționează către server pentru autorizare.
4. Serverul, după ce a primit un token de la utilizator, îi cere autentificarea și parola, iar dacă autentificarea are succes, îi cere utilizatorului să confirme accesul clientului la resurse (autorizare), după care utilizatorul este redirecționat de către server către client.
5. Clientul transmite un token serverului prin TLS și solicită acces la resurse.
6. Serverul confirmă cererea și răspunde clientului cu un nou token de acces.
7. Folosind noul token, clientul contactează serverul pentru resurse.
8. Serverul acceptă cererea și furnizează resurse.

Acest exemplu descrie un flux cu un cod de autorizare (Authorization Code Flow). În plus, standardul OAuth 2.0 descrie următoarele fluxuri:

• Fluxul de grant implicit

Diferența față de fluxul codului de verificare este că clientul nu este autentificat de server și jetonul de acces este emis de server după cererea de autorizare.

• Reîmprospătarea unui flux de jetoane de acces expirat

Diferențele a acestui curent din exemplul de mai sus, după cum urmează: la pasul 2, serverul, pe lângă jetonul de acces, care are o durată de viață limitată, emite un jeton de reîmprospătare; la pasul 8, serverul verifică dacă jetonul de acces este valid (în sensul expirării duratei de viață), iar în funcție de aceasta, fie acordă acces la resurse, fie solicită actualizarea jetonului de acces (care este furnizat la prezentarea jetonul de reîmprospătare).

• Flux de acreditări a parolei proprietarului resursei

În acest flux, proprietarul resursei oferă clientului un login și o parolă, el le transmite serverului și primește un token pentru a accesa resursele. În ciuda faptului că acest mod de operare este oarecum contrar conceptului de creare a unui protocol, este descris în specificație.

• Fluxul de acreditări ale clienților

ÎN acest mod cum funcționează protocolul, serverul oferă un token de acces după ce clientul își transmite utilizatorul și parola, care au fost stabilite anterior de serverul de autorizare (specificația nu specifică exact cum). De fapt, clientul trece imediat atât la autorizare, cât și la autentificare.

OAuth acceptă două metode de autentificare a mesajelor de la client: HMAC -SHA1 și RSA -SHA1 . Este posibil să trimiteți mesaje fără semnătură, apoi „text simplu” este indicat în câmpul tip semnătură. Dar în acest caz, conform specificației, conexiunea dintre client și server trebuie stabilită prin SSL sau TLS.

Portaluri care utilizează OAuth

Discuţie

În iulie 2012, Eran Hammer, actualul editor al standardului OAuth 2.0, și-a anunțat demisia după trei ani de muncă la noul standard și a cerut ca numele său să fie eliminat din specificații. El a vorbit despre opiniile sale pe site-ul său. Mai târziu a făcut o prezentare. .

Note

Vezi si

Legături

Fundația Wikimedia. 2010.

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

Această opțiune necesită ridicarea ferestrei browserului în aplicație, dar nu necesită partea de server și un apel suplimentar de la server la server pentru schimb Cod de autorizare pe jeton de acces.

Exemplu

Deschideți browserul cu pagina de autentificare:
> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1 > Gazdă: connect.mail.ru

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ă

Autorizarea prin autentificare și parolă este o simplă solicitare POST, în urma căreia revine jeton de acces. Această schemă nu este ceva nou, dar este inclusă în standard pentru generalitate și este recomandată pentru utilizare numai atunci când alte opțiuni de autorizare nu sunt disponibile.

Exemplu

> POST /oauth/token HTTP/1.1 > Gazdă: connect.mail.ru > Tip de conținut: application/x-www-form-urlencoded > > grant_type=password&client_id=31337&client_secret=deadbeef [email protected]&parola=qwerty< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"SlAV32hkKG", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"8xLOxBtZp8", < }
Descriere în caietul de sarcini

Restabilirea autorizației anterioare

De obicei, jeton de acces Are perioadă limitată adecvarea. Acest lucru poate fi util, de exemplu, dacă este transmis peste canale deschise. Pentru a evita forțarea utilizatorului să se autentifice după expirare jeton de acces„și, în toate opțiunile de mai sus, pe lângă jeton de acces„Poate să revin din nou jeton de reîmprospătare. Îl poți folosi pentru a obține jeton de acces folosind o solicitare HTTP, similar cu autorizarea folosind un login și o parolă.

Exemplu

> POST /oauth/token HTTP/1.1 > Gazdă: connect.mail.ru > Tip de conținut: application/x-www-form-urlencoded > > grant_type=refresh_token&client_id=31337&client_secret=deadbeef&refresh_token=8xLOxBtZp8< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"Uu8oor1i", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"ohWo1ohr", < }

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 având propria bază de utilizatori - asta caut în acest caz, Eu o numesc „social”. 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ă

Să ne întoarcem la 2005 și să ne imaginăm că scriem o rețea de socializare. Are un formular pentru importarea contactelor de la adresa Cărți Gmail. Ce este necesar pentru a accesa Contacte Gmail? Desigur, autentificarea și parola pentru căsuța poștală. Dar dacă vă cerem să le introduceți pe site-ul nostru, utilizatorul va bănui că ceva nu este în regulă. Unde este garanția că nu salvăm parolele introduse pe server? Deci vrem să fie introdusă parola doar pe site-ul GMail, iar după aceea accesul la contacte prin API-ul GMail a fost oferit de către nostru rețea socială(poate pentru o vreme). Să cădem de acord asupra termenilor.

• 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.

Sarcină OAuth- asigurați-vă că Utilizatorul are posibilitatea de a lucra la Serviciul Consumatorului (pe o rețea de socializare) cu datele protejate ale Furnizorului de Servicii (GMail), introducând parola pentru aceste date exclusiv pe Furnizorul de Servicii și rămânând în același timp pe Serviciul Consumatorului site-ul web. Nu atât de greu, nu?

Prin ce diferă OAuth de OpenID?

OAuth este adesea denumit „protocol robot”, spre deosebire de OpenID ca „protocol de utilizator”. Nu-i confunda!

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.

Analogie cu poliția Imaginați-vă că sunteți un angajat al Departamentului de Investigații Criminale, în căutarea de a pune capăt cazului de furt WebMoney din 1973. Să cădem de acord asupra termenilor: Consumator OAuth: Anchetă penală. Utilizator: Ofiţer de Investigaţii Criminale. Furnizor de servicii: Dosar card al arhivei infracțiunilor. OpenID: un angajat al Departamentului de Investigații Criminale (Utilizator) vine la Indexul Cardurilor (Furnizorul de Servicii), prezintă Autorizația la intrare și sortează cardurile pe loc în căutarea informațiilor. OAuth: un angajat al Departamentului de Investigații Criminale (Utilizator) direct de la serviciu (Consumator) sună la Card Index (Furnizorul de servicii). Își raportează numele; dacă este recunoscut (Autorizare), el cere să furnizeze o listă cu toate crimele pentru 1973 (apel API). După cum puteți vedea, OpenID și OAuth sunt lucruri diferite. OpenID vă permite să accesați anumite resurse chiar pe loc. OAuth asigură că unele informații sunt preluate de la un serviciu de la distanță printr-un API.

Schița acestui articol

Înainte de a trece la partea principală, să vedem exact cum vom proceda.

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

O modalitate bună de a înțelege ceva este să o faci singur, călcând pe toată grebla așezată pe parcurs. Acum vom reinventa roata: să încercăm să ne imaginăm cum am rezolva problema interacțiunii dintre Consumator și Furnizor de servicii fără nicio protocoală standardizată.

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 va reveni 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 ea ș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

Ei bine, desigur, ați ghicit că atacatorul va plasa mai întâi un link pe site-ul său și vă va forța să dați clic pe el. Ca urmare, el va primi cheia secretă pe care a returnat-o GMail și, prin urmare, contactele dvs.:

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

Să presupunem că am protejat cumva calea retpath și acum poate indica doar site-ul nostru. Dar problema cu parametrul secret rămâne.Secretul poate fi spionat din spate sau interceptat ascultând traficul WiFi. Sau într-o zi site-ul dvs. va avea o vulnerabilitate XSS care vă permite să „furați” cheia secretă. Cu valoarea secretă, un atacator vă va putea citi carte de adrese. Aceasta înseamnă că secretul trebuie protejat împotriva interceptării (în mod ideal, nu ar trebui să fie transmis deloc prin URL).

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

Dacă fiecare apel API necesită un secret diferit, atunci va trebui să organizăm atâtea redirecționări către site-ul Furnizorului de servicii câte apeluri există. Cu intens folosind API-ul funcționează foarte lent și este destul de incomod...

Rake numărul patru: identificare slabă a consumatorului

GMail, desigur, vrea să știe cine își folosește API-ul. Permite accesul la unele site-uri și interzice accesul altora... Aceasta înseamnă că la crearea unei cereri în formularul de import de contact, Consumatorul (site-ul) trebuie să fie „prezentat” Furnizorului de servicii (GMail). În cazul nostru, această funcție este parțial efectuată de retpath (numele site-ului din el), dar aceasta metoda nu universal, pentru că Mecanismul de „prezentare” trebuie activat și la apelarea metodelor API.

Fundația OAuth

Este de remarcat faptul că au mai rămas multe „greble subacvatice”. Nu le voi descrie aici, deoarece aceste greble se află în șanțul Marianelor (adâncime, 10920 m). Ar fi nevoie de o duzină de pagini pentru a descrie vulnerabilitățile. Deci voi merge direct la Descriere OAuth, unde toate problemele au fost deja rezolvate.

Aplicație = Consumer + acces API

Când lucrați cu OAuth, este important ca termenul Consumator să nu se limiteze la sensul de „site”. Consumatorul este ceva aplicarea, iar unde se află nu este atât de important. Exemple de consumatori din viata reala: Dar nu puteți face mizerie numai cu OAuth. Într-adevăr, tot ceea ce oferă OAuth este capacitatea de a vă autentifica serviciu de la distanță(Furnizorul de servicii) și faceți solicitări autorizate către API. Nu contează cum este structurat acest API: ar putea fi SOAP pur, o abordare REST etc. Principalul lucru este că toată lumea Metoda API acceptați ca intrare parametri speciali trecuți conform Protocolul OAuth.

Token = Cheie + Secret

Unul dintre principiile OAuth afirmă că nicio cheie privată nu trebuie transmisă în public în cereri (ne-am uitat la motivul în exemplul de mai sus). Prin urmare, protocolul funcționează cu conceptul de Token. Token-ul este foarte asemănător cu perechea login + parolă: login - informații deschise, iar parola este cunoscută numai de către părțile expeditoare și primitoare. În termeni OAuth, analogul unei autentificări se numește Cheie, iar analogul unei parole se numește Secret. Situația în care Secretul este cunoscut doar de expeditor și destinatar, dar de nimeni altcineva, se numește Secret Partajat.

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ă

„Semnătura digitală” sună înfricoșător, dar de fapt este un lucru destul de evident. Când semnați un document cu un stilou, certificați că documentul a fost scris de dvs. și nu de altcineva. Semnătura dvs. este, așa cum spunea, „adăugata” documentului și este însoțită de „un set”.

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

Pentru a înțelege cu adevărat OAuth, avem nevoie de două lucruri:

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.)

Privind codul de script demo și citind explicațiile de mai jos în articol, puteți înțelege detaliile protocolului.

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

Să vorbim despre de unde provin aplicațiile și despre cum învață Furnizorul de servicii despre ele. Totul este destul de simplu: Furnizorul de servicii are un formular special de înregistrare a cererii pe care oricine îl poate folosi. Iată un exemplu de astfel de formă:

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

În exemplul cu GMail, am folosit 2 tipuri de apeluri la distanță: a) redirecționare prin browser; b) accesarea API-ului din interiorul scriptului.

Ș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: solicitările intermediare suplimentare 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 jeton de solicitare 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 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 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

Sfârșitul scenariului ar trebui să fie clar, fără explicații detaliate.

Lista 14: Sfârșitul scriptului: ieșire widget

// sfârșitul cazului ) ) // Obțineți toate tweet-urile disponibile. $text = file_get_contents("http://api.rutvit.ru/search.xml?rpp=5&q=" . urlencode("#" . TAG)); $TWEETS = nou SimpleXMLElement($text); // Comandă rapidă pentru afișarea unui mesaj cu recodare și citare. funcția e($text, $quote = 1) ( $text = iconv("utf-8", ENCODING, $text); echo $quote? htmlspecialchars($text) : $text; ) ?> starea ca $tweet) (?> user->screen_name)?>: text_formatted, 0)?> ?action=form_is_sent" style="margin: 1em 0 0 0">

Link-uri utile pe OAuth

• rutvit

Adaugă etichete