OAuth2-Authentifizierung

Alle Aufrufe der AdWords API müssen über OAuth2 autorisiert werden. Mit OAuth2 kann Ihre AdWords API-Client-Anwendung auf das AdWords-Konto eines Nutzers zugreifen, ohne die Anmeldedaten des Nutzers verarbeiten oder speichern zu müssen.

OAuth2-Anmeldedaten generieren

Gehen Sie wie folgt vor, um OAuth2-Anmeldedaten zu generieren:

1. Anwendungstyp ermitteln

Ermitteln Sie zunächst den Typ der zur erstellenden Anwendung. In der AdWords API gibt es zwei Anwendungstypen:

  • Installierte Anwendung (empfohlen)
  • Webanwendung

In der folgenden Tabelle finden Sie Informationen dazu, welcher Typ für die zu erstellende Anwendung am besten geeignet ist:

Diesen Anwendungstyp auswählen Wenn…
Installierte Anwendung (empfohlen)
  • Sie verwalten alle Ihre AdWords-Konten mit einem einzelnen Verwaltungskonto auf der obersten Ebene.
  • Sie erstellen zum ersten Mal eine Anwendung oder Sie möchten schnell mit der einfachsten Konfiguration beginnen.
  • Von Ihrer Anwendung wird der gleiche Satz AdWords-Konten von mehreren Nutzern verwaltet.
Webanwendung
  • Sie möchten sich im Namen eines beliebigen Nutzers authentifizieren, der Ihrer Anwendung die Berechtigung erteilt, auf seine AdWords-Kontodaten zuzugreifen.
  • Sie möchten schnell mehrere Autorisierungsanmeldedaten generieren, um beispielsweise Konten von Dritten zu verwalten.
  • Ihre Anwendung erfordert Rückruf-URLs. Rückruf-URLs werden im Ablauf von installierten Anwendungen nicht unterstützt.

Weitere Informationen finden Sie in der Google Identity Platform-OAuth-Dokumentation für installierte Anwendungen und Webanwendungen.

2. Client-ID und Clientschlüssel erstellen

Nachdem Sie den Anwendungstyp ermittelt haben, klicken Sie unten auf den entsprechenden Tab und folgen Sie der Anleitung, um die OAuth2-Client-ID und den Clientschlüssel zu generieren:

Installierte Anwendung
  1. Öffnen Sie die Google Developers Console-Seite mit Anmeldedaten.
  2. Wählen Sie aus der Drop-down-Liste Neues Projekt erstellen aus, geben Sie einen Namen für das Projekt ein und ändern Sie gegebenenfalls die vorgeschlagene Projekt-ID. Klicken Sie auf Erstellen.
  3. Wählen Sie auf der Seite "Anmeldedaten" Anmeldedaten erstellen und dann OAuth-Client-ID aus.
  4. Möglicherweise werden Sie nun aufgefordert, auf dem Bildschirm "Zustimmung" einen Produktnamen festzulegen. Klicken Sie in diesem Fall auf Zustimmungsbildschirm konfigurieren, geben Sie die benötigten Informationen ein und klicken Sie auf Speichern, um zum Bildschirm "Anmeldedaten" zurückzukehren.
  5. Wählen Sie Anderer als Anwendungstyp aus und geben Sie ggf. zusätzlich erforderliche Informationen ein.
  6. Klicken Sie auf Erstellen.
  7. Kopieren Sie auf der nun angezeigten Seite die Client-ID und den Clientschlüssel in die Zwischenablage. Sie benötigen sie später beim Konfigurieren der Clientbibliothek.
