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 oder Client-IDs 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.

Sie können die Informationen von einem gültigen (nicht abgelaufenen oder widerrufenen) Zugriffstoken mit dem Endpunkt tokeninfo von Google OAuth 2.0 abrufen.

Ersetzen Sie ACCESS_TOKEN durch das gültige, nicht abgelaufene Zugriffstoken.

curl "https://oauth2.googleapis.com/tokeninfo?access_token=ACCESS_TOKEN"

Dieser Befehl gibt in etwa Folgendes zurück:

{
  "azp": "32553540559.apps.googleusercontent.com",
  "aud": "32553540559.apps.googleusercontent.com",
  "sub": "111260650121245072906",
  "scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/accounts.reauth",
  "exp": "1650056632",
  "expires_in": "3488",
  "email": "user@example.com",
  "email_verified": "true"
}

In der folgenden Tabelle sind die wichtigsten Felder aufgeführt:

Feld Beschreibung
azp Die Projekt-, E-Mail- oder Dienstkonto-ID der Anwendung, die das Token angefordert hat. Dieser Wert ist nur enthalten, wenn https://www.googleapis.com/auth/userinfo.email in der Liste der Bereiche angegeben ist.
scope Die OAuth-Bereiche, die diesem Zugriffstoken hinzugefügt wurden. Für Google Cloud-Dienste empfiehlt es sich, den Bereich https://www.googleapis.com/auth/cloud-platform zu verwenden. Dieser enthält alle Google Cloud APIs zusammen mit Identitäts- und Zugriffsverwaltung (Identity and Access Management, IAM), die eine detaillierte Zugriffssteuerung bietet.
expires_in Anzahl der Sekunden bis zum Ablauf des Tokens. Weitere Informationen finden Sie unter Lebensdauer von Zugriffstoken.

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.

Weitere Informationen zur Implementierung von OIDC durch Google finden Sie unter OpenID Connect. Best Practices für die Arbeit mit JWTs finden Sie unter Best Practices für JSON Web Tokens.

Inhalt des ID-Tokens

Sie können ein gültiges (nicht abgelaufenes oder widerrufenes) ID-Token mithilfe des Endpunkts tokeninfo prüfen.

Ersetzen Sie ID_TOKEN durch das gültige, nicht abgelaufene ID-Token.

curl "https://oauth2.googleapis.com/tokeninfo?id_token=ID_TOKEN"

Dieser Befehl gibt in etwa Folgendes zurück:

{
  "iss": "https://accounts.google.com",
  "azp": "32555350559.apps.googleusercontent.com",
  "aud": "32555350559.apps.googleusercontent.com",
  "sub": "111260650121185072906",
  "hd": "google.com",
  "email": "user@example.com",
  "email_verified": "true",
  "at_hash": "_LLKKivfvfme9eoQ3WcMIg",
  "iat": "1650053185",
  "exp": "1650056785",
  "alg": "RS256",
  "kid": "f1338ca26835863f671403941738a7b49e740fc0",
  "typ": "JWT"
}

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 Ihr Dienst oder Ihre Anwendung einen Google-Dienst wie Cloud Run, Cloud Run Functions oder Identity-Aware Proxy verwendet, validiert Google ID-Tokens für Sie. In diesen Fällen müssen die ID-Tokens von Google signiert werden.

Wenn Sie ID-Tokens in Ihrer Anwendung validieren müssen, können Sie dies tun, obwohl dies ein erweiterter Workflow ist. Weitere Informationen finden Sie unter ID-Token prüfen.

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.

Wenn Inhabertokens für Ihren Anwendungsfall nicht genügend Sicherheit bieten, sollten Sie eine weitere Verschlüsselungsebene hinzufügen oder eine gegenseitige Transport Layer Security-Lösung (mTLS) wie Chrome Enterprise Premium verwenden, die den Zugriff auf authentifizierte Nutzer auf einem vertrauenswürdigen Gerät beschränkt.

Nächste Schritte