Arten von Tokens

Google Cloud gibt verschiedene Arten von Tokens aus, die sich in ihrem Zweck und den Parteien unterscheiden, zwischen denen sie ausgetauscht werden.

In der folgenden Tabelle finden Sie einen Überblick über die wichtigsten Tokenkategorien, in denen sich verschiedene Tokentypen befinden.

Tokenkategorie Kommunikationspfad Zweck
Zugriffstokens Autorisierungsserver ⭢ Client ⭢ Google API Ermöglicht Clients, Google Cloud APIs aufzurufen.
Token-granting tokens Autorisierungsserver ⭤ Client Ermöglicht es Clients, neue oder andere Tokens zu erhalten, möglicherweise zu einem späteren Zeitpunkt.
Identitätstokens Autorisierungsserver ⭢ Client Ermöglicht es Clients, den Nutzer zu identifizieren, mit dem sie interagieren.

Zugriffs- und Identitätstokens sind Inhabertokens. Inhabertokens sind eine allgemeine Klasse von Tokens, die Zugriff auf die Partei gewähren, die das Token besitzt.

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, können Sie das Risiko eines Tokendiebstahls verringern, indem Sie kontextbezogenen Zugriff verwenden, die Lebensdauer von Zugriffstokens begrenzen oder eine gegenseitige Transport Layer Security-Lösung (mTLS) wie Chrome Enterprise Premium verwenden.

Zugriffstokens

Mit Zugriffstokens können Clients authentifizierte Aufrufe an Google Cloud APIs senden. Google Cloud unterstützt verschiedene Arten von Zugriffstokens, die folgende Eigenschaften gemeinsam haben:

  • Sie authentifizieren ein Hauptkonto, das ein Nutzer oder eine Arbeitslast sein kann.

  • Sie werden für einen bestimmten Client ausgestellt.

  • Sie sind nur kurz gültig und laufen nach höchstens einigen Stunden ab.

  • Sie sind auf bestimmte OAuth-Bereiche, Endpunkte oder Ressourcen beschränkt. Das bedeutet, dass ein Zugriffstoken in der Regel nicht den Zugriff auf alle Ressourcen eines Nutzers gewährt, sondern nur auf eine bestimmte Teilmenge.

Zugriffstokens können sich in folgenden Punkten unterscheiden:

  • Aussteller: Die Partei, die das Token ausstellt.

  • Principal: Der Typ des Hauptkontos, das mit dem Token authentifiziert werden kann.

  • Einschränkungen: Die Einschränkungen, die für das Token gelten können.

In der folgenden Tabelle sind die verschiedenen Arten von Zugriffstokens aufgeführt:

Tokentyp Aussteller Hauptkonten Beschränkungen
Nutzerzugriffstoken Google-Autorisierungsserver
  • Nutzer (verwalteter Nutzer)
  • Nutzer (Privatnutzerkonto)
 OAuth-Bereich
Dienstkonto-Zugriffstoken
  • Google-Autorisierungsserver
  • Google Cloud IAM-Autorisierungsserver
 Dienstkonto OAuth-Bereich
Token für die domainweite Delegierung Google-Autorisierungsserver Nutzer (verwalteter Nutzer) OAuth-Bereich
JSON-Webtoken (JWT) für Dienstkonto Kunde Dienstkonto OAuth-Bereich oder API
Föderiertes Zugriffstoken Google Cloud IAM-Autorisierungsserver
  • Hauptkonto des Mitarbeiteridentitätspools
  • Hauptkonto des Workload Identity-Pools
 OAuth-Bereich
Token für die Zugriffsgrenze für Anmeldedaten Google Cloud IAM-Autorisierungsserver
  • Nutzer (verwalteter Nutzer)
  • Nutzer (Privatnutzerkonto)
  • Dienstkonto
 Bestimmte Cloud Storage-Objekte
Vom Client ausgegebenes Zugriffsgrenztoken für Anmeldedaten Kunde Dienstkonto Bestimmte Cloud Storage-Objekte

Die verschiedenen Arten von Zugriffstokens weisen auch unterschiedliche Sicherheitseigenschaften auf:

  • Format: Einige Zugriffstokens sind undurchsichtig, d. h. sie haben ein proprietäres Format und können nicht geprüft werden. Andere Tokens sind als JSON Web Token codiert, das vom Client decodiert werden kann.

  • Introspectability: Einige undurchsichtige Tokens können mit derGoogle Cloud API introspektiert werden, andere nicht.

  • Gültigkeitsdauer: Die Gültigkeitsdauer von Tokens variiert. Außerdem kann es Einschränkungen geben, inwieweit sie geändert werden können.

  • Widerrufbarkeit: Einige Tokens können widerrufen werden. Andere Tokens bleiben bis zum Ablaufdatum gültig.

In der folgenden Tabelle werden die Unterschiede zwischen den Zugriffstoken-Typen zusammengefasst.

Tokentyp Format Introspektierbar Lebensdauer Widerrufbar
Nutzerzugriffstoken Undurchsichtig Ja 1 Stunde Ja
Dienstkonto-Zugriffstoken Undurchsichtig Ja 5 Minuten bis 12 Stunden Nein
Token für die domainweite Delegierung Undurchsichtig Ja 1 Stunde Nein
JSON-Webtoken (JWT) für Dienstkonto JWT – 5 Minuten bis 1 Stunde Nein
Föderiertes Zugriffstoken Undurchsichtig Nein Weitere Informationen finden Sie unter Föderierte Zugriffstokens. Nein
Token für Zugriffsgrenzen für Anmeldedaten Undurchsichtig Nein Weitere Informationen finden Sie unter Zugriffsbeschränkungstokens für Anmeldedaten. Nein
Clientseitig ausgegebenes Zugriffsgrenzen-Token für Anmeldedaten Undurchsichtig Nein – Nein

Nutzerzugriffstokens

