Guide de Vérification Google OAuth (Sans CASA Tier 2)

Ce guide décrit le processus simplifié de vérification Google OAuth maintenant que le scope gmail.compose a été retiré. Plus besoin de CASA Tier 2 - la vérification est beaucoup plus simple !

📋 Vue d'ensemble

Avec seulement les scopes suivants :

• profile - Informations de profil de base
• email - Adresse email
• https://www.googleapis.com/auth/calendar.events.owned - Gestion des événements créés par l'application
• https://www.googleapis.com/auth/calendar - Création/gestion de l'agenda dédié "Aaperture" dans Google Calendar

Aucune validation CASA Tier 2 n'est requise car ces scopes ne sont pas considérés comme "restreints" ou "sensibles" par Google.

✅ Prérequis

1. Un compte Google Cloud Platform (GCP)
2. Un projet GCP créé
3. Google Calendar API activée dans le projet
4. OAuth 2.0 configuré

🚀 Étapes de Vérification

Étape 1 : Vérifier la Configuration OAuth

1. Accéder à Google Cloud Console

   • URL: https://console.cloud.google.com/
   • Sélectionner votre projet

2. Vérifier les APIs activées

   • Aller dans "APIs & Services" > "Library"
   • Vérifier que Google Calendar API est activée
   • ❌ Gmail API n'est plus nécessaire - vous pouvez la désactiver si elle était activée

3. Vérifier l'écran de consentement OAuth

   • Aller dans "APIs & Services" > "OAuth consent screen"
   • Vérifier que les informations sont complètes :
     • Nom de l'application
     • Email de support utilisateur
     • Email du développeur
     • URL de la politique de confidentialité
     • URL des conditions d'utilisation

Étape 2 : Vérifier les Scopes Demandés

1. Dans l'écran de consentement OAuth

   • Aller dans "Scopes"
   • Vérifier que seuls ces scopes sont listés :
     • profile
     • email
     • https://www.googleapis.com/auth/calendar.events.owned
     • https://www.googleapis.com/auth/calendar

2. Vérifier dans le code

   • Fichier: backend/src/auth/google-oauth.service.ts
   • Vérifier que requiredScopes contient :

     private readonly requiredScopes = [
       "profile",
       "email",
       "https://www.googleapis.com/auth/calendar.events.owned",
       "https://www.googleapis.com/auth/calendar",
     ];

Étape 3 : Tester en Mode "Testing"

Pour le développement et les tests :

1. Configurer l'application en mode "Testing"

   • Dans "OAuth consent screen", l'application doit être en mode "Testing"
   • Ajouter les emails des utilisateurs de test dans "Test users"

2. Limitations du mode Testing

   • Maximum 100 utilisateurs de test
   • L'écran d'avertissement "non vérifiée" s'affichera
   • Fonctionne pour le développement et les tests

Étape 4 : Soumettre pour Vérification (Production)

Quand vous êtes prêt pour la production :

1. Préparer la documentation

   • ✅ Politique de confidentialité (déjà mise à jour)
   • ✅ Conditions d'utilisation
   • ✅ Page d'accueil de l'application
   • ✅ Email de support fonctionnel

2. Soumettre pour vérification

   • Dans "OAuth consent screen", cliquer sur "PUBLISH APP"
   • Google va examiner votre application
   • Pas besoin de CASA Tier 2 car aucun scope restreint n'est utilisé

3. Temps de traitement

   • Généralement 1-2 semaines pour les applications sans scopes restreints
   • Google peut demander des clarifications si nécessaire

Étape 5 : Champs d'Application Sensibles

Question importante : "Vos champs d'application sensibles"

Réponse : Aucun champ sensible n'est utilisé

Avec les scopes actuels (profile, email, calendar.events.owned, calendar), votre application n'utilise aucun champ sensible selon les critères de Google.

Réponse recommandée :

