Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Partager des clients OAuth

Cette page explique comment partager un client OAuth avec une autre application de votre organisation.

Présentation

Partager des clients OAuth entre des projets signifie utiliser un seul client OAuth personnalisé pour plusieurs applications protégées par Identity-Aware Proxy (IAP) au lieu de créer un client OAuth pour chaque application. Cette approche simplifie la gestion, en particulier pour les organisations comportant de nombreuses applications.

Lorsque vous configurez IAP, vous pouvez utiliser l'un des deux types de clients OAuth suivants :

Client OAuth géré par Google : IAP l'utilise automatiquement par défaut. Cette option intégrée ne nécessite pas de créer manuellement un client, mais présente deux limites principales :
- Autorise uniquement l'accès aux utilisateurs de votre organisation (utilisateurs internes)
- Affiche le branding Google Cloud sur l'écran de consentement au lieu de celui de votre organisation
Client OAuth personnalisé : vous le créez et le gérez vous-même. Cette option :
- Peut être partagé entre plusieurs applications
- Permet de personnaliser l'image de marque sur l'écran de consentement
- L'accès est autorisé pour les utilisateurs externes (en dehors de votre organisation).

Lorsque vous créez un client OAuth personnalisé, vous pouvez l'utiliser avec une seule application ou le partager entre plusieurs applications. Le partage d'un client OAuth personnalisé présente plusieurs avantages :

Réduit les frais généraux administratifs liés à la gestion de plusieurs clients
Simplifie l'activation d'IAP pour les membres de l'équipe qui ne devraient pas avoir accès à la page "Identifiants"
Facilite l'accès programmatique (non lié au navigateur) aux applications protégées par IAP

Pour savoir comment créer des clients OAuth, consultez Créer des clients OAuth pour IAP. Pour en savoir plus sur les clients OAuth gérés par Google, consultez Personnaliser une configuration OAuth pour activer IAP.

Avant de commencer

Créez un client OAuth en suivant les étapes de la section Créer un client OAuth ou utilisez un client OAuth existant.

Accès à une interface de programmation

Configurez des clients OAuth pour l'accès programmatique afin de permettre aux applications autres que les navigateurs de s'authentifier auprès de vos ressources protégées par IAP. Cela permet aux scripts, aux jobs automatisés et aux services de backend d'accéder de manière sécurisée à vos applications protégées sans connexion interactive de l'utilisateur.

Vous pouvez appliquer ces paramètres d'authentification à n'importe quel niveau de votre hiérarchie de ressources : organisation, dossier ou projet.

Pour connaître les étapes d'implémentation, consultez le guide d'authentification programmatique et la documentation sur la gestion des paramètres IAP.

gcloud

Préparez un fichier de paramètres avec vos ID client OAuth :

cat << EOF > SETTINGS_FILENAME
  access_settings:
    oauth_settings:
      programmatic_clients: [clientId1, clientId2, ..]
EOF

Appliquez les paramètres à l'aide de la commande gcloud iap settings set :

gcloud iap settings set SETTINGS_FILENAME \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

Exemples de commandes :

# Organization level
gcloud iap settings set SETTINGS_FILENAME --organization=ORGANIZATION

# Folder level
gcloud iap settings set SETTINGS_FILENAME --folder=FOLDER

# Project level (web resources)
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=iap_web

# App Engine service in a project
gcloud iap settings set SETTINGS_FILENAME \
  --project=PROJECT \
  --resource-type=app-engine \
  --service=SERVICE

Où :

SETTINGS_FILENAME : fichier YAML que vous avez préparé.
ORGANIZATION : ID d'organisation
FOLDER : ID du dossier
PROJECT : ID du projet
RESOURCE_TYPE : type de ressource IAP (app-engine, iap_web, compute, organization ou folder)
SERVICE : nom du service (facultatif pour les types de ressources compute ou app-engine)
VERSION : nom de la version (non applicable pour compute, facultatif pour app-engine)

API

Préparez un fichier JSON de paramètres :

cat << EOF > iap_settings.json
{
  "access_settings": {
    "oauth_settings": {
      programmatic_clients: [clientId1, clientId2, ..]
    }
  }
}
EOF

Obtenez le nom de la ressource :

