OAuth VKontakte: gebruik voor persoonlijk gewin. Het opzetten van de clientbibliotheek

Een populair protocol dat dit mogelijk maakt sociaal diensten met elkaar integreren en mogelijk maken veilige manier aandelenbeurs persoonlijke informatie. OAuth kan 2 services met elkaar verbinden, die elk hun eigen services hebben gebruikersbestand- daar houd ik van in dit geval Ik noem het ‘sociaal’. Wanneer je met OAuth aan de slag gaat, is het eerste gevoel dat het protocol erg complex en overbodig is. In dit artikel zal ik proberen de basisprincipes van OAuth in menselijke taal uit te leggen.

Voorbeeld van kruisautorisatie

• Consument: consument; script voor het verwerken van het formulier voor het importeren van contacten op een sociaal netwerk.
• Dienstverlener: gegevensprovider; Gmail, met daarin adresboekgegevens die van belang zijn voor de Consument.
• Gebruiker: een gebruiker die een account heeft bij zowel de Consument als de Dienstverlener.
• Beschermde hulpbron: persoonlijke gegevens; contacten uit het adresboek op Gmail (d.w.z. bronnen van serviceproviders).
• Provider-API: Gmail API waarmee elk script contacten uit een Gmail-adresboek kan ophalen.

Waarin verschilt OAuth van OpenID?

1. OpenID is een protocol voor versnelde registratie. Met OpenID kan een gebruiker een account krijgen bij elke dienst zonder een wachtwoord in te voeren als hij al ergens anders op internet is geregistreerd. (En dan kunt u inloggen bij de service zonder een wachtwoord in te voeren, omdat u 'ergens' geautoriseerd bent.) Als u bijvoorbeeld een account bij Yandex heeft, kunt u deze gebruiken om 'in te loggen' bij elke service die OpenID-autorisatie ondersteunt.
2. OAuth is een protocol voor geautoriseerde toegang tot API's van derden. Met OAuth kan een consumentenscript beperkte API-toegang krijgen tot de gegevens van een externe serviceprovider als de gebruiker toestemming geeft. Die. het is een middel om toegang te krijgen tot de API.

Overzicht van dit artikel

1. Laten we eens kijken naar de problemen die zich voordoen bij het “handmatig” implementeren van kruisautorisatie.
2. Laten we het hebben over wat een “applicatie” is en wie een consument is.
3. Laten we het hebben over de basisprincipes van cryptografie.
4. Laten we de demo-applicatie aanduiden die we in dit artikel zullen schrijven.
5. Laten we beslissen testserver OAuth, waarmee we zullen experimenteren.
6. Laten we alle stappen van het OAuth-protocol doorlopen en de scriptbronnen opgeven.

Over de uitvinding van fietsen

Laten we eerst het formulier zelf schrijven voor het importeren van contacten uit Gmail: Vervolgens vragen we de ontwikkelaars van Gmail om ervoor te zorgen dat wanneer de gebruiker naar de URI /auth.php navigeert, hij een autorisatieformulier krijgt (in onze veloworld, GMail is geschreven in PHP). Nadat het wachtwoord succesvol is ingevoerd, moet de gebruiker worden omgeleid naar de site waarvan de URL is opgegeven in de retpath-parameter. Bovendien moet er een geheime sleutel in de URL worden verzonden, die al kan worden gebruikt om toegang te krijgen tot de GMail API.

Dus na het invoeren van het wachtwoord keert de gebruiker terug naar onze site op het volgende adres: En vanuit het script /import.php gaan we naar de GMail API, geven de sleutel Y49xdN0Zo2B5v0RR erin door en laden de contacten: Nou, laten we nu tel de hark (omdat de hobbels te laat zijn om te tellen).

De eerste rake: het vervangen van het retpath-retouradres

De tweede hark: “afluisteren” van de geheime sleutel

Hark nummer drie: te veel omleidingen

Hark nummer vier: slechte identificatie van de consument

Stichting OAuth

Applicatie = Consument + API-toegang

Token = Sleutel + Geheim

Dus als de consument en de aanbieder het op de een of andere manier eens zijn over een gedeeld geheim, kunnen ze de bijbehorende sleutels in de URL openlijk uitwisselen zonder bang te hoeven zijn dat die sleutels worden onderschept. Maar hoe bescherm je URL's met sleutels tegen vervalsing?