Screenshot von Client-ID- und Clientschlüssel
Webanwendung
  1. Öffnen Sie die Google Developers Console-Seite mit Anmeldedaten.
  2. Wählen Sie aus der Drop-down-Liste Neues Projekt erstellen aus, geben Sie einen Namen für das Projekt ein und ändern Sie gegebenenfalls die vorgeschlagene Projekt-ID. Klicken Sie auf Erstellen.
  3. Wählen Sie auf der Seite "Anmeldedaten" Anmeldedaten erstellen und dann OAuth-Client-ID aus.
  4. Möglicherweise werden Sie nun aufgefordert, auf dem Bildschirm "Zustimmung" einen Produktnamen festzulegen. Klicken Sie in diesem Fall auf Zustimmungsbildschirm konfigurieren, geben Sie die benötigten Informationen ein und klicken Sie auf Speichern, um zum Bildschirm "Anmeldedaten" zurückzukehren.
  5. Wählen Sie Webanwendung als Anwendungstyp aus. Folgen Sie der Anleitung zur Eingabe von JavaScript-Quellen, Weiterleitungs-URIs oder beiden Werten.
  6. Klicken Sie auf Erstellen.
  7. Kopieren Sie auf der nun angezeigten Seite die Client-ID und den Clientschlüssel in die Zwischenablage. Sie benötigen sie später beim Konfigurieren der Clientbibliothek.
Screenshot von Client-ID- und Clientschlüssel

3. Clientbibliothek konfigurieren und verwenden

Informationen zur Verwendung der OAuth2-Anmeldedaten in der Konfiguration für die Clientbibliothek Ihrer Programmiersprache finden Sie im entsprechenden Leitfaden unten:

OAuth2 Playground

Eine andere Möglichkeit, OAuth2-Anmeldedaten zu generieren, besteht in der Verwendung des OAuth2 Playground. Der OAuth2 Playground ermöglicht in Verbindung mit der Google Developers Console das manuelle Erstellen von OAuth2-Tokens.

Der OAuth2 Playground ist für Nutzer gedacht, die nur auf die Konten eines einzelnen Verwaltungskontos oder AdWords-Nutzers zugreifen müssen. Wenn von mehreren Nutzern Anmeldedaten angefordert werden müssen, ist der oben beschriebene Ansatz auf Basis der Clientbibliothek wahrscheinlich geeigneter.

Einrichtung

Client-ID und Clientschlüssel abrufen

  1. Öffnen Sie die Google Developers Console-Seite mit Anmeldedaten.
  2. Wählen Sie aus der Drop-down-Liste ein vorhandenes Projekt aus oder erstellen Sie ein neues.
  3. Wählen Sie auf der Seite "Anmeldedaten" Anmeldedaten erstellen und dann OAuth-Client-ID aus.
  4. Wählen Sie Webanwendung unter Anwendungstyp aus.
  5. Fügen Sie unter Autorisierte Weiterleitungs-URIs diese Zeile ein: https://developers.google.com/oauthplayground
  6. Klicken Sie auf Erstellen.
  7. Notieren Sie die Client-ID und den Clientschlüssel, die auf der nun angezeigten Seite zu sehen sind. Sie benötigen diese Informationen im nächsten Schritt.

