OAuth VKontakte: koristite za ličnu korist. OAuth: opisivanje protokola na jednostavnom i razumljivom jeziku

1. Otvaranje ugrađenog pretraživača sa stranicom za prijavu
2. Od korisnika se traži da potvrdi izdavanje prava
3. Ako se korisnik složi, pretraživač će biti preusmjeren na stub stranicu u fragmentu (nakon #) čiji je URL dodan pristupni token
4. Aplikacija presreće preusmjeravanje i prima pristupni token sa adrese stranice

Ova opcija zahtijeva podizanje prozora preglednika u aplikaciji, ali ne zahtijeva serversku stranu i dodatni server-server poziv za razmjenu autorizacijski kod on pristupni token.

Primjer

Otvorite pretraživač sa stranicom za autorizaciju:
> GET / oauth / autorizacija? 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 je to 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 zadnje preusmjeravanje, dobiti ga sa adrese access_token i koristiti ga za pristup zaštićenim resursima.

Autorizacija prijave i lozinke

Autorizacija prijave i lozinke je jednostavan POST zahtjev koji se vraća pristupni token... Ova shema nije ništa novo, ali je umetnuta u standard radi općenitosti i preporučuje se za korištenje 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 [email protected] corp.mail.ru & lozinka = 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

Vratite prethodnu autorizaciju

obično, pristupni token ima ograničen rok trajanja. Ovo može biti korisno, na primjer, ako se prenosi preko otvorenih kanala. Kako ne bi prisilili korisnika da prođe autorizaciju nakon isteka pristupni token"a, u svim gore navedenim opcijama, pored pristupni token„Možda se vratite po još refresh token... Na njemu možete dobiti pristupni token korištenjem HTTP zahtjeva, slično autorizaciji prijave i lozinke.

Primjer

> POST / oauth / token HTTP / 1.1> Host: connect.mail.ru> Content-Type: 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", < }

Popularan protokol koji dozvoljava društveni usluge se međusobno integriraju i pružaju siguran način za razmjenu ličnih podataka. OAuth može povezati 2 servisa, od kojih svaki ima svoju korisničku bazu - u ovom slučaju ja ih zovem "društvene". Kada počnete raditi s OAuthom, prvi osjećaj je da je protokol vrlo složen i suvišan. U ovom članku pokušaću da objasnim osnove OAuth-a u ljudskim terminima.

Primjer unakrsnog ovlaštenja

Vratimo se u 2005. godinu i zamislimo da pišemo društvenu mrežu. Sadrži obrazac za uvoz kontakata iz GMail adresara. Šta vam je potrebno za pristup GMail kontaktima? Naravno, login i lozinka za poštansko sanduče. Ali ako zatražimo da ih unesemo na našu stranicu, korisnik će posumnjati da nešto nije u redu. Gdje je garancija da unesene lozinke ne čuvamo na serveru? 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. Hajde da se dogovorimo oko uslova.

• Potrošač: potrošač; skripta za obradu forme uvoza kontakata na društvenu mrežu.
• Dobavljač usluga: provajder podataka; Gmail koji sadrži podatke iz adresara od interesa za Potrošača.
• Korisnik: korisnik koji ima nalog i kod potrošača i kod pružaoca usluga.
• Zaštićeni resurs: lični podaci; kontakte iz adresara na Gmail-u (tj. Resursi dobavljača usluga).
• API dobavljača: GMail API koji dozvoljava bilo kojoj skripti da dobije kontakte iz GMail adresara.

OAuth zadatak- učiniti tako da Korisnik ima mogućnost da radi na Potrošačkom servisu (na društvenoj mreži) sa zaštićenim podacima Pružaoca usluge (GMail), unoseći lozinku za ove podatke isključivo na Pružaocu usluge i zadržavajući se na Potrošačevu web stranica. Nije tako teško, zar ne?

Po čemu se OAuth razlikuje od OpenID-a?

OAuth se često naziva "protokol za robote" za razliku od OpenID-a, koji je "protokol za korisnike". Nemojte ih zbuniti!

1. OpenID je protokol za ubrzanu registraciju. OpenID omogućava korisniku da dobije nalog na bilo kom servisu bez unošenja lozinke ako je već registrovan negde drugde na Internetu. (I tada se možete prijaviti na uslugu bez unošenja lozinke, autorizirani ste „negdje“.) Na primjer, ako imate Yandex nalog, možete se „prijaviti“ sa njim na bilo koju uslugu koja podržava OpenID autorizaciju.
2. OAuth je protokol za ovlašteni pristup API-ju treće strane. OAuth dozvoljava skripti potrošača da dobije ograničen API pristup podacima dobavljača usluga treće strane, ako se Korisnik slaže. One. to je sredstvo za pristup API-ju.

Policijska analogija Zamislite da ste kriminalistički istražitelj koji traži krajeve u slučaju krađe WebMoney iz 1973. godine. Da se dogovorimo oko uslova: OAuth Consumer: Kriminalistička istraga. Korisnik: uposlenik Odjeljenja za kriminalistiku. Dobavljač usluga: Arhiva zločina. OpenID: uposlenik Odjeljenja za kriminalističke istrage (Korisnik) dolazi do Pružaoca usluga, na ulazu predočava Ovlašćenje i na licu mjesta pregledava kartice u potrazi za informacijama. OAuth: zaposlenik Odjeljenja za kriminalističke istrage (Korisnik) direktno sa posla (Potrošač) poziva Pružaoca usluge. On javlja svoje ime; ako ga prepozna (Ovlašćenje), traži spisak svih zločina za 1973. (API poziv). Kao što vidite, OpenID i OAuth su različite stvari. OpenID vam omogućava pristup određenim resursima na licu mjesta. OAuth pruža dio informacija sa udaljene usluge putem API-ja.

Pregled ovog članka

Prije nego pređemo na glavni dio, da vidimo kako ćemo se kretati.

1. Hajde da razmotrimo probleme koji se javljaju tokom "ručne" implementacije unakrsnog ovlašćenja.
2. Hajde da razgovaramo o tome šta je "aplikacija" i šta je potrošač.
3. Dotaknimo se osnova kriptografije.
4. Označimo demo aplikaciju koju ćemo pisati u ovom članku.
5. Odlučimo se za testni OAuth server na kojem ćemo eksperimentirati.
6. Prođimo kroz sve korake OAuth protokola i pružimo izvore skripte.

O pronalasku bicikla

Dobar način da nešto shvatite je da to uradite sami, nagazivši na sve grabulje postavljene na putu. Sada ćemo ponovo izmisliti točak: hajde da pokušamo da zamislimo kako bismo rešili problem interakcije između potrošača i pružaoca usluga bez ikakvih standardizovanih protokola.

Prvo ćemo napisati obrazac za uvoz kontakata iz samog GMail-a: Zatim ćemo zamoliti programere GMail-a da se uvjere da će korisnik, kada dođe do URI-a /auth.php, dobiti obrazac za autorizaciju (u našem biciklističkom svijetu , GMail je napisan u PHP-u). Nakon uspješnog unosa lozinke, korisnika treba preusmjeriti na stranicu, čiji je URL naveden u parametru retpath. Također, dodatni tajni ključ mora biti proslijeđen u URL-u, koji se već može koristiti za pristup GMail API-ju.

Dakle, nakon unosa lozinke, korisnik će se vratiti na našu web stranicu na sljedeću adresu: I iz /import.php skripte ćemo se obratiti na GMail API, proslijediti ključ Y49xdN0Zo2B5v0RR u njega i učitati kontakte: Pa, sad hajde da prebrojimo rake (jer neravnine će biti kasno za brojanje).

Prvi rake: zamjena povratne adrese retpath

Naravno, pretpostavili ste da bi prva stvar koju bi napadač uradio na svom sajtu bila da postavi link i da vas natera da kliknete na njega. Kao rezultat toga, on će dobiti tajni ključ koji je GMail vratio, 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 on može ukazivati ​​samo na našu stranicu. Ali problem sa parametrom tajne ostaje. Secret se može špijunirati s leđa ili presretnuti slušanjem WiFi saobraćaja. Ili će se jednog dana pojaviti XSS ranjivost na vašoj web lokaciji koja vam omogućava da "ukradete" tajni ključ. Uz tajnu vrijednost, napadač će moći pročitati vaš adresar. To znači da trebate zaštititi tajnu od presretanja (u idealnom slučaju, nemojte je prenositi preko URL-a uopće).

Rake treći: previše preusmjeravanja

Ako svaki API poziv zahtijeva drugačiju tajnu, tada ćemo morati organizirati onoliko preusmjeravanja na stranicu dobavljača usluga koliko imamo poziva. Uz intenzivnu upotrebu API-ja, ovo radi veoma sporo, i prilično je nezgodno...

Četvrto: loša identifikacija potrošača

GMail, naravno, želi znati ko koristi njegov API. Dozvolite pristup nekim sajtovima, a zabranite pristup drugima... To znači da prilikom formiranja zahteva u vidu uvoza kontakata, potrošača (sajta) treba "prezentovati" dobavljaču usluga (GMail). U našem slučaju, ovu funkciju djelomično izvodi retpath (naziv stranice u njoj), ali ova metoda nije univerzalna, jer mehanizam "prezentacije" se također mora koristiti prilikom pozivanja API metoda.

OAuth fondacija

Važno je napomenuti da je ostalo još mnogo "podvodnih grabulja". Neću ih ovdje opisivati, jer ova grabulja leži u Marijanskom rovu (duboka 10920 m). Trebalo bi desetak stranica da se opišu ranjivosti. Tako da ću odmah preći na opis OAuth-a, gdje su svi problemi već riješeni.

Aplikacija = potrošač + pristup API-ju

Kada radite sa OAuth-om, važno je da pojam potrošača nije ograničen samo na „stranica“. 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 OAuth-a. Zaista, sve što OAuth daje je mogućnost prijavljivanja na udaljenu uslugu (Service Provider) i pravljenja ovlaštenih zahtjeva API-ju. Nije bitno kako ovaj API radi: može biti čisti SOAP, REST pristup, itd. Glavna stvar je da svaki API metod prihvata posebne parametre prosleđene prema OAuth protokolu kao ulaz.

Token = ključ + tajna

Jedan od principa OAuth-a glasi da se tajni ključevi ne smiju javno prenositi u zahtjevima (u primjeru iznad pogledali smo zašto). Dakle, protokol radi sa konceptom tokena. Token je vrlo sličan paru login + lozinka: prijava je javna informacija, a lozinka je poznata samo strani koja šalje i prima. U OAuth terminima, analogni login se zove Key, a analog lozinke se zove Secret. Situacija kada je tajna poznata samo pošiljaocu i primaocu, ali nikome drugom, naziva se Zajednička tajna.

Dakle, ako se potrošač i dobavljač nekako dogovore oko zajedničke tajne, oni mogu otvoreno razmijeniti odgovarajuće ključeve (ključ) u URL-u, bez straha da će presretanje ovih ključeva biti opasno. Ali kako zaštititi URL sa ključem od krivotvorenja?

Poruka = ​​Dokument + Digitalni potpis

"Digitalni potpis" zvuči zastrašujuće, ali u stvari je sasvim očigledna stvar. Kada potpisujete dokument olovkom, potvrđujete da ste dokument napisali vi, a ne neko drugi. Vaš potpis je, takoreći, „dodan“ dokumentu i ide uz njega u „jednom kompletu“.

Isto tako, nekom bloku podataka se dodaje digitalni potpis, koji potvrđuje da se onaj koji je generirao te podatke ne lažno predstavlja kao drugi. Digitalni potpis ne šifrira dokument, samo garantuje njegovu autentičnost! Potpis dozvoljava ista Zajednička tajna, koja je poznata primaocu i pošiljaocu, ali nikome drugom.

Kako radi? Neka naš $ sharedSecret = 529AeGWg, a mi smo to šapnuli na uho strani koja prima. Želimo da pošaljemo poruku "Moj telefon 1234567" sa garantovanom zaštitom od lažiranja od strane uljeza.

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

Demonstracija OAuth-a koristeći jednostavnu aplikaciju kao primjer

Da "osjetimo" OAuth uživo, potrebne su nam dvije stvari:

1. Skripta koja implementira klijentsku stranu protokola. Napisao sam tako malu PHP skriptu (link do zip arhive). To je widget koji se može ugraditi u PHP stranice.
2. Testni OAuth server s kojim možemo eksperimentirati. U tu svrhu zgodno je koristiti RuTvit: postoji stranica http://rutvit.ru/apps/new, koja vam omogućava da dodate probnu aplikaciju za 30 sekundi. (Usput, ne morate navesti povratni URL u obrascu - mi ćemo ga ionako proslediti iz test skripte.)

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

Možete umetnuti ovaj widget u bilo koju PHP stranicu jednostavnim kopiranjem koda i podešavanjem izgleda. Prikazuju se svi tvitovi sa servisa RuTvit, označeni navedenim hash tagom, a moguće je i dodavanje novih tvitova (tu se koristi OAuth). Vidžet koristi RuTvit API i OAuth autorizaciju, koja je, uzgred, ista kao Twitter API standard. Ovu skriptu možete pokrenuti na svom test serveru. Da biste to učinili, potrebno je izvršiti tri koraka:

1. Preuzmite kod skripte i rasporedite ga u bilo koji prikladan direktorij na web serveru.
2. Registrirajte novu aplikaciju za testiranje na OAuth serveru.
3. Nakon registracije aplikacije, zamijenite parametre OA_CONSUMER_KEY i OA_CONSUMER_SECRET u skripti vrijednostima primljenim od servera.

Registracija aplikacije i parametri

Hajde da razgovaramo o tome odakle dolaze aplikacije i kako serviser saznaje o njima. Sve je prilično jednostavno: Provajder usluga ima poseban formular za prijavu koji može koristiti svako. Evo primjera takvog obrasca:

Nakon registracije aplikacije dobijate 5 parametara koji su potrebni za rad sa OAuthom. Evo kako bi mogle izgledati:

Ovdje su Consumer key i Consumer secret neka vrsta "login + password" vaše aplikacije (sjećate se razgovora o tokenima iznad? Ovo je samo jedan od njih). Da vas podsjetim da je tajna potrošača Zajednička tajna, poznata samo pošiljaocu i primaocu, ali nikome drugom. Ostale 3 vrijednosti postavljaju URL-ove usluga, čije ćemo značenje sada razmotriti.

OAuth = Dohvati token zahtjeva + Preusmjeravanje na autorizaciju + Dohvat tokena za pristup + API poziva

U primjeru sa GMail-om koristili smo 2 vrste udaljenih poziva: a) preusmjeravanje preko pretraživača; b) pozivanje API-ja iz skripte.

