Arten von Tokens

Auf dieser Seite werden die Arten von Tokens erläutert, die zur Authentifizierung bei Google APIs, Google Cloud-Diensten und von Kunden erstellten Diensten verwendet werden, die in Google Cloud gehostet werden.

Wenn Sie über eine Clientbibliothek auf Google APIs und Google-Dienste zugreifen, können Sie Standardanmeldedaten für Anwendungen einrichten. Die Clientbibliothek verarbeitet Tokens für Sie. Dies ist der empfohlene Ansatz.

Was Tokens sind

Für die Authentifizierung und Autorisierung ist ein Token ein digitales Objekt, das Informationen zur Identität des Hauptkontos enthält, das die Anfrage stellt, und zu welcher Art von Zugriff es autorisiert ist. In den meisten Authentifizierungsabläufen tauscht die Anwendung (oder eine von der Anwendung verwendete Bibliothek) Anmeldedaten für ein Token aus, die bestimmen, auf welche Ressourcen die Anwendung zugreifen darf.

Arten von Tokens

In verschiedenen Umgebungen werden verschiedene Arten von Tokens verwendet. Die folgenden Arten von Tokens werden auf dieser Seite beschrieben:

Auf dieser Seite werden keine API-Schlüssel behandelt, die als Anmeldedaten betrachtet werden.

Zugriffstokens

Zugriffstokens sind intransparente Tokens, die dem OAuth 2.0-Framework entsprechen. Sie enthalten Autorisierungsinformationen, jedoch keine Identitätsdaten. Sie werden für die Authentifizierung und die Bereitstellung von Autorisierungsinformationen für Google APIs verwendet.

Wenn Sie Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC) und die Cloud-Clientbibliotheken oder Google API-Clientbibliotheken verwenden, müssen Sie keine Zugriffstoken verwalten. Die Bibliotheken rufen automatisch die Anmeldedaten ab, tauschen sie gegen ein Zugriffstoken aus und aktualisieren das Zugriffstoken nach Bedarf.

Inhalt des Zugriffstokens

Zugriffstokens sind undurchsichtige Tokens, d. h. sie haben ein proprietäres Format. Anwendungen können sie nicht prüfen.

Lebensdauer des Zugriffstokens

Standardmäßig sind Zugriffstokens 1 Stunde (3.600 Sekunden) lang gültig. Wenn das Zugriffstoken abgelaufen ist, muss Ihr Tokenverwaltungscode ein neues abrufen.

Wenn Sie ein Zugriffstoken mit einer längeren oder kürzeren Lebensdauer benötigen, können Sie die Methode serviceAccounts.generateAccessToken verwenden, um es zu erstellen. Bei dieser Methode können Sie die Lebensdauer des Tokens selbst auswählen, bei einer maximalen Lebensdauer von 12 Stunden.

Wenn Sie die Tokenlebensdauer über die Standardeinstellung hinaus verlängern möchten, müssen Sie eine Organisationsrichtlinie erstellen, die die Einschränkung iam.allowServiceAccountCredentialLifetimeExtension aktiviert. Weitere Informationen finden Sie unter Kurzlebiges Zugriffstoken erstellen.

ID-Tokens

ID-Tokens sind JSON-Webtokens (JWTs), die der OIDC-Spezifikation (OpenID Connect) entsprechen. Sie bestehen aus einer Reihe von Schlüssel/Wert-Paaren, die als Anforderungen bezeichnet werden.

Im Gegensatz zu Zugriffstokens, bei denen es sich um intransparente Objekte handelt, die nicht von der Anwendung überprüft werden können, sollen ID-Tokens von der Anwendung geprüft und verwendet werden. Informationen von dem Token, z. B. wer das Token signiert hat oder für das das ID-Token ausgegeben wurde, stehen für die Anwendung zur Verfügung.

Best Practices für die Arbeit mit JWTs finden Sie unter Best Practices für JSON Web Tokens.

Inhalt des ID-Tokens

In der folgenden Tabelle werden erforderliche oder häufig verwendete Anforderungen an ID-Tokens beschrieben:

Anspruch Beschreibung
iss Der Aussteller oder Unterzeichner des Tokens. Für von Google signierte ID-Tokens ist der Wert https://accounts.google.com.
azp Optional. Wem das Token ausgestellt wurde.
aud Die Zielgruppe des Tokens. Der Wert dieser Anforderung muss mit der Anwendung oder dem Dienst übereinstimmen, der das Token zur Authentifizierung der Anfrage verwendet. Weitere Informationen finden Sie unter Anforderung von ID-Token aud.
sub Betreff: Die ID, die das Hauptkonto darstellt, das die Anfrage stellt.
iat Unixzeit, wenn das Token ausgestellt wurde.
exp Unixzeit, wenn das Token abläuft.

Je nach Aussteller und Anwendung können auch andere Anforderungen vorhanden sein.

Anforderung des ID-Tokens aud

Die Anforderung aud beschreibt den Dienstnamen, den dieses Token zum Aufrufen erstellt hat. Wenn ein Dienst ein ID-Token empfängt, muss er seine Integrität (Signatur), Gültigkeit (ist abgelaufen) und die Anforderung aud prüfen, die dem erwarteten Namen entspricht. Wenn es nicht übereinstimmt, sollte der Dienst das Token ablehnen, da es sich um eine für ein anderes System beabsichtigte Wiederholung handeln kann.

Wenn Sie ein ID-Token abrufen, verwenden Sie im Allgemeinen die von einem Dienstkonto bereitgestellten Anmeldedaten anstelle von Nutzeranmeldedaten. Dies liegt daran, dass die Anforderung aud für ID-Tokens, die mit Nutzeranmeldedaten generiert wurden, statisch an die Anwendung gebunden ist, die der Nutzer zur Authentifizierung verwendet hat. Wenn Sie ein Dienstkonto verwenden, um ein ID-Token zu erhalten, können Sie einen anderen Wert für die Anforderung aud angeben.

Lebensdauer des ID-Tokens

ID-Tokens sind bis zu 1 Stunde (3.600 Sekunden) lang gültig. Wenn ein ID-Token abläuft, müssen Sie ein neues Token erhalten.

ID-Token-Validierung

Wenn Ihre Anwendung ID-Tokens zur Authentifizierung akzeptiert, muss sie die ID-Tokens validieren.

Selbstsignierte JSON Web Tokens (JWTs)

Darüber hinaus können Sie selbstsignierte JWTs für die Authentifizierung bei einigen Google APIs verwenden, ohne ein Zugriffstoken vom Autorisierungsserver abrufen zu müssen.

Das Erstellen selbstsignierter JWTs wird empfohlen, wenn Sie Ihre eigenen Clientbibliotheken für den Zugriff auf Google APIs erstellen, aber ein erweiterter Workflow ist. Weitere Informationen zu selbst signierten JWTs finden Sie unter Selbstsignierte JSON Web Tokens erstellen. Best Practices für die Arbeit mit JWTs finden Sie unter Best Practices für JSON Web Tokens.

Aktualisierungstokens

Ihr IdP verwaltet die Lebensdauer langlebiger Tokens. Eine Ausnahme sind lokale ADC-Dateien, die Aktualisierungstokens enthalten, die von den Authentifizierungsbibliotheken verwendet werden, um Zugriffstokens für Clientbibliotheken automatisch zu aktualisieren.

Föderierte Tokens

Föderierte Tokens werden von der Workload Identity-Föderation und der Workforce Identity-Föderation aus föderierten Identitäten generiert.

Föderierte Tokens werden auf folgende Weise verwendet:

Die von der Workload Identity-Föderation und der Workforce Identity-Föderation zurückgegebenen föderierten Tokens entsprechen nicht den von der Workload Identity-Föderation für GKE zurückgegebenen Tokens. Weitere Informationen zur Authentifizierung von Google Kubernetes Engine-Anwendungen bei Google APIs finden Sie unter Anwendungen für die Verwendung der Workload Identity-Föderation für GKE konfigurieren.

Inhabertoken

Inhabertokens sind eine allgemeine Klasse von Tokens, die Zugriff auf die Partei gewähren, die das Token besitzt. Zugriffstokens, ID-Tokens und selbstsignierte JWTs sind alle Inhabertokens.

Die Verwendung von Inhabertokens für die Authentifizierung basiert auf der Sicherheit, die durch ein verschlüsseltes Protokoll wie HTTPS bereitgestellt wird. Wenn ein Inhaber-Token abgefangen wird, kann es von einem böswilligen Akteur verwendet werden, um Zugriff zu erhalten.

Nächste Schritte