Mit Nutzerzugriffstokens wird ein Nutzer authentifiziert und ein Client autorisiert, im Namen des Nutzers zu handeln:

Das authentifizierte Hauptkonto ist entweder ein verwaltetes Nutzerkonto oder ein privates Konto. Der Client kann eine Webanwendung oder eine native Anwendung sein.

Nutzerzugriffstokens sind nicht transparent. Zu Diagnosezwecken können Sie ein Zugriffstoken mit dem folgenden Befehl untersuchen. Ersetzen Sie dabei ACCESS_TOKEN durch ein gültiges Zugriffstoken:

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

Die Ausgabe dieses Befehls sieht in etwa so aus:

{
  "azp": "0000000000.apps.googleusercontent.com",
  "aud": "0000000000.apps.googleusercontent.com",
  "sub": "00000000000000000000",
  "scope": "openid https://www.googleapis.com/auth/userinfo.email",
  "exp": "1744687132",
  "expires_in": "3568",
  "email": "user@example.com",
  "email_verified": "true"
}

Die Ausgabe enthält die folgenden Felder:

Feld Name Beschreibung
aud Zielgruppe

Der OAuth-Client, für den dieses Token bestimmt ist, identifiziert durch seine OAuth-Client-ID.

OAuth-Clients können Zugriffstokens für andere OAuth-Clients abrufen, die zum selben Projekt gehören. Die Zielgruppe kann sich von der autorisierten Partei unterscheiden.

azp Bevollmächtigter Der OAuth-Client, der das Token angefordert hat, identifiziert durch seine OAuth-Client-ID.
email Primäre E-Mail-Adresse

Die primäre E-Mail-Adresse des Nutzers.

Dieses Feld ist nur vorhanden, wenn das Token den Bereich https://www.googleapis.com/auth/userinfo.email enthält.

exp Ablaufdatum Die Ablaufzeit des Tokens im Unix-Epochenzeitformat.
scope OAuth-Bereiche Die Gruppe von APIs, auf die der Client im Namen des Nutzers zugreifen darf, identifiziert durch den OAuth-Bereich.
sub Betreff

Das authentifizierte Hauptkonto, das durch seine eindeutige ID identifiziert wird.

Diese ID entspricht der ID, die in der Directory API verfügbar ist.

Nutzer-Zugriffstokens laufen nach einer Stunde automatisch ab, können aber bei Bedarf auch früher widerrufen werden.

Standardmäßig sind Nutzerzugriffstokens Inhabertokens, d. h., sie sind nicht an einen bestimmten Kommunikationskanal, ein bestimmtes Netzwerk oder zusätzliche Anmeldedaten gebunden. Optional können Sie die Tokenbindung implementieren, indem Sie zertifikatbasierten Zugriff bereitstellen, sodass Nutzerzugriffstokens nur in Verbindung mit einem gültigen mTLS-Clientzertifikat verwendet werden können.

Dienstkonto-Zugriffstokens

Mit Dienstkonto-Zugriffstokens wird ein Dienstkonto authentifiziert. Die Tokens sind undurchsichtig und können mit der https://oauth2.googleapis.com/tokeninfo-API geprüft werden.

Für ein Dienstkonto-Zugriffstoken gibt die API eine Ausgabe zurück, die dem folgenden Beispiel ähnelt:

{
  "azp": "000000000000000000000",
  "aud": "000000000000000000000",
  "scope": "https://www.googleapis.com/auth/userinfo.email",
  "exp": "1744687132",
  "expires_in": "3568",
  "email": "service-account@example.iam.gserviceaccount.com",
  "email_verified": "true",
  "access_type": "online"
}

Ein Dienstkonto-Token enthält die folgenden Felder:

Feld Name Beschreibung
aud Zielgruppe Das Dienstkonto, für das das Token bestimmt ist, entspricht der autorisierten Partei.
azp Bevollmächtigter Das Dienstkonto, das das Token angefordert hat, identifiziert durch seine eindeutige ID.
email Primäre E-Mail-Adresse

Die E-Mail-Adresse des Dienstkontos.

Dieses Feld ist nur vorhanden, wenn das Token den Bereich https://www.googleapis.com/auth/userinfo.email enthält.

exp Ablaufdatum Die Ablaufzeit des Tokens im Unix-Epochenzeitformat.

Dienstkonto-Zugriffstokens können nicht widerrufen werden und bleiben bis zum Ablauf gültig.

Standardmäßig laufen Dienstkonto-Zugriffstokens nach einer Stunde ab. Mit der Methode serviceAccounts.generateAccessToken können Sie Tokens mit unterschiedlichen Gültigkeitsdauern anfordern. Da längere Token-Lebensdauern das Risiko erhöhen können, müssen Sie die Einschränkung iam.allowServiceAccountCredentialLifetimeExtension konfigurieren, damit Clients Dienstkonto-Zugriffstokens mit einer Lebensdauer von mehr als einer Stunde anfordern können.

Tokens für die domainweite Delegierung

Mit domainweiten Delegierungstokens wird ein Nutzer authentifiziert und ein Dienstkonto autorisiert, im Namen des Nutzers zu handeln. Die Tokens sind nicht transparent und können mit der https://oauth2.googleapis.com/tokeninfo-API geprüft werden.

Für ein Token für die domainweite Delegierung gibt die API eine Ausgabe zurück, die dem folgenden Beispiel ähnelt:

{
  "azp": "000000000000000000000",
  "aud": "000000000000000000000",
  "scope": "https://www.googleapis.com/auth/admin.directory.user.readonly https://www.googleapis.com/auth/userinfo.email",
  "exp": "1744688957",
  "expires_in": "3540",
  "email": "user@example.com",
  "email_verified": "true",
  "access_type": "offline"
}

Ein Token für die domainweite Delegierung enthält die folgenden Felder:

Feld Name Beschreibung
aud Zielgruppe Das Dienstkonto, für das das Token bestimmt ist, entspricht der autorisierten Partei.
azp Bevollmächtigter Das Dienstkonto, das das Token angefordert hat, identifiziert durch seine eindeutige ID.
email Primäre E-Mail-Adresse

