Aller au contenu

Configuration Google — SSO restreint au domaine serpe.fr

Ce document décrit les actions manuelles à réaliser dans la console Google Cloud Platform (GCP) et dans le dashboard Supabase pour activer la connexion « Continuer avec Google », restreinte aux comptes du domaine de l'agence.

Ces actions ne peuvent pas être automatisées par l'agent : elles nécessitent un accès humain aux consoles GCP et Supabase. Suivez les étapes dans l'ordre.

Prérequis

  • Un compte Google avec les droits nécessaires pour créer/gérer un projet GCP (idéalement un Google Workspace du domaine serpe.fr, pour pouvoir choisir un écran de consentement de type interne).
  • Accès admin au projet Supabase (voir docs/SETUP_SUPABASE.md).
  • L'URL du projet Supabase, sous la forme https://<project-ref>.supabase.co (le <project-ref> apparaît dans Project Settings > General du dashboard Supabase, et dans SUPABASE_URL).

Étape 1 — Créer/choisir un projet GCP

  1. Rendez-vous sur console.cloud.google.com.
  2. Créez un nouveau projet (ou réutilisez un projet existant dédié à Serpe).

Étape 2 — Activer l'API nécessaire

  1. Menu APIs & Services > Library.
  2. Recherchez Google Identity / Google People API (l'API OAuth de base est activée par défaut pour tout projet GCP ; l'important ici est surtout l'écran de consentement et l'identifiant client — voir étapes suivantes).
  3. Si vous prévoyez d'utiliser d'autres API Google (Drive, Vertex AI) pour le reste du projet Serpe, activez-les également ici, mais ce n'est pas requis pour le seul SSO.

Étape 3 — Configurer l'écran de consentement OAuth

  1. Menu APIs & Services > OAuth consent screen.
  2. Type d'utilisateur : choisissez Interne (« Internal »).
  3. Ce choix n'est disponible que si le projet GCP appartient à une organisation Google Workspace. Il garantit que seuls les comptes du Workspace peuvent apparaître dans l'écran de consentement Google — une première barrière, complémentaire à la vérification applicative (voir rappel de sécurité plus bas).
  4. Si vous n'avez pas de Workspace et devez utiliser le type Externe, la restriction de domaine repose alors entièrement sur le trigger PostgreSQL décrit plus bas : configurez-le sans faute.
  5. Renseignez le nom de l'application (ex. « Serpe — Gestion AO »), l'email d'assistance et l'email de contact développeur.
  6. Scopes : ajoutez les scopes suivants (scopes standards, non sensibles) :
  7. .../auth/userinfo.email
  8. .../auth/userinfo.profile
  9. openid
  10. Enregistrez.

Étape 4 — Créer l'identifiant client OAuth 2.0

  1. Menu APIs & Services > Credentials.
  2. Create Credentials > OAuth client ID.
  3. Type d'application : Web application.
  4. Nom : ex. « Serpe — Supabase Auth ».
  5. Authorized redirect URIs — ajoutez exactement : 
    https://<project-ref>.supabase.co/auth/v1/callback
    Remplacez <project-ref> par la référence réelle du projet Supabase (visible dans l'URL du dashboard, ex. rnxuwktlbyczulacznoy).
  6. Validez. Google affiche un Client ID et un Client Secret — copiez-les immédiatement, le secret ne sera plus affiché en clair ensuite.

Étape 5 — Brancher les identifiants dans Supabase

  1. Dashboard Supabase du projet Serpe > Authentication > Providers.
  2. Ouvrez Google, activez le provider.
  3. Collez le Client ID et le Client Secret obtenus à l'étape 4.
  4. Enregistrez.

À ce stade, le bouton « Continuer avec Google » de l'application (page app/pages/login.vue) fonctionne : il appelle supabase.auth.signInWithOAuth({ provider: 'google', options: { queryParams: { hd: 'serpe.fr', prompt: 'select_account' } } }).

Vertex AI (Gemini) — provider de génération

Gemini/Vertex AI est l'unique provider de génération du projet (server/utils/generation/providers/gemini.ts). Il utilise le même projet GCP que le SSO, mais un compte de service dédié.

  1. Menu IAM & Admin > Service Accounts > Create Service Account dans le même projet GCP.
  2. Attribuez-lui le rôle Vertex AI User (roles/aiplatform.user) — c'est le rôle minimal permettant d'appeler generateContent sur les modèles publiés (publishers/google/models/...).
  3. Créez une clé JSON pour ce compte de service (Keys > Add key > Create new key > JSON) et téléchargez-la.
  4. En local : enregistrez le fichier téléchargé sous service-account.json à la racine du projet (déjà ignoré par Git) et référencez-le via GOOGLE_APPLICATION_CREDENTIALS=./service-account.json dans .env — la librairie google-auth-library le détecte automatiquement.
  5. Sur Cloudflare Workers (pas de système de fichiers) : collez le contenu JSON complet du fichier, sur une seule ligne, dans GOOGLE_SERVICE_ACCOUNT_JSON (voir docs/SETUP_CLOUDFLARE.md).
  6. Région utilisée : europe-west4 (GOOGLE_CLOUD_LOCATION), à adapter si les modèles Gemini visés ne sont pas disponibles dans cette région.

Rappel de sécurité important

Le paramètre hd: 'serpe.fr' envoyé à Google est un filtre purement côté UX : il pré-sélectionne/suggère un compte du domaine dans l'écran de connexion Google, mais rien n'empêche techniquement un utilisateur de le contourner (URL modifiée, compte personnel, etc.) et d'obtenir malgré tout un token OAuth valide pour un email hors domaine.

La restriction réelle est appliquée côté base de données, par le trigger enforce_email_domain défini dans la migration supabase/migrations/0003_auth_config_triggers.sql :

  • Il s'exécute BEFORE INSERT (et BEFORE UPDATE OF email) sur auth.users.
  • Il lit le domaine autorisé dans app_config (clé allowed_email_domain, seedée à serpe.fr).
  • Si l'email ne se termine pas exactement par @<domaine autorisé>, l'insertion est rejetée (raise exception) — la création du compte échoue, quel que soit ce que Google a autorisé côté OAuth.

Consultez docs/SETUP_SUPABASE.md pour vérifier/ajuster la valeur de app_config.allowed_email_domain si le domaine réel diffère de serpe.fr.

Vérification

  1. Depuis l'application déployée (ou en local avec les variables d'env correctement renseignées), cliquez sur « Continuer avec Google ».
  2. Connectez-vous avec un compte @serpe.fr : la connexion doit réussir et un profil doit être créé automatiquement dans la table users (trigger provision_app_user, même migration).
  3. Testez avec un compte hors domaine (ex. Gmail personnel) : la création du compte doit être refusée côté base — l'utilisateur ne doit pas se retrouver connecté à l'application.