Bericht = Document + Digitale handtekening

Op dezelfde manier wordt een digitale handtekening toegevoegd aan een gegevensblok om ervoor te zorgen dat de persoon die de gegevens heeft gegenereerd, zich niet voordoet als iemand anders. Een digitale handtekening versleutelt een document niet, maar garandeert alleen de authenticiteit ervan! Met hetzelfde gedeelde geheim, dat bekend is bij de ontvanger en de afzender, maar bij niemand anders, kunt u ondertekenen.

Hoe werkt dit? Laat ons $sharedSecret = 529AeGWg, en we fluisterden het in het oor van de ontvangende partij. We willen het bericht "Mijn telefoon 1234567" verzenden gegarandeerde bescherming tegen vervalsing door een aanvaller.

1. De consument voegt een digitale handtekening toe aan het bericht algemeen beeld- $overdracht = $bericht . "-" . md5($bericht. $sharedSecret); // $transfer = "Mijn telefoon is 1234567" . "-" . md5("Mijn telefoon is 1234567" . "529AeGWg")
2. De serviceprovider neemt de gegevens, splitst deze weer in twee delen - $message en $signature - en voert precies dezelfde bewerking uit: $signatureToMatch = md5($message . $sharedSecret); // $signatureToMatch = md5("Mijn telefoon is 1234567". "529AeGWg");

Dan hoeft u alleen nog maar de resulterende $signatureToMatch-waarde te vergelijken met wat er in de ontvangen $signature-gegevens stond en een nep te melden als de waarden niet overeenkomen.

1. Om een ​​echt gevoel voor OAuth te krijgen, hebben we twee dingen nodig:
2. Een script dat het clientgedeelte van het protocol implementeert. Ik heb zo'n klein PHP-script geschreven (link naar zip-archief). Dit is een widget die in PHP-sites kan worden ingevoegd.

Door naar de demoscriptcode te kijken en de onderstaande uitleg in het artikel te lezen, kunt u de details van het protocol begrijpen.

1. U kunt deze widget in elke PHP-website invoegen door simpelweg de code te kopiëren en de lay-out aan te passen. Alle tweets van de RuTvit-service die zijn getagd met de opgegeven hashtag worden weergegeven en het is ook mogelijk om nieuwe tweets toe te voegen (dit is waar OAuth in het spel komt). De widget maakt gebruik van de API- en OAuth-autorisatie van RuTvit, die overigens samenvalt met de Twitter API-standaard. U kunt dit script op uw testserver uitvoeren. Om dit te doen, moet u drie stappen uitvoeren:
2. Download de scriptcode en implementeer deze in een geschikte map op uw webserver.
3. Registreer uw nieuwe testapplicatie bij de OAuth-server.

Na registratie van de applicatie vervangt u de parameters OA_CONSUMER_KEY en OA_CONSUMER_SECRET in het script door de waarden die u van de server heeft ontvangen.

Laten we het hebben over waar applicaties vandaan komen en hoe de serviceprovider erover leert. Alles is heel eenvoudig: Service Provider heeft een speciaal aanvraagregistratieformulier dat iedereen kan gebruiken. Hier is een voorbeeld van zo’n formulier:

Hier zijn Consumentensleutel en Consumentengeheim een ​​soort “login + wachtwoord” van uw applicatie (herinnert u zich het bovenstaande gesprek over tokens? Dit is er slechts één van). Ik wil u eraan herinneren dat het consumentengeheim een ​​gedeeld geheim is, dat alleen bekend is bij de afzender en de ontvanger, maar bij niemand anders. De overige 3 waarden specificeren service-URL's, waarvan we de betekenis nu zullen bekijken.

OAuth = Aanvraagtoken ophalen + Omleiden naar autorisatie + Toegangstoken ophalen + API aanroepen

En we hebben een aantal veiligheidsproblemen blootgelegd, wat suggereert dat er nog meer uitdagingen zouden moeten zijn. Dit is wat er gebeurt in OAuth: er worden meer tussenliggende verzoeken toegevoegd vanuit het Consumer-script naar de Provider, waarbij gebruik wordt gemaakt van tokens. Laten we ze bekijken.

