Tag Manager API-Autorisierung

In diesem Dokument wird beschrieben, wie eine Anwendung die Autorisierung für Anfragen an die Tag Manager API erhalten kann.

Anfragen autorisieren

Bevor Nutzer ihre Kontoinformationen auf einer Google-Website aufrufen können, müssen sie sich zuerst mit einem Google-Konto anmelden. Wenn Nutzer zum ersten Mal auf Ihre Anwendung zugreifen, müssen sie Ihrer Anwendung auf dieselbe Weise die Berechtigung zum Zugriff auf ihre Daten erteilen.

Jede Anfrage, die von Ihrer Anwendung an die Tag Manager API gesendet wird, muss ein Autorisierungstoken enthalten. Anhand dieses Tokens wird deine Anwendung Google gegenüber identifiziert.

Autorisierungsprotokolle

Ihre Anwendung muss zur Autorisierung von Anfragen OAuth 2.0 verwenden. Andere Autorisierungsprotokolle werden nicht unterstützt. Wenn deine Anwendung Über Google anmelden verwendet, werden einige Schritte der Autorisierung automatisch ausgeführt.

Anfragen mit OAuth 2.0 autorisieren

Alle Anfragen an die Tag Manager API müssen von einem authentifizierten Nutzer autorisiert werden.

Die Details dieses Autorisierungsablaufs für OAuth 2.0 hängen davon ab, welche Art von Anwendung du schreibst. Die folgende allgemeine Vorgehensweise gilt für alle Arten von Anwendungen:

  1. Wenn Sie Ihre Anwendung erstellen, registrieren Sie diese über die Google API Console. Google stellt Ihnen dann die Informationen bereit, die du später benötigst, z. B. eine Client-ID und einen Clientschlüssel.
  2. Aktivieren Sie die Tag Manager API in der Google API Console. Überspringe diesen Schritt, falls die API nicht in der API Console aufgeführt ist.
  3. Wenn deine Anwendung Zugriff auf Nutzerdaten benötigt, bittet sie Google um einen bestimmten Zugriffsbereich.
  4. Dem Nutzer wird von Google ein Zustimmungsbildschirm angezeigt, auf dem er gebeten wird, deine Anwendung dazu zu autorisieren, einige seiner Daten abzufragen.
  5. Wenn der Nutzer zustimmt, erhält deine Anwendung von Google ein kurzlebiges Zugriffstoken.
  6. Die Anwendung fordert Nutzerdaten an, wobei das Zugriffstoken an die Anfrage angehängt wird.
  7. Stellt Google fest, dass Ihre Anfrage und das Token gültig sind, werden die angeforderten Daten zurückgegeben.

Einige Abläufe enthalten zusätzliche Schritte, beispielsweise die Verwendung von Aktualisierungstoken zum Erhalt neuer Zugriffstoken. Weitere Informationen über die Abläufe für die unterschiedlichen Anwendungstypen findest du in der OAuth 2.0-Dokumentation.

Im Folgenden finden Sie die Informationen zum OAuth 2.0-Bereich für die Tag Manager API:

Umfang Bedeutung
https://www.googleapis.com/auth/tagmanager.readonly Ihre Google Tag Manager-Container ansehen
https://www.googleapis.com/auth/tagmanager.edit.containers Google Tag Manager-Container verwalten
https://www.googleapis.com/auth/tagmanager.delete.containers Löschen Sie Ihre Google Tag Manager-Container.
https://www.googleapis.com/auth/tagmanager.edit.containerversions Ihre Google Tag Manager-Containerversionen verwalten
https://www.googleapis.com/auth/tagmanager.publish Veröffentlichen Sie Ihre Google Tag Manager-Container.
https://www.googleapis.com/auth/tagmanager.manage.users Nutzerberechtigungen für Ihre Google Tag Manager-Daten verwalten
https://www.googleapis.com/auth/tagmanager.manage.accounts Google Tag Manager-Konten verwalten

Zur Anforderung eines Zugriffs mit OAuth 2.0 benötigt Ihre Anwendung die Informationen zum Umfang sowie die Informationen, die Google bei der Registrierung Ihrer Anwendung bereitstellt, z. B. die Client-ID und den Clientschlüssel.

Erste Schritte

Damit Sie die Tag Manager API verwenden können, müssen Sie zuerst mithilfe des Einrichtungstools ein Projekt in der Google API Console erstellen und die API aktivieren.

So richten Sie ein neues Dienstkonto ein:

  1. Klicken Sie auf Anmeldedaten erstellen > Dienstkontoschlüssel.
  2. Wählen Sie aus, ob Sie den öffentlichen/privaten Schlüssel des Dienstkontos als Standard-P12-Datei oder als JSON-Datei herunterladen möchten, die von einer Google API-Clientbibliothek geladen werden kann.