I otkrili smo niz sigurnosnih pitanja, što sugerira da bi trebalo biti više izazova. Ovo se dešava u OAuth-u: dodatni posredni zahtjevi se dodaju iz skripte potrošača dobavljaču, koji rade sa tokenima. Hajde da ih pogledamo.

1. Obrada podnošenja obrasca. Ovo nije dio OAuth-a, već dio naše aplikacije. Prije nego što kontaktiramo API dobavljača, moramo primiti radni nalog od korisnika za ovu radnju. Evo primjera takve "naredbe":
2. Dohvati token zahtjeva (interni zahtjev).
   • Potrošačka skripta se odnosi na Zatražite URL tokena Provajder: na primjer, api.rutvit.ru/oauth/request_token. Zahtjev prenosi potrošački ključ - "prijava na aplikaciju", a sam zahtjev se potpisuje korištenjem tajne potrošača - "lozinke aplikacije", koja ga štiti od krivotvorenja.
   • Kao odgovor, Dobavljač generiše i vraća token pun smeća koji se zove Request Token. I dalje će nam trebati, pa ga moramo negdje sačuvati - na primjer, u varijablu sesije $ S_REQUEST_TOK.
3. Preusmjeravanje na autorizaciju (preko preusmjeravanja pretraživača). Naša aplikacija sada ima jedinstveni token zahtjeva. Za korištenje ovog tokena potrebno je dobiti dozvolu od korisnika, tj. pitaj ga autorizirati token zahtjeva.
   • Potrošač preusmjerava pretraživač na poseban Autoriziraj URL Provajder: na primjer, api.rutvit.ru/oauth/authorize. Request Token Key se prosljeđuje u parametrima.
   • Provajder prikazuje formular za autorizaciju za svog korisnika i, ako je prijavljen, preusmjerava pretraživač nazad. Gdje tačno? I to ukazujemo u parametru oauth_callback.