Tokens generieren

  1. Wechseln Sie über diesen Link zum OAuth2 Playground. Dadurch werden einige wichtige Werte eingetragen.
  2. Klicken Sie rechts oben auf das Zahnradsymbol  und klicken Sie das Kästchen Eigene OAuth-Anmeldedaten verwenden an (falls noch kein Häkchen darin ist).
  3. Stellen Sie sicher, dass
    • OAuth-Ablauf auf Serverseite festgelegt ist.
    • Zugriffstyp auf Offline festgelegt ist. So ist sichergestellt, dass Sie ein Aktualisierungs-Token und ein Zugriffs-Token statt nur ein Zugriffs-Token erhalten.
  4. Geben Sie die oben notierten Werte für die OAuth2-Client-ID und den OAuth2-Clientschlüssel ein. Playground-Einstellungen
  5. Geben Sie im Abschnitt Schritt 1 APIs auswählen und autorisieren die folgende URL in das Textfeld unten ein (falls noch nicht vorhanden). Klicken Sie dann auf APIs autorisieren:

    https://www.googleapis.com/auth/adwords

    APIs autorisieren

  6. Wenn Sie dazu aufgefordert werden, melden Sie sich in dem Konto an, dem Sie Zugriff und Autorisierung erteilen möchten. Bestätigen Sie andernfalls, dass der derzeitige Google-Nutzer rechts oben das AdWords- oder Verwaltungskonto ist, für das Sie Anmeldedaten abrufen möchten.

  7. Nun wird gemeldet, dass Ihre Anwendung Ihre AdWords-Kampagnen verwalten möchte. Klicken Sie auf Akzeptieren, um fortzufahren.

  8. Auf dem Tab mit der Bezeichnung Schritt 2 – Autorisierungscode für Tokens austauschen sollten Sie jetzt einen Autorisierungscode sehen. Klicken Sie auf Autorisierungscode für Tokens austauschen. Playground-Authentifizierungs-Token
  9. Wenn alles in Ordnung ist, sollten jetzt die Felder Aktualisierungs-Token und Zugriffs-Token ausgefüllt sein. Möglicherweise müssen Sie Schritt 2 – Autorisierungscode für Tokens austauschen maximieren, um diese Werte zu sehen: Playground-Aktualisierungs-Token
  10. Kopieren Sie das Aktualisierungs-Token sowie die Client-ID und den Clientschlüssel in die Konfigurationsdatei Ihrer ausgewählten Clientbibliothek. In der Anleitung oben wird beschrieben, wie Sie Konfigurationsoptionen für eine Clientbibliothek festlegen.

OAuth2 Playground aus Client-ID entfernen

Da Sie jetzt ein Aktualisierungs-Token haben, benötigen Sie den OAuth2 Playground nicht mehr als autorisierte Weiterleitungs-URI. So entfernen Sie ihn aus der Liste autorisierter Weiterleitungs-URIs:

  1. Öffnen Sie die Google Developers Console-Seite mit Anmeldedaten.
  2. Wählen Sie Ihr Projekt aus der Drop-down-Liste aus.
  3. Klicken Sie auf der Seite "Anmeldedaten" auf den Client-ID-Namen, um Änderungen vorzunehmen.
  4. Entfernen Sie https://developers.google.com/oauthplayground aus Autorisierte Weiterleitungs-URIs. Es muss jedoch noch mindestens eine Weiterleitungs-URI vorhanden sein
  5. Klicken Sie auf Speichern.

Nun haben Sie die zur Ausgabe von AdWords API-Anfragen erforderlichen OAuth-Anmeldedaten. Sie können damit die Codebeispiele in der Clientbibliothek Ihrer Wahl ausprobieren.

OAuth2-Dienstkonten

In diesem Abschnitt wird gezeigt, wie der Zugriff auf die AdWords API mithilfe von Dienstkonten erfolgen kann.

Ein Dienstkonto ist ein Konto, das statt einem einzelnen Endnutzer Ihrer Anwendung gehört. Dienstkonten ermöglichen Server-zu-Server-Interaktionen zwischen einer Webanwendung und einem Google-Dienst. Ihre Anwendung ruft Google APIs im Namen des Dienstkontos auf, sodass Nutzer nicht unmittelbar beteiligt sind.

Mit der AdWords API ist der Zugriff über Dienstkonten für Google Apps-Domains möglich.

In einem Dienstkonto wird ein OAuth2-Ablauf verwendet, für den keine Autorisierung durch einen Nutzer erforderlich ist. Stattdessen wird eine Schlüsseldatei eingesetzt, auf die nur Ihre Anwendung zugreifen kann.

Dienstkonten haben zwei wesentliche Vorteile:

  • Die Autorisierung des Zugriffs auf die Google API für eine Anwendung erfolgt als Konfigurationsschritt. Daher fallen die Komplikationen weg, die bei anderen OAuth2-Abläufen auftreten können. Diese Komplikationen könnten es andernfalls erforderlich machen, dass ein Nutzer eingreift oder dass die Anwendung die Tokens im Cache speichert, um zu vermeiden, dass der Nutzer später aktiv werden muss.
  • Beim OAuth2-Assertion-Ablauf darf Ihre Anwendung ggf. die Identität anderer Nutzer übernehmen.