Die primäre E-Mail-Adresse des imitierten Nutzers.

Dieses Feld ist nur vorhanden, wenn das Token den Bereich https://www.googleapis.com/auth/userinfo.email enthält.

exp Ablaufdatum Die Ablaufzeit des Tokens im Unix-Epochenzeitformat.
scope OAuth-Bereiche Die Gruppe von APIs, auf die der Client im Namen des imitierten Nutzers zugreifen darf, identifiziert durch den OAuth-Bereich.

Tokens für die domainweite Delegation laufen nach einer Stunde automatisch ab und können nicht widerrufen werden.

JSON-Webtokens für Dienstkonten

Mit JSON Web Tokens (JWTs) für Dienstkonten wird ein Dienstkonto authentifiziert. Dienstkonto-Zugriffstokens werden von einem Autorisierungsserver ausgestellt, Dienstkonto-JWTs können jedoch vom Client selbst ausgestellt werden.

Manchmal werden diese auch als „selbst signierte“ JWTs bezeichnet. Sie können nützlich sein, wenn Sie sich bei einigen Google APIs authentifizieren müssen, ohne ein Zugriffstoken vom Autorisierungsserver abzurufen, z. B. wenn Sie eigene Clientbibliotheken erstellen.

Um ein Dienstkonto-JWT auszustellen, müssen Clients die folgenden Schritte ausführen:

  1. Bereiten Sie eine JSON-Websignatur-Nutzlast vor, die die E-Mail-Adresse des Dienstkontos, einen OAuth-Bereich oder API-Endpunkt und eine Ablaufzeit enthält.

  2. Signieren Sie die Nutzlast mit einem Dienstkontoschlüssel des entsprechenden Dienstkontos. Clients können die Nutzlast offline mit einem von Nutzern verwalteten Dienstkontoschlüssel oder online mit der Methode signJwt und einem von Google verwalteten Dienstkontoschlüssel signieren. Weitere Informationen finden Sie unter Selbstsigniertes JSON Web Token erstellen.

Ein decodiertes Dienstkonto-JWT sieht in etwa so aus. Dabei wird SIGNATURE durch die Signatur des Tokens ersetzt:

{
  "alg": "RS256",
  "kid": "290b7bf588eee0c35d02bf1164f4336229373300",
  "typ": "JWT"
}.{
  "iss": "service-account@example.iam.gserviceaccount.com",
  "sub": "service-account@example.iam.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/cloud-platform",
  "exp": 1744851267,
  "iat": 1744850967
}.SIGNATURE

Anstatt einen OAuth-Bereich im Schlüssel scope anzugeben, kann in einem Dienstkonto-JWT ein API-Endpunkt im Schlüssel aud angegeben werden:

{
  "alg": "RS256",
  "kid": "290b7bf588eee0c35d02bf1164f4336229373300",
  "typ": "JWT"
}.{
  "iss": "service-account@example.iam.gserviceaccount.com",
  "sub": "service-account@example.iam.gserviceaccount.com",
  "aud": "https://cloudresourcemanager.googleapis.com/",
  "exp": 1744854799,
  "iat": 1744851199
}.SIGNATURE

Ein Dienstkonto-JWT enthält die folgenden Felder:

Feld Name Beschreibung
aud Zielgruppe API-Endpunkte, auf die der Client zugreifen darf. Nur gültig, wenn scope nicht angegeben ist.
exp Ablaufdatum Die Ablaufzeit des Tokens im Unix-Epochenzeitformat.
iat Zeitpunkt des Problems Die Zeit, zu der das Token ausgestellt wurde, im Unix-Epochenzeitformat.
iss Aussteller Der Aussteller des Tokens, also das Dienstkonto selbst.
scope OAuth-Bereiche Die Gruppe von APIs, auf die der Client zugreifen darf, identifiziert durch den OAuth-Bereich. Nur gültig, wenn aud nicht angegeben ist.
sub Betreff Authentifiziertes Hauptkonto, das das Dienstkonto selbst ist.

JWTs für Dienstkonten können bis zu einer Stunde gültig sein und können nicht widerrufen werden.

Föderierte Zugriffstokens

Mit föderierten Zugriffstokens wird ein Principal eines Workforce Identity-Pools oder eines Workload Identity-Pools authentifiziert.

Mit der Mitarbeiteridentitätsföderation können Clients ein externes Token gegen ein föderiertes Zugriffstoken eintauschen, mit dem ein Mitarbeiterpool-Principal authentifiziert wird. Das Hauptkonto des Workforce Identity-Pools wird durch eine Hauptkonto-ID identifiziert, die in etwa so aussieht:

principal://iam.googleapis.com/locations/global/workforcePools/POOL/subject/raha@altostrat.com.

Mit der Identitätsföderation von Arbeitslasten können Clients ein externes Token gegen ein föderiertes Zugriffstoken eintauschen, mit dem ein Arbeitslastpool-Principal authentifiziert wird. Das Hauptkonto des Workload Identity-Pools wird durch eine Hauptkonto-ID identifiziert, die der folgenden ähnelt:

principal://iam.googleapis.com/projects/PROJECT/locations/global/workloadIdentityPools/POOL/subject/SUBJECT_ATTRIBUTE_VALUE

Föderierte Zugriffstokens sind undurchsichtig und können nicht geprüft werden. Die Tokens können nicht widerrufen werden und bleiben bis zum Ablauf gültig. Die Ablaufzeiten für die einzelnen Tokentypen sind so festgelegt:

  • Bei der Workforce Identity-Föderation wird das Ablaufdatum des Tokens auf den kleineren der beiden folgenden Werte festgelegt:

    • Verbleibende Zeit bis zum Ablauf der Workforce Identity-Föderationssitzung

    • 1 Stunde

    Das Ablaufdatum der Workforce Identity-Föderationssitzung wird anhand der Anmeldezeit und der für den Workforce Identity-Föderationspool konfigurierten Sitzungsdauer bestimmt.

  • Bei der Identitätsföderation von Arbeitslasten wird das Ablaufdatum des Tokens so festgelegt, dass es mit dem Ablaufdatum des externen Tokens übereinstimmt.

