Arten von Tokens

Die meisten Zugriffs- und Identitätstokens sind Bearer-Tokens. Inhabertokens gewähren Zugriff auf die Partei, die das Token besitzt, unabhängig davon, wie sie das Token erhalten hat. Wenn ein böswilliger Akteur ein Inhabertoken abfängt, kann er es verwenden, um unbefugten Zugriff zu erhalten.

Gebundene Tokens gewähren Zugriff auf einen bestimmten Client. Um ein gebundenes Token zu verwenden, muss ein Client einen zusätzlichen Nachweis dafür erbringen, dass er der rechtmäßige Inhaber des Tokens ist. Gebundene Tokens sind daher restriktiver als Inhabertokens und können das Risiko eines Tokendiebstahls verringern.

Zugriffstokens

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

• Sie authentifizieren einen Prinzipal, der ein Nutzer oder eine Arbeitslast sein kann.

• Sie werden für einen bestimmten Kunden 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:

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.
• Gültigkeitsdauer: Tokens unterscheiden sich in ihrer Gültigkeitsdauer und darin, inwieweit sie geändert werden können.
• Widerrufbarkeit: Einige Tokens können widerrufen werden. Andere Tokens bleiben bis zum Ablaufdatum gültig.
• Bindung: Einige Tokens können optional an ein zusätzliches Anmeldedatum gebunden werden. In diesem Fall handelt es sich um gebundene Tokens.

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

Dienstkonto-Zugriffstokens

Dienstkonto-Zugriffstokens sind Inhabertokens, mit denen ein Dienstkonto authentifiziert wird. Die Tokens sind undurchsichtigüberprü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.s3ns.iam.gserviceaccount.com",
  "email_verified": "true",
  "access_type": "online"
}

Ein Dienstkonto-Token enthält die folgenden Felder:

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.

JSON-Webtokens für Dienstkonten

JSON Web Tokens (JWTs) für Dienstkonten sind Inhabertokens, mit denen ein Dienstkonto authentifiziert wird. 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.s3ns.iam.gserviceaccount.com",
  "sub": "service-account@example.s3ns.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.s3ns.iam.gserviceaccount.com",
  "sub": "service-account@example.s3ns.iam.gserviceaccount.com",
  "aud": "https://cloudresourcemanager.googleapis.com/",
  "exp": 1744854799,
  "iat": 1744851199
}.SIGNATURE

Ein Dienstkonto-JWT enthält die folgenden Felder:

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

Föderierte Zugriffstokens

Föderierte Zugriffstokens sind Bearer-Tokens, mit denen ein Hauptkonto eines Mitarbeiterpools oder ein Hauptkonto eines Workload Identity-Pools authentifiziert wird.

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 Mitarbeiteridentitätspools wird durch eine Hauptkonto-ID identifiziert, die der folgenden ähnelt:

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.

Zugriffstokens für die Identität von Agenten

Mit Zugriffstokens für Agentenidentitäten wird ein Agent authentifiziert, dem eine Agentenidentität zugewiesen wurde. Dabei wird eine Prinzipal-ID verwendet, die der folgenden ähnelt:

principal://agents.global.org-ORGANIZATION_ID.system.id.goog/resources/aiplatform/projects/PROJECT_NUMBER/locations/us-central1/reasoningEngines/REASONING_ENGINE_ID

Die Hauptkonto-ID basiert auf der SPIFFE-ID des X.509-Clientzertifikats des Agents, verwendet aber das Präfix principal:// anstelle von spiffe://.

Ein Agent kann ein Zugriffstoken für die Agent-Identität vom Compute Engine-Metadatenserver abrufen. Optional kann der Agent anfordern, dass das Token an sein X.509-Clientzertifikat gebunden wird. Ein gebundenes Zugriffstoken für die Agentenidentität ist nur gültig, wenn es über eine gegenseitige TLS-Verbindung verwendet wird, die mit dem X.509-Clientzertifikat authentifiziert wird, an das das Token gebunden ist.

Wie föderierte Zugriffstokens sind auch Zugriffstokens für Agentenidentitäten intransparent, können nicht geprüft oder widerrufen werden und bleiben bis zum Ablauf gültig. Standardmäßig sind Zugriffstokens für die Identität des Kundenservicemitarbeiters eine Stunde lang gültig. Die Gültigkeit eines Tokens kann jedoch kürzer sein, wenn es an ein X.509-Clientzertifikat gebunden ist, das bald abläuft.

Tokens für Zugriffsgrenzen für Anmeldedaten

Zugriffsgrenzen-Tokens für Anmeldedaten sind Inhabertoken, mit denen ein Nutzer oder Dienstkonto authentifiziert wird und die eine Zugriffsgrenze enthalten. Die Zugriffsgrenze schränkt das Token ein, sodass es nur für den Zugriff auf eine definierte Teilmenge von Cloud Storage-Ressourcen verwendet werden kann.

Zugriffsgrenzentokens 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, stärker eingeschränkt sind.

Das Ablaufdatum von Zugriffsgrenzen-Tokens für Anmeldedaten wird vom Ablaufdatum des Eingabetokens abgeleitet, das ein Dienstkonto-Zugriffstoken ist. 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 Zugriffsgrenzen, 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. Cloud de Confiance by S3NS unterstützt verschiedene Arten von Token-Gewährungstokens, die alle Folgendes gemeinsam haben:

• Sie stellen eine vorherige Authentifizierung dar.

• 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.

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.

• Bindung: Einige Tokens sind an zusätzliche Anmeldedaten gebunden. Diese Tokens werden als gebundene Tokens bezeichnet. Andere Tokens sind nicht gebunden und daher Bearer Tokens.

In der folgenden Tabelle sind die Unterschiede zwischen diesen Attributen für Token zusammengefasst, mit denen Token gewährt werden:

Föderierte Aktualisierungstokens

Föderierte Aktualisierungstokens sind undurchsichtige Tokens, mit denen Clients Zugriffstokens für ein Hauptkonto eines 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 Cloud de Confiance by S3NS 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.

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 Cloud de Confiance by S3NS 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-Identitätspool-Prinzipal 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 der Mitarbeiteridentitätsföderation oder der 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 Mitarbeiteridentitätsfö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 Tokenskö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öderationstokens zu erhalten.

Identitätstokens

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

• Sie sind signiert, aber nicht verschlüsselt, damit sie vom Client decodiert, überprüft und interpretiert werden können.

• Sie authentifizieren einen Prinzipal, der ein Nutzer oder eine Arbeitslast sein kann.

• Sie werden für einen bestimmten Kunden 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.

• 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.

Die verschiedenen Arten von Identitätstokens haben auch unterschiedliche Sicherheitseigenschaften:

• Format: Einige Tokens sind JSON-Web-Tokens (JWT), andere verwenden die XML-Formatierung.

• Lebensdauer: Die Lebensdauer von Tokens ist unterschiedlich.

• Bindung: Einige Tokens können optional an ein zusätzliches Anmeldedatum gebunden werden. In diesem Fall handelt es sich um gebundene Tokens.

In der folgenden Tabelle werden die Unterschiede zwischen den Identitätstoken-Typen zusammengefasst.

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.s3ns.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:

Der genaue Satz der in einem ID-Token enthaltenen Ansprüche 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.

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

ID-Tokens für die Identität von KI-Agenten

ID-Tokens für die Identität von KI-Agenten sind SPIFFE-verifizierbare Identitätsdokumente (JWT-SVID) und authentifizieren einen KI-Agenten, dem eine Identität als KI-Agent zugewiesen wurde.

Ein Agent kann ein ID-Token vom Compute Engine-Metadatenserver abrufen. Optional kann der Agent anfordern, dass das Token an sein X.509-Clientzertifikat gebunden wird. Ein gebundenes Agent-Identitäts-ID-Token enthält den Fingerabdruck des X.509-Clientzertifikats und ist nur gültig, wenn es über eine gegenseitige TLS-Verbindung verwendet wird, die mit demselben X.509-Clientzertifikat authentifiziert wird.

Im Gegensatz zu Nutzer-ID-Tokens und Dienstkonto-ID-Tokens werden Agent-Identitäts-ID-Tokens nicht vom Google JSON Web Key Set (JWKS) signiert und können nicht überprüft werden.

Ein decodiertes ID-Token für die Identität des Agenten sieht in etwa so aus, wobei SIGNATURE durch die Signatur des Tokens ersetzt wird:

{
  "alg": "RS256",
  "kid": "78ab40e4a0319f9ced58024f5bb66e6387d68066",
  "typ": "JWT"
}.{
  "iss": "https://sts.googleapis.com/v1/organizations/1234567890/locations/global/workloadIdentityPools/agents.global.org-1234567890.system.id.goog",
  "sub": "spiffe://agents.global.org-1234567890.system.id.goog/resources/aiplatform/projects/1234567890/locations/us-central1/reasoningEngines/987654321",
  "aud": ["https://example.com/"],
  "iat": 1775776191,
  "exp": 1775779791,
  "cnf": {
    "x5t#S256": "QTB5TSHeDxHrzDzcrrHU+/shhkfCnARcBEvMldp2uis"
  }
}.SIGNATURE

Ein Agent-Identitäts-ID-Token enthält die folgenden Felder:

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.

• 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": 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:

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.