Eine Alternative zu Dienstkonten

Viele Entwickler erwägen den Einsatz von Dienstkonten, weil sie mit OAuth2 programmatischen Zugriff auf die API erhalten möchten, ohne dass ein Nutzereingriff erforderlich ist.

Da die Einrichtung von Dienstkonten für die AdWords API ein komplexer Vorgang ist, stellen der OAuth2-Workflow für installierte Anwendungen und die wiederholte Verwendung des Aktualisierungs-Tokens eine einfachere Alternative dar, mit der sich dasselbe erreichen lässt. Damit kann von Ihrer Anwendung bei Bedarf immer ein neues Zugriffs-Token angefordert werden.

Dazu ist erforderlich, dass Sie Ihre Anwendung bei der Konfiguration Ihrer Clientbibliothek entsprechend dem oben beschriebenen Verfahren für installierte Anwendungen autorisieren. Dies muss nur einmal erfolgen, da Google OAuth2-Aktualisierungs-Tokens nicht verfallen.

Voraussetzungen

  • Google Apps-Domain, deren Inhaber Sie sind, etwa "mydomain.com" oder "mybusiness.com"
  • AdWords API-Entwickler-Token und optional ein Testkonto
  • Clientbibliothek für die verwendete Programmiersprache

Dienstkontenzugriff einrichten

Als Erstes müssen Sie in der Google Developers Console einen Dienstkontoschlüssel generieren:

  1. Öffnen Sie die Google Developers Console, während Sie in Ihrem Google Apps for Work-Konto angemeldet sind.
  2. Wählen Sie aus der Drop-down-Liste Neues Projekt erstellen aus, geben Sie die erforderlichen Informationen ein und klicken Sie auf Erstellen. Nach kurzer Zeit wird das neue Projekt zum aktiven Projekt.
  3. Wählen Sie aus dem Menü links oben IAM und Verwaltung aus. Wählen Sie dann im Menü auf der linken Seite Dienstkonten aus.
  4. Klicken Sie oben auf Dienstkonto erstellen.
  5. Geben Sie einen Namen für das Dienstkonto ein.
  6. Klicken Sie das Kästchen Neuen privaten Schlüssel bereitstellen an und wählen Sie den Schlüsseltyp "JSON" oder "P12" aus. JSON wird derzeit für die Java-, .NET-, Perl-, Ruby- und PHP-Clientbibliotheken unterstützt; für alle anderen muss P12 verwendet werden.
  7. Klicken Sie das Kästchen Domain-weite Google Apps-Delegation aktivieren an und geben Sie einen Produktnamen für den Zustimmungsbildschirm ein.
  8. Klicken Sie auf Erstellen. Wenn Sie P12 als Format für den privaten Schlüssel ausgewählt haben, wird die Schlüsseldatei auf Ihren Computer heruntergeladen und ein Bildschirm mit einem Passwort für den privaten Schlüssel angezeigt. Speichern Sie dieses Passwort sofort, da es nicht nochmals angezeigt wird. Sie müssen dieses Passwort bei Verwendung des privaten P12-Schlüssels angeben.

    Wenn Sie JSON als Format für den privaten Schlüssel ausgewählt haben, wird die JSON-Schlüsseldatei auf Ihren Computer heruntergeladen.

    Speichern Sie die P12- oder JSON-Schlüsseldatei an einem sicheren Ort, auf den nur Sie Zugriff haben.

  9. Das neue Dienstkonto wird auf der Seite Dienstkonten des Projekts angezeigt.

Sicherheitsbedenken