4. Dohvati pristupni token (interni zahtjev). Dakle, pretraživač se vratio u našu aplikaciju nakon niza preusmjeravanja. To znači da je autorizacija dobavljaču bila uspješna i da je tokenu zahtjeva dozvoljeno da radi. Međutim, u OAuth-u, radi sigurnosti, svaki token ima svoju strogo ograničenu svrhu. Na primjer, token zahtjeva se koristi samo za primanje potvrde od korisnika i ni za šta drugo. Da bismo pristupili resursima, moramo 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 izda token za pristup umjesto tokena zahtjeva koji ima. Zahtjev je potpisan digitalnim potpisom na osnovu tajne tokena zahtjeva.
   • Dobavljač generiše i vraća pristupni token pun smeća. Takođe u svojim tabelama označava da je pristup API-ju dozvoljen za ovaj pristupni token. Naša aplikacija mora zadržati pristupni token ako će u budućnosti koristiti API.
5. API poziva (interni zahtjev). Pa, sada imamo token za pristup i možemo prenijeti njegov ključ kada pozivamo API metode.
   • Potrošač generiše zahtjev API dobavljaču (na primjer, koristeći POST zahtjev prema REST ideologiji). Pristupni ključ tokena se prenosi u zahtjevu, a potpisuje se korištenjem zajedničke tajne ovog tokena.
   • Dobavljač upravlja pozivom API-ja i vraća podatke aplikaciji.

