OAuth: opis protokola na jednostavnom i razumljivom jeziku.

Postoji mnogo načina za širenje zlonamjerne neželjene pošte na VKontakte. Ali štetnici ne spavaju, na pamet im dolazi sve zanimljivije ideje. I pokazalo se da je to baš tako. Prevaranti su ga naučili koristiti da zaobiđu stranicu upozorenja o zlonamjernim stranicama.

A sve je počelo činjenicom da se jednog dana na mom zidu pojavila ova poruka:


Iz radoznalosti sam pratio link i završio na drugoj phishing stranici. Ali sama poveznica mi se učinila čudnom, izgledala je ovako (pola znakova u ASCII):
vkontakte.ru/away.php ? do=http%3A%2F%2FApi.vKontakte.Ru%2F%2Fo%2561u%2574%…

Ovdje zabava počinje...

Analizirajmo drugu poveznicu u dijelovima:

Što znači svaka od opcija:

• client_id - ID aplikacije za koju je potrebna autorizacija;
• redirect_uri - adresa na koju će access_token biti poslan (putem preusmjeravanja);
• display - tip prozora za autorizaciju (stranica, popup, touch i wap).

Zapravo, redirect_uri sadržavao je adresu stranice za krađu identiteta. Budući da je napravljena pogreška u parametru prikaza (u njega je ušlo smeće "?390852"), prozor za autorizaciju nije prikazan, ali je preusmjeravanje na phishing stranicu odmah preusmjereno na phishing stranicu s parametrima: error=invalid_request&error_description= Nevažeće+prikaz+prošlo

To je cijela poanta zaobilaženja crne liste zlonamjernih web-mjesta na VKontakteu. Pojavljuje se samo upozorenje o prijelazu na api.vk.com. I kao rezultat prijelaza, idemo ravno na mjesto za krađu identiteta koje je na crnoj listi. Kada kliknete na vezu vkontakte.ru/away.php?to=vgostivk.dyndns**:

Kako se ispostavilo, aplikacija koja je navodno zahtijevala autorizaciju visila je na hakiranom korisniku:

I sama phishing stranica bila je prilično zanimljiva. Dizajn je, kao i obično, bio kontakt i ponudio prijavu. Prošao sam autorizaciju putem nasumične pošte i lozinke, savršeno sam progutao lažnjak. Tada je bilo još zanimljivije, na glavnoj stranici bile su vijesti iz "Pavela Durova":

Nakon klika na gumb "Kreiraj osobni brojač" uslijedila je prekrasna traka napretka. Zatim je zatraženo da navedete svoj broj i pošaljete sms:

U teoriji, nakon uspješne “aktivacije”, trebao je biti prebačen na stranicu activ.php, ali nisam mogao doći tamo. Izvodi iz JS skripti phishing stranice:

...
ako (req.status == 200) (
// ako je status 200 (OK) - izdati odgovor korisniku
if (req.responseText == "ok") (
//statusElem.innerHTML = "Sve je dobro!";
get_aktivacija();
}
if (req.responseText == "ne" ) (statusElem.innerHTML = "Nevažeći aktivacijski kod";}
//statusElem.innerHTML = "Odgovor poslužitelja: "+req.responseText;
...
funkcija get_activation() (
dokument .location="activ.php" ;
}

* Ovaj izvorni kod označen je alatom za isticanje izvornog koda.

Ishod: Prevaranti koriste OAuth 2.0 kako bi zaobišli upozorenja, dobili korisničku lozinku i e-poštu, pa čak i pokušali ih navesti da pošalju sms (najvjerojatnije korištenjem sustava pretplate).

Godine 2010. započeo je rad na potpuno novoj verziji protokola OAuth 2.0 koja neće biti unatrag kompatibilna s OAuth 1.0. U listopadu 2012. okvir OAuth 2.0 objavljen je u RFC 6749, a korištenje nositelja tokena u RFC 6750, oba standarda prate zahtjeve za komentarima. Dodatni RFC-ovi se još uvijek razvijaju.

Bilo je nekoliko preduvjeta za izradu OAutha 2.0. Prije svega, OAuth je prilično netrivijalan za korištenje na strani klijenta. Jedan od ciljeva razvoja novog OAutha je olakšati razvoj klijentskih aplikacija. Drugo, unatoč implementaciji tri metode (nazvane tokovi) deklarirane u standardu za dobivanje tokena (jedinstvenog identifikatora) za autorizaciju: za web aplikacije, desktop klijente i mobilne klijente, zapravo su sve tri metode spojene u jednu. I, treće, pokazalo se da je protokol slabo skalabilan. Planirano je dodati:

• 6 novih tema.

Tijek korisničkog agenta - za klijente koji rade unutar korisničkog agenta (obično web preglednika). Protok web poslužitelja - za klijente koji su dio aplikacije web poslužitelja, dostupni putem HTTP zahtjeva. Tijek uređaja - Prikladno za klijente koji rade na ograničenim uređajima, ali gdje krajnji korisnik ima zaseban pristup pregledniku na drugom računalu ili uređaju. Tijek korisničkog imena i lozinke - Koristi se u slučajevima kada korisnik vjeruje da će klijent rukovati njegovim vjerodajnicama, ali i dalje nepoželjno dopušta klijentu da pohrani korisničko ime i lozinku. Ovaj tijek je prikladan samo kada postoji visok stupanj povjerenja između korisnika i klijenta. Tijek vjerodajnica klijenta - Klijent koristi svoje vjerodajnice za dobivanje tokena. Tijek tvrdnje - Klijent šalje tvrdnju, kao što je SAML tvrdnja, autorizacijskom poslužitelju u zamjenu za token. Aplikacije koje se pokreću na stolnom računalu ili mobilnom uređaju mogu se implementirati pomoću gornjih tokova.

• Token nositelja.

Metoda autorizacije slična je postojećoj metodi autorizacije kolačića. U ovom slučaju, token se izravno koristi kao tajna (samo postojanje tokena autorizira klijenta) i prenosi se preko HTTPS-a. To vam omogućuje pristup API-ju putem jednostavnih skripti (na primjer, korištenjem cURL-a).

• Pojednostavljeni potpis.

Potpis je uvelike pojednostavljen kako bi se eliminirala potreba za posebnim raščlanjivanjem, kodiranjem i sortiranjem parametara.

• Kratkotrajni tokeni s dugotrajnom autorizacijom.

Umjesto izdavanja dugotrajnog tokena (koji se tijekom vremena može kompromitirati), poslužitelj pruža kratkoročni pristup i dugoročnu mogućnost obnavljanja tokena bez intervencije korisnika.

• Razdvajanje uloga.

Za autorizaciju i pružanje pristupa API-ju mogu biti odgovorni različiti poslužitelji.

Vrijedi napomenuti da iako standard OAuth 2.0 još nije odobren, neke usluge ga već koriste. Na primjer, Facebook Graph API podržava samo OAuth 2.0.

Razlika između OAuth-a i OpenID-a

Postoji zabluda da je OAuth proširenje OpenID protokola. Zapravo nije. Iako OpenID i OAuth imaju mnogo zajedničkog, potonji je samostalni protokol koji nema nikakve veze s OpenID-om.

Vremenska oznaka i Nonce

Kako bi spriječio prijetnju zahtjeva za ponovnu upotrebu, OAuth koristi jednokratnu i vremensku oznaku . Izraz "nonce" znači da se ovo vrijeme koristi jednom i da je jedinstveni nasumični skup slova i brojeva, koji je namijenjen jedinstvenoj identifikaciji svakog potpisanog zahtjeva. Imajući jedinstveni identifikator za svaki zahtjev, davatelj usluga će moći spriječiti ponovnu upotrebu zahtjeva. To znači da klijent generira jedinstveni niz za svaki zahtjev koji pošalje poslužitelju, a poslužitelj prati sve korištene nonces kako bi spriječio njihovo korištenje po drugi put.

Korištenje nonces može biti vrlo skupo za poslužitelj, jer zahtijevaju trajnu pohranu svih primljenih nonces. Kako bi olakšao implementaciju, OAuth dodaje vremensku oznaku svakom zahtjevu, što poslužitelju omogućuje pohranjivanje nonce samo ograničeno vrijeme. Kada stigne zahtjev s vremenskom oznakom koja je ranije od pohranjenog vremena, on se odbija jer poslužitelj više nema jednokratnu stavku iz tog vremena.

Dozvole i tokeni

OAuth koristi tri vrste vjerodajnica: vjerodajnice klijenta (korisnički ključ i tajne ili klijentske vjerodajnice), privremene vjerodajnice (zahtjev za token i tajne ili privremene vjerodajnice) i tokene (pristupni token i tajne ili vjerodajnice za tokene).

Za provjeru autentičnosti klijenta koriste se vjerodajnice klijenta. To poslužitelju omogućuje prikupljanje informacija o klijentima. Koristeći svoje usluge, poslužitelj nekim klijentima nudi posebne tretmane, kao što je besplatna kontrola pristupa, ili kako bi vlasniku resursa pružio detaljnije informacije o klijentima koji pokušavaju pristupiti njihovim zaštićenim resursima. U nekim slučajevima, vjerodajnicama klijenta možda se neće vjerovati i mogu se koristiti samo u informativne svrhe, kao što su aplikacije za stolna računala.

Token se koristi umjesto imena i lozinke vlasnika resursa. Vlasnik resursa neće dijeliti svoje vjerodajnice s klijentom, ali će dopustiti poslužitelju da izda klijentu token, posebnu klasu vjerodajnica koje predstavljaju odobrenje pristupa. Klijent koristi token za pristup zaštićenom resursu bez poznavanja lozinke vlasnika resursa.

Token se sastoji od identifikatora tokena, obično (ali ne uvijek) slučajnog skupa slova i brojeva koji je jedinstven, teško pogodan, i ključa za zaštitu tokena od korištenja od strane neovlaštenih osoba. Token je ograničen u opsegu i trajanju, a vlasnik resursa ga može opozvati u bilo kojem trenutku, bez utjecaja na druge tokene izdane drugim klijentima.

OAuth proces autorizacije također koristi skup privremenih vjerodajnica koje se koriste za određivanje zahtjeva za autorizaciju. Kako bi se zadovoljile različite vrste klijenata (web, desktop, mobilni itd.), privremene vjerodajnice nude dodatnu fleksibilnost i sigurnost.

Kako radi OAuth

Shema OAuth protokola

Objasnimo kako OAuth protokol radi na primjeru. Pretpostavimo da korisnik (vlasnik resursa) želi ispisati svoje fotografije (resurse) prenesene na photos.example.net (poslužitelj) koristeći uslugu ispisa "printer.example.net" (klijent).

1. Klijent šalje zahtjev poslužitelju putem HTTPS protokola koji sadrži identifikator klijenta, vremensku oznaku, povratnu adresu za koju treba vratiti token, vrstu korištenog digitalnog potpisa i sam potpis.
2. Poslužitelj prihvaća zahtjev i odgovara klijentu s pristupnim tokenom i dijelom zajedničke tajne.
3. Klijent prosljeđuje token vlasniku resursa (korisniku) i preusmjerava ga na poslužitelj radi autorizacije.
4. Poslužitelj, nakon što je od korisnika primio token, traži od njega njegovu prijavu i lozinku, a u slučaju uspješne autentifikacije traži od korisnika da potvrdi pristup klijenta resursima (autorizaciju), nakon čega korisnika server preusmjerava na klijent.
5. Klijent šalje token poslužitelju koristeći TLS protokol i traži pristup resursima.
6. Poslužitelj prihvaća zahtjev i odgovara klijentu s novim tokenom za pristup.
7. Koristeći novi token, klijent kontaktira poslužitelj za resurse.
8. Poslužitelj prihvaća zahtjev i daje resurse.

Ovaj primjer opisuje tijek autorizacijskog koda. Osim toga, u standardu OAuth 2.0 opisani su sljedeći tokovi:

• Implicitni tijek davanja

Razlika od tijeka koda za potvrdu je u tome što poslužitelj nije autentificiran klijentu i poslužitelj izdaje token za pristup nakon zahtjeva za autorizacijom.

• Osvježavanje toka tokena pristupa koji je istekao

Razlike između ovog tijeka i gornjeg primjera su sljedeće: u koraku 2, poslužitelj, uz token za pristup, koji ima ograničeni vijek trajanja, izdaje token za osvježavanje; u koraku 8, poslužitelj provjerava je li pristupni token valjan (u smislu isteka životnog vijeka), i ovisno o tome, ili odobrava pristup resursima, ili zahtijeva osvježavanje pristupnog tokena (koji se daje nakon predočenja token za osvježavanje).

• Tijek vjerodajnica lozinke vlasnika resursa

U ovom tijeku, vlasnik resursa daje klijentu prijavu i lozinku, on ih prosljeđuje poslužitelju i prima token za pristup resursima. Unatoč činjenici da je ovaj način rada donekle proturječan konceptu stvaranja protokola, opisan je u specifikaciji.

• Tijek vjerodajnica klijenta

U ovom načinu rada protokola poslužitelj osigurava pristupni token nakon što klijent prenese svog korisnika i lozinku, koju je prethodno postavio autorizacijski poslužitelj (specifikacija ne navodi kako). Zapravo, klijent odmah prolazi i autorizaciju i autentifikaciju.

OAuth podržava dvije metode za provjeru autentičnosti poruka od klijenta: HMAC -SHA1 i RSA -SHA1. Moguće je slati poruke i bez potpisa, tada je u polju za vrstu potpisa naveden "običan tekst". No, u ovom slučaju, prema specifikaciji, veza između klijenta i poslužitelja mora se uspostaviti putem SSL ili TLS protokola.

Portali koji koriste OAuth

Rasprava

U srpnju 2012. Eran Hammer, trenutni urednik standarda OAuth 2.0, najavio je ostavku nakon tri godine rada na novom standardu i zatražio da se njegovo ime izbaci iz specifikacija. O svojim stavovima govorio je na svojoj web stranici. Kasnije je održao prezentaciju. .

Bilješke

vidi također

Linkovi

Zaklada Wikimedia. 2010 .

1. Otvaranje ugrađenog preglednika sa stranicom za autorizaciju
2. Od korisnika se traži da potvrdi dodjelu prava
3. Ako se korisnik slaže, preglednik će preusmjeriti na rubnu stranicu u fragmentu (nakon #) čiji je URL dodan pristupni token
4. Aplikacija presreće preusmjeravanje i prima pristupni token s adrese stranice

Ova opcija zahtijeva podizanje prozora preglednika u aplikaciji, ali ne zahtijeva stranu poslužitelja i dodatni poziv između poslužitelja za razmjenu autorizacijski kod na pristupni token.

Primjer

Otvorite preglednik sa stranicom za autorizaciju:
> GET /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1 > Host: connect.mail.ru

Nakon što korisnik dodijeli prava, dolazi do preusmjeravanja na standardnu ​​stub stranicu, za Mail.Ru to je 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

Aplikacija mora presresti posljednje preusmjeravanje, dobiti s adrese access_token i koristiti ga za pristup zaštićenim resursima.

Autorizacija prijave i lozinke

Autorizacija putem prijave i lozinke je jednostavan POST zahtjev koji se vraća pristupni token. Ova shema nije ništa novo, ali je uključena u standard radi općenitosti i preporučuje se samo kada druge opcije autorizacije nisu dostupne.

Primjer

> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_ty [e-mail zaštićen] corp.mail.ru& password=qwerty< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"SlAV32hkKG", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"8xLOxBtZp8", < }
Opis u specifikaciji

Vraćanje prethodne autorizacije

Obično, pristupni token ima ograničen rok trajanja. To može biti korisno, na primjer, ako se prenosi preko otvorenih kanala. Kako biste izbjegli prisiljavanje korisnika da se prijavi nakon isteka roka pristupni token"i, u svim gore navedenim opcijama, pored pristupni token„možeš se vratiti opet token za osvježavanje. Može se dobiti pristupni token korištenjem HTTP zahtjeva, slično autorizaciji prijave i lozinke.

Primjer

> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Vrsta sadržaja: application/x-www-form-urlencoded > > grant_type=refresh_token&client_id=31337&client_secret=deadbeef&refresh_token=8xLOxBtZp< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"Uu8oor1i", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"ohWo1ohr", < }