Da die Google Apps-Steuerung auf Domain-Ebene erfolgt, müssen Sie die Schlüsseldatei schützen, mit der ein Dienstkonto auf die Google-Dienste zugreifen kann, für die es autorisiert wurde. Dies ist äußerst wichtig, da es mit dem Dienstkonto möglich sein wird, die Identität beliebiger Nutzer in der Domain zu übernehmen.

Außerdem sollten Dienstkonten jeweils nur Zugriff auf eine Google API erhalten (mithilfe des im folgenden Abschnitt beschriebenen Felds Umfang). Dies ist eine vorbeugende Maßnahme, damit Angreifer auf möglichst wenig Daten zugreifen können, falls die Schlüsseldatei des Dienstkontos kompromittiert wird.

Rechte zur Übernahme von Nutzeridentitäten gewähren

Gehen Sie wie folgt vor, um einem Dienstkonto Rechte zur Übernahme von Nutzeridentitäten zu gewähren:

  1. Fügen Sie Ihrer Google Maps-Domain einen neuen autorisierten API-Client hinzu, indem Sie zu https://admin.google.com/IHRE_DOMAIN/ManageOauthClients wechseln.
  2. Fügen Sie einen neuen autorisierten API-Client als Clientname hinzu. Verwenden Sie dazu die Client-ID aus der P12- bzw. JSON-Datei, die Sie bei der Aktivierung des Dienstkontos zur Domain-weiten Delegation weiter oben generiert haben.
  3. Geben Sie für den API-Umfang Folgendes ein:

    https://www.googleapis.com/auth/adwords

  4. Wiederholen Sie diesen Ablauf für alle anderen Dienstkonten, denen Sie das Recht zur Übernahme von Nutzeridentitäten gewähren möchten.

Sie können jetzt das Dienstkonto verwenden, um auf Ihr AdWords-Konto über den OAuth2-Assertion-Workflow zuzugreifen.

Clientbibliothek konfigurieren

Wählen Sie unten die zu Ihrer Programmiersprache passende Anleitung aus, um Ihre Clientbibliothek zu konfigurieren.

Java

Eine Anleitung zur Konfiguration der Clientbibliothek für Ihr Dienstkonto finden Sie in GitHub.

.NET

Eine Anleitung zur Konfiguration der Clientbibliothek für Ihr Dienstkonto finden Sie in GitHub.

Python

Eine Anleitung zur Konfiguration der Clientbibliothek für Ihr Dienstkonto finden Sie in GitHub.

PHP

Eine Anleitung zur Konfiguration der Clientbibliothek für Ihr Dienstkonto finden Sie in GitHub.

Perl

Eine Anleitung zur Konfiguration der Clientbibliothek für Ihr Dienstkonto finden Sie in GitHub.

Ruby

Eine Anleitung zur Konfiguration der Clientbibliothek für Ihr Dienstkonto finden Sie in GitHub.

OAuth2-Anforderungen optimieren

Wenn Ihre Anwendung Anmeldedaten nicht zwischen Servern, Prozessen und Threads teilt, sendet sie möglicherweise übermäßig viele Anforderungen an Google. Dies kann dazu führen, dass unsere Server der Anwendung Geschwindigkeitsobergrenzen auferlegen, die zu Leistungseinbußen führen.

In diesem Abschnitt erfahren Sie, wie Sie die Verwaltung von OAuth2-Anmeldedaten optimieren, damit Ihre Anwendung effizient mit der AdWords API interagieren kann.

Strategien zum Teilen von Anmeldedaten

Wenn Anmeldedaten von allen API-Anforderungen geteilt werden, erhöht sich die Leistung. Außerdem wird ein Übermaß an Anforderungen vermieden, die zu Geschwindigkeitsobergrenzen führen könnten.

Die Strategie zum Teilen von Anmeldedaten hängt vom Design Ihrer Anwendung ab:

In Multi-Threaded-Anwendungen müssen Sie jeder Thread-Sitzung dieselben Anmeldedaten übergeben.