Aucun champ sensible n'est utilisé. L'application utilise uniquement :
- Les scopes de base (profile, email) pour l'authentification
- Le scope calendar.events.owned qui donne accès uniquement aux événements de calendrier créés par l'application elle-même, pas à tous les événements du calendrier de l'utilisateur
- Le scope calendar qui est nécessaire pour créer, vérifier et gérer l'agenda dédié "Aaperture" dans le compte Google Calendar de l'utilisateur (il ne donne pas accès aux événements d'autres agendas que nous ne manipulons pas)

Pourquoi calendar.events.owned n'est PAS sensible :

• ✅ Accès uniquement aux événements créés par l'application
• ❌ Pas d'accès aux autres événements du calendrier
• ❌ Pas d'accès aux calendriers partagés
• C'est le scope le plus restrictif pour Calendar

Pourquoi le scope calendar est requis malgré tout :

• Nécessaire pour créer/mettre à jour un agenda Google (API calendars.insert/calendarList)
• Utilisé uniquement pour créer l'agenda "Aaperture" de l'utilisateur (un agenda séparé)
• Les événements restent limités à ceux créés par l'application via calendar.events.owned

📚 Voir le guide détaillé : [GOOGLE_OAUTH_SENSITIVE_FIELDS_GUIDE.md]../GOOGLE_OAUTH_SENSITIVE_FIELDS_GUIDE.md)

Étape 6 : Répondre aux Questions de Google (Si demandé)

Si Google pose des questions, voici les réponses types :

Question : "Pourquoi avez-vous besoin du scope calendar.events.owned ?"

Réponse :

Notre application permet aux photographes de gérer leurs séances photo. Nous utilisons le scope calendar.events.owned pour :

• Créer automatiquement des événements de calendrier pour les séances photo programmées
• Synchroniser les dates et heures des séances avec le calendrier Google de l'utilisateur
• Permettre aux utilisateurs de voir leurs séances dans leur calendrier Google

Nous utilisons uniquement le scope le plus restrictif (calendar.events.owned) pour les événements créés par notre application, pas à tous les événements du calendrier.

Question : "Pourquoi avez-vous besoin du scope https://www.googleapis.com/auth/calendar ?"

Réponse :

Nous devons créer un agenda dédié "Aaperture" dans le compte Google Calendar de chaque utilisateur pour séparer clairement les séances photo des autres événements. L'API Google Calendar exige le scope https://www.googleapis.com/auth/calendar pour créer, vérifier ou supprimer un agenda. Sans ce scope, nous ne pouvons pas créer cet agenda distinct et l'expérience utilisateur est dégradée. Ce scope n'est utilisé que pour ces opérations d'agenda, jamais pour lire les événements personnels des utilisateurs.

Question : "Comment protégez-vous les données utilisateur ?"

Réponse :

Nous implémentons plusieurs mesures de sécurité :

• Tous les tokens OAuth sont chiffrés avec AES-256-GCM avant stockage
• Les tokens sont isolés par utilisateur
• Nous ne partageons pas les données avec des tiers
• Conformité avec les politiques de confidentialité et de sécurité

Voir notre politique de confidentialité : [URL]

Question : "Quelles données stockez-vous ?"

Réponse :

Nous stockons uniquement :

