Types de jetons

Google Cloud émet plusieurs types de jetons, qui diffèrent par leur objectif et les parties entre lesquelles ils sont échangés.

Le tableau suivant présente les principales catégories de jetons, qui contiennent différents types de jetons.

Catégorie de jeton Chemin de communication Objectif
Jetons d'accès Serveur d'autorisation ⭢ Client ⭢ API Google Permet aux clients d'appeler les API  Google Cloud .
Jetons d'octroi de jetons Serveur d'autorisation ⭤ Client Permet aux clients d'obtenir des jetons nouveaux ou différents, éventuellement à un moment ultérieur.
Jetons d'identité Serveur d'autorisation ⭢ Client Permet aux clients d'identifier l'utilisateur avec lequel ils interagissent.

Les jetons d'accès et d'identité sont des jetons de support. Les jetons de support sont une classe générale de jetons qui accorde l'accès à la partie en possession du jeton.

L'utilisation de jetons de support pour l'authentification repose sur la sécurité fournie par un protocole chiffré, tel que HTTPS. Si un jeton de support est intercepté, il peut être utilisé par un acteur malintentionné pour obtenir l'accès.

Si les jetons de support n'offrent pas une sécurité suffisante pour votre cas d'utilisation, vous pouvez réduire le risque de vol de jetons en utilisant l'accès contextuel, en limitant la durée de vie des jetons d'accès ou en utilisant une solution mutuelle Transport Layer Security (mTLS) telle que Chrome Enterprise Premium.

Jetons d'accès

Les jetons d'accès permettent aux clients d'effectuer des appels authentifiés aux API Google Cloud .Google Cloud accepte plusieurs types de jetons d'accès, qui ont les propriétés suivantes en commun :

  • Ils authentifient un compte principal, qui peut être un utilisateur ou une charge de travail.

  • Elles sont émises pour un client spécifique.

  • Elles sont éphémères et expirent au bout de quelques heures maximum.

  • Elles sont limitées à certains champs d'application, points de terminaison ou ressources OAuth. Cela signifie qu'un jeton d'accès n'accorde généralement pas l'accès à toutes les ressources d'un utilisateur, mais seulement à un certain sous-ensemble d'entre elles.

Les jetons d'accès peuvent différer de plusieurs façons :

  • Émetteur : partie qui émet le jeton.

  • Principal : type de principal que le jeton peut authentifier.

  • Restrictions : restrictions qui peuvent être imposées au jeton.

Le tableau suivant répertorie les différents types de jetons d'accès :

Type de jeton Émetteur Comptes principaux Restrictions
Jeton d'accès utilisateur Serveur d'autorisation Google
  • Utilisateur (utilisateur géré)
  • Utilisateur (compte personnel)
 Habilitation OAuth
Jeton d'accès au compte de service
  • Serveur d'autorisation Google
  • Google Cloud Serveur d'autorisation IAM
 Compte de service Habilitation OAuth
Jeton de délégation à l'échelle du domaine Serveur d'autorisation Google Utilisateur (utilisateur géré) Habilitation OAuth
Jeton Web JSON (JWT) du compte de service Client Compte de service Habilitation OAuth ou API
Jeton d'accès fédéré Google Cloud Serveur d'autorisation IAM
  • Principal du pool d'identités de personnel
  • Compte principal du pool d'identités de charge de travail
 Habilitation OAuth
Jeton de limite d'accès aux identifiants Google Cloud Serveur d'autorisation IAM
  • Utilisateur (utilisateur géré)
  • Utilisateur (compte personnel)
  • Compte de service
 Objets Cloud Storage spécifiques
Jeton de limite d'accès aux identifiants émis par le client Client Compte de service Objets Cloud Storage spécifiques

Les différents types de jetons d'accès présentent également des propriétés de sécurité différentes :

  • Format : certains jetons d'accès sont opaques, ce qui signifie qu'ils se présentent dans un format propriétaire et ne peuvent pas être inspectés. Les autres jetons sont encodés en tant que jeton Web JSON, qui peut être décodé par le client.

  • Introspection : certains jetons opaques peuvent être introspectés à l'aide de l'API Google Cloud , tandis que d'autres ne le peuvent pas.

  • Durée de vie : les jetons diffèrent par leur durée de vie et par la mesure dans laquelle ils peuvent être modifiés.

  • Révocabilité : certains jetons peuvent être révoqués. Les autres jetons restent valides jusqu'à leur expiration.