In Multiprozess- oder verteilten Anwendungen müssen Sie eine geeignete Infrastruktur implementieren, um die Anmeldedaten zwischen Prozessen zu teilen. Außerdem müssen Sie sicherstellen, dass Threads nicht blockiert und in Ihrer Implementierung keine Race-Bedingungen vorhanden sind.

Eine Anwendung, die innerhalb jedes Prozesses sowohl Multiprozess/verteilt als auch Multi-Threaded ist, sollte beide Strategien verwenden.

Diese Strategien werden im Folgenden für die Authentifizierung eines einzelnen AdWords-Kontos wie beispielsweise das Verwaltungskonto auf der obersten Ebene Ihrer Hierarchie beschrieben.

Im Anschluss erfahren Sie, wie diese Strategien zur Authentifizierung mehrerer AdWords-Konten angepasst werden.

Multi-Threaded-Anwendungen

In Multi-Threaded-Anwendungen müssen Anmeldedaten zwischen Threads geteilt werden. Aktualisierungen der Anmeldedaten sollten synchron erfolgen, um Race-Bedingungen zu vermeiden.

Laufzeit

Das Diagramm zeigt eine Laufzeit mit Threads, die einen Pool von Sitzungen (oder Nutzern) verwenden, um Anforderungen an die AdWords API zu senden. Jede Sitzung muss dasselbe Anmeldedatenobjekt verwenden. Bei jeder API-Anfrage erhält der Thread eine Sitzung (oder einen Nutzer). Wenn für die Anmeldedaten eine Tokenaktualisierung erforderlich ist, muss dies synchron erfolgen. Das Anmeldedatenobjekt muss also Thread-sicher sein, um Race-Bedingungen zu vermeiden.

Mit den Clientbibliotheken ist das Teilen von Anmeldedaten zwischen Threads einfach. Jede Clientbibliothek hat ein Sitzungs- (oder Nutzer)-Objekt mit Anmeldedaten, die über seine gesamte Lebensdauer immer wieder verwendet werden. Um die Anmeldedaten über Threads zu teilen, müssen Sie lediglich jede Sitzung mit denselben Anmeldedaten erstellen. In allen Clientbibliotheken sind die Anmeldedaten ein Thread-sicheres Objekt, das sich selbst synchron aktualisiert, wenn sein Zugriffs-Token abläuft.

In der Clientbibliothek für Java würden Sie beispielsweise ein Credential als Singleton erstellen und zwischen allen Sitzungen teilen.

Multiprozess oder verteilte Anwendungen

Wenn sich Multiprozess oder verteilte Anwendungen Anmeldedaten teilen, müssen diese beständig sein. Um sicherzustellen, dass nicht mehrere Prozesse oder Server versuchen, die Anmeldedaten gleichzeitig zu aktualisieren (was zu übermäßigen Aktualisierungsanforderungen führt), empfehlen wir, die Anmeldedaten proaktiv zentral zu aktualisieren und zwischen Prozessen/Servern zu teilen.

Indem beispielsweise ein separater Auftrag oder Dienst zur regelmäßigen Aktualisierung der Anmeldedaten verwendet wird, können die Anmeldedaten proaktiv in den Datenspeicher geschrieben und somit vom Serverpool verwendet werden.

Aktualisieren

Das Diagramm zeigt den regelmäßig ausgeführten Auftrag zur Aktualisierung von Anmeldedaten und zum Schreiben der Properties der Anmeldedaten in den Datenspeicher. Jeder Server ruft dann die Anmeldedaten ab, bevor eine Anforderung an die API erfolgt.

Aktualisierungsauftrag

Vom Aktualisierungsauftrag werden die Anmeldedaten regelmäßig aktualisiert und in Datenspeicher gespeichert. Der Auftrag sollte nicht warten, bis die aktuellen Anmeldedaten abgelaufen sind, bevor eine Aktualisierung gestartet wird. Andernfalls würde ein Dialogfeld geöffnet und die Anwendung wäre aufgrund fehlender gültiger Anmeldedaten blockiert.