Popularan protokol koji dopušta društvenim usluge za međusobnu integraciju i pruža siguran način razmjene osobnih podataka. OAuth može povezati 2 usluge, od kojih svaka ima svoju korisničku bazu - to je ono što u ovom slučaju nazivam "društvenim". Kada počnete raditi s OAuthom, prvi je dojam da je protokol vrlo kompliciran i suvišan. U ovom članku pokušat ću objasniti osnove OAutha na ljudskom jeziku.

Primjer unakrsnog ovlaštenja

Vratimo se u 2005. godinu i zamislimo da pišemo društvenu mrežu. Ima obrazac za uvoz kontakata iz Gmail adresara. Što vam je potrebno za pristup vašim Gmail kontaktima? Naravno, prijava i lozinka iz kutije. Ali ako ih zamolimo da ih unesu na našu stranicu, korisnik će posumnjati da nešto nije u redu. Gdje je jamstvo da unesene lozinke ne spremamo na server? Stoga želimo da se unese lozinka samo na web stranici Gmaila, a nakon toga je našoj društvenoj mreži (možda privremeno) omogućen pristup kontaktima putem GMail API-ja. Dogovorimo se oko uvjeta.

• potrošač: potrošač; skripta za obradu obrasca za uvoz kontakata na društvenoj mreži.
• Pružatelj usluga: pružatelj podataka; Gmail koji sadrži podatke iz adresara od interesa za potrošača.
• korisnik: Korisnik koji ima račun i kod Potrošača i kod Davatelja usluga.
• zaštićeni resurs: osobni podaci; kontakte iz adresara na Gmailu (tj. resursi davatelja usluga).
• API pružatelja usluga: GMail API koji omogućuje bilo kojoj skripti da dobije kontakte iz GMail adresara.