Kraj skripte: prikazivanje widgeta

Kraj skripte treba da bude jasan i bez detaljnih objašnjenja.

Listing 14: Zatvaranje skripte: prikazivanje widgeta

// kraj slučaja)) // Dobij sve dostupne tweetove. $text = file_get_contents ("http://api.rutvit.ru/search.xml?rpp=5&q=". urlencode ("#". TAG)); $ TWEETS = novi SimpleXMLElement ($ tekst); // Prečica za prikaz poruke s ponovnim 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)?>: formatiran tekst, 0)?> ? action = form_is_sent "style =" margin: 1em 0 0 0 ">

OAuth korisni linkovi

• rutvit

Dodaj oznake

Kao rezultat toga, klijentska aplikacija koja koristi AdWords API može pristupiti AdWords računu bez adrese e-pošte i lozinke korisnika.

Generiranje OAuth2 akreditiva

Slijedite korake u nastavku da kreirate OAuth2 vjerodajnice.

Određivanje vrste aplikacije

Prvo, morate definisati tip aplikaciježelite da kreirate. Postoje dvije vrste aplikacija u AdWords API-ju:

• instaliranu aplikaciju(preporučeno);
• web aplikacija.

Koristite donju tabelu da odredite vrstu aplikacije koju želite.

Šta izabrati	Situacija
Instalirana aplikacija(preporučeno)	Svim svojim AdWords računima upravljate s jednim računom upravitelja najvišeg nivoa. Tek počinjete ili želite da počnete brzo. Vaša aplikacija će raditi s jednim skupom AdWords računa s više korisnika.
Web aplikacija	Želite se autentifikovati tako da različiti korisnici imaju različita prava pristupa podacima vašeg AdWords računa. Morate kreirati nekoliko skupova vjerodajnica, na primjer, za upravljanje računima trećih strana. Vaša aplikacija zahtijeva URL-ove povratnog poziva koji nisu podržani u aplikacijama koje se instaliraju.

