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 auprès des API Google
Les API Google requièrent un jeton d'accès ou une clé API valide avec chaque requête. La procédure à suivre pour fournir ces identifiants requis 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). Application Default Credentials (ADC) est une stratégie utilisée par les bibliothèques d'authentification pour rechercher automatiquement des identifiants en fonction de l'environnement d'application. Les bibliothèques d'authentification mettent ces identifiants à la disposition des bibliothèques clientes Cloud et des bibliothèques clientes des API Google. Lorsque vous utilisez le service ADC, votre code peut s'exécuter dans un environnement de développement ou bien de production, sans modifier la manière dont votre application s'authentifie auprès des API et services 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 Knative serving
Vous authentifiez vos services Knative serving à l'aide de 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 auprès de clusters GKE Enterprise
Vous pouvez vous authentifier auprès des clusters GKE Enterprise à l'aide des identités Google Cloud ou d'un fournisseur d'identité tiers :
- Authentifiez-vous auprès des identités Google Cloud à l'aide de la passerelle Connect.
- Authentifiez-vous auprès d'un fournisseur d'identité tiers compatible avec OIDC ou LDAP à l'aide d'Anthos Identity Service.
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 :
- Choisir une méthode d'authentification pour API Gateway
- Choisir une méthode d'authentification pour Cloud Endpoints
Authentification pour les 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. Pour en savoir plus sur les jetons d'ID, y compris sur la validation des jetons d'ID, consultez la section Jetons 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 à partir d'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 fonctionnalité Se connecter avec 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. En savoir plus 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. En savoir plus 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 est destinée aux applications grand public. Identity Platform est idéal pour les utilisateurs qui souhaitent être leurs propres fournisseurs d'identité ou qui ont besoin de fonctionnalités adaptées aux entreprises, telles qu'en propose Identity Platform. 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. En savoir plus 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 est destinée aux applications grand public. Identity Platform est idéal pour les utilisateurs qui souhaitent être leurs propres fournisseurs d'identité ou qui ont besoin de fonctionnalités adaptées aux entreprises, telles qu'en propose Identity Platform. 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. En savoir plus 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 ses ressources. 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 section Authentification automatisée. Pour en savoir plus sur la manière dont IAP sécurise vos ressources d'application, consultez la page Présentation d'IAP. Les tutoriels suivants, spécifiques à chaque langage, sont disponibles pour IAP : |
| API App Engine Users | Pour les applications exécutées dans l'environnement standard App Engine, l'API Users peut fournir une fonctionnalité d'authentification utilisateur pour certaines langues. |
| 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, renforcer 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 accepte diverses solutions matérielles pour l'authentification à deux facteurs, telles que les clés Titan.
Configurer un accès basé sur des certificats
Intégré à la solution zéro confiance Chrome Enterprise Premium, 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).
Informations générales sur les comptes et l'authentification
Obtenir de l'aide pour accéder à un compte Google
Si vous avez besoin d'aide pour accéder à un compte Google ou pour en gérer un, consultez la page d'assistance des 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 atténuer la situation. Pour en savoir plus, consultez la page Gérer des identifiants Google Cloud dont la sécurité a été compromise.
Obtenir de l'aide pour résoudre les problèmes liés à l'autorité de certification
Si vous constatez des erreurs liées à un problème avec votre certificat ou votre autorité de certification, y compris votre autorité de certification racine, consultez les questions fréquentes sur Google Trust Services.