Tokens für Zugriffsgrenzen für Anmeldedaten

Mit Zugriffsgrenzen-Tokens für Anmeldedaten werden Nutzer oder Dienstkonten authentifiziert und eine Zugriffsgrenze eingeschlossen. Die Zugriffsgrenze schränkt das Token so ein, dass es nur für den Zugriff auf eine definierte Teilmenge von Cloud Storage-Ressourcen verwendet werden kann.

Tokens für die Zugriffsgrenze für Anmeldedaten werden manchmal als herabgestuft bezeichnet, da sie von einem Eingabetoken abgeleitet werden, aber hinsichtlich der Ressourcen, auf die sie Zugriff gewähren, eingeschränkter sind.

Das Ablaufdatum von Zugriffsgrenzen-Tokens für Anmeldedaten wird vom Ablaufdatum des Eingabetokens abgeleitet. Dabei kann es sich um ein Nutzerzugriffstoken oder ein Dienstkonto-Zugriffstoken handeln. Tokens für Zugriffsbeschränkungen für Anmeldedaten sind undurchsichtig und können nicht geprüft oder widerrufen werden.

Von Clients ausgegebene Zugriffstokens für Anmeldedaten

Von Clients ausgegebene Zugriffstokens für Zugriffsgrenzen für Anmeldedaten ähneln Zugriffstokens für Zugriffsgrenzen für Anmeldedaten, sind aber für Szenarien optimiert, in denen Clients häufig Zugriffstokens für Zugriffsgrenzen für Anmeldedaten mit unterschiedlichen Zugriffsgrenzen abrufen müssen.

Clients können lokal Zugriffsgrenzentokens für vom Client ausgestellte Anmeldedaten erstellen. Dazu verwenden sie die Cloud-Clientbibliotheken und ein Vermittlertoken für die Zugriffsgrenze, das sie regelmäßig aktualisieren müssen.

Von Clients ausgegebene Zugriffsbeschränkungstokens für Anmeldedaten sind undurchsichtig und können nicht geprüft oder widerrufen werden.

Tokens zur Tokenerteilung

Mit Token-Gewährungstokens können Clients neue oder andere Tokens abrufen, möglicherweise zu einem späteren Zeitpunkt. Google Cloud unterstützt verschiedene Arten von Token-Gewährungstokens, die alle Folgendes gemeinsam haben:

  • Sie stehen für eine vorherige Authentifizierung.

  • Sie authentifizieren ein Hauptkonto, das eine Google-Identität (ein Nutzer oder eine Arbeitslast) oder eine externe Identität sein kann.

  • Sie können gegen ein Zugriffstoken eingelöst werden.

  • Sie können nicht für Google API-Aufrufe verwendet werden, was sie von Zugriffstokens unterscheidet.

Token-Granting-Tokens können sich in folgenden Punkten unterscheiden:

  • Aussteller: Die Partei, die das Token ausstellt.

  • Hauptkonto: Der Typ der Hauptkonto-Identität, die mit dem Token authentifiziert werden kann.

  • Einschränkungen: Die Einschränkungen, die für das Token gelten können.

In der folgenden Tabelle sind die verschiedenen Arten von Token-Gewährungstokens aufgeführt.

Tokentyp Aussteller Eingelöster Zugriffstokentyp Hauptkonten Beschränkungen
Aktualisierungstoken Google-Autorisierungsserver Nutzerzugriffstoken
  • Nutzer (verwalteter Nutzer)
  • Nutzer (Privatnutzerkonto)
 OAuth-Bereich
Autorisierungscode Google-Autorisierungsserver Nutzerzugriffstoken
  • Nutzer (verwalteter Nutzer)
  • Nutzer (Privatnutzerkonto)
 OAuth-Bereich
Föderiertes Aktualisierungstoken Google Cloud IAM-Autorisierungsserver Föderiertes Zugriffstoken Hauptkonto des Mitarbeiteridentitätspools OAuth-Bereich
Föderierter Autorisierungscode Google Cloud IAM-Autorisierungsserver Föderiertes Zugriffstoken Hauptkonto des Mitarbeiteridentitätspools OAuth-Bereich
JSON-Webtoken-Assertion für Dienstkonto Kunde
  • Token für die domainweite Delegierung
  • Dienstkonto-Zugriffstoken
  • Nutzer (verwalteter Nutzer)
  • Dienstkonto
 OAuth-Bereich
Externes JSON-Webtoken Externer Identitätsanbieter Föderiertes Zugriffstoken Externes Hauptkonto Keine
Externe SAML-Assertion oder ‑Antwort Externer Identitätsanbieter Föderiertes Zugriffstoken Externes Hauptkonto Keine
Amazon Web Services (AWS) GetCallerIdentity-Token Externer Identitätsanbieter Föderiertes Zugriffstoken Externes Hauptkonto Keine

Die verschiedenen Arten von Token-Gewährungstokens haben auch unterschiedliche Sicherheitseigenschaften:

  • Format: Einige Tokens sind undurchsichtig. Andere Tokens können vom Client decodiert werden.

  • Gültigkeitsdauer: Tokens unterscheiden sich in ihrer Gültigkeitsdauer und darin, inwieweit sie geändert werden können.

  • Mehrfach verwendbar: Einige Token-Gewährungstokens können nur einmal verwendet werden. Andere Tokens können mehrmals verwendet werden.

  • Widerrufbarkeit: Einige Tokens können widerrufen werden. Andere Tokens bleiben bis zum Ablaufdatum gültig.

