Google Cloud Platform Authentication

Um die verschiedenen Google Cloud APIs verwenden zu können, müssen die Anfragen zu diesen APIs eine Authentifizierung bestehen. In diesem Artikel erklären wir die Grundlagen.

Um Anfragen zu den Google Cloud APIs zu authentifizieren gibt es grundsätzlich drei verschiedene Arten:
  • API Keys
  • OAuth 2.0 Client IDs
  • Service Accounts
Sollte man bei der Wahl der richtigen Credentials Hilfe benötigen, so kann der GCP Credential Wizard genutzt werden. Abhängig von der verwendeten API (Google Maps API etc.), der Umgebung (Client, Server, Chrome Application etc.) und der verwendeten Daten (User data und Application data), wird einem dann die passende Art angezeigt.

Google Cloud Platform Authentication

Quelle: eigener Screenshot

1 API Keys

Ein API Key ist einfach eine Abfolge von Zeichen, als Beispiel anbei ein Screenshot. Er dient dazu eine Applikation ohne einen Principal / User zu identifizieren. Sie werden dazu verwendet, um auf öffentliche Daten anonym zuzugreifen. Zusätzlich sind sie immer an ein GCP Projekt gebunden und es können auf diese Weise API Quotas (z.B. nur 1.000 Anfragen am Tag) durchgesetzt als auch Kosten verrechnet werden.

API KEY

Quelle: eigener Screenshot

Ein klassisches Beispiel für die Verwendung von einem API Key ist eine der Google Maps APIs. Um den folgenden Kartenausschnitt von Google Maps auf der eigenen Website einzubinden, muss zuerst ein API Key generiert und bei der Google Maps Abfrage mitgesendet werden. Dabei ist darauf zu achten, dass der API Key nicht öffentlich sichtbar ist.

staticmap

Quelle: https://developers.google.com/

2 OAuth 2.0 Client IDs

Bei dieser Authentifizierungsart gibt es einmal die öffentlich sichtbare Client ID, sie identifiziert den Client / was in den meisten Fällen die entwickelte Applikation selbst ist. Zusätzlich gibt es noch den Client secret, dieser wird im Hintergrund an Google gesendet, um die Authentifizierung zu ermöglichen.

Client ID

Quelle: eigener Screenshot

In der Praxis kennen wir alle das Google Popup um uns auf einer Website oder App mittels unseren Google Accounts einzuloggen, das ist OAuth 2.0. Als Beispiel habe ich anbei einen Screenshot des Google Login Popups eingefügt, welches auch während der Installation eines Google Sheet Addons erscheint. In der URL ist auch die oben erwähnte Client ID sichtbar.

OAuth 2.0

Quelle: eigener Screenshot

Mit dieser Authentifizierungsart wird ermöglicht, dass eine Applikation im Namen des Endnutzers auf Google Cloud APIs zugreifen kann. Beispiele dafür sind: die Applikation kann Google Analytics Konten ändern oder Berichte abrufen, E-Mails über GMail senden und lesen, auf Google Drive Dokumente zugreifen, Campaign Manager Berichte abrufen etc.

Wenn eine Applikation Zugriff mittels OAuth anfragt, so müssen dabei auch immer OAuth-Bereiche / OAuth-Scopes definiert werden. Das sind die erlaubten Rechte je Google Cloud API.

Eine komplette Liste der Scopes findet man hier: https://developers.google.com/identity/protocols/oauth2/scopes

Zum Beispiel bietet die Google Analytics Reporting API diese beiden Scopes an:



Für den Endnutzer werden diese Scopes in verständlichere Begriffe übersetzt. Die Scopes werden innerhalb des Google Login Popups auf der zweiten Seite aufgelistet.

GTM Tools

Quelle: eigener Screenshot

Um zu sehen welchen Applikationen man in der Vergangenheit welche Scopes erlaubt hat, kann man die Seite: https://myaccount.google.com/security aufrufen. Unter den Punkten “Thirt-party apps with account access” und “Singin in to other sites > Singing in with Google” sind alle Applikationen aufgelistet und man kann diesen ggf. die Berechtigungen auch wieder entziehen.

Third Party Apps

Quelle: eigener Screenshot

3 Service Accounts

