Tag Manager API-Autorisierung

In diesem Dokument wird beschrieben, wie Anwendungen die Berechtigung erhalten, Anfragen an die Tag Manager API zu senden.

Anfragen autorisieren

Bevor Nutzer ihre Kontoinformationen auf einer Google-Website aufrufen können, müssen sie sich mit einem Google-Konto anmelden. Ebenso müssen Nutzer beim ersten Zugriff auf Ihre Anwendung die Anwendung für den Zugriff auf ihre Daten autorisieren.

Jede Anfrage, die Ihre Anwendung an die Tag Manager API sendet, 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.

Hier finden Sie Informationen zum Umfang von OAuth 2.0 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 Verwalten Sie Ihre Google Tag Manager-Container.
https://www.googleapis.com/auth/tagmanager.delete.containers Löschen Sie Ihre Google Tag Manager-Container.
https://www.googleapis.com/auth/tagmanager.edit.containerversions Verwalten Sie Ihre Google Tag Manager-Containerversionen.
https://www.googleapis.com/auth/tagmanager.publish Veröffentlichen Sie Ihre Google Tag Manager-Container.
https://www.googleapis.com/auth/tagmanager.manage.users Hier können Sie Nutzerberechtigungen für Ihre Google Tag Manager-Daten verwalten.
https://www.googleapis.com/auth/tagmanager.manage.accounts Verwalten Sie Ihre Google Tag Manager-Konten.

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

Wenn Sie die Tag Manager API verwenden möchten, müssen Sie zuerst das Einrichtungstool verwenden. Dieses Tool führt Sie durch die Erstellung eines Projekts in der Google API Console, die Aktivierung der API und die Erstellung von Anmeldedaten.

So richten Sie ein neues Dienstkonto ein:

  1. Klicken Sie auf Anmeldedaten erstellen > Dienstkontoschlüssel.
  2. Wählen Sie aus, ob der öffentliche/private Schlüssel des Dienstkontos als Standard-P12-Datei oder als JSON-Datei heruntergeladen werden soll, 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. Es liegt in Ihrer Verantwortung, ihn sicher aufzubewahren.

Gängige OAuth 2.0-Abläufe

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-/geplanten Zugriff auf das Google Tag Manager-Konto eines Nutzers.

Beispiel:
  • Tag Manager-Informationen werden automatisch von einem Server aktualisiert.

Clientseitig

Ideal, wenn Nutzer direkt mit der Anwendung interagieren, um über einen Browser auf ihr Google Tag Manager-Konto zuzugreifen. Bei diesem Ablauf sind keine serverseitigen Funktionen erforderlich. Er ist aber auch nicht für automatisierte, Offline- oder geplante Berichte geeignet.

Beispiel:
  • Ein benutzerdefiniertes browserbasiertes Konfigurationstool.

Installierte Apps

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

Beispiele:
  • Ein Desktop-Widget auf einem PC oder Mac.
  • Plug-in für ein Content-Management-System. Der Vorteil dieses Ablaufs im Vergleich zum Webserver oder auf Clientseite besteht darin, dass für Ihre Anwendung ein einzelnes API-Konsolenprojekt verwendet werden kann. Dies erleichtert Nutzern die 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 mit anderen Nutzern zu teilen.

Fehlerbehebung

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

Wenn der autorisierte Nutzer keinen Zugriff auf das Google Tag Manager-Konto oder -Container hat, wird in der Antwort der Statuscode 403 zurückgegeben. Prüfen Sie, ob Sie vom richtigen Nutzer autorisiert sind und ob Sie Berechtigungen für den Zugriff auf das Tag Manager-Konto oder -Container haben.

OAuth 2.0 Playground

Mit OAuth 2.0 Playground kannst du den gesamten Autorisierungsvorgang über eine Weboberfläche durchlaufen. Das Tool zeigt außerdem alle HTTP-Anfrageheader an, die zum Erstellen einer autorisierten Abfrage erforderlich sind. Wenn Sie keine Autorisierung für die Ausführung in Ihrer eigenen Anwendung erhalten, sollten Sie versuchen, sie über OAuth 2.0 Playground auszuführen. Dann können Sie die HTTP-Header und die Anfrage aus dem Playground mit den Daten vergleichen, die Ihre Anwendung sendet. Mit dieser Prüfung können Sie ganz einfach prüfen, ob Ihre Anfragen richtig formatiert sind.

Ungültige Erteilung

Wenn Sie beim Versuch, ein Aktualisierungstoken zu verwenden, die Fehlermeldung invalid_grant erhalten, kann der Fehler durch eine oder beide der folgenden Ursachen verursacht werden:

  1. Die Uhr Ihres Servers ist nicht NTP synchron.
  2. Sie haben die maximale Anzahl von 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 die Fehlerantwort invalid_grant zurückgegeben. Jede eindeutige Kombination aus Client-ID und Konto kann bis zu 25 Aktualisierungstokens haben. Diese Beschränkung kann sich ändern. Wenn die Anwendung weiterhin Aktualisierungstokens für dieselbe Kombination aus Client-ID und Konto anfordert, wird das erste ausgestellte Aktualisierungstoken ungültig, sobald das 26. Token ausgegeben wurde. Das 27. angeforderte Aktualisierungstoken macht das zweite ausgestellte Token ungültig usw.