In der folgenden Tabelle werden die Unterschiede zwischen diesen Attributen für Token-Gewährungstokens zusammengefasst:

Tokentyp Format Lebensdauer Widerrufbar Mehrfachnutzung
Aktualisierungstoken Undurchsichtig Variiert, siehe Aktualisierungstokens Ja Ja
Autorisierungscode Undurchsichtig 10 Minuten Nein Nein
Föderiertes Aktualisierungstoken Undurchsichtig Variiert, siehe Föderierte Aktualisierungstokens Nein Ja
Föderierter Autorisierungscode Undurchsichtig 10 Minuten Nein Nein
JSON Web Token-Assertion für Dienstkonto JWT 5 Minuten bis 1 Stunde Nein Ja
Externes Token oder externes JSON-Webtoken JWT Abhängig vom Identitätsanbieter Abhängig vom Identitätsanbieter Ja
Externe SAML-Assertion oder ‑Antwort SAML Abhängig vom Identitätsanbieter Abhängig vom Identitätsanbieter Ja
Amazon Web Services (AWS) GetCallerIdentity-Token Text-Blob Abhängig vom Identitätsanbieter Abhängig vom Identitätsanbieter Ja

Aktualisierungstokens

Aktualisierungstokens sind undurchsichtige Tokens, mit denen Clients ID-Tokens und Zugriffstokens für einen Nutzer abrufen können, wenn der Nutzer einen Client zuvor autorisiert hat, in seinem Namen zu handeln.

Aktualisierungstokens sind an einen bestimmten Client gebunden und können nur in Kombination mit gültigen Clientanmeldedaten verwendet werden, z. B. einer Client-ID und einem Clientschlüssel.

Wenn die Autorisierung des Clients einen oder mehrere Google Cloud OAuth-Bereiche umfasst, unterliegt die Lebensdauer des Aktualisierungstokens der Steuerung der Google Cloud Sitzungslänge. Andernfalls bleiben Aktualisierungstokens gültig, bis der Nutzer seine Autorisierung widerruft oder andere Ereignisse zum Widerrufen von Tokens eintreten.

Autorisierungscodes

Autorisierungscodes sind undurchsichtige, kurzlebige Tokens. Die Codes sind nur für die Nutzerauthentifizierung als Vermittler zwischen dem Client und dem Google-Autorisierungsserver vorgesehen.

Wie Aktualisierungstokens sind Autorisierungscodes an einen Client gebunden und können nur in Kombination mit gültigen Clientanmeldedaten verwendet werden. Im Gegensatz zu Aktualisierungstokens können Autorisierungscodes nur einmal verwendet werden.

Föderierte Aktualisierungstokens

Föderierte Aktualisierungstokens sind undurchsichtige Tokens, mit denen Clients Zugriffstokens für ein Hauptkonto des Mitarbeiteridentitätspools abrufen können, wenn der Nutzer zuvor einen Client autorisiert hat, in seinem Namen zu handeln.

Wie Aktualisierungstokens sind auch föderierte Aktualisierungstokens an einen bestimmten Client gebunden und können nur in Kombination mit gültigen Clientanmeldedaten verwendet werden, z. B. einer Client-ID und einem Clientgeheimnis.

Im Gegensatz zu Aktualisierungstokens können föderierte Aktualisierungstokens nicht widerrufen werden. Die Lebensdauer eines föderierten Aktualisierungstokens ist mit der Workforce Identity-Sitzung verknüpft, die zum Abrufen des Tokens verwendet wurde. Das Token bleibt gültig, bis die Sitzung abläuft.

Föderierte Autorisierungscodes

Wie Autorisierungscodes sind auch föderierte Autorisierungscodes undurchsichtige, kurzlebige Tokens. Die Codes sind nur für die Verwendung während der Nutzerauthentifizierung als Vermittler zwischen dem Client und dem Google Cloud IAM-Autorisierungsserver vorgesehen.

Autorisierungscodes sind an einen Client gebunden, können nur in Kombination mit gültigen Clientanmeldedaten verwendet werden und sind nur einmal nutzbar.

JSON Web Token-Assertions für Dienstkonten

Mit Dienstkonto-JSON Web Tokens (JWTs) wird die Identität eines Dienstkontos bestätigt. Arbeitslasten können JWT-Assertions für Dienstkonten verwenden, um Zugriffstokens für Dienstkonten oder Tokens für die domainweite Delegierung abzurufen. Die JWT-Assertion des Dienstkontos wird mit einem Dienstkontoschlüssel signiert.

Eine decodierte JWT-Assertion für ein Dienstkonto sieht in etwa so aus. Dabei wird SIGNATURE durch die Signatur des Tokens ersetzt:

{
  "alg": "RS256",
  "kid": "290b7bf588eee0c35d02bf1164f4336229373300",
  "typ": "JWT"
}.{
  "iss": "service-account@example.iam.gserviceaccount.com",
  "scope": "https://www.googleapis.com/auth/devstorage.read_only",
  "aud": "https://oauth2.googleapis.com/token",
  "exp": 1744851267,
  "iat": 1744850967
}.SIGNATURE

JWT-Assertions für Dienstkonten sind strukturell ähnlich wie JWTs für Dienstkonten: Beide Arten von Tokens können vom Client selbst ausgestellt und mit einem Dienstkontoschlüssel signiert werden. Die beiden Arten von Tokens verwenden jedoch unterschiedliche Nutzlasten, wie in der folgenden Tabelle beschrieben.

Feld Dienstkonto-JWT JWT-Assertion für Dienstkonto
aud Google Cloud API, wird ausgelassen, wenn scope angegeben ist Muss https://oauth2.googleapis.com/token lauten.
exp Ablaufdatum Ablaufdatum
iat Zeitpunkt des Problems Zeitpunkt des Problems
iss E-Mail-Adresse des Dienstkontos E-Mail-Adresse des Dienstkontos
scope OAuth-Bereiche, die weggelassen werden, wenn aud angegeben ist OAuth-Bereiche
sub E-Mail-Adresse des Dienstkontos E-Mail-Adresse eines Nutzerkontos für die domainweite Delegation. Andernfalls wird sie ausgelassen.