OAuth zadatak- pobrinuti se da Korisnik ima priliku raditi na Potrošačkoj usluzi (na društvenoj mreži) sa zaštićenim podacima Pružatelja usluge (GMail), unoseći lozinku za te podatke isključivo na Davatelju usluge i ostajući na web stranici Potrošača . Nije tako teško, zar ne?

Po čemu se OAuth razlikuje od OpenID-a?

OAuth se često naziva "protokol robota", za razliku od OpenID-a, "korisnički protokol". Nemojte ih zbuniti!

1. OpenID je protokol za ubrzanu registraciju. OpenID omogućuje korisniku da dobije račun na bilo kojoj usluzi bez unosa lozinke ako je već registriran negdje drugdje na internetu. (A zatim možete ući u uslugu bez unosa lozinke, ovlašteni ste "negdje".) Na primjer, ako imate Yandex račun, možete ga koristiti za "prijavu" na bilo koju uslugu koja podržava OpenID autorizaciju.
2. OAuth je protokol za ovlašteni pristup API-ju treće strane. OAuth omogućuje skripti potrošača da dobije ograničen pristup API-ju podacima pružatelja usluga treće strane ako korisnik da zeleno svjetlo. Oni. to je sredstvo za pristup API-ju.

Policijska analogija Zamislite da ste član Odjela za kriminalističku istragu koji tražite krajeve u slučaju krađe WebMoneya iz 1973. godine. Dogovorimo se oko uvjeta: OAuth potrošač: Kriminalističko istraživanje. korisnik: službenik Odjela za kriminalistiku. Pružatelj usluga: Kartoteka arhive zločina. OpenID: djelatnik Odjela za kriminalističku obradu (Korisnik) dolazi do Card Indexa (Davatelja usluge), na ulazu predočava vjerodajnicu (Autorizaciju) i na licu mjesta prebira kartice u potrazi za informacijama. OAuth: zaposlenik Odjela za kriminalističku obradu (Korisnik) poziva Card Index (Davatelj usluge) izravno s posla (Potrošač). Javlja svoje prezime; ako je prepoznat (Ovlaštenje), traži popis svih zločina za 1973. godinu (API poziv). Kao što vidite, OpenID i OAuth su različite stvari. OpenID vam omogućuje pristup određenim resursima na licu mjesta. OAuth omogućuje dobivanje nekih informacija s udaljene usluge putem API-ja.