gcloud iap settings get \
  [--organization=ORGANIZATION | --folder=FOLDER | --project=PROJECT] \
  [--resource-type=RESOURCE_TYPE] \
  [--service=SERVICE] \
  [--version=VERSION]

Mettez à jour les paramètres à l'aide du nom de la ressource :
```
curl -X PATCH \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Accept: application/json" \
-H "Content-Type: application/json" \
-d @iap_settings.json \
"https://iap.googleapis.com/v1/RESOURCE_NAME:iapSettings?updateMask=iapSettings.accessSettings.oauthSettings.programmaticClients"
```
Où :
- ORGANIZATION : ID d'organisation
- FOLDER : ID du dossier
- PROJECT : ID du projet
- RESOURCE_TYPE : type de ressource IAP (app-engine, iap_web, compute, organization ou folder)
- SERVICE : nom du service (facultatif pour les types de ressources compute ou app-engine)
- VERSION : nom de la version (non applicable pour compute, facultatif pour app-engine)

Une fois la configuration terminée, connectez-vous à l'application à l'aide de l'un des ID client OAuth que vous avez configurés. Pour en savoir plus, consultez Authentification programmatique.

Accès au navigateur

Pour permettre à IAP d'utiliser votre ID client et votre code secret via la consoleGoogle Cloud , suivez les instructions ci-dessous :

Risques

Bien qu'il soit pratique de partager un client entre vos applications, il existe des risques. Cette section décrit les risques potentiels liés au partage de clients et la manière de les limiter.

Point de défaillance unique

L'utilisation d'un seul client OAuth pour de nombreuses applications crée un point de dépendance unique. Si un client est supprimé ou modifié de manière incorrecte, toutes les applications qui l'utilisent sont affectées. Les clients OAuth supprimés peuvent être restaurés dans un délai de 30 jours.

Pour gérer efficacement ce risque opérationnel :

Mettez en place des contrôles d'accès appropriés pour éviter les modifications ou suppressions accidentelles.
Restreindre l'accès aux clients OAuth à l'aide des autorisations clientauthconfig.clients.*
Utilisez Google Cloud Journaux d'audit pour suivre les activités d'administration impliquant des clients OAuth.

Il s'agit principalement d'un risque opérationnel plutôt que d'un risque de sécurité. Avec des contrôles des accès et une surveillance appropriés, les avantages de commodité et de gestion des clients OAuth partagés l'emportent généralement sur cette considération.

Fuites de codes secrets du client

Pour partager un client, vous devez partager son code secret du client avec des personnes et des scripts. Cela augmente le risque de fuites du code secret du client. Les achats via l'application ne peuvent pas faire la différence entre les jetons créés à partir de votre application et ceux créés à partir d'un code secret du client divulgué.

Pour limiter ce risque :

Protégez les codes secrets du client comme les mots de passe et ne les stockez jamais en texte brut.
Implémenter une gestion sécurisée des identifiants à l'aide de Secret Manager
Surveiller l'accès à vos ressources IAP avec Cloud Audit Logging
Un code secret du client divulgué n'a d'incidence que sur l'authentification, et non sur l'autorisation d'accéder aux ressources. Si vous pensez que votre secret a été divulgué, réinitialisez-le immédiatement.

Pour accéder aux ressources protégées par IAP de manière programmatique, envisagez d'utiliser l'authentification JWT avec un compte de service au lieu de partager les codes secrets du client OAuth avec des utilisateurs individuels. Cette approche permet une meilleure isolation de la sécurité tout en conservant les avantages d'un client OAuth partagé pour vos applications.

Points à prendre en compte concernant le champ d'application des autorisations

Lorsque vous partagez des clients OAuth, toutes les applications utilisent les mêmes niveaux d'autorisation. Pour IAP, openid et email sont les seuls niveaux d'accès requis. Cette considération en soi ne constitue pas un risque important, mais il est important de comprendre les points suivants :

OAuth n'est utilisé que pour l'authentification (vérification de l'identité) dans IAP. L'autorisation (accès aux ressources) est gérée séparément par le biais des stratégies IAM.
Même si les identifiants d'authentification sont compromis, un pirate informatique aura toujours besoin des autorisations IAM appropriées pour accéder aux ressources protégées.
En limitant le client aux seuls niveaux d'accès openid et email requis, vous contribuez à limiter l'impact potentiel sur la sécurité.

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