• Tokens OAuth chiffrés (pour l'authentification API)
• Informations de profil de base (nom, email) obtenues via les scopes profile et email
• Métadonnées des événements de calendrier créés (pas le contenu complet)

Nous ne stockons pas :

• Le contenu des événements de calendrier
• Les emails de l'utilisateur
• D'autres données sensibles

📝 Checklist de Vérification

Avant de Soumettre

• Google Calendar API activée
• Gmail API désactivée (si elle était activée)
• OAuth consent screen configuré avec toutes les informations
• Seuls les scopes nécessaires sont demandés (profile, email, calendar.events.owned, calendar)
• Aucun champ sensible déclaré (réponse : "Aucun champ sensible")
• Politique de confidentialité mise à jour (sans références Gmail)
• Conditions d'utilisation mises à jour
• Page d'accueil accessible
• Email de support fonctionnel
• Application testée en mode "Testing"

Après Soumission

• Email de confirmation reçu de Google
• Statut de vérification suivi dans Google Cloud Console
• Réponses aux questions de Google (si demandées)
• Application approuvée et publiée

🔍 Vérification des Scopes dans le Code

Fichiers à Vérifier

1. backend/src/auth/google-oauth.service.ts

   private readonly requiredScopes = [
     "profile",
     "email",
     "https://www.googleapis.com/auth/calendar.events.owned",
     "https://www.googleapis.com/auth/calendar",
   ];

2. backend/src/google-calendar/google-calendar.controller.ts

   • Vérifier que le callback ne mentionne plus gmail.compose

3. Tests

   • Vérifier que les tests OAuth fonctionnent toujours
   • Vérifier que la connexion Google Calendar fonctionne

🎯 Avantages de cette Configuration

✅ Pas de CASA Tier 2 - Processus de vérification simplifié
✅ Pas de coûts d'audit externe - Économie de ~$1000+
✅ Vérification plus rapide - Généralement 1-2 semaines
✅ Moins de documentation requise - Pas besoin de documentation CASA complète
✅ Scopes non restreints - Pas de restrictions spéciales

📚 Ressources

• Google OAuth 2.0 Documentation
• Google Calendar API Documentation
• OAuth Consent Screen Guide

⚠️ Notes Importantes

1. Ne pas réactiver Gmail API - Si vous réactivez le scope gmail.compose, vous devrez repasser par CASA Tier 2
2. Tester avant de publier - Assurez-vous que tout fonctionne en mode "Testing" avant de publier
3. Maintenir la documentation - Gardez votre politique de confidentialité à jour
4. Surveiller les logs - Vérifiez qu'aucune erreur liée à Gmail n'apparaît

🆘 Dépannage

Problème : "Redirect URI mismatch"

• Vérifier que les URIs de redirection dans Google Cloud Console correspondent exactement à ceux utilisés par l'application
• Utiliser https:// même pour localhost (ou configurer GOOGLE_OAUTH_USE_HTTP_LOCALHOST=true)

Problème : "Scope not authorized"

• Vérifier que les scopes sont correctement configurés dans google-oauth.service.ts
• Vérifier que Google Calendar API est activée
• Vérifier que l'utilisateur est dans la liste des "Test users" (mode Testing)

Problème : "Application not verified"

• En mode "Testing", c'est normal - l'avertissement s'affichera
• Pour la production, soumettre l'application pour vérification
• Le processus prend généralement 1-2 semaines

Problème : Alerte de sécurité affichée alors que l'application est vérifiée

• Vérifier dans Google Cloud Console que l'application est bien en statut Publiée (OAuth consent screen → Publishing status).
• Pour les utilisateurs déjà connectés, définir GOOGLE_OAUTH_PROMPT=select_account dans le .env : l'écran de consentement complet n'est plus affiché à chaque connexion, ce qui réduit ou supprime l'alerte pour les utilisateurs récurrents. La première connexion peut encore afficher l'écran de consentement une fois.
• Important : cette variable s'applique uniquement au login principal (connexion à l'app). La connexion Google Calendar (Réglages → Connexions) utilise toujours prompt: "consent" pour garantir un refresh token ; les tokens Calendrier existants ne sont pas écrasés lors d'un login sans nouveau refresh token.

✅ Résultat Attendu

Une fois vérifiée, votre application :

• ✅ Sera visible pour tous les utilisateurs Google (pas seulement les test users)
• ✅ N'affichera plus l'avertissement "non vérifiée"
• ✅ Pourra être utilisée par un nombre illimité d'utilisateurs
• ✅ Fonctionnera avec Google Calendar sans restrictions

---

Variable d'environnement optionnelle : GOOGLE_OAUTH_PROMPT

• Valeur : consent (défaut) ou select_account.
• Effet : Contrôle le paramètre prompt de l'URL OAuth pour le login principal uniquement.
• select_account : limite l'affichage de l'écran de consentement pour les utilisateurs déjà autorisés (utile une fois l'app vérifiée).
• consent : affiche toujours l'écran de consentement (comportement par défaut).
• La connexion Google Calendar (Réglages → Connexions) ignore cette variable et utilise toujours consent pour obtenir un refresh token.

---

Dernière mise à jour : 2026-02
Statut : Application prête pour vérification Google OAuth (sans CASA Tier 2)