JWT-Assertions für Dienstkonten können bis zu einer Stunde gültig sein und können nicht widerrufen werden.

Externe JSON-Webtokens

Externe JSON-Webtokens (JWTs) werden von einem externen Identitätsanbieter wie Microsoft Entra ID, Okta, Kubernetes oder GitHub ausgestellt. Sie können sich in Struktur und Inhalt unterscheiden.

Wenn Sie die Workforce Identity-Föderation oder die Workload Identity-Föderation konfigurieren, können Sie eine Vertrauensstellung zwischen Google Cloud und einem externen Identitätsanbieter einrichten. Arbeitslasten können dann externe JWTs als Token-Gewährungstokens verwenden, um Tokens für den föderierten Zugriff abzurufen.

Wenn Sie die Mitarbeiteridentitätsföderation verwenden, wird mit dem resultierenden föderierten Zugriffstoken ein Mitarbeiter-Principal authentifiziert.

Wenn Sie die Workload Identity-Föderation verwenden, wird mit dem resultierenden föderierten Zugriffstoken ein Arbeitslast-Identitätspool-Principal authentifiziert.

In beiden Fällen wird die Prinzipal-ID aus einer oder mehreren Anforderungen des externen JWT abgeleitet.

Damit externe JWTs mit Workforce Identity-Föderation oder Workload Identity-Föderation kompatibel sind, müssen sie bestimmte Anforderungen erfüllen.

Externe SAML-Assertions oder -Antworten

Externe Security Assertion Markup Language-Assertions (SAML) sind SAML 2.0-Assertions, die von einem externen Identitätsanbieter wie Microsoft Entra ID, Okta oder Active Directory Federation Services ausgestellt werden. Diese externen SAML-Assertions können optional in einer SAML 2.0-Antwort enthalten oder verschlüsselt sein.

Wie bei externen JSON Web Tokens können Sie die Workforce Identity-Föderation oder die Workload Identity-Föderation so konfigurieren, dass Arbeitslasten externe SAML-Assertions oder -Antworten als Token-Gewährungstokens verwenden können, um föderierte Zugriffstokens abzurufen.

Damit externe SAML-Assertions mit Workforce Identity Federation oder Workload Identity-Föderation kompatibel sind, müssen sie bestimmte Anforderungen erfüllen.

Amazon Web Services (AWS) GetCallerIdentity-Token

Externe AWS-GetCallerIdentity-Tokens sind Text-Blobs, die eine signierte Anfrage an die AWS-GetCallerIdentity-API enthalten. Ähnlich wie bei externen JSON Web Tokens und SAML-Assertions können Sie die Workforce Identity-Föderation oder die Workload Identity-Föderation so konfigurieren, dass Arbeitslasten diese Text-Blobs als Token-Gewährungstoken verwenden können, um föderierte Zugriffstokens abzurufen.

Identitätstokens

Mit ID-Tokens können Clients den Nutzer identifizieren, mit dem sie interagieren. Google Cloud unterstützt verschiedene Arten von ID-Tokens, die alle Folgendes gemeinsam haben:

  • Sie sind als JSON Web Tokens (JWTs) formatiert, damit sie vom Client decodiert, überprüft und interpretiert werden können.

  • Sie authentifizieren ein Hauptkonto, das ein Nutzer oder eine Arbeitslast sein kann.

  • Sie werden für einen bestimmten Client ausgestellt.

  • Sie sind nur kurz gültig und laufen nach maximal einer Stunde ab.

  • Sie sind nicht widerrufbar.

  • Sie können nicht für Google API-Aufrufe verwendet werden, was sie von Zugriffstokens unterscheidet.

  • Sie können nicht verwendet werden, um Zugriffstokens zu erhalten. Das unterscheidet sie von Token-Granting-Tokens.

  • Sie können zur Authentifizierung von Aufrufen zwischen Mikrodiensten oder zur programmatischen Authentifizierung bei Identity-Aware Proxy (IAP) verwendet werden.

Identitätstokens können sich in folgenden Punkten unterscheiden:

  • Zielgruppe: Die Partei, die das Token decodieren und verwenden soll.

  • Aussteller: Die Partei, die das Token ausstellt.

  • Gültigkeitsdauer: Die Tokens unterscheiden sich in der Gültigkeitsdauer und darin, inwieweit sie geändert werden können.

  • Hauptkonto: Der Typ der Hauptkonto-Identität, die mit dem Token authentifiziert werden kann.

In der folgenden Tabelle sind die verschiedenen Arten von Identitätstokens aufgeführt.

Tokentyp Aussteller Zielgruppe Hauptkonto Lebensdauer
Nutzer-ID-Token Google-Autorisierungsserver OAuth-/OIDC-Client
  • Nutzer (verwalteter Nutzer)
  • Nutzer (Privatnutzerkonto)
 1 Stunde
ID-Token für Dienstkonto Google Cloud IAM-Autorisierungsserver Beliebige Zielgruppe auswählen Dienstkonto 1 Stunde
IAP-Assertion (Identity-Aware Proxy) IAP
  • Backend
  • App Engine-App
  • Nutzer (verwalteter Nutzer)
  • Nutzer (Privatnutzerkonto)
  • Hauptkonto des Mitarbeiteridentitätspools
 10 Minuten
SAML-Assertion Google-Autorisierungsserver SAML-App Nutzer (verwalteter Nutzer) 10 Minuten

Nutzer-ID-Tokens

Nutzer-ID-Tokens sind JSON-Web-Tokens (JWTs), mit denen ein Nutzer authentifiziert wird. Clients können ein Nutzer-ID-Token abrufen, indem sie einen OIDC-Authentifizierungsablauf initiieren.