In einem GCP Projekt können vier verschieden Mitglieds Typen hinzugefügt werden, ein Typ davon sind Service Accounts / Dienstkonten.

iam-overview-basics

Quelle: https://cloud.google.com/

Ein Dienstkonto ist ein spezieller Kontotyp, der nicht von einer Person, sondern von einer Anwendung verwendet wird. Ein Dienstkonto wird durch seine E-Mail-Adresse definiert, die für das Konto spezifisch ist.

Weitere wichtige Eigenschaften sind:

  • Dienstkonten haben keine Passwörter und können sich nicht über Browser oder Cookies anmelden.
  • Dienstkonten sind privaten und öffentlichen RSA-Schlüsselpaaren zugeordnet, die zur Authentifizierung bei Google verwendet werden.
  • Diese Schlüssel können entweder von Google oder von einem GCP Nutzer selbst verwaltet werden.


Ein Beispiel für einen öffentlichen Schlüssel:

89850be783b604313d51f0c2bf225f35e12dd6ea

Ein Beispiel für einen privaten Schlüssel:

Private Key

Mit Hilfe dieses “Robo Accounts” können dann Anwendungen ausgeführt werden. Zum Beispiel führen Service Accounts bei unseren Kunden folgende Tätigkeiten durch:

  • Täglicher Upload von Floodlight Offline Conversions
  • Täglicher Import über die Google Analytics Data Import API
  • etc.


Ein Vorteil von Service Accounts ist, dass die Ausführung der Anwendung unabhängig von Mitarbeitern ist. Denn sollte der Mitarbeiter welcher die Anwendung erstellt hat das Unternehmen verlassen, wird der Service Account weiterhin seine Aufgaben ausführen.

Wenn die Anwendung in der Compute Engine, Google Kubernetes Engine, App Engine, Cloud Run, oder Cloud Functions umgesetzt wird, muss nicht extra ein neuer Service Account erstellt werden. Es kann ein sogenannter “Default Service Account” verwendet werden, welcher automatisch in jedem GCP Projekt existiert. Auch der Zugriff und die Verwendung der Schlüssel ist in diesem Fall einfacher und sicherer.

Eine gut Übersicht der Authentifizierungs Arten gibt es ebenfalls innerhalb der GCP Dokumentation:
Anforderung Empfehlung Kommentar
Auf öffentliche Daten ohne Anmeldedaten zugreifen API-Schlüssel Ein API-Schlüssel identifiziert nur die Anwendung und erfordert keine Nutzerauthentifizierung. Dies ist für den Zugriff auf öffentliche Daten ausreichend.
Auf private Daten im Namen eines Endnutzers zugreifen OAuth 2.0-Client Ein OAuth 2.0-Client identifiziert die Anwendung und ermöglicht es Endnutzern, Ihre Anwendung bei Google zu authentifizieren. Dadurch kann Ihre Anwendung im Namen des Endnutzers auf Google Cloud APIs zugreifen.
Innerhalb von Google Cloud-Umgebungen im Namen eines Dienstkontos auf private Daten zugreifen Von der Umgebung bereitgestelltes Dienstkonto Wenn Ihre Anwendung in einer Google Cloud-Umgebung wie Compute Engine, App Engine, GKE, Cloud Run oder Cloud Functions ausgeführt wird, sollte sie das von der Umgebung bereitgestellte Dienstkonto verwenden. Google Cloud-Clientbibliotheken suchen und verwenden automatisch die Anmeldedaten für das Dienstkonto.
Außerhalb von Google Cloud-Umgebungen im Namen eines Dienstkontos auf private Daten zugreifen Dienstkontoschlüssel Sie müssen ein Dienstkonto erstellen und den privaten Schlüssel als JSON-Datei herunterladen. Sie müssen die Datei an Google Cloud-Clientbibliotheken übergeben, damit sie die Anmeldedaten für das Dienstkonto zur Laufzeit generieren können. Google Cloud-Clientbibliotheken suchen und verwenden die Anmeldedaten für das Dienstkonto automatisch mithilfe der Umgebungsvariablen GOOGLE_APPLICATION_CREDENTIALS.
Quelle: https://cloud.google.com/docs/authentication

Für mehr Information zur Google Cloud Platform kontaktiert unsere Experts:

kontakt@e-dialog.at

Hinterlassen Sie einen Kommentar: