Arten von Tokens

Cloud de Confiance by S3NS gibt mehrere Arten von Tokens aus, die sich in ihrem Zweck und den Parteien unterscheiden, zwischen denen sie ausgetauscht werden.

Die folgende Tabelle bietet einen Überblick über die wichtigsten Tokenkategorien, in denen sich verschiedene Tokentypen befinden.

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 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 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 Principals, für den das Token zur Authentifizierung verwendet 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: 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.

Dienstkonto-Zugriffstokens

Mit Dienstkonto-Zugriffstokens wird ein Dienstkonto authentifiziert. Die Tokens sind intransparentgeprü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

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

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 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 Principal des Arbeitslastpools 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 wird ein Nutzer oder Dienstkonto 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 den Zugriff auf Ressourcen stärker einschränken.

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 Zugriffsgrenzen 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 Zugriffsgrenzen-Vermittlungstoken, 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 eingetauscht 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.

In der folgenden Tabelle sind die Unterschiede zwischen diesen Attributen für Token zur Gewährung von Token zusammengefasst:

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 Principal des Mitarbeiteridentitäts-Pools 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 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 der Workforce Identity-Föderation oder der Identitätsföderation von Arbeitslasten 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öderierte Zugriffstokens 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 als JSON Web Tokens (JWTs) formatiert, 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 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.

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.

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.

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