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 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 qui possèdent 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éation manuelle de client, mais présente deux limites principales :

    • Elle n'autorise l'accès qu'aux utilisateurs de votre organisation (utilisateurs internes).
    • Elle affiche la marque sur l'écran de consentement au lieu de celle de votre organisation. Google Cloud

  • Client OAuth personnalisé : vous le créez et le gérez vous-même. Cette option :

    • peut être partagée entre plusieurs applications ;
    • permet de personnaliser la marque sur l'écran de consentement ;
    • autorise l'accès aux 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 :

  • Il réduit la charge administrative liée à la gestion de plusieurs clients.
  • Il simplifie l'activation d'IAP pour les membres de l'équipe qui ne devraient pas avoir accès à la page "Identifiants".
  • Il facilite l'accès par programmation (sans 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 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 par programmation afin d'autoriser les applications sans navigateur à s'authentifier auprès de 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 que l'utilisateur ait besoin de se connecter de manière interactive.

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 par programmation 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 gcloud iap settings set commande :

    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 (ne s'applique pas à 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 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 (ne s'applique pas à 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 par programmation.

Accès au navigateur

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

Risques

Le partage d'un client entre vos applications est pratique, mais 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 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 en termes 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 du client 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 limiter ce risque :

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

Pour l'accès par programmation aux ressources protégées par IAP, envisagez d'utiliser l'authentification JWT du compte de service au lieu de partager les codes secrets des clients 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 des autorisations. Pour IAP, openid et email sont les seuls champs d'application 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 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 champs d'application openid et email requis permet de limiter l'impact potentiel sur la sécurité.