Types de jetons

Cette page décrit les types de jetons utilisés pour l'authentification auprès des API Google, des services Google Cloud et des services créés par le client hébergés sur Google Cloud.

Si vous accédez aux API et aux services de Google à l'aide d'une bibliothèque cliente, vous pouvez configurer le service Identifiants par défaut de l'application, et la bibliothèque cliente gère les jetons pour vous. Il s'agit de l'approche recommandée.

Définition des jetons

Pour l'authentification et l'autorisation, un jeton est un objet numérique qui contient des informations sur l'identité du compte principal qui effectue la requête et le type d'accès pour lequel il est autorisé. Dans la plupart des flux d'authentification, l'application (ou une bibliothèque utilisée par l'application) échange un identifiant contre un jeton, qui détermine les ressources auxquelles l'application est autorisée à accéder.

Types de jetons

Différents types de jetons sont utilisés dans différents environnements. Les types de jetons suivants sont décrits sur cette page :

Cette page ne traite pas des clés API ni des ID clients, qui sont considérés comme des identifiants.

Jetons d'accès

Les jetons d'accès sont des jetons opaques conformes au framework OAuth 2.0. Ils contiennent des informations d'autorisation, mais pas d'informations d'identité. Elles permettent de s'authentifier et de fournir des informations d'autorisation aux API Google.

Si vous utilisez le service Identifiants par défaut de l'application et les bibliothèques clientes Cloud ou les bibliothèques clientes des API Google, vous n'avez pas besoin de gérer les jetons d'accès. Les bibliothèques récupèrent automatiquement les identifiants, les échangent contre un jeton d'accès et actualisent le jeton d'accès si nécessaire.

Contenu des jetons d'accès

Les jetons d'accès sont des jetons opaques, ce qui signifie qu'ils se présentent dans un format propriétaire. Les applications ne peuvent pas les inspecter.

Vous pouvez obtenir les informations à partir d'un jeton d'accès valide (non expiré ni révoqué) à l'aide du point de terminaison tokeninfo de Google OAuth 2.0.

Remplacez ACCESS_TOKEN par le jeton d'accès valide et non expiré.

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

Cette commande renvoie un résultat semblable à l'exemple suivant :

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

Le tableau suivant répertorie les champs les plus importants à comprendre :

Champ Description
azp ID du projet, de l'adresse e-mail ou du compte de service de l'application qui a demandé le jeton. Cette valeur n'est incluse que si https://www.googleapis.com/auth/userinfo.email est spécifié dans la liste des champs d'application.
scope Niveaux d'accès OAuth qui ont été ajoutés à ce jeton d'accès. Pour les services Google Cloud, il est recommandé d'utiliser le champ d'application https://www.googleapis.com/auth/cloud-platform, qui inclut toutes les API Google Cloud, ainsi que Identity and Access Management (IAM), qui fournit un contrôle des accès précis.
expires_in Nombre de secondes avant l'expiration du jeton. Pour en savoir plus, consultez la section Durée de vie d'un jeton d'accès.

Durée de vie d'un jeton d'accès

Par défaut, les jetons d'accès sont valides pendant une heure, soit 3 600 secondes. Lorsque le jeton d'accès a expiré, votre code de gestion des jetons doit en obtenir un nouveau.

Si vous avez besoin d'un jeton d'accès avec une durée de vie plus longue ou plus courte, vous pouvez utiliser la méthode serviceAccounts.generateAccessToken pour le créer. Cette méthode vous permet de choisir la durée de vie du jeton, avec une durée de vie maximale de 12 heures.

Si vous souhaitez prolonger la durée de vie du jeton au-delà de la valeur par défaut, vous devez créer une règle d'administration qui active la contrainte iam.allowServiceAccountCredentialLifetimeExtension. Pour en savoir plus, consultez la section Créer un jeton d'accès éphémère.

Jetons d'ID

Les jetons d'ID sont des jetons Web JSON (JWT, JSON Web Tokens) conformes à la spécification OpenID Connect (OIDC). Ils sont composés d'un ensemble de paires clé/valeur appelées revendications.

Contrairement aux jetons d'accès, qui sont des objets opaques qui ne peuvent pas être inspectés par l'application, les jetons d'ID sont destinés à être inspectés et utilisés par l'application. Les informations du jeton, telles que la personne qui a signé le jeton ou l'identité pour laquelle le jeton d'ID a été émis, peuvent être utilisées par l'application.

Pour plus d'informations sur l'implémentation d'OIDC par Google, consultez la page OpenID Connect. Pour connaître les bonnes pratiques concernant l'utilisation des jetons JWT, consultez la page Bonnes pratiques actuelles concernant les jetons Web JSON.

Contenu des jetons d'ID

Vous pouvez inspecter un jeton d'ID valide (non expiré ni révoqué) à l'aide du point de terminaison tokeninfo.

Remplacez ID_TOKEN par un jeton d'ID valide et non expiré.

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

Cette commande renvoie un résultat semblable à l'exemple suivant :

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

Le tableau suivant décrit les revendications de jeton d'ID obligatoires ou couramment utilisées :

Affirmation Description
iss Émetteur, ou signataire, du jeton. Pour les jetons d'ID signés par Google, cette valeur est https://accounts.google.com.
azp Facultatif. la personne pour laquelle le jeton a été émis.
aud Audience du jeton. La valeur de cette revendication doit correspondre à l'application ou au service qui utilise le jeton pour authentifier la requête. Pour en savoir plus, consultez la section Revendication aud d'un jeton d'ID.
sub Le sujet : ID qui représente le compte principal qui effectue la requête.
iat Heure epoch Unix lors de l'émission du jeton.
exp Heure epoch Unix lorsque le jeton expire.

D'autres revendications peuvent être présentes, en fonction de l'émetteur et de l'application.

Revendication aud d'un jeton d'ID

La revendication aud décrit le nom du service que ce jeton a été créé pour appeler. Si un service reçoit un jeton d'ID, il doit vérifier son intégrité (signature), sa validité (a-t-il expiré) et si la revendication aud correspond au nom attendu. Si ce n'est pas le cas, le service doit rejeter le jeton, car il peut s'agir d'une relecture conçue pour un autre système.

En règle générale, lorsque vous obtenez un jeton d'ID, vous utilisez les identifiants fournis par un compte de service plutôt que les identifiants de l'utilisateur. En effet, la revendication aud pour les jetons d'ID générés à l'aide d'identifiants utilisateur est statiquement liée à l'application que l'utilisateur a utilisée pour l'authentification. Lorsque vous utilisez un compte de service pour acquérir un jeton d'ID, vous pouvez spécifier une valeur différente pour la revendication aud.

Durée de vie d'un jeton d'ID

Les jetons d'ID sont valides pendant une durée maximale d'une heure (3 600 secondes). Lorsqu'un jeton d'ID expire, vous devez en acquérir un nouveau.

Validation des jetons d'ID

Lorsque votre service ou application utilise un service Google tel que Cloud Run, Cloud Run Functions ou Identity-Aware Proxy, Google valide les jetons d'ID à votre place. Dans ce cas, les jetons d'ID doivent être signés par Google.

Si vous devez valider les jetons d'ID dans votre application, vous pouvez le faire, bien qu'il s'agisse d'un workflow avancé. Pour en savoir plus, consultez la section Valider un jeton d'ID.

Jetons Web JSON (JWT) autosignés

De plus, vous pouvez utiliser des jetons JWT autosignés pour vous authentifier auprès de certaines API Google sans avoir à obtenir de jeton d'accès auprès du serveur d'autorisation.

La création de jetons JWT autosignés est recommandée si vous créez vos propres bibliothèques clientes pour accéder aux API Google, mais il s'agit d'un workflow avancé. Pour en savoir plus sur les jetons JWT autosignés, consultez la section Créer un jeton Web JSON autosigné. Pour connaître les bonnes pratiques concernant l'utilisation des jetons JWT, consultez la page Bonnes pratiques actuelles concernant les jetons Web JSON.

Jetons d'actualisation

Votre IdP gère la durée de vie des jetons de longue durée. Les fichiers ADC locaux, qui contiennent des jetons d'actualisation utilisés par les bibliothèques d'authentification pour actualiser automatiquement les jetons d'accès pour les bibliothèques clientes, constituent une exception.

Jetons fédérés

Les jetons fédérés sont générés à partir d'identités fédérées par la fédération d'identité de charge de travail et la fédération des identités des employés.

Les jetons fédérés sont utilisés de la manière suivante :

Les jetons fédérés renvoyés par Workload Identity Federation et Workforce Identity Federation ne sont pas équivalents aux jetons renvoyés par Workload Identity Federation for GKE. Pour en savoir plus sur l'authentification des applications Google Kubernetes Engine auprès des API Google, consultez la page Configurer des applications pour qu'elles utilisent Workload Identity Federation for GKE.

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. Les jetons d'accès, les jetons d'ID et les jetons JWT autosignés sont tous des jetons de support.

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, envisagez d'ajouter une autre couche de chiffrement ou d'utiliser une solution mutuelle Transport Layer Security (mTLS), telle que Chrome Enterprise Premium, qui limite l'accès aux seuls utilisateurs authentifiés sur un appareil vérifié.

Étapes suivantes