Le tableau suivant récapitule les différences entre les types de jetons d'accès.

Type de jeton Format Introspectable Durée de vie Révocable
Jeton d'accès utilisateur Opaque Oui 1 heure Oui
Jeton d'accès au compte de service Opaque Oui 5 minutes à 12 heures Non
Jeton de délégation au niveau du domaine Opaque Oui 1 heure Non
Jeton Web JSON (JWT) de compte de service JWT N/A 5 minutes à 1 heure Non
Jeton d'accès fédéré Opaque Non Consultez Jetons d'accès fédérés. Non
Jeton de limite d'accès aux identifiants Opaque Non Consultez Jetons de limite d'accès aux identifiants. Non
Jeton de limite d'accès aux identifiants émis par le client Opaque Non N/A Non

Jetons d'accès utilisateur

Les jetons d'accès utilisateur authentifient un utilisateur et autorisent un client à agir en son nom :

Le compte principal authentifié est soit un compte utilisateur géré, soit un compte consommateur. Le client peut être une application Web ou une application native.

Les jetons d'accès utilisateur sont opaques. À des fins de diagnostic, vous pouvez inspecter un jeton d'accès à l'aide de la commande suivante, en remplaçant ACCESS_TOKEN par un jeton d'accès valide :

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

Cette commande produit un résultat semblable à celui de l'exemple suivant :

{
  "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"
}

Le résultat inclut les champs suivants :

Champ Name Description
aud Audience

Client OAuth auquel ce jeton est destiné, identifié par son ID client OAuth.

Les clients OAuth peuvent obtenir des jetons d'accès pour d'autres clients OAuth appartenant au même projet. L'audience peut être différente de la partie autorisée.

azp Partie autorisée Client OAuth ayant demandé le jeton, identifié par son ID client OAuth.
email Adresse e-mail principale

Adresse e-mail principale de l'utilisateur.

Ce champ n'est présent que si le jeton inclut le champ d'application https://www.googleapis.com/auth/userinfo.email.

exp Expiration Heure d'expiration du jeton, au format horaire UNIX.
scope Habilitations OAuth Ensemble d'API auxquelles le client est autorisé à accéder pour le compte de l'utilisateur, identifié par le champ d'application OAuth.
sub Objet

Principal authentifié, identifié par son ID unique.

Cet ID est équivalent à celui exposé dans l' API Directory.

Les jetons d'accès utilisateur expirent automatiquement au bout d'une heure, mais peuvent être révoqués plus tôt si nécessaire.

Par défaut, les jetons d'accès utilisateur sont des jetons de support, ce qui signifie qu'ils ne sont liés à aucun canal de communication, réseau ni identifiant supplémentaire. Vous pouvez éventuellement implémenter l'association de jetons en déployant un accès basé sur les certificats afin que les jetons d'accès utilisateur ne puissent être utilisés qu'avec un certificat client mTLS valide.

Jetons d'accès aux comptes de service

Les jetons d'accès au compte de service authentifient un compte de service. Les jetons sont opaques et vous pouvez les examiner à l'aide de l'API https://oauth2.googleapis.com/tokeninfo.

Pour un jeton d'accès à un compte de service, l'API renvoie un résultat semblable à l'exemple suivant :

{
  "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"
}

Un jeton de compte de service inclut les champs suivants :

Champ Name Description
aud Audience Compte de service auquel le jeton est destiné, équivalent à la partie autorisée.
azp Partie autorisée Compte de service qui a demandé le jeton, identifié par son ID unique.
email Adresse e-mail principale

Adresse e-mail du compte de service.

Ce champ n'est présent que si le jeton inclut le champ d'application https://www.googleapis.com/auth/userinfo.email.

exp Expiration Heure d'expiration du jeton, au format horaire UNIX.

Les jetons d'accès aux comptes de service ne peuvent pas être révoqués et restent valides jusqu'à leur expiration.

