Partager des clients OAuth

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

Présentation

Le partage de clients OAuth entre projets consiste à 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 disposant de nombreuses applications.

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

  • Client OAuth géré par Google : IAP l'utilise automatiquement par défaut. Cette option intégrée ne nécessite pas de création manuelle de client, mais présente deux limites principales :

    • Autorise l'accès uniquement 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.

    • Prise en charge de l'accès 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 administratifs liés à la gestion de plusieurs clients

  • Simplifie l'activation d'IAP pour les membres de l'équipe qui ne doivent 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 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 la procédure décrite dans Création d'un client OAuth ou utilisez un client OAuth existant.

Accès à une interface de programmation

Configurez des clients OAuth pour l'accès automatisé 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 tâches automatisées 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 la hiérarchie des ressources : organisation, dossier ou projet.

Pour connaître les étapes de mise en œuvre, consultez le guide d'authentification programmatique et la documentation sur la gestion des paramètres IAP.

gcloud

  1. 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

  2. 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

  1. Préparez un fichier JSON de paramètres :

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

  2. Obtenez le nom de la ressource :

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

  3. 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)

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 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 que le partage d'un client entre vos applications soit pratique, il comporte 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 :

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

Fuites de codes secrets du client

Pour partager un client, vous devez partager votre code secret du client avec des personnes et des scripts. Cela augmente le risque de fuites du code secret du client. IAP ne peut 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

  • Surveillez l'accès à vos ressources IAP avec Cloud Audit Logging.

  • La fuite d'un code secret du client 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 l'accès automatisé aux ressources protégées par IAP, envisagez d'utiliser l'authentification JWT par compte de service au lieu de partager les codes secrets du 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 niveau d'autorisation

Lorsque vous partagez des clients OAuth, toutes les applications utilisent les mêmes champs d'application d'autorisation. Pour IAP, openid et email sont les seuls champs d'application requis. Cette considération ne constitue pas un risque important en soi, 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 via des stratégies IAM.

  • Même si les identifiants d'authentification sont compromis, un pirate informatique aurait toujours besoin des autorisations IAM appropriées pour accéder aux ressources protégées.

  • Limiter le client aux seuls champs d'application openid et email requis permet de limiter l'impact potentiel sur la sécurité.