1. Formulierinzending verwerken. Dit is geen onderdeel van OAuth, maar onderdeel van onze applicatie. Voordat we toegang krijgen tot de API Provider, moeten we voor deze actie een werkorder van de gebruiker ontvangen. Hier is een voorbeeld van zo’n “bestelling”:
2. Verzoektoken ophalen (intern verzoek).
   • Het Consumer-script heeft toegang Token-URL aanvragen Provider: bijvoorbeeld api.rutvit.ru/oauth/request_token. Het verzoek bevat de consumentensleutel - de "applicatie-login", en het verzoek zelf is ondertekend met het consumentengeheim - het "applicatiewachtwoord", dat het beschermt tegen vervalsing.
   • Als reactie hierop genereert en retourneert de Provider een “met afval gevuld” token, het Request Token genaamd. We hebben het later nodig, dus we moeten het ergens opslaan, bijvoorbeeld in de sessievariabele $S_REQUEST_TOK.
3. Omleiding naar Autorisatie (via een omleiding in de browser). Nu heeft onze applicatie een uniek Request Token. Voor het gebruik van dit token is toestemming van de gebruiker vereist, d.w.z. vraag het hem autoriseer Request Token.
   • Consument verwijst de browser door naar een speciale browser Autoriseer URL Provider: bijvoorbeeld api.rutvit.ru/oauth/authorize. De Request Token Key wordt doorgegeven in de parameters.
   • De aanbieder toont een autorisatieformulier voor de gebruiker en stuurt, als hij geautoriseerd is, de browser terug. Waar precies? En dit geven we aan in de oauth_callback parameter.
4. Toegangstoken ophalen (intern verzoek). De browser keerde dus na een reeks omleidingen terug naar onze applicatie. Dit betekent dat de autorisatie bij de Provider succesvol is geweest en dat het Request Token mag werken. In OAuth voor beveiliging heeft elk token echter zijn eigen, strikt beperkte doel. Request Token wordt bijvoorbeeld alleen gebruikt om bevestiging van de gebruiker te ontvangen, en niets anders. Om toegang te krijgen tot de bronnen die we nodig hebben nieuw teken- Access Token - of, zoals ze zeggen, "wissel Request Token uit voor Access Token."
   • Consument verwijst naar Toegangstoken-URL- bijvoorbeeld api.rutvit.ru/oauth/access_token - en vraagt ​​om hem een ​​Access Token te geven in plaats van het Request Token dat hij heeft. Het verzoek is ondertekend digitale handtekening gebaseerd op Request Token-geheim.
   • De Provider genereert en retourneert een Access Token gevuld met afval. Hij merkt dat ook op in zijn tabellen Toegangstoken API-toegang is toegestaan. Onze applicatie moet het Access Token behouden als deze in de toekomst de API gaat gebruiken.
5. API aanroepen (intern verzoek). Welnu, nu hebben we een toegangstoken en kunnen we de sleutel ervan doorgeven bij het aanroepen van API-methoden.
   • De Consument genereert een verzoek aan de API van de Provider (bijvoorbeeld met behulp van een POST-verzoek volgens de REST-ideologie). Het verzoek bevat de Access Token Key en is ondertekend met het gedeelde geheim van dit token.
   • De Provider verwerkt de API-oproep en stuurt gegevens terug naar de applicatie.

Einde van script: widgetuitvoer

Handige links over OAuth

• sleur

