Jeton daccès google

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 et hébergés sur Google Cloud.

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

Que sont les jetons

Pour l’authentification et l’autorisation, un jeton est un objet numérique qui contient des informations sur le principal qui effectue la demande et sur 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 des informations d’identification contre un jeton, ce 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 ou des ID client, qui sont considérés comme des informations d’identification.

Les jetons

d’accès sont des jetons opaques conformes à l’infrastructure OAuth 2.0. Ils contiennent des informations sur le type de mandataire utilisé pour créer le jeton, ainsi que des informations d’autorisation. Ils sont utilisés pour authentifier et fournir des informations d’autorisation aux API Google. Les jetons d'accès ne contiennent pas l'identité du principal.

Si vous utilisez les informations d'identification par défaut de l'application (ADC) et les bibliothèques clientes Cloud ou les bibliothèques clientes API Google, vous n'avez pas besoin de gérer les jetons d'accès. Les bibliothèques récupèrent automatiquement les informations d'identification, 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, c’est-à-dire qu’ils sont 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é ou révoqué) à l’aide du point de terminaison Google OAuth 2.0.

Remplacez-le par le jeton d’accès valide et non expiré.

Cette commande renvoie quelque chose de similaire à l’exemple suivant :

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

Description du
champ L’ID de projet, d’adresse e-mail ou de compte de service de l’application qui a demandé le jeton. Cette valeur n’est incluse que si elle est spécifiée dans la liste des étendues.
Étendues OAuth qui ont été ajoutées à ce jeton d’accès. Pour les services Google Cloud, il est recommandé d’utiliser le champ d’application, qui comprend toutes les API Google Cloud, ainsi que la gestion des identités et des accès (IAM), qui fournit : Contrôle d’accès précis.
Nombre de secondes avant l’expiration du jeton. Pour plus d’informations, consultez Durée de vie du jeton d’accès.

Durée

de vie des jetons d’accès

Par défaut, les jetons d’accès sont valables 1 heure (3 600 secondes). Lorsque le jeton d’accès a expiré, votre code de gestion des jetons doit en recevoir 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 pour créer le jeton. 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 stratégie d’organisation qui active la contrainte. Pour plus d’informations, consultez Créer un jeton d’accès de courte durée.

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

Les jetons d’accès fédérés sont des jetons d’accès renvoyés par l’API du service de jeton de sécurité dans échange des informations d’identification externes générées à partir d’identités fédérées par Workload Identity Federation et Workforce Identity Federation. Les jetons d’accès fédérés sont similaires aux jetons d’accès standard, à l’exception des différences suivantes :

Les jetons d’accès fédérés ne peuvent pas être utilisés pour tous les services Google Cloud. Pour obtenir la liste des limitations des jetons d’accès fédéré, consultez Fédération d’identités : produits et limitations.
Les jetons d’accès fédéré affirment l’identité fédérée externe.

Si vous devez utiliser une API qui ne prend pas en charge les jetons d’accès fédérés, vous pouvez utiliser le jeton d’accès fédéré pour emprunter l’identité d’un compte de service et générer un jeton d’accès standard. Pour plus d’informations, consultez Créer un jeton d’accès de courte durée.

Pour plus d’informations sur la façon dont les applications Google Kubernetes Engine s’authentifient auprès des API Google, consultez À propos de la fédération d’identités de charge de travail pour GKE.

Les

jetons d’ID sont des jetons Web JSON (JWT) conformes à la spécification OpenID Connect (OIDC). Elles sont composées 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 l’auteur du signature du 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 meilleures pratiques d’utilisation des JWT, consultez Bonnes pratiques actuelles en matière de jeton Web JSON.

Contenu du jeton d’ID

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

Remplacez-le par le jeton d’ID valide et non expiré.

Cette commande renvoie quelque chose similaire à l’exemple suivant :

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

Revendication	Description
L’émetteur, ou le signataire, du jeton. Pour les jetons d’ID signés Google, cette valeur est .
optionnel. À qui le jeton a été émis.
L’audience du jeton. La valeur de cette revendication doit correspondre à l’application ou au service qui utilise le jeton pour authentifier la demande. Pour plus d’informations, consultez Revendication de jeton d’ID.
L’objet : l’ID qui représente le mandant à l’origine de la demande.
Époque Unix à laquelle le jeton a été émis.
Heure d’époque Unix à laquelle le jeton expire.

D’autres réclamations peuvent être présentes, selon l’émetteur et le application.

Revendication de jeton d’ID

La revendication décrit le nom de service pour lequel ce jeton a été créé. Si un service reçoit un jeton d’ID, il doit vérifier son intégrité (signature), sa validité (est-ce qu’il a expiré) et si la revendication correspond au nom qu’il attend. S’il ne correspond pas, le service doit rejeter le jeton, car il pourrait s’agir d’un replay destiné à un autre système.

En règle générale, lorsque vous obtenez un jeton d’ID, vous utilisez les informations d’identification fournies par un compte de service, plutôt que les informations d’identification de l’utilisateur. En effet, la revendication des jetons d’ID générés à l’aide des informations d’identification de l’utilisateur est liée statiquement à l’application que l’utilisateur a utilisé pour s’authentifier. 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.

Les

jetons d’identification à vie sont valides jusqu’à 1 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 votre application utilise un service Google tel que Cloud Run, les fonctions Cloud Run ou le proxy prenant en charge l’identité, Google valide les jetons d’ID pour vous. Dans ce cas, les jetons d’ID doivent être signés par Google.

Si vous devez valider des jetons d’ID dans votre application, vous pouvez le faire, bien qu’il s’agisse d’un flux de travail avancé. Pour plus d’informations, consultez Validation d’un jeton d’ID.

Jetons Web JSON auto-signés (JWT)

Vous pouvez utiliser des JWT auto-signés pour vous authentifier auprès de certaines API Google sans avoir à obtenir un jeton d’accès auprès du serveur d’autorisation.

La création de JWT auto-signé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 flux de travail avancé. Pour plus d’informations sur les JWT auto-signés, consultez Création d’un jeton Web JSON auto-signé. Pour connaître les meilleures pratiques d’utilisation des JWT, consultez Bonnes pratiques actuelles en matière de jeton Web JSON.

Votre

fournisseur d’identité gère la durée de vie des jetons à longue durée de vie. 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 des bibliothèques clientes, constituent une exception.

Les

jetons au porteur sont une classe générale de jetons qui donne accès à la partie en possession du jeton. Les jetons d’accès, les jetons d’ID et les JWT auto-signés sont tous des jetons au porteur.

L’utilisation de jetons porteurs pour l’authentification repose sur la sécurité fournie par un protocole chiffré, tel que ; si un jeton porteur est intercepté, il peut être utilisé par un acteur malveillant pour y accéder.

Si les jetons de porteur 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 mTLS (Transport Layer Security) mutuelle telle que Chrome Enterprise Premium, qui limite l’accès aux seuls utilisateurs authentifiés sur un appareil.