In diesem Dokument und im Dokument Tokentypen werden die verschiedenen Tokens beschrieben, die von Google Cloud für die Authentifizierung und Autorisierung verwendet werden. Sie sind für Personen gedacht, die mehr über die tokenbasierte Authentifizierung erfahren oder die Authentifizierung ohne die Cloud-Clientbibliotheken implementieren möchten.
Sie müssen diese Informationen nicht kennen, wenn Sie über die Cloud-Clientbibliotheken, die Google Cloud -Konsole oder die Google Cloud CLI mit Google Cloud-APIs interagieren. Die Auswahl des richtigen Tokentyps sowie das Abrufen und Aktualisieren dieser Tokens werden automatisch für Sie erledigt.
Nutzerauthentifizierung
Wenn menschliche Nutzer mit Google Cloudinteragieren, interagieren sie nicht direkt mitGoogle Cloud APIs. Stattdessen verwenden sie einen Client, der in ihrem Namen handelt.
Der Client, den sie verwenden, kann eine Webanwendung, eine Desktopanwendung oder ein Dienstprogramm wie die Google Cloud CLI oder curl sein.
Da der Client Anfragen stellt und nicht der Nutzer, kann Google Cloud nicht direkt Identitätsinformationen vom Nutzer anfordern, um zu prüfen, ob er die Berechtigung zur Verwendung einer API hat. Stattdessen wird diese Identität über den Client in Form eines Tokens an die API übergeben, das in jeder API-Anfrage enthalten ist.
Ein Nutzerauthentifizierungstoken enthält die folgenden Informationen:
Die Identität des Nutzers.
Die Identität des Clients.
Bestätigung, dass der Client im Namen des Nutzers handeln darf.
Die Authentifizierung des Nutzers und die Autorisierung des Clients umfassen die folgenden Parteien:
Mit einem Nutzer.
Ein Client, der im Namen des Nutzers handelt.
Ein Autorisierungsserver, auf den Google APIs angewiesen sind, um den Client zu authentifizieren.
Eine Google Cloud API, mit der der Client interagiert.
Clients können keine eigenen Tokens ausstellen. Stattdessen müssen sie mit einem Autorisierungsserver zusammenarbeiten, um Folgendes zu tun:
Authentifizieren Sie den Nutzer.
Authentifizieren Sie den Client.
Autorisieren Sie den Client, im Namen des Nutzers zu handeln.
Stellen Sie dem Client ein Token aus.
Ein Nutzer, der sich durch Anmeldung in seinem Google-Konto authentifiziert, ist ein Nutzer-Principal. Der Prinzipal hat eine Prinzipal-ID, die in etwa so aussieht:
user:alex@example.com
Ein Nutzer, der sich mit der Workforce Identity-Föderation und einem externen Identitätsanbieter authentifiziert, ist ein Workforce Identity-Pool-Hauptkonto. Der Prinzipal hat eine Prinzipal-ID, die in etwa so aussieht:
principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/raha@altostrat.com
Arbeitslastauthentifizierung
Einige Clients müssen in ihrem eigenen Namen mit Google-APIs interagieren. Beispielsweise muss ein geplanter Job möglicherweise Daten aus BigQuery oder Cloud Storage lesen, ohne dass ein menschlicher Nutzer beteiligt ist.
Clients, die unbeaufsichtigt und in eigenem Namen agieren, werden als Arbeitslasten bezeichnet. Im Gegensatz zur Nutzerauthentifizierung wird bei der Arbeitslastauthentifizierung die Authentifizierung des Nutzers und die Autorisierung des Clients in einem einzigen Schritt kombiniert. Aus diesem Grund wird in einem Token zur Workload-Authentifizierung nur die Identität des Clients codiert.
Die Authentifizierung und Autorisierung von Arbeitslasten umfasst die folgenden Parteien:
Eine Arbeitslast, die sowohl als Client als auch als Nutzer und in ihrem eigenen Namen fungiert.
Ein Autorisierungsserver, auf den Google APIs angewiesen sind, um den Client zu authentifizieren.
Eine Google Cloud API, mit der der Client interagiert.
Um auf Google Cloud APIs zuzugreifen, müssen Clients mit einem Autorisierungsserver zusammenarbeiten, um Folgendes zu tun:
Authentifizieren Sie den Client.
Autorisieren Sie den Client.
Stellen Sie dem Client ein Token aus.
Eine authentifizierte Arbeitslast wird auch als Prinzipal bezeichnet. Arbeitslasten verwenden jedoch andere Prinzipal-IDs als Nutzer.
Eine Arbeitslast, die sich mit einem Dienstkonto authentifiziert, ist ein Dienstkonto-Hauptkonto. Der Prinzipal hat eine Prinzipal-ID, die etwa so aussieht:
serviceAccount:my-service-account@my-project.iam.gserviceaccount.com
Eine Arbeitslast, die sich mit Workload Identity-Föderation authentifiziert, ist ein Prinzipal des Workload Identity-Pools. Das Hauptkonto hat eine Hauptkonto-ID, die der folgenden ähnelt:
principal://iam.googleapis.com/projects/PROJECT_NAME/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE
Autorisierungsserver
Google Cloud bietet bestimmte Authentifizierungs- und Autorisierungsfunktionen für andere Google-Dienste. Zu den gemeinsamen Funktionen gehören Mit Google anmelden sowie die von Google Identity bereitgestellten Dienste OpenID Connect und OAuth 2.0.
Andere authentifizierungsbezogene Dienste wie die Workload Identity-Föderation und die Workforce Identity-Föderation sind spezifisch für Google Cloud und können nicht für andere Google-Dienste verwendet werden.
Aus diesem Grund verwendet Google Cloud zwei Autorisierungsserver. Eine wird mit anderen Google-Diensten geteilt, die andere ist spezifisch für Google Cloud. In der folgenden Tabelle werden die verschiedenen Server und ihre Eigenschaften beschrieben.
| Autorisierungsserver | Authentifizierungstyp | Authentifizierungs-APIs | Hauptkonten |
|---|---|---|---|
| Google-Autorisierungsserver |
|
|
|
| Google Cloud Autorisierungsserver für die Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM) |
|
Die Autorisierungsserver sind globale Dienste und können von jeder Google Cloud Region aus aufgerufen werden. Allerdings sind nicht in allen Regionen beide Autorisierungsserver verfügbar:
Der Google-Autorisierungsserver ist in ausgewählten Regionen verfügbar.
Der Google Cloud IAM-Autorisierungsserver ist in allen Regionen verfügbar.
Um die Zuverlässigkeit zu optimieren, sollten Sie nach Möglichkeit immer den Google Cloud IAM-Autorisierungsserver verwenden.
Nächste Schritte
Weitere Informationen zu Tokentypen