Pažnja!Čak i ako razvijate web aplikaciju, još uvijek možete odabrati aplikaciju koju želite instalirati. Glavna razlika je da li je potrebno da se pozovete nakon izdavanja tokena. Na primjer, ako koristite jedan menadžerski račun najviše razine za upravljanje svim svojim AdWords računima, aplikacija koju instalirate mora biti registrirana čak i ako je klijentska aplikacija dostupna preko Interneta. Bilješka.diskutovano u nastavku. Ako vam nije potrebna funkcionalnost naloga usluge, toplo preporučujemo korištenje procesa autorizacije za instaliranu ili za web aplikaciju.

Generisanje ID-a i tajne klijenta

Nakon što ste identificirali svoj tip aplikacije, kliknite na odgovarajuću karticu ispod i slijedite upute da kreirate ID klijenta i tajnu.

Instalirana aplikacija

1. Otvoriti
2. Kreirajte projekat Stvoriti.
3. Kreirajte vjerodajnice, i onda - ID OAuth klijenta.
4. Sačuvaj
5. U poglavlju Vrsta aplikacije izabrati Druge vrste i popunite tražene podatke.
6. Kliknite na Stvoriti.
7. identifikator i Tajni ključ

Web aplikacija

1. Otvoriti
2. Iz padajućeg izbornika projekata odaberite Kreirajte projekat, zatim navedite naziv projekta i, ako je potrebno, promijenite njegov identifikator, a zatim kliknite na dugme Stvoriti.
3. Na stranici Akreditivi odaberite Kreirajte vjerodajnice, i onda - ID OAuth klijenta.
4. Možda će vam biti zatraženo ime proizvoda. U tom slučaju kliknite Prilagodite prozor zahtjeva za pristup, unesite tražene podatke i kliknite Sačuvaj da se vratite na ekran akreditiva.
5. U poglavlju Vrsta aplikacije izabrati Web aplikacija... Slijedite upute za pružanje JavaScript izvora i/ili preusmjeravanja URI-ja.
6. Kliknite na Stvoriti.
7. Na stranici koja se pojavi kopirajte identifikator i Tajni ključ klijent - ovo će vam trebati kada konfigurirate klijentsku biblioteku.

Slijedite uputstva u nastavku da biste konfigurisali upotrebu OAuth2 akreditiva sa klijentskom bibliotekom vašeg jezika.

Bilješka.Ako odlučite da ne koristite neku od naših klijentskih biblioteka, morat ćete implementirati procese za sebe ili za sebe.

OAuth2 Playground

Alternativni način kreiranja OAuth2 vjerodajnica je korištenje OAuth2 Playground... U kombinaciji sa Google API konzolom, ovaj sistem vam omogućava da kreirate sopstvene OAuth2 tokene.

OAuth2 Playground sistem je namijenjen onim korisnicima kojima je potreban pristup svojim nalozima samo za jedan menadžerski račun ili AdWords korisnik. Ako trebate zatražiti vjerodajnice za više korisnika, onda je bolje koristiti klijentske biblioteke kao što je gore opisano.

Prilagodba

Upozorenje.Koristiti OAuth2 Playground, morate kreirati id klijenta za . Ovo jedini tip aplikacije koji radi s OAuth2 Playgroundom. Pročitajte više u odeljku iznad.

Kako dobiti ID klijenta i tajni ključ

1. Otvoriti
2. Izaberite postojeći projekat iz padajućeg menija ili kreirajte novi.
3. Na stranici Akreditivi odaberite Kreirajte vjerodajnice, i onda - ID OAuth klijenta.
4. U poglavlju Vrsta aplikacije izabrati Web aplikacija.
5. U odjeljku dodajte sljedeći red: https: // site / oauthplayground
6. Kliknite na Stvoriti.
7. Zapiši identifikator i Tajni ključ klijent naveden na stranici koja se pojavi. Trebat će vam u sljedećem koraku.

Kako kreirati tokene

Upozorenje.Na koji Google račun ste prijavljeni u svom pregledniku određuje kojim AdWords računima možete pristupiti koristeći OAuth2 vjerodajnice koje kreirate. Možda bi vam bilo bolje da ove korake radite u anonimnom načinu rada ili bez prijave na svoj Google račun. Vjerovatno ćete morati koristiti vjerodajnice osim računa na kojem ste bili kada ste primili ID klijenta i tajnu.

Kako ukloniti OAuth2 Playground iz ID-a klijenta

Pošto već jeste refresh token, više ne morate koristiti OAuth2 Playground kao riješeni URI za preusmjeravanje. Da biste uklonili ovaj sistem sa liste, slijedite ove korake:

1. Idi.
2. Izaberite svoj projekat iz padajućeg menija.
3. Na stranici Akreditivi odaberite ime ID-a kupca.
4. Uklonite https: // site / oauthplayground u okviru Dozvoljeni URI-ji za preusmjeravanje... Imajte na umu da morate otići barem jedan Preusmjeravanje URI.
5. Kliknite na Sačuvaj.

Dakle, imate svoje OAuth akreditive. Sada možete postavljati AdWords API zahtjeve i koristiti ih protiv potrebne klijentske biblioteke.

OAuth2 servisni računi

Ovaj odjeljak opisuje kako pristupiti AdWords API-ju pomoću računa usluge.

Servisni račun je račun u vlasništvu aplikacije, a ne pojedinačnog krajnjeg korisnika. Servisni računi pružaju interakciju između web aplikacije i Google usluge. Vaša aplikacija poziva API u ime računa usluge bez direktnog uključivanja korisnika.

AdWords API omogućava pristup računu usluge putem G Suite domena.

Nalog usluge implementira OAuth2 proces, koji koristi ključnu datoteku koja je dostupna samo vašoj aplikaciji umjesto autorizacije korisnika.

Upotreba uslužnih računa pruža dvije značajne prednosti:

• Autorizacija pristupa aplikacije Google API-ju se vrši u fazi konfiguracije. Ovo izbjegava gnjavažu potrebe za intervencijom korisnika ili keširanje tokena u drugim OAuth2 tokovima.
• Lažno predstavljanje drugih korisnika u aplikaciji radi se kao dio procesa odobrenja OAuth2 prema potrebi.

Bilješka. Osim ako ne koristite funkcije specifične za domenu kao što je lažno predstavljanje, toplo se preporučuje da koristite proces za. U procesima za instalirane OAuth2 i web aplikacije, učešće korisnika je potrebno samo jednom - u trenutku odobravanja pristupa nalogu.

Alternativa servisnim računima

Servisni nalozi se široko koriste za pružanje programskog pristupa API-jima preko OAuth2 protokola bez intervencije korisnika.

Međutim, postavljanje ovih računa za rad s AdWords API-jem nije lako. Lakša alternativa je token trajnog osvježavanja. Ovaj pristup omogućava aplikaciji da zatraži nove pristupne tokene u bilo kojem trenutku.

Kao dio ovog procesa, trebate konfigurirati autorizaciju aplikacije preko klijentske biblioteke kao što je gore opisano. Ovo trebate učiniti samo jednom jer Google OAuth2 tokeni za osvježavanje nemaju datum isteka.

Zahtjevi

• G Suite domena koju posjedujete, kao što je mydomain.com ili mybusiness.com.
• AdWords API razvojni token i po mogućnosti probni račun.
• za jezik koji koristite.

Konfiguriranje pristupa za klijentski račun

Prvo, trebate kreirati ključ računa usluge u Google API konzoli.

1. Prijavite se na svoj G Suite račun, otvorite.
2. Iz padajućeg izbornika projekata odaberite Kreirajte projekat, zatim popunite tražene podatke i kliknite Stvoriti... Novi projekat će se pojaviti na aktivnoj listi.
3. Iz menija u gornjem levom uglu izaberite IAM i administracija, i onda - Servisni računi u meniju sa leve strane.
4. Kliknite na Kreirajte račun usluge na vrhu stranice.
5. Unesite naziv računa usluge.
6. Označite polje Kreirajte novi privatni ključ i odaberite tip JSON ključa.
7. Označite polje Omogućite delegiranje podataka G Suite domene i navedite naziv proizvoda za prozor zahtjeva za pristup.
8. Kliknite na Stvoriti... Preuzimanje datoteke JSON ključa će započeti. Sačuvajte datoteku na sigurnom mjestu gdje samo vi imate pristup.
9. Na stranici Servisni računi pojavit će se novi račun usluge.

Bilješka. Budući da se lažno predstavljanje korisnika može kontrolisati samo na nivou domene, da biste koristili servisne račune i proces odobravanja sa Google OAuth2 uslugama, potrebna vam je vlastita domena registrirana u G Suiteu. Svi korisnici domene koji koriste nalog usluge sa odgovarajućim dozvolama mogu se lažno predstavljati kao bilo koji korisnik domene.

Sigurnosni problemi

Budući da se G Suite-om upravlja na nivou domene, morate sigurno osigurati ključnu datoteku koja omogućava ovlaštenim nalozima pristup Google uslugama. Ovo je posebno važno jer nalogu usluge pružamo mogućnost lažnog predstavljanja bilo kojeg korisnika domene.

Osim toga, preporučuje se da svakom servisnom računu date pristup samo jednom Google API-ju. Da biste to učinili, koristite polje obimšto je opisano u sljedećem dijelu. Ova preventivna mjera vam omogućava da ograničite količinu podataka otvorenih za neovlašteni pristup u slučaju kompromitacije datoteke ključa.

Kako pružiti mogućnosti lažnog predstavljanja

Da biste omogućili servisni račun s mogućnošću lažnog predstavljanja, slijedite ove korake:

Sada možete pristupiti svom AdWords računu koristeći račun usluge kao dio OAuth2 procesa odobrenja.

Konfiguriranje klijentske biblioteke

Odaberite jezik da vidite upute za postavljanje klijentske biblioteke.

Bilješka.Ako odlučite da ne koristite neku od naših klijentskih biblioteka, morat ćete sami implementirati proces.

Optimiziranje OAuth2 zahtjeva

Ako vaša aplikacija ne koristi balansiranje vjerodajnica, to može značajno povećati broj zahtjeva koji se šalju Googleu. Kao rezultat toga, naši serveri mogu postaviti ograničenja za takvu aplikaciju, što će usporiti njene performanse.

Ovaj odjeljak opisuje kako optimizirati upravljanje vjerodajnicama za OAuth2 kako bi vaša aplikacija djelovala učinkovitije s AdWords API-jem.

Pažnja!Pod terminom vjerodajnice odnosi se na ukupnost OAuth2 atributa vjerodajnica, uključujući pristupni token i njegov datum isteka.

Strategije distribucije vjerodajnica

Distribucija vjerodajnica kroz API zahtjeve poboljšava performanse i izbjegava greške i greške kršenja ograničenja.

Strategija distribucije vjerodajnica ovisi o dizajnu aplikacije.

U aplikacijama s više niti, morate koristiti iste vjerodajnice za svaku sesiju niti.

U višeprocesnim i distribuiranim aplikacijama, morate implementirati neku vrstu infrastrukture za prijenos vjerodajnica između procesa. Osim toga, blokiranje niti i uvjeti trkanja moraju se izbjegavati.

U aplikaciji koja je i višeprocesna/distribuirana i višenitna, obje strategije moraju se kombinirati u svakom procesu.

Sljedeće su strategije za provjeru autentičnosti jednog AdWords računa, kao što je račun upravitelja najvišeg nivoa u hijerarhiji.

Zatim opisuje kako prilagoditi ove strategije za.

Višenitne aplikacije

U višenitnim aplikacijama, vjerodajnice moraju biti dostupne za različite niti. Ažuriranje akreditiva mora biti obavljeno sinhrono kako bi se izbjegli uvjeti utrke.

Ovaj dijagram prikazuje niti koje šalju zahtjeve AdWords API-ju u vrijeme izvođenja. Koristi se zajednički skup sesija (korisnika). Imajte na umu da svaka sesija mora koristiti isti objekt vjerodajnice. Kao odgovor na svaki API zahtjev, nit prima odgovarajuću sesiju (korisnika). Ako pristupni token treba da se ažurira, to se mora učiniti sinhrono kako bi se izbjeglo stanje utrke. Drugim riječima, objekt vjerodajnice mora biti siguran niti.

Klijentske biblioteke olakšavaju prosljeđivanje vjerodajnica između niti. Svaka klijentska biblioteka ima objekat sesije (ili korisnika) sa vjerodajnicama koje ponovo koristi tokom svog životnog ciklusa. Da biste koristili vjerodajnice u svim sesijama, morate ih primijeniti prilikom kreiranja svake sesije. U svim klijentskim bibliotekama vjerodajnice su objekt siguran niti koji se sinhrono ažurira kada istekne pristupni token.

Na primjer, u Java klijent biblioteci kreirate jednostruku klasu Credential i koristite je za sve sesije.

Višeprocesne i distribuirane aplikacije

U višeprocesnim i distribuiranim aplikacijama, distribucija akreditiva treba da se vrši kontinuirano. Da biste izbjegli stanje utrke u kojem više servera pokušava ažurirati vjerodajnice u isto vrijeme (što dovodi do prevelikog broja zahtjeva za ažuriranje), preporučujemo da prisilno izvršite ažuriranje i pružite ažurirane vjerodajnice svim procesima i serverima.

Na primjer, poseban zadatak ili usluga može povremeno ažurirati vjerodajnice i gurnuti ih u skladište podataka gdje će ih koristiti različiti serveri.

Dijagram pokazuje kako povremeno ažurirati vjerodajnice i zapisati njihova svojstva u spremište podataka. Svi serveri tada dobijaju vjerodajnice prije nego što podnesu zahtjev API-ju.

Zadatak ažuriranja

Zadatak osvježavanja periodično osvježava vjerodajnice i šalje ih spremištu podataka. Ovaj zadatak ne bi trebao čekati da trenutne vjerodajnice isteknu, jer će to uzrokovati da aplikacija prestane raditi neko vrijeme zbog nedostatka valjanih vjerodajnica.

Najbolja alternativa je periodično prisilno osvježavanje, koje svaki put zamjenjuje vjerodajnice u skladištu podataka novima. Zadatak ažuriranja mora se pokrenuti dosta prije nego što trenutni akreditivi isteknu tako da ostane dovoljno vremena u slučaju prolazne greške. Možete početi obavljanjem ažuriranja svakih 15 minuta.

Bilješka.Ako token za pristup vjerodajnicama istekne tokom obrade API zahtjeva, taj zahtjev će i dalje biti dovršen. Na primjer, ako ste kreirali dugotrajan upit i imate manje od minute za pristup, rezultati će i dalje biti vraćeni.

Skladište podataka

Skladište podataka se koristi za pružanje vjerodajnica različitim procesima i serverima.