Pregled ovog članka

Prije nego prijeđemo na glavni dio, da vidimo kako ćemo se točno kretati.

1. Razmotrimo probleme koji nastaju tijekom "ručne" provedbe unakrsnog ovlaštenja.
2. Razgovarajmo o tome što je "aplikacija" i tko je potrošač.
3. Dotaknimo se osnova kriptografije.
4. Označimo demo aplikaciju koju ćemo napisati u ovom članku.
5. Odlučimo se za testni OAuth poslužitelj na kojem ćemo eksperimentirati.
6. Prođimo kroz sve korake OAuth protokola i pružimo izvore skripte.

O izumu bicikala

Dobar način da nešto shvatite je da to učinite sami, nagazivši na sve grablje usput. Sada ćemo ponovno izumiti kotač: pokušat ćemo zamisliti kako bismo riješili problem interakcije između potrošača i pružatelja usluga bez ikakvih standardiziranih protokola.

Prvo, napišimo sam obrazac za uvoz GMail kontakta: Zatim ćemo zamoliti programere GMail-a da ga naprave tako da kada korisnik prijeđe na /auth.php URI, dobije obrazac za autorizaciju (u našem biciklističkom svijetu, GMail je napisan u PHP-u). Nakon uspješnog unosa lozinke, korisnik bi trebao biti preusmjeren na stranicu čiji je URL naveden u parametru retpath. Također, u URL-u mora biti proslijeđen neki tajni ključ koji se već može koristiti za pristup GMail API-ju.

