Cette page a été traduite par l'API Cloud Translation.

Partager des clients OAuth

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

Présentation

Le partage de clients OAuth entre des projets implique d'utiliser un seul client OAuth personnalisé pour plusieurs applications protégées par un proxy 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 qui disposent de nombreuses applications.

Lorsque vous configurez l'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 aucune création manuelle de client, mais présente deux limites majeures:
- n'autorise l'accès qu'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 le branding sur l'écran d'autorisation
- Permet l'accès des utilisateurs externes (hors 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 administratifs liés à la gestion de plusieurs clients
Simplifie l'activation de l'IAP pour les membres de l'équipe qui ne devraient pas avoir accès à la page "Identifiants"
Facilite l'accès programmatique (hors navigateur) aux applications protégées par IAP

Pour en savoir plus sur la création de clients OAuth, consultez la section Créer des clients OAuth pour les achats intégrés. Pour en savoir plus sur les clients OAuth gérés par Google, consultez la section Personnaliser une configuration OAuth pour activer les achats intégrés.

Avant de commencer

Créez un client OAuth en suivant la procédure décrite dans la section Créer un client OAuth ou utilisez un client OAuth existant.

Accès à une interface de programmation

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

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

Pour connaître la procédure d'implémentation, consultez le guide d'authentification programmatique et la documentation sur la gestion des paramètres de l'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 de l'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 de l'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)

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

Accès par navigateur

Pour autoriser IAP à utiliser votre ID client et votre code secret via la consoleGoogle Cloud , procédez comme suit:

Risques

Même si le partage d'un client entre vos applications s'avère pratique, il présente 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 client OAuth pour de nombreuses applications crée un point de dépendance unique. Toute suppression ou modification incorrecte d'un client a une incidence sur chaque application utilisant ce dernier. Les clients OAuth supprimés peuvent être restaurés dans un délai de 30 jours.

Pour gérer efficacement ce risque opérationnel:

Implémenter des contrôles d'accès appropriés pour éviter les modifications ou les suppressions accidentelles
Limiter l'accès aux clients OAuth à l'aide des autorisations clientauthconfig.clients.*
Utiliser les journaux d'auditGoogle Cloud pour suivre les activités administratives 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 et une surveillance d'accès 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 de clients

Le partage d'un client requiert également le partage de son code secret avec des personnes et des scripts. Cela augmente le risque de fuites du code secret du client. IAP ne peut pas différencier les jetons créés à partir de votre application de ceux générés à partir d'un code secret du client piraté.

Pour atténuer ce risque:

Protégez les secrets 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
Une fuite de code secret du client n'affecte que l'authentification, et non l'autorisation d'accéder aux ressources. Si vous pensez que votre secret a été divulgué, réinitialisez-le immédiatement.

Pour un accès programmatique aux ressources protégées par un IAP, envisagez d'utiliser l'authentification JWT du compte de service au lieu de partager des secrets client OAuth avec des utilisateurs individuels. Cette approche offre 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 champs d'application. Pour l'IAP, openid et email sont les seuls champs d'application obligatoires. Cette considération n'est pas un risque important en soi, mais il est important de comprendre:

OAuth n'est utilisé que pour l'authentification (vérification de l'identité) dans l'IAP. L'autorisation (accès aux ressources) est gérée séparément via 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.
Limiter le client aux portées openid et email requises permet de 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.