Da biste to učinili, možete koristiti postojeće skladište podataka ili kreirati specijalizirano preko kojeg će serveri primati vjerodajnice. Potencijalna rješenja uključuju servere za keširanje (kao što su Memcached ili Infinispan) i NoSQL skladišta podataka (kao što je MongoDB).

Glavna svrha skladišta podataka je da obezbedi pouzdan interfejs svim serverima koji pristupaju API-ju. Treba ga optimizirati za brzo čitanje podataka: serveri i procesi će češće čitati vjerodajnice nego što će se ažurirati.

Ne zaboravite čuvati svoje vjerodajnice.

Kada spremate vjerodajnice, morate sačuvati svojstvo expiry_time (trenutno vrijeme + expires_in) i refresh_token zajedno sa svojstvom access_token. Svojstvo expiry_time (istek tokena) izračunava se pomoću sljedeće formule: access_token vrijeme zahtjeva za ažuriranje + expires_in vrijeme (datum isteka tokena).

Server pool

Svaki server u spremištu dobiva najnovije vjerodajnice iz skladišta podataka prije nego što uputi zahtjev. Sve dok se zadatak ažuriranja uspješno izvodi, vjerodajnice će biti važeće. Međutim, u slučaju neuspjeha zadatka ažuriranja ili skladišta podataka, mora postojati rezervni mehanizam.

Ako poslužitelj ili proces ne mogu dohvatiti vjerodajnice iz skladišta podataka, ili ako su vjerodajnice istekle, poslužitelj mora ažurirati svoje vjerodajnice tako da aplikacija nastavi koristiti API dok se problem ne riješi.

U višenitnim procesima, morate koristiti istu strategiju za distribuciju vjerodajnica između niti.

Višestruka autentifikacija naloga

Akreditivi kreirani za AdWords račun upravitelja mogu se koristiti za pristup svim podređenim računima. Korisnici s jednim računom upravitelja obično samo trebaju kreirati vjerodajnice za račun upravitelja najviše razine kako bi autorizirali aplikaciju za sve podređene AdWords račune.

U drugim slučajevima, aplikaciji je potreban pristup AdWords računima koji nisu međusobno povezani u hijerarhiji računa upravitelja. U takvoj situaciji morate kreirati i održavati više vjerodajnica za različite račune, na primjer, za svaki AdWords račun klijenta kojem imate pristup, ili za svaki račun upravitelja najviše razine u nezavisnim hijerarhijama.

Možete se držati ovih strategija za i za aplikacije s minimalnim promjenama. Kada koristite dijeljenu pohranu, vjerodajnice moraju biti indeksirane identifikatorom naloga customerId da bi se vjerodajnice povezali sa potrebnim računom. Osim toga, zadatak ažuriranja mora ih ažurirati na vrijeme. Nakon povezivanja novog naloga, možda ćete morati da ga pokrenete.

Konačno, u aplikacijama s više niti, trebate distribuirati objekt vjerodajnice samo među nitima koje se pokreću na računu s kojim je povezan.

Kako radi OAuth2

Bilješka... AdWords API još uvijek ne podržava istovremenu prijavu pomoću zahtjeva za pristup podacima (hibridni) ili delegiranja na razini domene (2LO).

Obim

Pristupni token može pružiti različite stepene pristupa podacima. Parametar opsega varijable definira skup resursa i operacija kojima token odobrava pristup. Kada zahtijevate pristupni token, vaša aplikacija šalje jednu ili više vrijednosti parametru opsega.

Slijede trenutni i zastarjeli opseg za AdWords API.

Offline pristup

Klijentska aplikacija koja koristi AdWords API obično zahtijeva vanmrežni pristup. Ovo se može dogoditi kada aplikacija treba da pokrene grupne poslove kada korisnik pregleda vašu web lokaciju bez internetske veze.

Aplikacije koje instalirate koriste vanmrežni pristup prema zadanim postavkama.

HTTP zaglavlje zahtjeva

HTTP zaglavlje u svakom zahtjevu prema AdWords API serveru mora uključivati ​​u ovom obrascu:

Autorizacija: Nosilac THE_ACCESS_TOKEN

POST… HTTP / 1.1 Host:… Autorizacija: Nosilac 1 / fFAGRNJru1FTz70BzhT3Zg Tip sadržaja: tekst / xml; charset = UTF-8 Dužina sadržaja:… …

Pristup i osvježavanje tokena

U većini slučajeva, token za osvježavanje mora biti pohranjen na sigurnom mjestu jer može biti potrebno kasnije. Pročitajte više o traženju tokena za pristup i osvježavanje u sljedećim vodičima:

Kada pristupni token istekne

Pristupni token ima datum isteka koji ovisi o vrijednosti expires_in. Pristupni token koji je istekao može se osvježiti pomoću tokena za osvježavanje, međutim naše klijentske biblioteke to rade automatski.

Osim ako je drugačije navedeno, sadržaj ove stranice je licenciran pod licencom Creative Commons Attribution 3.0, a uzorci koda su licencirani pod Apache 2.0 licencom. Za detalje pogledajte našu. Java je registrovani zaštitni znak kompanije Oracle i/ili njenih filijala.

Ažurirano 24. septembra 2018