Cas d'utilisation de l'authentification et de l'autorisation

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Cette page répertorie certains cas d'utilisation courants de l'authentification et de l'autorisation, ainsi que des liens vers des informations supplémentaires sur la mise en œuvre de chaque cas d'utilisation.

Pour en savoir plus sur l'authentification chez Google, consultez la page Authentification chez Google.

S'authentifier sur les API Google

Les API Google nécessitent un jeton d'accès ou une clé API valide pour chaque requête. La manière dont vous fournissez ces identifiants dépend de l'emplacement d'exécution du code et des types d'identifiants acceptés par l'API.

Utiliser les bibliothèques clientes et les ADC (Identifiants par défaut de l'application)

La méthode recommandée pour utiliser les API Google consiste à utiliser une bibliothèque cliente et les ADC (Identifiants par défaut de l'application). Les identifiants par défaut de l'application (ADC) sont une stratégie utilisée par les bibliothèques clientes Cloud et les bibliothèques clientes des API Google, permettant de trouver automatiquement des identifiants en fonction de l'environnement d'application et de les utiliser pour s'authentifier auprès des API Google Cloud. Lorsque vous configurez la stratégie ADC et utilisez une bibliothèque cliente, votre code peut s'exécuter dans un environnement de développement ou bien de production, sans devoir modifier la manière dont votre application s'authentifie auprès des services et des API Google Cloud.

La configuration ADC dépend de l'emplacement d'exécution de votre code. Les ADC prennent en charge l'authentification en tant que compte de service et l'authentification en tant qu'utilisateur.

S'authentifier depuis Google Kubernetes Engine (GKE)

Vous utilisez Workload Identity pour permettre à vos charges de travail exécutées sur GKE d'accéder en toute sécurité aux API Google. Workload Identity permet à un compte de service GKE de votre cluster GKE d'agir en tant que compte de service IAM (Identity and Access Management).

S'authentifier à partir de Cloud Run for Anthos

Vous authentifiez vos services Cloud Run for Anthos en utilisant Workload Identity, qui vous permet d'accéder aux API Google.

Utiliser une API compatible avec les clés API

Les clés API associent une requête API à un projet Google Cloud à des fins de facturation et de quota. Si une API est compatible avec les clés API, une clé API peut être fournie avec la requête API au lieu du jeton. Pour déterminer si une API est compatible avec les clés API, consultez la documentation de votre API.

Utiliser des jetons Web JSON (JWT) autosignés

Certaines API Google sont compatibles avec les jetons Web JSON (JWT) autosignés en lieu et place des jetons d'accès. L'utilisation d'un jeton JWT autosigné vous permet d'éviter d'envoyer une requête réseau au serveur d'autorisation de Google. Cette approche nécessite que vous créiez votre propre jeton JWT signé. Pour en savoir plus sur les jetons, consultez la section Types de jetons.

Utiliser les bibliothèques et les packages d'authentification

Si les ADC et la mise en œuvre OAuth fournis par les bibliothèques clientes Cloud ou les bibliothèques clientes des API Google ne sont pas disponibles dans votre environnement, vous pouvez utiliser les bibliothèques et les packages d'authentification.

Les bibliothèques et les packages d'authentification suivants sont disponibles :

Vous pouvez également mettre en œuvre le flux OAuth 2.0 à l'aide des points de terminaison OAuth 2.0 de Google. Cette approche nécessite une compréhension plus détaillée du fonctionnement d'OAuth 2.0 et d'OpenID Connect. Pour plus d'informations, consultez l'article consacré à l'utilisation d'OAuth 2.0 pour les applications de serveur Web.

Cas d'utilisation spécifiques aux services Google Cloud

Certains services Google Cloud sont compatibles avec les flux d'authentification spécifiques à ce service.

Fournir un accès limité dans le temps à une ressource Cloud Storage à l'aide d'URL signées

Les URL signées fournissent un accès limité dans le temps à une ressource Cloud Storage spécifique.

S'authentifier sur des clusters Anthos

Vous pouvez vous authentifier auprès de clusters Anthos à l'aide d'identités Google Cloud ou d'un fournisseur d'identité tiers:

Configurer une API déployée avec API Gateway ou Cloud Endpoints pour l'authentification

API Gateway et Cloud Endpoints sont compatibles avec l'authentification de service à service et avec l'authentification des utilisateurs via Firebase, jetons d'ID signés par Google, Okta, Auth0 et jetons JWT.

Pour en savoir plus, consultez la documentation du produit :

S'authentifier sur IoT Core à partir d'un appareil IoT

Les appareils IoT (Internet des Objets) utilisent les jetons JWT pour s'authentifier auprès d'IoT Core.

S'authentifier auprès d'applications hébergées sur Cloud Run ou Cloud Functions

Les applications hébergées sur Cloud Run et Cloud Functions nécessitent des jetons OpenID Connect (OIDC) ou des jetons d'ID pour l'authentification.

Pour en savoir plus, consultez la documentation des services d'hébergement répertoriés ci-dessous. Pour en savoir plus sur les autres façons d'obtenir un jeton d'ID, consultez la section Obtenir un jeton d'ID.

Cloud Run

Il existe différentes manières de configurer un service Cloud Run, selon la manière dont le service sera appelé. Vous devrez peut-être également vous authentifier auprès d'autres services à partir d'un service Cloud Run, ce qui nécessite un jeton d'ID OIDC.

Pour authentifier les utilisateurs auprès de votre service depuis une application Web ou mobile, vous utilisez Identity Platform ou Firebase Authentication. Vous pouvez également utiliser Identity-Aware Proxy (IAP) pour authentifier les utilisateurs internes.

Cloud Functions

Lorsque vous appelez une fonction, vous devez authentifier votre appel. Vous pouvez utiliser les identifiants de l'utilisateur ou un jeton d'ID OIDC.

Authentifier les utilisateurs de l'application

Différentes options permettent d'authentifier les utilisateurs finaux de votre application, en fonction du reste de l'environnement de votre application. Les descriptions ci-dessous vous aideront à comprendre la meilleure option pour votre application.

Service d'authentification Description
Google Identity Services

Google Identity Services inclut la connexion à Google, le bouton de connexion utilisateur de Google, ainsi que les API et le SDK Identity Services. Google Identity Services est basé sur les protocoles OAuth 2.0 et OpenID Connect (OIDC).

Si vous créez une application mobile et que vous souhaitez authentifier les utilisateurs à l'aide de comptes Gmail et Google Workspace, la connexion avec Google peut être une bonne option. La connexion avec Google est également compatible avec l'utilisation de comptes Google avec un système de connexion existant.

Informations complémentaires

Se connecter avec Google permet de se connecter avec des comptes Gmail et Google Workspace, et accepte également les mots de passe à usage unique (OTP). Se connecter avec Google est réservé aux comptes Google, ou aux comptes Google d'un système de connexion existant, pour les applications mobiles.

Se connecter avec Google est disponible pour les applications iOS, Android et Web.

Firebase Authentication

Firebase Authentication fournit des services d'authentification et des bibliothèques permettant d'authentifier les utilisateurs auprès de votre application pour un large éventail de types de comptes utilisateur.

Si vous souhaitez accepter les connexions des utilisateurs provenant de plusieurs plates-formes, Firebase Authentication peut être une bonne option.

Informations complémentaires

Firebase Authentication fournit une fonctionnalité d'authentification pour de nombreux types de comptes utilisateur. Firebase Authentication permet l'authentification par mot de passe et la connexion fédérée via Google, Facebook, Twitter et d'autres plates-formes.

Identity Platform et Firebase Authentication sont tous deux basés sur Google Identity Services. Firebase Authentication s'adresse aux applications grand public. Identity Platform est idéal pour les utilisateurs qui souhaitent être leurs propres fournisseurs d'identité ou qui ont besoin des fonctionnalités adaptées à l'entreprise qu'Identity Platform fournit. Pour en savoir plus sur les différences entre ces produits, consultez la section Différences entre Identity Platform et Firebase Authentication.

Les liens suivants fournissent plus d'informations:

Identity Platform

Identity Platform est une plate-forme de gestion de l'authentification et des accès client (CIAM) qui permet aux entreprises d'intégrer une fonctionnalité de gestion de l'authentification et des accès à leurs applications.

Si vous créez une application à utiliser avec un fournisseur d'identité Google tel que Google Workspace ou avec votre propre service de gestion de l'authentification et des accès, Identity Platform peut être une bonne option.

Informations complémentaires

Identity Platform fournit un service d'authentification et d'identité prêt à l'emploi et personnalisable pour l'inscription et la connexion des utilisateurs. Identity Platform est compatible avec plusieurs méthodes d'authentification: SAML, OIDC, e-mail/mot de passe, réseaux sociaux, téléphone et options personnalisées.

Identity Platform et Firebase Authentication sont tous deux basés sur Google Identity Services. Firebase Authentication s'adresse aux applications grand public. Identity Platform est idéal pour les utilisateurs qui souhaitent être leurs propres fournisseurs d'identité ou qui ont besoin des fonctionnalités adaptées à l'entreprise qu'Identity Platform fournit. Pour en savoir plus sur les différences entre ces produits, consultez la section Différences entre Identity Platform et Firebase Authentication.

OAuth 2.0 et OpenID Connect

OpenID Connect permet de gérer et d'utiliser des jetons d'authentification avec la plus grande personnalisation.

Si vous souhaitez contrôler au maximum votre mise en œuvre OAuth 2.0 et que vous maîtrisez la mise en œuvre de flux OAuth 2.0, envisagez cette option.

Informations complémentaires

La mise en œuvre OAuth 2.0 de Google est conforme à la spécification OpenID Connect, et elle est certifiée OpenID. OpenID Connect est une couche d'identité en complément du protocole OAuth 2.0. Votre application peut utiliser OpenID Connect pour valider le jeton d'ID et récupérer des informations de profil utilisateur.

OAuth 2.0 peut être utilisé pour mettre en œuvre l'authentification automatisée sur une ressource sécurisée par IAP (Identity-Aware Proxy).

Identity-Aware Proxy (IAP)

IAP vous permet de contrôler l'accès à votre application avant que les requêtes n'atteignent vos ressources d'application.

Contrairement aux autres services d'authentification de ce tableau, qui sont mis en œuvre dans votre application, IAP effectue l'authentification avant que votre application ne soit accessible.

En savoir plus

Avec IAP, vous établissez une couche d'autorisation centrale pour les applications et utilisez des en-têtes signés pour sécuriser votre application. Les applications protégées par IAP ne sont accessibles qu'aux comptes principaux disposant du rôle IAM approprié. Lorsqu'un utilisateur final tente d'accéder à une ressource sécurisée par IAP, des vérifications d'authentification et d'autorisation sont effectuées. IAP ne protège pas contre les activités au sein d'un projet, tel qu'un autre service dans le même projet.

Pour les identités Google, IAP utilise des jetons d'ID. Pour en savoir plus, consultez la page Authentification automatisée.

Pour en savoir plus sur la manière dont IAP sécurise vos ressources d'application, consultez la présentation d'IAP.

API App Engine Users Pour les applications exécutées dans l'environnement standard App Engine, l'API Users est disponible pour fournir une fonctionnalité d'authentification des utilisateurs pour certains langages.
Autoriser l'accès aux ressources de l'utilisateur final Si votre application accède à des ressources appartenant à votre utilisateur final, vous devez sécuriser l'autorisation de cet utilisateur. Ce cas d'utilisation est parfois appelé autorisation OAUTH à trois acteurs ou 3LO (three-legged OAuth), car trois entités sont impliquées : l'application, le serveur d'autorisation et l'utilisateur.

Options d'authentification et d'autorisation pour Google Cloud et Google Workspace

Google Cloud et Google Workspace proposent diverses options pour configurer l'accès, améliorer la sécurité des comptes et administrer les comptes.

Accorder l'accès aux ressources Google Cloud pour les charges de travail externes

La fédération d'identité de charge de travail vous permet d'accorder aux charges de travail sur site ou multicloud l'accès aux ressources Google Cloud. Historiquement, ce cas d'utilisation nécessite l'utilisation de clés de compte de service, mais la fédération d'identité de charge de travail évite la maintenance et la charge de sécurité liée à l'utilisation de clés de compte de service. La fédération d'identité de charge de travail est compatible avec de nombreux fournisseurs d'identité compatibles avec OIDC ou SAML 2.0. Les fournisseurs d'identité acceptés incluent AWS, Azure Active Directory, Active Directory sur site, Okta, GitHub Actions et les clusters Kubernetes.

Configurer un fournisseur d'identité

Vous pouvez utiliser Google comme fournisseur d'identité à l'aide de Cloud Identity ou de Google Workspace. Vous pouvez également fédérer un compte Cloud Identity ou Google Workspace avec un fournisseur d'identité externe. Cette approche utilise SAML, ce qui permet à vos employés d'utiliser leur identité et leurs identifiants existants pour se connecter aux services Google.

Configurer l'authentification à deux facteurs

Exiger l'authentification à deux facteurs est une bonne pratique qui permet d'empêcher les acteurs malintentionnés d'accéder à un compte lorsqu'ils ont obtenu l'accès aux identifiants de ce compte. Avec l'authentification à deux facteurs, une deuxième information ou identification de l'utilisateur est requise avant que cet utilisateur ne soit authentifié. Google fournit plusieurs solutions compatibles avec la norme FIDO (Fast IDentity Online).

Identity Platform est compatible avec l'authentification à deux facteurs pour les applications Web, iOS et Android.

Google Identity Services est compatible avec l'authentification FIDO (Fast IDentity Online).

Google est compatible avec diverses solutions matérielles pour l'authentification à deux facteurs, telles que les clés Titan.

Configurer un accès basé sur des certificats

Faisant partie de la solution zéro confiance BeyondCorp Enterprise, l'accès basé sur les certificats limite l'accès aux utilisateurs authentifiés sur un appareil approuvé, en identifiant les appareils via leurs certificats X.509. L'accès basé sur des certificats est également appelé "Transport Layer Security" (mTLS).

Obtenir de l'aide pour accéder à un compte Google

Si vous avez besoin d'aide pour accéder à un compte Google ou le gérer, consultez la page Assistance aux comptes Google.

Gérer les identifiants piratés

Si vous pensez que vos identifiants ont été piratés, vous ou votre administrateur pouvez prendre des mesures pour résoudre ce problème. Pour en savoir plus, consultez la page Gérer les identifiants Google Cloud compromis.