Nutzer-ID-Tokens werden mit dem Google JSON Web Key Set (JWKS) signiert. Das Google-JWKS ist eine globale Ressource und dieselben Signaturschlüssel werden für verschiedene Nutzertypen verwendet, darunter:

  • Verwaltete Nutzerkonten

  • Privatnutzerkonten

  • Dienstkonten

Ein decodiertes Nutzer-ID-Token sieht in etwa so aus, wobei SIGNATURE durch die Signatur des Tokens ersetzt wird:

{
  "alg": "RS256",
  "kid": "c37da75c9fbe18c2ce9125b9aa1f300dcb31e8d9",
  "typ": "JWT"
}.{
  "iss": "https://accounts.google.com",
  "azp": "1234567890-123456789abcdef.apps.googleusercontent.com",
  "aud": "1234567890-123456789abcdef.apps.googleusercontent.com",
  "sub": "12345678901234567890",
  "at_hash": "y0LZEe-ervzRNSxn4R-t9w",
  "name": "Example user",
  "picture": "https://lh3.googleusercontent.com/a/...",
  "given_name": "Example",
  "family_name": "User",
  "hd": "example.com",
  "iat": 1745361695,
  "exp": 1745365295
}.SIGNATURE

Ein ID-Token enthält die folgenden Felder:

Feld Name Beschreibung
aud Zielgruppe

Der OAuth-Client, für den dieses Token bestimmt ist, identifiziert durch seine OAuth-Client-ID.

OAuth-Clients können Zugriffstokens für andere OAuth-Clients abrufen, die zum selben Projekt gehören. In diesem Fall kann sich die Zielgruppe von der autorisierten Partei unterscheiden.

azp Bevollmächtigter Der OAuth-Client, der den OIDC-Authentifizierungsablauf durchgeführt hat, identifiziert durch seine OAuth-Client-ID.
exp Ablaufdatum Die Ablaufzeit des Tokens im Unix-Epochenzeitformat.
hd Gehostete Domain

Die primäre Domain des Cloud Identity- oder Google Workspace-Kontos des Nutzers.

Dieser Anspruch ist nur vorhanden, wenn der Nutzer ein verwaltetes Nutzerkonto ist und der Client den Parameter hd in der Authentifizierungsanfrage angegeben hat.

iss Aussteller Der Aussteller des Tokens. Immer auf https://accounts.google.com gesetzt.
sub Betreff

Das authentifizierte Hauptkonto, das durch seine eindeutige ID identifiziert wird.

Diese ID entspricht der ID, die in der Directory API verfügbar ist.

Welche Ansprüche in einem ID-Token enthalten sind, hängt vom Parameter scope in der Authentifizierungsanfrage ab.

Um festzustellen, ob ein Nutzer ein verwaltetes Nutzerkonto ist oder zu welchem Cloud Identity- oder Google Workspace-Konto ein Nutzer gehört, müssen Clients den Anspruch hd prüfen.

Nutzer-ID-Tokens sind eine Stunde lang gültig und können nicht widerrufen werden.

Dienstkonto-ID-Tokens

Dienstkonto-ID-Tokens sind JSON Web Tokens (JWTs), mit denen ein Dienstkonto authentifiziert wird.

Im Gegensatz zu Dienstkonto-JWTs und Dienstkonto-JWT-Assertions werden Dienstkonto-ID-Tokens nicht mit einem Dienstkontoschlüssel signiert. Stattdessen werden Dienstkonto-ID-Tokens vom Google JSON Web Key Set (JWKS) signiert.

Ein decodiertes Dienstkonto-ID-Token sieht in etwa so aus, wobei SIGNATURE durch die Signatur des Tokens ersetzt wird:

{
  "alg": "RS256",
  "kid": "c37da75c9fbe18c2ce9125b9aa1f300dcb31e8d9",
  "typ": "JWT"
}.{
  "aud": "example-audience",
  "azp": "112010400000000710080",
  "email": "service-account@example.iam.gserviceaccount.com",
  "email_verified": true,
  "exp": 1745365618,
  "iat": 1745362018,
  "iss": "https://accounts.google.com",
  "sub": "112010400000000710080"
}.SIGNATURE

Ein Dienstkonto-ID-Token enthält die folgenden Felder:

Feld Name Beschreibung
aud Zielgruppe Kennung der Partei, für die dieses Token bestimmt ist. Der Wert kann vom Tokenanforderer frei gewählt werden.
azp Bevollmächtigter Das Dienstkonto, das das Token angefordert hat, identifiziert durch seine eindeutige ID.
exp Ablaufdatum Die Ablaufzeit des Tokens im Unix-Epochenzeitformat.
iss Aussteller Der Aussteller des Tokens, immer auf https://accounts.google.com festgelegt.
sub Betreff Das Dienstkonto, das das Token angefordert hat, identifiziert durch seine eindeutige ID.

Der genaue Satz der in einem ID-Token enthaltenen Anforderungen hängt davon ab, wie das ID-Token angefordert wird. Beispiel: ID-Tokens, die vom Compute Engine-Metadatenserver angefordert werden, können optional zusätzliche Ansprüche enthalten, die die Identität der VM bestätigen. ID-Tokens, die mit der IAM Credentials API angefordert werden, können optional die Organisations-ID des Projekts des Dienstkontos enthalten.

Im Gegensatz zu Nutzer-ID-Tokens unterstützen Dienstkonto-ID-Tokens nicht den hd-Anspruch.

ID-Tokens für Dienstkonten sind eine Stunde lang gültig und können nicht widerrufen werden.

Identity-Aware Proxy-Assertions

Identity-Aware Proxy (IAP)-Assertions sind JSON-Web-Tokens (JWTs), die IAP im HTTP-Anfrageheader x-goog-iap-jwt-assertion an IAP-geschützte Webanwendungen übergibt. IAP-Assertions authentifizieren einen Nutzer und dienen auch als Nachweis dafür, dass eine Anfrage von IAP autorisiert wurde.