Besser ist es, die Aktualisierung regelmäßig zu erzwingen und jedes Mal die Anmeldedaten im Datenspeicher durch neue zu ersetzen. Der Aktualisierungsauftrag sollte rechtzeitig vor Ablauf der aktuellen Anmeldedaten ausgeführt werden, damit die Zeit bei einem vorübergehenden Ausfall nicht zu knapp wird. Alle 15 Minuten ist ein guter Ausgangspunkt.

Datenspeicher

Ein zentraler Datenspeicher kann verwendet werden, um die Anmeldedaten zwischen Prozessen und Servern zu teilen.

Sie können einen vorhandenen Datenspeicher nutzen oder einen Datenspeicher bereitstellen, der nur für das Teilen von Anmeldedaten zwischen Servern zuständig ist. Dafür gibt es Lösungen wie Caching-Server (z. B. Memcached oder Infinispan) oder NoSQL-Datenspeicher (z. B. MongoDB).

Der Datenspeicher ist eine zuverlässige Schnittstelle zu allen Servern, die Anforderungen an die API senden. Er muss für schnelle Lesevorgänge optimiert sein, da der Server oder Prozess die aktuellen Anmeldedaten häufiger liest, als sie vom Aktualisierungsauftrag aktualisiert werden.

Anmeldedaten müssen sicher aufbewahrt werden.

Beim Speichern der Anmeldedaten müssen Sie außer dem Zugriffs-Token access_token die berechnete Ablaufzeit expiry_time (jetzt + expires_in) und das Aktualisierungs-Token refresh_token speichern. Die expiry_time wird zum Zeitpunkt der Aktualisierungsanforderung von access_token berechnet. Dazu wird die expires_in-Zeit addiert.

Serverpool

Jeder Server oder Prozess im Pool ruft die neuesten Anmeldedaten aus dem Datenspeicher ab, bevor er eine Anforderung sendet. Wenn der Aktualisierungsauftrag erfolgreich ausgeführt wird, sind die Anmeldedaten gültig. Falls jedoch vom Aktualisierungsauftrag oder Datenspeicher ein Fehler zurückgegeben wird, muss ein Fallback-Mechanismus vorhanden sein.

Sollte ein Server oder Prozess aus dem Datenspeicher keine Anmeldedaten erhalten oder sind die Anmeldedaten abgelaufen, muss der Server seine eigenen Anmeldedaten aktualisieren, damit die Anwendung weiterhin mit der API arbeiten kann, bis das Problem gelöst ist.

Bei Prozessen mit mehreren Threads müssen Sie dieselbe Strategie zum Teilen von Anmeldedaten zwischen Threads verwenden (siehe weiter oben).

Mehrere Konten authentifizieren

Für ein AdWords-Verwaltungskonto generierte Anmeldedaten können für den Zugriff auf sämtliche untergeordneten Konten verwendet werden. Für Nutzer mit einer Hierarchie mit einem einzelnen Verwaltungskonto ist es daher in der Regel ausreichend, Anmeldedaten nur für das Verwaltungskonto der obersten Ebene zu generieren. Dadurch wird die Anwendung für sämtliche AdWords-Konten darunter autorisiert.

Es gibt aber auch Fälle, in denen Ihre Anwendung auf AdWords-Konten zugreifen muss, die in keiner Verwaltungskontohierarchie miteinander in Beziehung stehen. In diesem Fall müssen Sie unterschiedliche Anmeldedaten für unterschiedliche Konten generieren und verwalten, wie beispielsweise für jedes AdWords-Kundenkonto oder jedes Verwaltungskonto auf der obersten Ebene in unabhängigen Hierarchien, auf das Sie zugreifen.