1. De ingebouwde browser openen met de inlogpagina
2. De gebruiker wordt gevraagd te bevestigen dat rechten zijn verleend.
3. Als de gebruiker akkoord gaat, wordt de browser doorgestuurd naar een stubpagina in het fragment (na #) waarvan de URL wordt toegevoegd toegangstoken
4. De applicatie onderschept de omleiding en ontvangt toegangstoken van het paginaadres

Voorbeeld

Nadat de gebruiker toestemming heeft verleend, vindt er een omleiding plaats naar een standaard stubpagina, voor Mail.Ru is dit het geval 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

De applicatie moet de laatste omleiding onderscheppen en het adres ophalen toegang_token en gebruik het om toegang te krijgen tot beschermde bronnen.

Autorisatie via login en wachtwoord

Voorbeeld

Eerdere autorisatie herstellen

Voorbeeld

1. De ingebouwde browser openen met de inlogpagina
2. De gebruiker wordt gevraagd te bevestigen dat rechten zijn verleend.
3. Als de gebruiker akkoord gaat, wordt de browser doorgestuurd naar een stubpagina in het fragment (na #) waarvan de URL wordt toegevoegd toegangstoken
4. De applicatie onderschept de omleiding en ontvangt toegangstoken van het paginaadres

Voorbeeld

Nadat de gebruiker toestemming heeft verleend, vindt er een omleiding plaats naar een standaard stubpagina, voor Mail.Ru is dit het geval 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

De applicatie moet de laatste omleiding onderscheppen en het adres ophalen toegang_token en gebruik het om toegang te krijgen tot beschermde bronnen.

Autorisatie via login en wachtwoord

Voorbeeld

Eerdere autorisatie herstellen

Voorbeeld

Als gevolg hiervan kan een clienttoepassing die de AdWords API gebruikt, toegang krijgen tot het AdWords-account zonder het e-mailadres en wachtwoord van de gebruiker.

OAuth2-referenties maken

Volg de onderstaande stappen om OAuth2-inloggegevens aan te maken.

Het toepassingstype definiëren

Eerst moet je bepalen toepassingstype, die u wilt maken. Er zijn twee soorten toepassingen in de AdWords API:

• installeerbare applicatie(aanbevolen);
• webapplicatie.

Gebruik onderstaande tabel om te bepalen welk type toepassing u nodig heeft.

Een klant-ID en geheime code aanmaken

Nadat u uw aanvraagtype heeft bepaald, klikt u op het juiste tabblad hieronder en volgt u de instructies om een ​​klant-ID en geheim aan te maken.

Installeerbare applicatie

1. Open
2. Maak een project Creëren.
3. Credentialen maken, en dan - OAuth-client-ID.
4. Redden
5. In de sectie Toepassingstype selecteren Andere soorten en geef de benodigde informatie door.
6. Klik Creëren.
7. identificatie En geheime sleutel

1. Open
2. Selecteer in het vervolgkeuzemenu Projecten Maak een project, geef vervolgens de projectnaam op en wijzig indien nodig de ID ervan, en klik vervolgens op de knop Creëren.
3. Selecteer op de pagina Referenties Credentialen maken, en dan - OAuth-client-ID.
4. Mogelijk wordt u gevraagd de productnaam op te geven. Klik in dit geval Pas het venster voor toegangsverzoeken aan, voer de gevraagde gegevens in en klik Redden om terug te keren naar het scherm Aanmeldingsgegevens.
5. In de sectie Toepassingstype selecteren Webapplicatie. Volg de instructies om JavaScript-bronnen en/of omleidings-URI's op te geven.
6. Klik Creëren.
7. Kopieer op de pagina die verschijnt identificatie En geheime sleutel client - u heeft ze nodig bij het instellen van de clientbibliotheek.

Volg de onderstaande instructies om het gebruik van OAuth2-inloggegevens te configureren met de clientbibliotheek van uw taal.

OAuth2-speeltuin

Een alternatieve optie voor het aanmaken van OAuth2-referenties is het gebruik van OAuth2-speeltuin. Gecombineerd met de Google API Console maakt dit systeem het mogelijk om zelf OAuth2 tokens aan te maken.

Het OAuth2 Playground-systeem is ontworpen voor gebruikers die alleen toegang tot accounts nodig hebben een manageraccount of AdWords-gebruiker. Als u voor meerdere gebruikers om inloggegevens moet vragen, kunt u beter clientbibliotheken gebruiken zoals hierboven beschreven.

Instellingen

Hoe u een client-ID en geheime sleutel kunt verkrijgen

1. Open
2. Selecteer een bestaand project in het vervolgkeuzemenu of maak een nieuw project.
3. Selecteer op de pagina Referenties Credentialen maken, en dan - OAuth-client-ID.
4. In de sectie Toepassingstype selecteren Webapplicatie.
5. Voeg in de sectie de volgende regel toe: https://site/oauthplayground
6. Klik Creëren.
7. Schrijf het op identificatie En geheime sleutel klanten aangegeven op de pagina die verschijnt.

Je hebt ze nodig bij de volgende stap.

Met welk Google-account u in uw browser bent aangemeld, wordt bepaald tot welke AdWords-accounts u toegang krijgt met de OAuth2-inloggegevens die u maakt. Het is wellicht beter om deze stappen in de incognitomodus uit te voeren of zonder in te loggen op uw Google-account. Het is waarschijnlijk dat u inloggegevens moet gebruiken die verschillen van de account waarin u zich bevond toen u de client-ID en de geheime sleutel ontving.

Hoe OAuth2 Playground van Client ID te verwijderen Omdat je dat al hebt gedaan vernieuwingstoken

1. , hoeft u OAuth2 Playground niet langer te gebruiken als uw opgeloste omleidings-URI. Volg deze stappen om dit systeem uit de lijst te verwijderen:
2. Ga naar.
3. Selecteer uw project in het vervolgkeuzemenu.
4. Selecteer op de pagina Referenties de naam van de client-ID. Verwijder https://site/oauthplayground uit het veld Toegestane omleidings-URI's . Houd er rekening mee dat u minimaal moet vertrekken een
5. Klik Redden.

Omleidings-URI.

U beschikt dus over uw OAuth-inloggegevens. U kunt nu de AdWords API doorzoeken en deze gebruiken voor de vereiste klantenbibliotheek.

OAuth2-serviceaccounts

In dit gedeelte wordt beschreven hoe u toegang krijgt tot de AdWords API met behulp van serviceaccounts.

De AdWords API biedt toegang tot serviceaccounts in alle G Suite-domeinen.

Het serviceaccount implementeert een OAuth2-proces, waarbij in plaats van de gebruiker te autoriseren een sleutelbestand wordt gebruikt dat alleen toegankelijk is voor uw applicatie.

Het gebruik van serviceaccounts biedt twee belangrijke voordelen:

• Autorisatie van de toegang van een applicatie tot de Google API gebeurt tijdens de installatiefase. Dit vermijdt het gedoe van het vereisen van tussenkomst van de gebruiker of het cachen van tokens in andere OAuth2-stromen.
• Indien nodig wordt de identiteit van andere gebruikers in de applicatie nagebootst als onderdeel van het OAuth2-goedkeuringsproces.

Alternatief voor serviceaccounts

Serviceaccounts worden veel gebruikt om programmatische toegang tot API's te bieden met behulp van het OAuth2-protocol zonder tussenkomst van de gebruiker.

Het instellen van dergelijke accounts voor gebruik met de AdWords API is echter niet eenvoudig. Een eenvoudiger alternatief is met een persistent vernieuwingstoken. Dankzij deze aanpak kan de applicatie op elk moment nieuwe toegangstokens aanvragen.

Als onderdeel van dit proces moet u de applicatieautorisatie configureren via de clientbibliotheek, zoals hierboven beschreven. Dit hoeft slechts één keer te worden gedaan, omdat Google OAuth2-vernieuwingstokens nooit verlopen.

Vereisten

• Een G Suite-domein waarvan u de eigenaar bent, zoals mijndomein.com of mijnbedrijf.com.
• AdWords API-ontwikkelaarstoken en bij voorkeur een testaccount.
• voor de taal die wordt gebruikt.

Toegang instellen voor een klantaccount

Eerst moet u een serviceaccountsleutel maken in de Google API Console.

1. Log in op uw G Suite-account en open .
2. Selecteer in het vervolgkeuzemenu Projecten Maak een project, geef vervolgens de vereiste informatie op en klik op de knop Creëren. Het nieuwe project verschijnt in de actieve lijst.
3. Selecteer in het menu in de linkerbovenhoek IAM en administratie, en dan - Serviceaccounts in het menu aan de linkerkant.
4. Klik Maak een serviceaccount aan bovenaan de pagina.
5. Voer de naam van het serviceaccount in.
6. Vink het vakje aan Maak een nieuwe privésleutel en selecteer het JSON-sleuteltype.
7. Vink het vakje aan Schakel delegatie van gegevenstoegang in uw G Suite-domein in en geef de productnaam op voor het venster met toegangsverzoeken.
8. Klik Creëren. Het JSON-sleutelbestand wordt gedownload. Bewaar het bestand op een veilige plek waar alleen jij toegang toe hebt.
9. Op de pagina Serviceaccounts er verschijnt een nieuw serviceaccount.

Beveiligingsproblemen

Omdat G Suite op domeinniveau wordt beheerd, moet u het sleutelbestand waarmee geautoriseerde accounts toegang krijgen tot Google-services, veilig beveiligen. Dit is vooral belangrijk omdat we het serviceaccount de mogelijkheid bieden om zich voor te doen als elke domeingebruiker.

Daarnaast wordt aanbevolen dat elk serviceaccount toegang heeft tot slechts één Google API. Hiervoor wordt het veld gebruikt domein, die in de volgende sectie wordt beschreven. Met deze preventieve maatregel kunt u de hoeveelheid gegevens beperken die toegankelijk zijn voor ongeautoriseerde toegang in het geval dat een sleutelbestand wordt gecompromitteerd.

Hoe u imitatiemogelijkheden kunt bieden

Volg deze stappen om imitatiemogelijkheden aan een serviceaccount toe te kennen:

U heeft nu toegang tot uw AdWords-account via uw serviceaccount als onderdeel van het OAuth2-goedkeuringsproces.

Het opzetten van de clientbibliotheek

Selecteer een taal om instructies voor het instellen van de clientbibliotheek te bekijken.

OAuth2-verzoeken optimaliseren

Als uw app geen gebruik maakt van het delen van inloggegevens, kan dit het aantal verzoeken dat naar Google wordt verzonden aanzienlijk verhogen. Als gevolg hiervan kunnen onze servers beperkingen opleggen aan een dergelijke applicatie, waardoor de snelheid van de werking ervan afneemt.

In dit gedeelte wordt beschreven hoe u het beheer van OAuth2-referenties kunt optimaliseren, zodat uw applicatie effectiever samenwerkt met de AdWords API.

Strategieën voor het distribueren van inloggegevens

Het distribueren van inloggegevens over API-verzoeken verbetert de prestaties en voorkomt ook overhead en fouten als gevolg van schendingen van beperkingen.

De strategie voor de distributie van referenties is afhankelijk van het applicatieontwerp.

In toepassingen met meerdere threads moet u voor elke threadsessie dezelfde referenties gebruiken.

In multi-process en gedistribueerde applicaties is het noodzakelijk om een ​​bepaalde infrastructuur te implementeren voor het doorgeven van inloggegevens tussen processen. Bovendien moet worden voorkomen dat draden blokkeren en moeten er raceomstandigheden optreden.

In een applicatie die zowel multi-process/gedistribueerd als multi-threaded is, moet elk proces beide strategieën combineren.

Hieronder volgen strategieën voor het verifiëren van één AdWords-account, zoals het manageraccount op het hoogste niveau in een hiërarchie.

Vervolgens wordt beschreven hoe deze strategieën kunnen worden aangepast voor .

Multithreaded-applicaties

In toepassingen met meerdere threads moeten referenties beschikbaar zijn voor verschillende threads. Updates van inloggegevens moeten synchroon worden uitgevoerd om raceomstandigheden te voorkomen.

Dit diagram toont de threads die tijdens runtime verzoeken doorgeven aan de AdWords API. Er wordt gebruik gemaakt van een gedeelde pool van sessies (gebruikers). Houd er rekening mee dat elke sessie hetzelfde referentieobject moet gebruiken. Als reactie op elk API-verzoek ontvangt de thread de bijbehorende sessie (gebruiker). Als het toegangstoken moet worden vernieuwd, moet dit synchroon gebeuren om een ​​race condition te voorkomen. Met andere woorden: het referentieobject moet threadsafe zijn.

Clientbibliotheken maken het eenvoudig om inloggegevens tussen threads door te geven. Elke clientbibliotheek heeft een sessie- (of gebruikers-)object met referenties die gedurende de hele levenscyclus opnieuw worden gebruikt. Als u inloggegevens voor meerdere sessies wilt gebruiken, moet u deze toepassen bij het maken van elke sessie. In alle clientbibliotheken is de referentie een thread-safe object dat synchroon wordt bijgewerkt wanneer het toegangstoken verloopt.

In de Java-clientbibliotheek zou u bijvoorbeeld een singleton Credential-klasse maken en deze voor alle sessies gebruiken.

Multiproces- en gedistribueerde applicaties

In toepassingen die uit meerdere processen bestaan ​​en gedistribueerde toepassingen moet de distributie van referenties voortdurend plaatsvinden. Om een ​​racesituatie te voorkomen waarbij meerdere servers tegelijkertijd de inloggegevens proberen bij te werken (wat resulteert in overmatige updateverzoeken), wordt aanbevolen om de update te forceren en de bijgewerkte inloggegevens aan alle processen en servers te verstrekken.

Een enkele taak of service kan bijvoorbeeld periodiek de inloggegevens bijwerken en deze naar een gegevensopslag sturen waar ze door verschillende servers zullen worden gebruikt.

Het diagram toont het periodiek bijwerken van inloggegevens en het vastleggen van hun eigenschappen in het gegevensarchief. Alle servers ontvangen vervolgens inloggegevens voordat ze een verzoek indienen bij de API.

Taak bijwerken

Met de updatetaak worden de referenties periodiek bijgewerkt en naar de gegevensopslag verzonden. Deze taak mag niet wachten tot de huidige inloggegevens verlopen, omdat dit ertoe zou leiden dat de applicatie enige tijd niet beschikbaar zou zijn vanwege een gebrek aan geldige inloggegevens.

Het beste alternatief is het afdwingen van periodieke vernieuwingen, waarbij de inloggegevens in de gegevensopslag elke keer door nieuwe worden vervangen. De updatetaak moet worden uitgevoerd ruim voordat de huidige inloggegevens verlopen, zodat er voldoende tijd is voor het geval er een tijdelijke fout optreedt. U kunt beginnen door elke 15 minuten een update uit te voeren.

Gegevensopslag

Gegevensopslag wordt gebruikt om inloggegevens te verstrekken aan verschillende processen en servers.

Om dit te doen, kunt u een bestaand datawarehouse gebruiken of een gespecialiseerd datawarehouse maken waarmee servers inloggegevens ontvangen. Mogelijke oplossingen zijn onder meer caching-servers (zoals Memcached of Infinispan) en NoSQL-datastores (zoals MongoDB).

Het belangrijkste doel van het datawarehouse is om een ​​betrouwbare interface te bieden aan alle servers die toegang hebben tot de API. De werking ervan moet worden geoptimaliseerd om snel gegevens te kunnen lezen: servers en processen zullen vaker inloggegevens lezen dan dat ze worden bijgewerkt.

Vergeet niet om uw inloggegevens veilig te houden.

Wanneer u inloggegevens opslaat, moet u de eigenschap expiratie_time (huidige tijd + expires_in) en refresh_token samen met de eigenschap access_token opslaan. De eigenschap expiratie_time (vervaldatum token) wordt berekend met behulp van de volgende formule: access_token updateverzoektijd + expiratietijd (vervaldatum token).

Serverpool

Elke server in de pool verkrijgt de nieuwste referenties uit het gegevensarchief voordat het verzoek wordt verzonden. Zolang de updatetaak succesvol wordt uitgevoerd, zijn de inloggegevens geldig. Als de updatetaak of de gegevensopslag echter mislukt, moet er een terugvalmechanisme zijn.

Als de server of het proces geen inloggegevens uit het gegevensarchief kan verkrijgen, of als de inloggegevens zijn verlopen, moet de server de inloggegevens bijwerken zodat de toepassing met de API kan blijven werken totdat het probleem is opgelost.

Bij processen met meerdere threads moet u dezelfde strategie gebruiken voor het distribueren van referenties over threads.

Authenticatie van meerdere accounts

De inloggegevens die u voor uw AdWords-manageraccount maakt, kunnen worden gebruikt voor toegang tot alle onderliggende accounts. Gebruikers met één manageraccount hoeven doorgaans alleen inloggegevens voor het manageraccount op het hoogste niveau aan te maken om de aanvraag voor alle ondergeschikte AdWords-accounts te autoriseren.

In andere gevallen heeft de applicatie toegang nodig tot AdWords-accounts die niet aan elkaar gerelateerd zijn in de manageraccounthiërarchie. In deze situatie moet u meerdere inloggegevens aanmaken en onderhouden voor verschillende accounts, zoals voor elk AdWords-klantaccount waartoe u toegang heeft, of voor elk manageraccount op het hoogste niveau in onafhankelijke hiërarchieën.

U kunt deze strategieën voor beide toepassingen volgen met minimale wijzigingen. Wanneer u gedeelde opslag gebruikt, moeten de inloggegevens worden geïndexeerd op basis van de account-ID customerId om ervoor te zorgen dat de inloggegevens aan het gewenste account zijn gekoppeld. Bovendien moet de updatetaak ze op tijd bijwerken. Nadat u een nieuw account heeft gekoppeld, moet u dit mogelijk starten.

Ten slotte hoeft u in toepassingen met meerdere threads het referentieobject alleen te distribueren over de threads die worden uitgevoerd in het account waaraan het is gekoppeld.

Hoe OAuth2 werkt

Domein

Een toegangstoken kan verschillende niveaus van toegang tot gegevens bieden. De parameter variabele scope definieert de set bronnen en bewerkingen waartoe het token toegang biedt. Bij het aanvragen van een toegangstoken stuurt uw applicatie één of meerdere waarden naar de scope parameter.

Hieronder vindt u het huidige en oude bereik van de AdWords API.

Offlinetoegang

Een clienttoepassing die de AdWords API gebruikt, vraagt ​​doorgaans om offline toegang. Dit kan gebeuren als uw toepassing batchtaken moet uitvoeren terwijl de gebruiker zonder internetverbinding op uw site surft.

Geïnstalleerde apps gebruiken standaard offline toegang.

HTTP-verzoekheader

De HTTP-header in elk verzoek aan de AdWords API-server moet de volgende vorm bevatten:

Autorisatie: drager THE_ACCESS_TOKEN

POST ... HTTP/1.1 Host: ... Autorisatie: Bearer 1/fFAGRNJru1FTz70BzhT3Zg Inhoudstype: text/xml;charset=UTF-8 Inhoudslengte: ... …

Tokens openen en vernieuwen

In de meeste gevallen moet het vernieuwingstoken worden opgeslagen veilige plek, omdat dit in de toekomst misschien nodig zal zijn. Raadpleeg de volgende handleidingen voor meer informatie over het aanvragen van toegang en vernieuwingstokens:

Wanneer een toegangstoken verloopt

Het toegangstoken heeft een vervaldatum die afhankelijk is van de waarde vanexpes_in . Toegangstoken met verlopen acties kunnen worden vernieuwd met behulp van een vernieuwingstoken, maar onze clientbibliotheken doen dit automatisch.

Tenzij anders vermeld, valt de inhoud van deze pagina onder de Creative Commons Attribution 3.0-licentie, en zijn codevoorbeelden gelicentieerd onder de Apache 2.0-licentie. Voor details, zie de onze. Java is een geregistreerd handelsmerk van Oracle en/of haar dochterondernemingen.

Bijgewerkt op 24 september 2018

Als u Mail.Ru Mail gebruikt, hoeft u zich geen zorgen te maken over de veiligheid van uw gegevens. Dankzij OAuth  — toestemming.

In dit artikel willen we hierover de hele waarheid vertellen io-technologie waarom dit belangrijk is.

Wat is een protocolOAuth?

Volgens statistieken heeft elke gebruiker gemiddeld drie mailboxen. Ze allemaal controleren, vooral als ze op verschillende sites staan, is niet erg handig. 

In Mail.Ru Mail kunt u het verzamelen van brieven uit mailboxen op andere domeinen configureren ().Waarom de mailcollector in Mail gebruiken?Mail.Ru

veilig? Wanneer u een verzamelprogramma instelt, moet u doorgaans een naam, mailboxadres en wachtwoord invoeren. Om een ​​veilige overdracht van uw gegevens te garanderen, maakt Mail.Ru Mail al geruime tijd gebruik van encryptie van deze gegevens door te gebruiken protocollen SSL OAuth. En om de noodzaak om wachtwoorden over te dragen te elimineren, hebben we het verzamelen van brieven geïmplementeerd met behulp van . Dit protocol staat het programma toe.

vraag geen logins en wachtwoorden aan en bewaar deze ook niet

Hoe werkt dit? Stel dat u besluit een verzamelaar van brieven van Yandex-mail op te zetten in uw postbus OAuth Mail.Ru. Dankzij het protocol Mail.Ru mail zal niet om uw login en wachtwoord van Yandex mail vragen, maar zal erom vragen.

alleen recht op toegang

Klik gewoon op 'Postbus toevoegen' en Mail heeft toegang totdat het door u wordt ingetrokken.

Maar we weten niets over uw wachtwoord.

En tot slot, als u besluit een e-mailverzamelaar in te stellen vanuit uw Mail.Ru-mailbox op een derde partij postdienst– zorg ervoor dat er een protocol wordt gebruikt OAuth. Als dit niet het geval is, raden wij u af de veiligheid van uw gegevens in gevaar te brengen.

We hopen dat dit artikel nuttig voor u was. Als je vragen hebt, stel ze dan in de reacties.