Ihr neues öffentliches/privates Schlüsselpaar wird generiert und auf Ihren Computer heruntergeladen. Dies ist die einzige Kopie dieses Schlüssels. Sie sind dafür verantwortlich, dass er sicher aufbewahrt wird.

Häufige OAuth 2.0-Vorgänge

In den folgenden Richtlinien werden häufige Anwendungsfälle für bestimmte OAuth 2.0-Abläufe beschrieben:

Webserver

Dieser Ablauf eignet sich für den automatisierten, Offline- oder geplanten Zugriff auf das Google Tag Manager-Konto eines Nutzers.

Beispiel:
  • Tag Manager-Informationen automatisch von einem Server aktualisieren lassen

Clientseitig

Ideal, wenn Nutzer direkt mit der Anwendung interagieren, um in einem Browser auf ihr Google Tag Manager-Konto zuzugreifen. Bei diesem Ablauf sind keine serverseitigen Funktionen erforderlich. Er ist jedoch für automatisierte/Offline-/geplante Berichte ungeeignet.

Beispiel:
  • Ein angepasstes browserbasiertes Konfigurationstool.

Installierte Apps

Für Anwendungen, die als Paket verteilt und vom Nutzer installiert werden. Dazu muss die Anwendung oder der Nutzer Zugriff auf einen Browser haben, um den Authentifizierungsablauf abzuschließen.

Beispiele:
  • Ein Desktop-Widget auf einem PC oder Mac.
  • Ein Plug-in für ein Content-Management-System. Der Vorteil dieses Ablaufs im Vergleich zu Webserver- oder clientseitigen Abläufen besteht darin, dass für Ihre Anwendung ein einzelnes API-Konsolenprojekt verwendet werden kann. Dies ermöglicht Nutzern eine einfachere Installation.

Dienstkonten

Nützlich für den automatisierten/Offline-/geplanten Zugriff auf Ihr eigenes Google Tag Manager-Konto. Sie können beispielsweise ein benutzerdefiniertes Tool erstellen, um Ihr eigenes Google Tag Manager-Konto zu überwachen und es für andere Nutzer freizugeben.

Fehlerbehebung

Wenn Ihr access_token abgelaufen ist oder Sie für einen bestimmten API-Aufruf den falschen Bereich verwenden, erhalten Sie in der Antwort den Statuscode 401.

Wenn der autorisierte Nutzer keinen Zugriff auf das Google Tag Manager-Konto oder den Container hat, erhalten Sie in der Antwort den Statuscode 403. Prüfen Sie, ob Sie mit dem richtigen Nutzer autorisiert sind und ob Ihnen Berechtigungen für den Zugriff auf das Tag Manager-Konto oder den Container gewährt wurden.

OAuth 2.0 Playground

Mit dem OAuth 2.0 Playground können Sie den gesamten Autorisierungsvorgang über eine Weboberfläche durchlaufen. Das Tool zeigt auch alle HTTP-Anfrageheader an, die für eine autorisierte Anfrage erforderlich sind. Wenn die Autorisierung in Ihrer eigenen Anwendung nicht funktioniert, sollten Sie versuchen, sie über den OAuth 2.0 Playground zum Laufen zu bringen. Anschließend können Sie die HTTP-Header und die Anfrage aus der Playground-Umgebung mit den von Ihrer Anwendung gesendeten Daten vergleichen. So können Sie ganz einfach prüfen, ob Sie Ihre Anfragen richtig formatieren.

Ungültige Genehmigung

Wenn Sie beim Versuch, ein Aktualisierungstoken zu verwenden, eine invalid_grant-Fehlerantwort erhalten, kann der Fehler eine oder beide der folgenden Ursachen haben:

  1. Die Uhr Ihres Servers ist nicht mit NTP synchronisiert.
  2. Sie haben das Limit für Aktualisierungstokens überschritten.
    Anwendungen können mehrere Aktualisierungstokens anfordern, um auf ein einzelnes Google Tag Manager-Konto zuzugreifen. Das ist beispielsweise nützlich, wenn ein Nutzer eine Anwendung auf mehreren Computern installieren und auf dasselbe Google Tag Manager-Konto zugreifen möchte. In diesem Fall sind zwei Aktualisierungstokens erforderlich, eines für jede Installation. Wenn die Anzahl der Aktualisierungstokens das Limit überschreitet, werden ältere Tokens ungültig. Wenn die Anwendung versucht, ein ungültiges Aktualisierungstoken zu verwenden, wird eine invalid_grant-Fehlerantwort zurückgegeben. Für jede eindeutige Kombination aus Client-ID und Konto können bis zu 25 Aktualisierungstokens vorhanden sein. Dieses Limit kann sich ändern. Wenn die Anwendung weiterhin Aktualisierungstokens für dieselbe Client-ID-/Konto-Kombination anfordert, wird das erste ausgegebene Aktualisierungstoken ungültig, sobald das 26. Token ausgestellt wird. Das 27. angeforderte Aktualisierungstoken macht das 2. ausgestellte Token ungültig usw.