Sie können die gleichen Strategien mit geringen Änderungen auf Multi-Threaded und Multiprozess-/verteilte Anwendungen anwenden. Wenn Sie einen freigegebenen Datenspeicher verwenden, müssen Anmeldedaten mit der Kontokennung customerId indiziert werden, um sicherzustellen, dass Anmeldedaten mit dem richtigen Konto verknüpft sind. Außerdem muss der Aktualisierungsauftrag alle Anmeldedaten immer auf dem neuesten Stand halten. Wenn ein neues Konto verknüpft wird, muss möglicherweise der Aktualisierungsauftrag ausgelöst werden.

Sie dürfen außerdem in Multi-Threaded-Anwendungen das Anmeldedatenobjekt nur zwischen Threads teilen, die mit dem Konto arbeiten, mit dem das Anmeldedatenobjekt verknüpft ist.

OAuth2-Interna

Unsere Clientbibliotheken kümmern sich automatisch um die folgenden Details. Lesen Sie daher nur weiter, wenn Sie wissen möchten, was hinter den Kulissen abläuft.

Dieser Abschnitt ist für fortgeschrittene Nutzer gedacht, die bereits mit den OAuth 2.0-Spezifikationen vertraut sind und wissen, wie sie OAuth2 mit Google APIs verwenden.

Umfang

Ein einzelnes Zugriffs-Token kann mehreren APIs unterschiedliche Zugriffsebenen gewähren. Über den variablen Parameter scope werden die Ressourcen und Vorgänge gesteuert, die über ein Zugriffs-Token gewährt werden. Bei der Anforderung eines Zugriffs-Tokens sendet Ihre Anwendung im Parameter scope einen oder mehrere Werte.

Aktuelle und eingestellte Umfänge für die AdWords API:

Umfang Bedeutung
https://www.googleapis.com/auth/adwords Lese-/Schreibzugriff auf die AdWords API
https://adwords.google.com/api/adwords/ Dieser Umfang wurde eingestellt und sollte nicht mehr verwendet werden, um künftige Autorisierungen zu erhalten. Zuvor autorisierte Tokens funktionieren weiterhin.

Offlinezugriff

Eine AdWords API-Client-Anwendung fordert häufig Offlinezugriff an. So kann es beispielsweise vorkommen, dass Ihre Anwendung Batch-Aufgaben ausführen möchte, wenn der Nutzer gerade nicht auf Ihrer Website aktiv ist.

Um Offlinezugriff für eine Webanwendung anzufordern, müssen Sie für den Parameter access_type den Wert offline festlegen. Weitere Informationen erhalten Sie im OAuth2-Leitfaden von Google.

Für installierte Anwendungen ist der Offlinezugriff standardmäßig aktiviert. Sie müssen den Offlinezugriff nicht extra anfordern.

HTTP-Header von Anforderungen

Der HTTP-Header jeder Anforderung beim AdWords API-Server muss das Zugriffs-Token im folgenden Format enthalten:

Authorization: Bearer THE_ACCESS_TOKEN

Beispiel:

POST … HTTP/1.1
Host: …
Authorization: Bearer 1/fFAGRNJru1FTz70BzhT3Zg
Content-Type: text/xml;charset=UTF-8
Content-Length: …

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope">
  …
</soap:Envelope>

Zugriffs- und Aktualisierungs-Token

In den meisten Fällen müssen Sie die Aktualisierungs-Tokens für die zukünftige Verwendung sicher speichern. Lesen Sie die Ihrem Anwendungstyp entsprechende Anleitung, um weitere Informationen zum Anfordern von Zugriffs- und Aktualisierungs-Tokens zu erhalten:

Ablauf des Zugriffs-Tokens

Zugriffs-Tokens haben ein Gültigkeitsdatum (im Wert expires_in festgelegt). Nach diesem Datum wird das Token ungültig. Sie können abgelaufene Zugriffs-Tokens über das Aktualisierungs-Token wiederherstellen. Standardmäßig aktualisieren unsere Clientbibliotheken abgelaufene Zugriffs-Tokens automatisch.

Feedback geben zu...