Dakle, nakon unosa lozinke, korisnik će se vratiti na našu stranicu na sljedeću adresu: I mi ćemo se okrenuti GMail API-ju iz /import.php skripte, proslijediti mu ključ Y49xdN0Zo2B5v0RR i učitati kontakte: Pa, idemo sada prebrojite grablje (jer izbočine će biti prekasno za brojanje).

Prvi rake: zamjena povratne adrese retpath

Pa, naravno, pogodili ste da će napadač prvo postaviti link na svoju stranicu i natjerati vas da kliknete na nju. Kao rezultat toga, on će dobiti tajni ključ koji je vratio GMail, a time i vaše kontakte:

Drugi rake: "prisluškivanje" tajnog ključa

Pretpostavimo da smo na neki način zaštitili retpath, a sada može upućivati ​​samo na našu stranicu. No problem s parametrom tajne ostaje. Tajna se može proviriti odostraga ili presresti slušanjem WiFi prometa. Ili će vaša stranica jednog dana imati XSS ranjivost koja vam omogućuje da "povučete" tajni ključ. Ako se postavi na tajno, napadač će moći čitati vaš adresar. Dakle, morate zaštititi tajnu od presretanja (u idealnom slučaju, nemojte je uopće proslijediti kroz URL).

Treći rake: previše preusmjeravanja

Ako svaki API poziv zahtijeva drugačiju tajnu, tada ćemo morati organizirati onoliko preusmjeravanja na stranicu davatelja usluga koliko imamo poziva. Uz intenzivnu upotrebu API-ja, ovo radi vrlo sporo i nezgodno kako bi ...

Rake Four: Loša identifikacija potrošača

GMail, naravno, želi znati tko koristi njegov API. Dopustite pristup nekim stranicama i zabranite pristup drugima... To znači da prilikom formiranja zahtjeva u obliku uvoza kontakata, Potrošač (web stranica) mora biti “prezentovan” Davatelju usluge (GMail). U našem slučaju, ovu funkciju djelomično izvodi retpath (naziv stranice u njoj), ali ova metoda nije univerzalna, jer mehanizam "prezentacije" također mora biti uključen pri pozivanju API metoda.

Osnivanje OAuth-a

Važno je napomenuti da još uvijek ima mnogo "podvodnih grabulja". Ovdje ih neću opisivati, jer ove grablje leže u Marijanskom rovu (duboka 10920 m). Za opis ranjivosti bilo bi potrebno desetak stranica. Stoga ću skočiti ravno na opis OAuth-a, gdje su svi problemi već riješeni.

Aplikacija = potrošač + pristup API-ju

Kada radite s OAuthom, važno je da izraz potrošač nije ograničen na značenje "web-stranice". Potrošač je neki dodatak, a gdje se nalazi nije toliko bitno. Primjeri potrošača iz stvarnog života: Ali ne možete kuhati kašu samo iz OAutha. Doista, sve što OAuth daje je mogućnost prijave na udaljenu uslugu (davatelja usluga) i autoriziranih zahtjeva API-ju. Nije važno kako je ovaj API uređen: to može biti čisti SOAP, REST pristup itd. Glavna stvar je da svaka API metoda prihvaća posebne parametre kao ulaz, proslijeđene prema OAuth protokolu.

Token = ključ + tajna

Jedno od načela OAuth-a je da se nikakvi tajni ključevi ne smiju javno prosljeđivati ​​u zahtjevima (razgovarali smo zašto u gornjem primjeru). Stoga protokol djeluje s konceptom Tokena. Token je vrlo sličan paru prijava + lozinka: prijava je otvorena informacija, a lozinka je poznata samo strani koja šalje i prima. U smislu OAuth-a, analogni login se zove Key, a analogni lozinke je Secret. Situacija kada je tajna poznata samo pošiljatelju i primatelju, ali nikome drugome, naziva se Zajednička tajna.

Dakle, ako se Potrošač i Dobavljač nekako međusobno dogovore oko Zajedničke tajne, mogu otvoreno razmijeniti odgovarajuće ključeve (Ključ) u URL-u bez straha da će presretanje tih ključeva biti opasno. Ali kako zaštititi URL s ključem od krivotvorenja?

Poruka = ​​Dokument + Digitalni potpis