Im Gegensatz zu Nutzer-ID-Tokens und Dienstkonto-ID-Tokens werden IAP-Assertions nicht mit dem Google JSON Web Key Set (JWKS) signiert. Stattdessen werden IAP-Assertions mit einem separaten JWKS, dem IAP-JWKS, signiert. Dieser JWKS ist eine globale Ressource und dieselben Signaturschlüssel werden für verschiedene Nutzertypen verwendet, darunter:

  • Verwaltete Nutzerkonten

  • Privatnutzerkonten

  • Dienstkonten

  • Identitäten von Mitarbeitern in Pools

Eine decodierte IAP-Assertion sieht in etwa so aus, wobei SIGNATURE durch die Signatur des Tokens ersetzt wird:

{
  "alg": "ES256",
  "typ": "JWT",
  "kid": "4BCyVw"
}.{
  "aud": "/projects/0000000000/global/backendServices/000000000000",
  "azp": "/projects/0000000000/global/backendServices/000000000000",
  "email": "user@example.com",
  "exp": 1745362883,
  "google": {
    "access_levels": [
      "accessPolicies/0000000000/accessLevels/Australia"
    ]
  },
  "hd": "example.com",
  "iat": 1745362283,
  "identity_source": "GOOGLE",
  "iss": "https://cloud.google.com/iap",
  "sub": "accounts.google.com:112010400000000710080"
}.SIGNATURE

Wenn Sie IAP für die Verwendung der Mitarbeiteridentitätsföderation anstelle von Google-Identitäten konfigurieren, sehen IAP-Assertions etwas anders aus:

{
  "alg": "ES256",
  "typ": "JWT",
  "kid": "4BCyVw"
}.{
  "aud": "/projects/0000000000/global/backendServices/000000000000",
  "azp": "/projects/0000000000/global/backendServices/000000000000",
  "email": "user@example.com",
  "exp": 1745374290,
  "google": {
    "access_levels": [
      "accessPolicies/0000000000/accessLevels/Australia"
    ]
  },
  "iat": 1745373690,
  "identity_source": "WORKFORCE_IDENTITY",
  "iss": "https://cloud.google.com/iap",
  "sub": "sts.google.com:AAFTZ...Q",
  "workforce_identity": {
    "iam_principal": "principal://iam.googleapis.com/locations/global/workforcePools/example/subject/user-0000000000",
    "workforce_pool_name": "locations/global/workforcePools/example"
  }
}.SIGNATURE

Eine IAP-Assertion enthält die folgenden Felder:

Feld Name Beschreibung
aud Zielgruppe Der Back-End-Dienst, die App Engine-Anwendung oder der Cloud Run-Dienst, für den die IAP-Assertion vorgesehen ist.
iss Aussteller Der Aussteller des Tokens, immer auf https://cloud.google.com/iap gesetzt.
sub Betreff

Das authentifizierte Hauptkonto, das durch seine eindeutige ID identifiziert wird.

Wenn IAP für die Verwendung von Google-Identitäten konfiguriert ist, entspricht diese ID der ID, die in der Directory API verfügbar ist.

Weitere Informationen zu den IAP-Assertion-Claims finden Sie unter JWT-Nutzlast prüfen.

IAP-Assertions sind 10 Minuten lang gültig und können nicht widerrufen werden.

SAML-Assertions

SAML-Assertions (Security Assertion Markup Language) authentifizieren ein verwaltetes Nutzerkonto und autorisieren den Zugriff auf eine benutzerdefinierte SAML-App. SAML-Assertions werden von Cloud Identity ausgestellt und signiert und können nur zur Authentifizierung verwalteter Nutzerkonten verwendet werden.

Im Gegensatz zu ID-Tokens, die mit einem globalen Schlüssel signiert werden, werden SAML-Assertions mit einem Schlüssel signiert, der für ein Cloud Identity- oder Google Workspace-Konto spezifisch ist.

Eine decodierte SAML-Antwortassertion sieht in etwa so aus:

<saml2:Assertion
  xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion"
  ID="..."
  IssueInstant="2025-04-23T22:47:20.881Z"
  Version="2.0">
  <saml2:Issuer>
    https://accounts.google.com/o/saml2?idpid=C0123456789
  </saml2:Issuer>
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
  <saml2:Subject>
    <saml2:NameID
      Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
        user@example.com
    </saml2:NameID>
    <saml2:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
      <saml2:SubjectConfirmationData
        NotOnOrAfter="2025-04-23T22:52:20.881Z"
        Recipient="https://app.example.com/"/>
    </saml2:SubjectConfirmation>
  </saml2:Subject>

  <saml2:Conditions
    NotBefore="2025-04-23T22:42:20.881Z"
    NotOnOrAfter="2025-04-23T22:52:20.881Z">
    <saml2:AudienceRestriction>
      <saml2:Audience>example-app</saml2:Audience>
    </saml2:AudienceRestriction>
  </saml2:Conditions>

  <saml2:AuthnStatement
    AuthnInstant="2025-04-23T22:46:44.000Z"
    SessionIndex="...">
    <saml2:AuthnContext>
      <saml2:AuthnContextClassRef>
        urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
      </saml2:AuthnContextClassRef>
    </saml2:AuthnContext>
  </saml2:AuthnStatement>
</saml2:Assertion>

Eine SAML-Assertion enthält die folgenden Felder:

Feld Name Beschreibung
Audience Zielgruppe Entitäts-ID der SAML-App.
Issuer Aussteller Aussteller des Tokens, spezifisch für ein Cloud Identity- oder Google Workspace-Konto.
NameID Betreff Das authentifizierte Prinzipal. Das Format der Kennung hängt von der Konfiguration der SAML-App ab.

Der genaue Satz der Attribute, die in einer SAML-Assertion enthalten sind, hängt von der Konfiguration der SAML-App ab.

SAML-Assertions sind 10 Minuten lang gültig und können nicht widerrufen werden.