Par défaut, les jetons d'accès des comptes de service expirent au bout d'une heure. La méthode serviceAccounts.generateAccessToken vous permet de demander des jetons avec des durées de vie différentes. Étant donné que les durées de vie des jetons plus longues peuvent augmenter les risques, vous devez configurer la contrainte iam.allowServiceAccountCredentialLifetimeExtension pour permettre aux clients de demander des jetons d'accès aux comptes de service avec des durées de vie supérieures à une heure.

Jetons de délégation au niveau du domaine

Les jetons de délégation au niveau du domaine authentifient un utilisateur et autorisent un compte de service à agir en son nom. Les jetons sont opaques et vous pouvez les examiner à l'aide de l'API https://oauth2.googleapis.com/tokeninfo.

Pour un jeton de délégation au niveau du domaine, l'API renvoie un résultat semblable à l'exemple suivant :

{
  "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"
}

Un jeton de délégation à l'échelle du domaine inclut les champs suivants :

Champ Name Description
aud Audience Compte de service auquel le jeton est destiné, équivalent à la partie autorisée.
azp Partie autorisée Compte de service qui a demandé le jeton, identifié par son ID unique.
email Adresse e-mail principale

Adresse e-mail principale de l'utilisateur dont l'identité est usurpée.

Ce champ n'est présent que si le jeton inclut le champ d'application https://www.googleapis.com/auth/userinfo.email.

exp Expiration Heure d'expiration du jeton, au format horaire UNIX.
scope Habilitations OAuth Ensemble d'API auxquelles le client est autorisé à accéder au nom de l'utilisateur imité, identifié par le champ d'application OAuth.

Les jetons de délégation au niveau du domaine expirent automatiquement au bout d'une heure et ne peuvent pas être révoqués.

Jetons Web JSON de compte de service

Les jetons Web JSON (JWT) de compte de service authentifient un compte de service. Alors que les jetons d'accès aux comptes de service sont émis par un serveur d'autorisation, les jetons JWT de compte de service peuvent être émis par le client lui-même.

On parle parfois de jetons JWT "autosignés". Ils peuvent être utiles lorsque vous devez vous authentifier auprès de certaines API Google sans obtenir de jeton d'accès auprès du serveur d'autorisation, par exemple lorsque vous créez vos propres bibliothèques clientes.

Pour émettre un jeton JWT de compte de service, les clients doivent procéder comme suit :

  1. Préparez une charge utile de signature Web JSON qui inclut l'adresse e-mail du compte de service, un champ d'application OAuth ou un point de terminaison d'API, ainsi qu'une heure d'expiration.

  2. Signez la charge utile à l'aide d'une clé de compte de service du compte de service concerné. Les clients peuvent signer la charge utile hors connexion à l'aide d'une clé de compte de service gérée par l'utilisateur, ou en ligne à l'aide de la méthode signJwt et d'une clé de compte de service gérée par Google. Pour en savoir plus, consultez Créer un jeton Web JSON autosigné.

Un jeton JWT de compte de service décodé ressemble à ce qui suit, avec SIGNATURE remplacé par la signature du jeton :