"Digitalni potpis" zvuči zastrašujuće, ali je zapravo prilično očito. Kada potpisujete dokument olovkom, potvrđujete da ste taj dokument napisali vi, a ne netko drugi. Vaš potpis je, takoreći, "dodan" dokumentu i ide s njim u "jedan set".

Slično, digitalni potpis se dodaje nekom bloku podataka, koji potvrđuje da osoba koja je generirala te podatke ne lažno predstavlja drugu osobu. Digitalni potpis ne kriptira dokument, samo jamči njegovu autentičnost! Potpisivanje omogućuje istu Zajedničku tajnu, koja je poznata primatelju i pošiljatelju, ali nikome drugome.

Kako radi? Neka naša $sharedSecret = 529AeGWg, a mi to šapnemo na uho primatelju. Želimo prenijeti poruku "Moj telefon je 1234567" uz zajamčenu zaštitu od krivotvorenja od strane napadača.

1. Potrošač poruci dodaje digitalni potpis, općenito $transfer = $message. "-" . md5($message . $sharedSecret); // $transfer = "Moj telefon je 1234567" . "-" . md5("Moj telefon je 1234567" . "529AeGWg")
2. Davatelj usluge uzima podatke, dijeli ih natrag na 2 dijela - $message i $signature - i radi potpuno istu operaciju: $signatureToMatch = md5($message . $sharedSecret); // $signatureToMatch = md5("Moj telefon je 1234567" . "529AeGWg"); Zatim ostaje samo usporediti rezultirajuću vrijednost $signatureToMatch s onim što je bilo u primljenim podacima $signature i prijaviti lažno ako se vrijednosti ne podudaraju.

Demonstracija kako OAuth radi s jednostavnom aplikacijom

Da bismo stekli dojam za OAuth, potrebne su nam dvije stvari:

1. Skripta koja implementira klijentski dio protokola. Napisao sam baš tako malu PHP skriptu (link za zip arhivu). Ovo je widget koji se može umetnuti u PHP stranice.
2. OAuth testni poslužitelj na kojem možemo eksperimentirati. U tu svrhu prikladno je koristiti RuTwit: postoji stranica http://rutvit.ru/apps/new , koja vam omogućuje dodavanje testne aplikacije za 30 sekundi. (Usput, povratni URL u obrascu može se izostaviti - i dalje ga prosljeđujemo iz testne skripte.)

Gledajući kod demo skripte i čitajući objašnjenja kasnije u članku, možete razumjeti detalje protokola.

Ovaj widget možete ugraditi na bilo koju PHP stranicu jednostavnim kopiranjem koda i podešavanjem izgleda. Prikazuju se svi tweetovi s servisa RuTwit označeni navedenim hash tagom, a moguće je dodati i nove tweetove (tu u igri dolazi OAuth). Widget koristi RuTwit API i OAuth autorizaciju, koji su, inače, isti kao i Twitter API standard. Ovu skriptu možete pokrenuti na svom testnom poslužitelju. Da biste to učinili, morate izvršiti tri koraka:

1. Preuzmite kod skripte i rasporedite ga u bilo koji prikladan direktorij na web poslužitelju.
2. Registrirajte novu testnu aplikaciju na OAuth poslužitelju.
3. Nakon registracije aplikacije, zamijenite parametre OA_CONSUMER_KEY i OA_CONSUMER_SECRET u skripti vrijednostima primljenim od poslužitelja.

Registracija aplikacije i postavke

Razgovarajmo o tome odakle dolaze aplikacije i kako davatelj usluga saznaje za njih. Sve je vrlo jednostavno: Davatelj usluga ima poseban obrazac za prijavu koji svatko može koristiti. Evo primjera takvog oblika:

Nakon registracije aplikacije, dobivate 5 parametara koji su potrebni za rad s OAuthom. Evo kako bi mogli izgledati:

Ovdje su Consumer key i Consumer secret neka vrsta "login + password" vaše aplikacije (sjećate se gornjeg razgovora o tokenima? ovo je samo jedan od njih). Dopustite mi da vas podsjetim da je tajna potrošača Zajednička tajna, poznata samo pošiljatelju i primatelju, ali nikome drugome. Preostale 3 vrijednosti određuju URL-ove usluge, čije ćemo značenje sada razmotriti.

OAuth = dohvaćanje tokena zahtjeva + preusmjeravanje na autorizaciju + dohvaćanje tokena za pristup + API poziva

U primjeru GMail-a koristili smo 2 vrste udaljenih poziva: a) preusmjeravanje putem preglednika; b) pristup API-ju iz skripte.

Otkrili smo i niz sigurnosnih problema, što sugerira da bi izazova trebalo biti više. Ovo je ono što se događa u OAuth-u: dodaju se dodatni zahtjevi iz skripte Consumer davatelju, koji rade s tokenima. Pogledajmo ih.

1. Obrada podnošenja obrasca. Nije dio OAutha, već dio naše aplikacije. Prije pristupa API-ju Davatelja, moramo primiti nalog za ovu radnju od korisnika. Evo primjera takve narudžbe:
2. Dohvati token zahtjeva (interni zahtjev).
   • Skripta potrošača poziva URL zahtjeva za token Pružatelj: na primjer, api.rutvit.ru/oauth/request_token . Zahtjev prenosi ključ potrošača - "prijava aplikacije", a sam zahtjev je potpisan korištenjem tajne potrošača - "lozinke aplikacije", koja ga štiti od krivotvorenja.
   • Kao odgovor, Pružatelj generira i vraća token pun smeća koji se zove Request Token. I dalje će nam trebati, pa ga moramo negdje spremiti - na primjer, u varijablu sesije $S_REQUEST_TOK.
3. Preusmjeravanje na autorizaciju (preko preusmjeravanja preglednika). Sada naša aplikacija ima jedinstveni token zahtjeva. Za korištenje ovog tokena potrebno je dobiti dopuštenje korisnika, tj. Pitajte ga autorizirati token zahtjeva.
   • Potrošač preusmjerava preglednik na određeno Autorizirajte URL Pružatelj: na primjer, api.rutvit.ru/oauth/authorize . Ključ tokena zahtjeva se prosljeđuje u parametrima.
   • Pružatelj prikazuje obrazac za autorizaciju za svog korisnika i, ako je ovlašten, preusmjerava preglednik natrag. Gdje točno? I to specificiramo u parametru oauth_callback.
4. Dohvati pristupni token (interni zahtjev). Dakle, preglednik se vratio u našu aplikaciju nakon niza preusmjeravanja. To znači da je autorizacija na Dobavljaču bila uspješna i da je tokenu zahtjeva dopušteno da radi. Međutim, u OAuth-u, iz sigurnosnih razloga, svaki token ima svoju vlastitu, strogo ograničenu svrhu. Na primjer, token zahtjeva se koristi samo za primanje potvrde od korisnika i ništa drugo. Za pristup resursima trebamo nabaviti novi token - Access Token - ili, kako kažu, "razmijeniti token zahtjeva za token za pristup".
   • Potrošač se odnosi na URL tokena pristupa- na primjer, api.rutvit.ru/oauth/access_token , - i traži da mu se da pristupni token umjesto njegovog tokena zahtjeva. Zahtjev je digitalno potpisan na temelju tajne tokena zahtjeva.
   • Pružatelj generira i vraća Access Token ispunjen smećem. Također u svojim tablicama označava da je pristup API-ju dopušten za ovaj Access Token. Naša aplikacija mora zadržati pristupni token ako će u budućnosti koristiti API.
5. API poziva (interni zahtjev). Pa, sada imamo Access Token, i možemo proslijediti njegov ključ kada pozivamo API metode.
   • Potrošač generira zahtjev API-ju Dobavljača (na primjer, koristeći POST zahtjev prema REST ideologiji). Zahtjev prosljeđuje ključ pristupnog tokena i on se potpisuje korištenjem Zajedničke tajne ovog tokena.
   • Dobavljač upravlja pozivom API-ja i vraća podatke aplikaciji.

Kraj skripte: izlaz widgeta

Kraj scenarija treba biti jasan i bez detaljnih objašnjenja.

Listing 14: Kraj skripte: izlaz widgeta

// krajnji slučaj ) ) // Dobiti sve dostupne tweetove. $text = file_get_contents("http://api.rutvit.ru/search.xml?rpp=5&q=" . urlencode("#" . TAG)); $TWEETS = novi SimpleXMLElement($text); // Prečac za prikaz poruke s kodiranjem i citiranjem. funkcija e($text, $quote = 1) ( $text = iconv("utf-8", ENCODING, $text); echo $quote? htmlspecialchars($text) : $text; ) ?> status kao $tweet) (?> user->screen_name)?>: tekst_format, 0)?> ?action=form_is_sent" style="margin: 1em 0 0 0">

Korisne veze na OAuth

• rutvit

Dodaj oznake