{
  "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

Au lieu de spécifier un champ d'application OAuth dans la clé scope, un jeton JWT de compte de service peut spécifier un point de terminaison d'API dans la clé aud :

{
  "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

Un jeton JWT de compte de service inclut les champs suivants :

Champ Name Description
aud Audience Points de terminaison de l'API auxquels le client est autorisé à accéder. Valide uniquement si scope n'est pas spécifié.
exp Expiration Heure d'expiration du jeton, au format horaire UNIX.
iat Heure du problème Heure à laquelle le jeton a été émis, au format epoch Unix.
iss Émetteur Émetteur du jeton, qui est le compte de service lui-même.
scope Habilitations OAuth Ensemble d'API auxquelles le client est autorisé à accéder, identifié par le champ d'application OAuth. Valide uniquement si aud n'est pas spécifié.
sub Objet Compte principal authentifié, qui est le compte de service lui-même.

Les jetons JWT de compte de service peuvent être valides pendant une heure maximum et ne peuvent pas être révoqués.

Jetons d'accès fédérés

Les jetons d'accès fédérés authentifient un compte principal de pool de charges de travail ou un compte principal de pool de personnel.

La fédération des identités des employés permet aux clients d'échanger un jeton externe contre un jeton d'accès fédéré qui authentifie un compte principal de pool de personnel. Le principal du pool d'identités de charge de travail est identifié par un identifiant principal semblable à ce qui suit :

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

La fédération d'identité de charge de travail permet aux clients d'échanger un jeton externe contre un jeton d'accès fédéré qui authentifie un compte principal de pool de charges de travail. Le principal du pool d'identités de charge de travail est identifié par un identifiant principal semblable à ce qui suit :

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

Les jetons d'accès fédérés sont opaques et ne peuvent pas être introspectés. Les jetons ne peuvent pas être révoqués et restent valides jusqu'à leur expiration. Les dates d'expiration de chaque type de jeton sont basées sur les éléments suivants :

  • La fédération d'identité de personnel définit l'expiration du jeton en fonction de la configuration du fournisseur de pools d'identité de personnel.

  • La fédération d'identité de charge de travail définit l'expiration du jeton pour qu'elle corresponde à celle du jeton externe.

Jetons de limites d'accès aux identifiants

Les jetons de limite d'accès aux identifiants authentifient un utilisateur ou un compte de service et incluent une limite d'accès. La limite d'accès restreint le jeton afin qu'il ne puisse être utilisé que pour accéder à un sous-ensemble défini de ressources Cloud Storage.

Les jetons de limite d'accès aux identifiants sont parfois appelés jetons à champ d'application limité, car ils sont dérivés d'un jeton d'entrée, mais sont plus limités en termes de ressources auxquelles ils accordent l'accès.

L'expiration des jetons de limite d'accès aux identifiants est dérivée de l'expiration du jeton d'entrée, qui peut être un jeton d'accès utilisateur ou un jeton d'accès de compte de service. Les jetons de limites d'accès aux identifiants sont opaques et ne peuvent pas être introspectés ni révoqués.

Jetons de limites d'accès aux identifiants émis par le client

Les jetons de limite d'accès aux identifiants émis par le client sont semblables aux jetons de limite d'accès aux identifiants, mais sont optimisés pour les scénarios dans lesquels les clients doivent obtenir des jetons de limite d'accès aux identifiants avec différentes limites d'accès à haute fréquence.

Les clients peuvent créer localement des jetons de limites d'accès aux identifiants émis par le client à l'aide des bibliothèques clientes Cloud et d'un jeton intermédiaire de limites d'accès, qu'ils doivent actualiser régulièrement.

Les jetons de limites d'accès aux identifiants émis par le client sont opaques et ne peuvent pas être introspectés ni révoqués.

Jetons d'octroi de jetons

Les jetons d'octroi de jetons permettent aux clients d'obtenir de nouveaux jetons ou des jetons différents, éventuellement à une date ultérieure. Google Cloud est compatible avec plusieurs types de jetons d'octroi de jetons, qui ont tous les points suivants en commun :

  • Elles représentent une authentification préalable.

  • Ils authentifient un compte principal, qui peut être une identité Google (utilisateur ou charge de travail) ou une identité externe.

  • Ils peuvent être échangés contre un jeton d'accès.

  • Ils ne peuvent pas être utilisés pour effectuer des appels d'API Google, ce qui les distingue des jetons d'accès.

Les jetons d'autorisation peuvent différer de plusieurs façons :

  • Émetteur : partie qui émet le jeton.

  • Compte principal : type d'identité de compte principal que le jeton peut authentifier.

  • Restrictions : restrictions qui peuvent être imposées au jeton.

Le tableau suivant répertorie les différents types de jetons d'autorisation.

Type de jeton Émetteur Type de jeton d'accès utilisé Comptes principaux Restrictions
Jeton d'actualisation Serveur d'autorisation Google Jeton d'accès utilisateur
  • Utilisateur (utilisateur géré)
  • Utilisateur (compte personnel)
 Habilitation OAuth
Code d'autorisation Serveur d'autorisation Google Jeton d'accès utilisateur
  • Utilisateur (utilisateur géré)
  • Utilisateur (compte personnel)
 Habilitation OAuth
Assertion de jeton Web JSON du compte de service Client
  • Jeton de délégation au niveau du domaine
  • Jeton d'accès au compte de service
  • Utilisateur (utilisateur géré)
  • Compte de service
 Habilitation OAuth
Jeton Web JSON externe Fournisseur d'identité externe Jeton d'accès fédéré Entité principale externe Aucun
Assertion ou réponse SAML externe Fournisseur d'identité externe Jeton d'accès fédéré Entité principale externe Aucun
Jeton Amazon Web Services (AWS) GetCallerIdentity Fournisseur d'identité externe Jeton d'accès fédéré Entité principale externe Aucun

Les différents types de jetons d'autorisation présentent également des propriétés de sécurité différentes :

  • Format : certains jetons sont opaques. Le client peut décoder les autres jetons.

  • Durée de vie : les jetons ont une durée de vie différente et peuvent être modifiés dans une mesure différente.

  • À usages multiples : certains jetons d'octroi de jetons ne peuvent être utilisés qu'une seule fois. D'autres jetons peuvent être utilisés plusieurs fois.

  • Révocabilité : certains jetons peuvent être révoqués. Les autres jetons restent valides jusqu'à leur expiration.

Le tableau suivant récapitule les différences entre ces propriétés pour les jetons d'octroi de jetons :

Type de jeton Format Durée de vie Révocable Valable plusieurs fois
Jeton d'actualisation Opaque Consultez Jetons d'actualisation. Oui Oui
Code d'autorisation Opaque 10 minutes Non Non
Assertion de jeton Web JSON de compte de service JWT 5 minutes à 1 heure Non Oui
Jeton externe ou jeton Web JSON externe JWT Dépend du fournisseur d'identité Dépend du fournisseur d'identité Oui
Assertion ou réponse SAML externe SAML Dépend du fournisseur d'identité Dépend du fournisseur d'identité Oui
Jeton Amazon Web Services (AWS) GetCallerIdentity Blob de texte Dépend du fournisseur d'identité Dépend du fournisseur d'identité Oui

Jetons d'actualisation

Les jetons d'actualisation sont des jetons opaques qui permettent aux clients d'obtenir des jetons d'identité et d'accès pour un utilisateur, si celui-ci a précédemment autorisé un client à agir en son nom.

Les jetons d'actualisation sont associés à un client spécifique et ne peuvent être utilisés qu'avec des identifiants client valides (par exemple, un ID client et un code secret du client).

Si l'autorisation du client inclut un ou plusieurs Google Cloud champs d'application OAuth, la durée de vie du jeton d'actualisation est soumise au paramètre de Google Cloud durée de la session. Sinon, les jetons d'actualisation restent valides jusqu'à ce que l'utilisateur révoque son autorisation ou que d'autres événements de révocation de jeton se produisent.

Codes d'autorisation

Les codes d'autorisation sont des jetons opaques et de courte durée. Les codes ne sont destinés à être utilisés que lors de l'authentification de l'utilisateur en tant qu'intermédiaire entre le client et le serveur d'autorisation Google.

Comme les jetons d'actualisation, les codes d'autorisation sont associés à un client et ne peuvent être utilisés qu'avec des identifiants client valides. Contrairement aux jetons d'actualisation, les codes d'autorisation ne peuvent être utilisés qu'une seule fois.

Assertions de jeton Web JSON de compte de service

Les assertions de jetons Web JSON (JWT) de compte de service affirment l'identité d'un compte de service. Les charges de travail peuvent utiliser des assertions JWT de compte de service pour obtenir des jetons d'accès de compte de service ou des jetons de délégation à l'échelle du domaine. L'assertion JWT du compte de service est signée par une clé de compte de service.

Une assertion JWT de compte de service décodée ressemble à ce qui suit, avec SIGNATURE remplacé par la signature du jeton :

{
  "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

Les assertions JWT de compte de service sont structurellement semblables aux jetons JWT de compte de service : les deux types de jetons peuvent être émis par le client lui-même et sont signés par une clé de compte de service. Toutefois, les deux types de jetons utilisent des charges utiles différentes, comme décrit dans le tableau suivant.

Champ JWT du compte de service Assertion JWT du compte de service
aud APIGoogle Cloud , omise si scope est spécifié Doit être https://oauth2.googleapis.com/token
exp Expiration Expiration
iat Heure du problème Heure du problème
iss Adresse e-mail du compte de service Adresse e-mail du compte de service
scope Champs d'application OAuth, omis si aud est spécifié Habilitations OAuth
sub Adresse e-mail du compte de service Adresse e-mail d'un compte utilisateur pour la délégation au niveau du domaine. Omise dans le cas contraire.

Les assertions JWT de compte de service peuvent être valides jusqu'à une heure et ne peuvent pas être révoquées.

Jetons Web JSON externes

Les jetons Web JSON (JWT) externes sont émis par un fournisseur d'identité externe tel que Microsoft Entra ID, Okta, Kubernetes ou GitHub. Leur structure et leur contenu peuvent être différents.

En configurant la fédération d'identité de personnel ou la fédération d'identité de charge de travail, vous pouvez établir une relation d'approbation entre Google Cloud et un fournisseur d'identité externe. Les charges de travail peuvent ensuite utiliser des JWT externes comme jetons d'octroi de jetons pour obtenir des jetons d'accès fédérés.

Lorsque vous utilisez la fédération d'identité de personnel, le jeton d'accès fédéré obtenu authentifie un principal de pool d'identité de personnel.

Lorsque vous utilisez la fédération d'identité de charge de travail, le jeton d'accès fédéré obtenu authentifie un compte principal de pool d'identité de charge de travail.

Dans les deux cas, l'identifiant principal est dérivé d'une ou plusieurs revendications du JWT externe.

Pour être compatibles avec la fédération d'identité de personnel ou la fédération d'identité de charge de travail, les JWT externes doivent répondre à des exigences spécifiques.

Assertions ou réponses SAML externes

Les assertions SAML (Security Assertion Markup Language) externes sont des assertions SAML 2.0 émises par un fournisseur d'identité externe tel que Microsoft Entra ID, Okta ou Active Directory Federation Services. Ces assertions SAML externes peuvent éventuellement être incluses dans une réponse SAML 2.0 ou être chiffrées.

Comme pour les jetons Web JSON externes, vous pouvez configurer la fédération d'identité du personnel ou la fédération d'identité de charge de travail afin que les charges de travail puissent utiliser des assertions ou des réponses SAML externes comme jetons d'autorisation pour obtenir des jetons d'accès fédérés.

Pour être compatibles avec la fédération d'identité de personnel ou la fédération d'identité de charge de travail, les assertions SAML externes doivent répondre à des exigences spécifiques.

Jeton Amazon Web Services (AWS) GetCallerIdentity

Les jetons GetCallerIdentity AWS externes sont des blocs de texte contenant une requête signée adressée à l'API GetCallerIdentity AWS. Comme pour les jetons Web JSON externes et les assertions SAML, vous pouvez configurer la fédération d'identité du personnel ou la fédération d'identité de charge de travail afin que les charges de travail puissent utiliser ces blocs de texte comme jeton d'octroi de jeton pour obtenir des jetons d'accès fédérés.

Jetons d'identité

Les jetons d'identité (ID) permettent aux clients d'identifier l'utilisateur avec lequel ils interagissent. Google Cloud accepte plusieurs types de jetons d'identité, qui ont tous les points suivants en commun :

  • Ils sont mis en forme en tant que jetons Web JSON (JWT) afin de pouvoir être décodés, vérifiés et interprétés par le client.

  • Ils authentifient un compte principal, qui peut être un utilisateur ou une charge de travail.

  • Elles sont émises pour un client spécifique.

  • Ils sont de courte durée et expirent au bout d'une heure maximum.

  • Elles ne peuvent pas être révoquées.

  • Ils ne peuvent pas être utilisés pour effectuer des appels d'API Google, ce qui les distingue des jetons d'accès.

  • Ils ne peuvent pas être utilisés pour obtenir des jetons d'accès, ce qui les distingue des jetons d'octroi de jetons.

  • Ils peuvent être utilisés pour authentifier les appels entre microservices ou pour s'authentifier de manière programmatique auprès d'Identity-Aware Proxy (IAP).

Les jetons d'identité peuvent différer de plusieurs manières :

  • Audience : partie destinée à décoder et à utiliser le jeton.

  • Émetteur : partie qui émet le jeton.

  • Durée de vie : les jetons diffèrent par leur durée de vie et par la mesure dans laquelle ils peuvent être modifiés.

  • Compte principal : type d'identité de compte principal que le jeton peut authentifier.

Le tableau suivant répertorie les différents types de jetons d'identité.

Type de jeton Émetteur Audience Compte principal Durée de vie
Jeton d'ID utilisateur Serveur d'autorisation Google Client OAuth/OIDC
  • Utilisateur (utilisateur géré)
  • Utilisateur (compte personnel)
 1 heure
Jeton d'ID de compte de service Google Cloud Serveur d'autorisation IAM Libre de choisir n'importe quelle audience Compte de service 1 heure
Assertion Identity-Aware Proxy (IAP) IAP
  • Backend
  • App Engine app
  • Utilisateur (utilisateur géré)
  • Utilisateur (compte personnel)
  • Principal du pool d'identités de personnel
 10 minutes
Assertion SAML Serveur d'autorisation Google Application SAML Utilisateur (utilisateur géré) 10 minutes

Jetons d'ID utilisateur

Les jetons d'identification utilisateur sont des jetons Web JSON (JWT) qui authentifient un utilisateur. Les clients peuvent obtenir un jeton d'ID utilisateur en lançant un flux d'authentification OIDC.

Les jetons d'ID utilisateur sont signés à l'aide du jeu de clés Web JSON (JWKS) de Google. Le JWKS Google est une ressource globale. Les mêmes clés de signature sont utilisées pour différents types d'utilisateurs, y compris les suivants :

  • Comptes utilisateur gérés

  • Comptes utilisateur personnels

  • Comptes de service

Un jeton d'ID utilisateur décodé ressemble à ce qui suit, avec SIGNATURE remplacé par la signature du jeton :

{
  "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

Un jeton d'identité inclut les champs suivants :

Champ Name Description
aud Audience

Client OAuth auquel ce jeton est destiné, identifié par son ID client OAuth.

Les clients OAuth peuvent obtenir des jetons d'accès pour d'autres clients OAuth appartenant au même projet. Dans ce cas, l'audience peut être différente de la partie autorisée.

azp Partie autorisée Client OAuth ayant effectué le flux d'authentification OIDC, identifié par son ID client OAuth.
exp Expiration Heure d'expiration du jeton, au format horaire UNIX.
hd Domaine hébergé

Domaine principal du compte Cloud Identity ou Google Workspace de l'utilisateur.

Cette revendication n'est présente que si l'utilisateur est un compte utilisateur géré et que le client a spécifié le paramètre hd dans la demande d'authentification.

iss Émetteur Émetteur du jeton. Toujours défini sur https://accounts.google.com.
sub Objet

Principal authentifié, identifié par son ID unique.

Cet ID est équivalent à celui exposé dans l' API Directory.

L'ensemble exact de revendications incluses dans un jeton d'identité dépend du paramètre scope dans la requête d'authentification.

Pour déterminer si un utilisateur dispose d'un compte géré ou identifier le compte Cloud Identity ou Google Workspace auquel il appartient, les clients doivent inspecter la revendication hd.

Les jetons d'ID utilisateur sont valides pendant une heure et ne peuvent pas être révoqués.

Jetons d'identification de compte de service

Les jetons d'identité de compte de service sont des jetons Web JSON (JWT) qui authentifient un compte de service.

Contrairement aux jetons JWT de compte de service et aux assertions JWT de compte de service, les jetons d'identité de compte de service ne sont pas signés par une clé de compte de service. En revanche, les jetons d'identité de compte de service sont signés par le JWKS (JSON Web Key Set) de Google.

Un jeton d'identité de compte de service décodé ressemble à ce qui suit, avec SIGNATURE remplacé par la signature du jeton :

{
  "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

Un jeton d'ID de compte de service inclut les champs suivants :

Champ Name Description
aud Audience Identifiant de la partie à laquelle ce jeton est destiné. La valeur peut être choisie librement par le demandeur du jeton.
azp Partie autorisée Compte de service qui a demandé le jeton, identifié par son ID unique.
exp Expiration Heure d'expiration du jeton, au format horaire UNIX.
iss Émetteur Émetteur du jeton, toujours défini sur https://accounts.google.com.
sub Objet Compte de service qui a demandé le jeton, identifié par son ID unique.

L'ensemble exact de revendications incluses dans un jeton d'identification dépend de la manière dont le jeton d'identification est demandé. Par exemple, les jetons d'identification demandés par le serveur de métadonnées Compute Engine peuvent éventuellement inclure des revendications supplémentaires qui affirment l'identité de la VM. Les jetons d'identification demandés à l'aide de l'API IAM Credentials peuvent éventuellement contenir l'ID de l'organisation du projet du compte de service.

Contrairement aux jetons d'ID utilisateur, les jetons d'ID de compte de service ne sont pas compatibles avec la revendication hd.

Les jetons d'identité de compte de service sont valides pendant une heure et ne peuvent pas être révoqués.

Assertions Identity-Aware Proxy

Les assertions Identity-Aware Proxy (IAP) sont des jetons Web JSON (JWT) qu'IAP transmet aux applications Web protégées par IAP dans l'en-tête de requête HTTP x-goog-iap-jwt-assertion. Les assertions IAP authentifient un utilisateur et servent également de preuve qu'une requête a été autorisée par IAP.

Contrairement aux jetons d'ID utilisateur et aux jetons d'ID de compte de service, les assertions IAP ne sont pas signées à l'aide du jeu de clés Web JSON (JWKS) de Google. Les assertions IAP sont plutôt signées à l'aide d'un JWKS distinct, le JWKS IAP. Ce JWKS est une ressource globale. Les mêmes clés de signature sont utilisées pour différents types d'utilisateurs, y compris les suivants :

  • Comptes utilisateur gérés

  • Comptes personnels

  • Comptes de service

  • Principaux des pools d'identités de personnel

Une assertion IAP décodée ressemble à ce qui suit, avec SIGNATURE remplacé par la signature du jeton :

{
  "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

Si vous configurez IAP pour qu'il utilise la fédération d'identité de personnel au lieu des identités Google, les assertions IAP sont légèrement différentes :

{
  "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

Une assertion IAP inclut les champs suivants :

Champ Name Description
aud Audience Service de backend, application App Engine ou service Cloud Run auquel l'assertion IAP est destinée.
iss Émetteur Émetteur du jeton, toujours défini sur https://cloud.google.com/iap
sub Objet

Principal authentifié, identifié par son ID unique.

Si IAP est configuré pour utiliser des identités Google, cet ID est équivalent à celui exposé dans l' API Directory.

Pour en savoir plus sur les revendications d'assertion IAP, consultez Valider la charge utile JWT.

Les assertions IAP sont valides pendant 10 minutes et ne peuvent pas être révoquées.

Assertions SAML

Les assertions SAML (Security Assertion Markup Language) authentifient un compte utilisateur géré et l'autorisent à accéder à une application SAML personnalisée. Les assertions SAML sont émises et signées par Cloud Identity. Elles ne peuvent être utilisées que pour authentifier des comptes utilisateur gérés.

Contrairement aux jetons d'identité qui sont signés à l'aide d'une clé globale, les assertions SAML sont signées à l'aide d'une clé spécifique à un compte Cloud Identity ou Google Workspace.

Une assertion de réponse SAML décodée ressemble à ce qui suit :

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

Une assertion SAML inclut les champs suivants :

Champ Name Description
Audience Audience ID d'entité de l'application SAML.
Issuer Émetteur Émetteur du jeton, spécifique à un compte Cloud Identity ou Google Workspace.
NameID Objet Compte principal authentifié. Le format de l'identifiant dépend de la configuration de l'application SAML.

L'ensemble exact d'attributs inclus dans une assertion SAML dépend de la configuration de l'application SAML.

Les assertions SAML sont valides pendant 10 minutes et ne peuvent pas être révoquées.