LinkedIn
Instagram
WhatsApp
Telegram
Google Agenda
Rejoindre la communauté SlackGoogle OAuth Vérification & Identifiants de l'API Gmail
Étape par étape : créez les identifiants OAuth de l'API Gmail, passez la vérification de l'application Google et l'examen de niveau 2 CASA - ou expédiez aujourd'hui avec la clé OAuth déjà certifiée d'Unipile et certifiez la vôtre plus tard.
// Ignorer complètement la configuration de Google Cloud.La clé OAuth certifiée d'Unipile s'en charge. const response = await fetch('https://api.unipile.com/api/v1/hébergé/comptes', { method: POST, headers : { 'X-API-KEY': process.env.UNIPILE_API_KEY, 'Content-Type': 'application/json' }, body: JSON.stringify({ type : 'Google', nom : 'utilisateur-123', expire le : '2026-12-31' })}); const { url } = await réponse.json();// Redirigez votre utilisateur vers `url` - terminé.Ce qu'est réellement la vérification OAuth de Google
La vérification de Google OAuth est le processus d'approbation formelle par lequel Google confirme que votre application traite les données des utilisateurs conformément à ses politiques. Tant que votre application n'a pas réussi cet examen, elle est considérée comme non vérifiée, ce qui signifie que les utilisateurs voient un écran d'avertissement et que vous êtes limité à 100 utilisateurs de test au maximum. L'examen est obligatoire chaque fois que votre application demande des étendues d'API Gmail sensibles ou restreintes à des utilisateurs externes (non-internes).
Portées sensibles : qu'est-ce que c'est
Les champs d'application sensibles permettent à votre application de lire ou de modifier des données utilisateur au-delà des informations de profil de base. Pour Gmail, ceux-ci incluent :
gmail.lecture seule- lire tous les messagesgmail.envoyer- envoyer un e-mail au nom de l'utilisateurgmail.modifier- lire, composer, archivermail.google.com- accès complet (restreint)
Les portées sensibles nécessitent une évaluation de sécurité Google. Les portées restreintes (comme l'accès IMAP complet) nécessitent en outre un audit CASA de niveau 2. Voir la référence complète des portées dans notre Guide des scopes de l'API Gmail.
Pourquoi l'API Gmail déclenche-t-elle toujours cela
Contrairement à un flux de connexion Google de base (qui ne demande que des données de profil), l'API Gmail demande toujours des étendues qui accordent l'accès au contenu de la boîte aux lettres d'un utilisateur. Google traite par définition toute autorisation au niveau de la boîte aux lettres comme sensible.
Cela signifie que tout développeur souhaitant utiliser l'API Gmail pour des utilisateurs externes doit passer par la vérification de l'application Google OAuth - il n'existe aucune version de l'API Gmail qui contourne cette exigence pour une utilisation en production.
Pas sûr que vous ayez besoin d'identifiants OAuth ou d'une simple clé API ? Lisez notre Clé API Gmail vs OAuth : guide.
Distinction clé : La vérification de Google OAuth n'est pas un événement unique. Si vous ajoutez de nouveaux champs d'application à une application déjà vérifiée, vous devez soumettre l'application à un nouvel examen couvrant ces champs d'application supplémentaires. Planifiez votre stratégie de champs d'application avant de commencer le processus - cela vous fera gagner des semaines.
Des semaines de vérification.
Utilisez La clé d'Unipile et commencez maintenant.
Ne perdez pas de clients en attendant les avis Google. Connectez les comptes Gmail en 5 minutes grâce à nos identifiants développeur pré-vérifiés.
Comment obtenir les identifiants de l'API Gmail : étape par étape
Obtenir les identifiants OAuth de l'API Gmail nécessite six étapes distinctes dans la Google Cloud Console. Voici la séquence complète – de la création de votre projet à la détention d'un identifiant fonctionnel client_id et secret_client.
- Créer un projet Google Cloud - votre conteneur isolé de facturation et d'API.
- Activer l'API Gmail - activez l'API dans la Bibliothèque d'API pour votre projet.
- Configurer l'écran de consentement OAuth - choisir le type d'application (externe vs interne), renseigner le nom de l'application, l'e-mail de support et les domaines autorisés.
- Ajouter des scopes - sélectionnez les scopes Gmail dont votre application a besoin; cela détermine si une révision de sécurité est requise.
- Créer un ID client OAuth - choisissez le type d'application (Web, bureau ou iOS/Android) et enregistrez vos URI de redirection.
- Soumettre pour vérification - si votre application est externe et utilise des scopes sensibles, soumettez-la via le portail de vérification de Google.
Aller à console.cloud.google.com, cliquez sur le sélecteur de projet dans la barre de navigation supérieure et sélectionnez " Nouveau projet ". Donnez-lui un nom qui reflète votre produit ; il apparaîtra sur l'écran de consentement OAuth que les utilisateurs voient.
Activez la facturation pour le projet, même si vous pensez ne pas dépasser les quotas gratuits. De nombreuses API (dont Gmail) exigent qu'un compte de facturation soit associé avant de pouvoir être activées, même en cas d'utilisation $0.
Console Google Cloud : créez un nouveau projet via le sélecteur de projets dans la barre de navigation supérieure.
Dans la console Google Cloud, accédez à "API et services" > "Bibliothèque". Recherchez "Gmail API" et cliquez sur "Activer". Vous souhaiterez probablement également activer l'API Google People si vous avez besoin de données de contact en plus des e-mails.
Après activation, l'API Gmail apparaît dans le tableau de bord des "APIs activées". Les appels à l'API sans informations d'identification valides renverront un 403 accèsNonConfiguré erreur même à ce stade - les identifiants arrivent ensuite.
Bibliothèque de l'API Google : recherchez "API Gmail" et cliquez sur Activer pour l'activer pour votre projet.
Accédez à "API et services" > "Écran de consentement OAuth". Choisissez votre type d'utilisateur :
- Interne - uniquement les utilisateurs au sein de votre organisation Google Workspace. Aucune vérification requise.
- Externe - tout compte Google. La vérification est requise pour les champs d'application sensibles/restreints au-delà de 100 utilisateurs de test.
Écran de consentement OAuth : choisissez Interne (réservé à votre espace de travail) ou Externe (tout compte Google) comme type d'utilisateur.
Remplissez le nom de l'application, l'adresse e-mail du support utilisateur et l'adresse e-mail de contact du développeur. Ces champs apparaissent sur l'écran de consentement que les utilisateurs voient lorsqu'ils autorisent votre application. Ajoutez votre domaine autorisé (le domaine de votre page d'accueil et de l'URL de votre politique de confidentialité).
Pour une présentation détaillée de chaque champ, du plafond de 100 utilisateurs et du choix Interne vs Externe, consultez notre Guide de configuration de l'écran de consentement.
Informations sur l'application : saisissez le nom de l'application, le logo et l'e-mail de support tels qu'ils doivent apparaître sur l'écran de consentement.
Domaine de l'application : fournissez les URL en direct de votre page d'accueil, de votre politique de confidentialité et de vos conditions d'utilisation. L'équipe d'examen de Google vérifie ces éléments.
Domaines autorisés : ajoutez le domaine racine de votre application. Seuls les URI provenant de ce domaine peuvent être utilisés comme URI de redirection.
Coordonnées du développeur : Google utilise cette adresse e-mail pour vous informer des changements concernant le statut de vérification de votre application.
Astuce : La section " Domaine de l'application " accepte plusieurs liens (Page d'accueil, Politique de confidentialité, Conditions d'utilisation). L'équipe de vérification de Google vérifiera que ces URL sont actives et reflètent les portées que vous demandez. Une URL de politique de confidentialité manquante ou incorrecte est l'une des raisons les plus courantes du rejet des vérifications.
Dans la configuration de l'écran de consentement, cliquez sur "Ajouter ou supprimer des portées". Utilisez le filtre pour trouver les portées Gmail. La portée que vous choisissez a un impact direct sur votre parcours de vérification :
gmail.envoyerougmail.lecture seule- sensible, nécessite une évaluation de sécurité.gmail.modifieroumail.google.com- restreint, nécessite en plus un CASA de niveau 2.openid email profiluniquement - aucune vérification nécessaire (connexion de base).
Ajouter ou supprimer des champs d'application : sélectionnez les champs d'application Gmail dont votre application a besoin. La sélection des champs d'application détermine directement votre parcours de vérification.
Planifiez soigneusement la sélection de la portée. L'ajout ultérieur d'une portée restreinte implique de soumettre à nouveau l'application entière pour un examen CASA de niveau 2 supplémentaire. Pour la référence complète de la portée et les API que chaque portée débloque, consultez notre Guide des scopes de l'API Gmail.
Allez dans "APIs et services" > "Identifiants" > "Créer des identifiants" > "ID client OAuth". Sélectionnez votre type d'application :
- Application web - pour les applications côté serveur. Enregistrez vos URI de redirection (par exemple.
https://yourapp.com/oauth/callback). - Application de bureau - pour les applications installées. Utilise la redirection en boucle locale.
- iOS / Android - applications mobiles, utilise des schémas d'URI personnalisés.
Panneau des identifiants : sélectionnez " ID client OAuth " pour générer le client_id et le client_secret dont votre application a besoin.
Après la création, téléchargez le fichier d'identifiants JSON. Il contient votre client_id, secret_client, et les URI de redirection enregistrés. Stockez-le en toute sécurité – ne le commettez jamais dans le contrôle de code source.
Pour une analyse approfondie de la différence entre ce type d'identifiant et une simple clé API, consultez notre Clé API Gmail vs guide des identifiants OAuth.
Jetons d'accès et jetons d'actualisation : quand un utilisateur termine le flux OAuth, vous recevez un jeton de courte durée access_token (valable environ 1 heure) et un token_rafraîchissement (de longue durée, stocké côté serveur). Votre serveur utilise le jeton de rafraîchissement pour obtenir de nouveaux jetons d'accès sans redemander à l'utilisateur. Toujours demander type_accès=hors_ligne et consentement lors de la première autorisation pour recevoir le jeton d'actualisation. Stockez les jetons d'actualisation cryptés au repos.
Pour une vision plus large de la façon dont OAuth s'intègre dans l'architecture des API de messagerie - y compris les stratégies de synchronisation et les différences entre les fournisseurs - consultez notre Guide de l'API OAuth pour les e-mails.
Utilisez la clé d'UnipileL'avertissement " Cette application n'est pas vérifiée ", le plafond de 100 utilisateurs et les exemptions
Avant que votre application ne passe la vérification de l'application Google OAuth, chaque utilisateur qui tente de l'autoriser voit un écran d'avertissement. Google impose également une limite stricte de 100 utilisateurs aux applications externes non vérifiées. Voici ce que cela signifie exactement et quand cela ne s'applique pas.
L'écran affiche : " Cette application n'est pas vérifiée. Cette application n'a pas été vérifiée par Google. Elle pourrait demander l'accès à des informations sensibles. En savoir plus sur les risques. " Les utilisateurs doivent cliquer sur " Avancé " puis sur " Accéder à [Nom de l'application] (non sécurisé) " pour continuer. La plupart des utilisateurs non techniques s'arrêteront ici – c'est le véritable coût d'une vérification ignorée ou retardée.
Quand la vérification des applications via Google OAuth n'est PAS requise
Usage interne uniquement
Si vous configurez votre écran de consentement OAuth sur "Interne" et que votre application ne sert que des utilisateurs au sein de votre propre organisation Google Workspace, aucune vérification n'est requise, quels que soient les champs que vous demandez. C'est la voie la plus rapide pour les outils internes.
Mode test (moins de 100 utilisateurs)
Une application externe non vérifiée peut avoir jusqu'à 100 utilisateurs de test ajoutés via la console Google Cloud. Ces utilisateurs spécifiques peuvent autoriser l'application sans voir de blocage strict : ils voient l'avertissement mais peuvent continuer. Utile pour le développement et les bêtas privées avec une petite équipe.
Portées de base uniquement
Si votre application ne demande que des étendues non sensibles (openid, email, profile - connexion Google de base), aucune vérification n'est nécessaire, même pour les utilisateurs externes, quelle que soit l'échelle. La vérification est déclenchée spécifiquement par les étendues sensibles et restreintes.
Cadre important : L'intention du plafond de 100 utilisateurs et de l'écran d'avertissement est de protéger les utilisateurs pendant que l'application est en cours d'examen. La réponse correcte à l'atteinte du plafond est de soumettre votre application à la vérification d'application Google OAuth – pas de créer plusieurs projets Google Cloud pour répartir les utilisateurs entre eux. Google interdit explicitement cette approche et cela peut entraîner la suspension de votre compte développeur. La voie conforme consiste soit à faire vérifier votre application, soit à utiliser une plateforme qui fournit déjà une clé OAuth vérifiée, telle qu'Unipile.
Vérification de l'application Google : calendrier et coût en 2026
La vérification des applications Google n'est pas un processus unique : elle comporte trois parcours distincts en fonction des champs d'application que votre application demande. Chaque parcours a son propre calendrier et son propre coût. Voici à quoi s'attendre en 2026.
Même si votre application n'utilise que des champs d'application non sensibles (connexion Google de base), Google peut tout de même exiger une vérification de la marque afin de confirmer l'identité de votre application et le domaine de sa page d'accueil. Ce processus prend généralement 2 à 3 jours ouvrables et n'entraîne aucun coût autre que le temps que vous y consacrez.
Vous devrez vérifier la propriété du domaine via la Google Search Console et vous assurer que votre écran de consentement OAuth décrit fidèlement votre application.
Les applications qui demandent des champs d'application Gmail sensibles doivent passer par l'évaluation de sécurité complète de Google. L'équipe de Google examine les pratiques de traitement des données de votre application, votre politique de confidentialité et la justification de chaque champ d'application que vous demandez.
Le délai de livraison habituel est 2-4 semaines Lorsque votre soumission est terminée. Les soumissions incomplètes (politique de confidentialité manquante, justifications de portée vagues, domaines autorisés incohérents) redémarrent le délai. Google peut demander une démo ou une documentation supplémentaire pendant cette période.
Applications demandant des étendues restreintes - principalement https://mail.google.com/ (accès complet au niveau IMAP) - doit remplir un Évaluation de sécurité CASA de niveau 2 En plus de l'examen de Google. CASA (Cloud Application Security Assessment) est un audit de sécurité indépendant mené par un laboratoire approuvé par Google.
En 2026, Google proposera un Parcours CASA de niveau 2 en libre-service via des laboratoires agréés, coûtant généralement $540-$1 000 (frais de laboratoire pour la numérisation automatisée). Ceci représente une amélioration significative par rapport au système existant. L'ancienne évaluation de sécurité manuelle précédemment requise par Google pour la même classe de portée coûtait 1 000 à 15 000 TP4T - 75 000 TP4T et a pris des mois - cette voie héritée s'applique toujours à certaines applications grand-père et à des cas limites d'entreprise. Lors de l'établissement du budget, vérifiez auprès du laboratoire choisi quelle voie s'applique à votre application.
Calendrier complet incluant l'examen de Google après CASA : 4-12 semaines de la première soumission à l'approbation.
Résumé des coûts : vérification des applications via Google OAuth en 2026
| Piste de vérification | Portée du niveau | Chronologie | Coût |
|---|---|---|---|
| Vérification de la marque | Non sensible (openid, email, profile) | 2-3 jours ouvrables | Gratuit |
| Évaluation de la sécurité | Sensible (gmail.send, gmail.readonly, gmail.modify) | 2-4 semaines | Gratuit |
| CASA Niveau 2 (libre-service, 2026) | Restreint (mail.google.com) | 4 à 8 semaines | ~$540-$1 000 |
| CASA Niveau 2 (manuel hérité, avant 2025) | Restreint (mail.google.com) | 8-12 semaines | $15k-$75k |
Sources : Règles relatives à Google OAuth 2.0 (developers.google.com) et Google Cloud - Présentation de la validation d'application OAuth (support.google.com). La tarification en libre-service CASA de niveau 2 est basée sur les tarifs de laboratoire approuvés au premier trimestre 2026 et peut varier en fonction du laboratoire et du nombre de périmètres d'application. L'ancienne grille tarifaire $15k-$75k s'appliquait aux applications ayant suivi le précédent programme obligatoire d'évaluation de la sécurité par un prestataire de Google avant que l'option en libre-service CASA ne soit disponible.
Sautez l'attenteErreurs Google OAuth courantes que vous rencontrerez
Lorsque vous gérez votre propre projet Google Cloud, une poignée d'erreurs reviennent constamment pendant le développement et après la mise en production. Voici un aide-mémoire pour les six plus courantes.
L'URI de redirection dans votre requête ne correspond pas exactement à l'un de ceux enregistrés dans Google Cloud Console (le protocole, la barre oblique finale et le port sont tous importants).
L'administrateur Google Workspace de l'utilisateur a bloqué les applications OAuth tierces ou restreint les champs d'application spécifiques demandés par votre application.
Votre application utilise des champs d'application sensibles ou restreints mais n'a pas terminé le processus de vérification de Google, par conséquent Google bloque le consentement pour les nouveaux utilisateurs.
Le jeton de rafraîchissement a expiré ou a été révoqué (l'utilisateur a changé de mot de passe, révoqué l'accès, ou le jeton est resté inactif pendant 6 mois). L'utilisateur doit se réauthentifier.
L'écran de consentement est mal configuré dans la console Google Cloud : type d'utilisateur incorrect (interne vs externe), utilisateurs de test manquants, ou l'application est encore à l'état de brouillon.
Une chaîne de portée contient une faute de frappe, ou l'API correspondante (par exemple, l'API Gmail) n'a pas été activée dans la console Google Cloud pour votre projet.
Avez-vous besoin du diagnostic complet ? Chacune de ces erreurs a une correction spécifique. Voir notre guide complet pour erreurs courantes Google OAuth et API Gmail et comment corriger chacune d'elles.
Lorsque l'OAuth est géré par Unipile, un intermédiaire technique indépendant agissant au nom de chaque utilisateur authentifié, ces erreurs sont gérées au niveau de l'API. Unipile est déjà certifié CASA Tier 2, les obstacles de vérification sont donc traités une fois, et non une fois par projet.
Des semaines de vérification.
Utilisez La clé d'Unipile et commencez maintenant.
Ne perdez pas de clients en attendant les avis Google. Connectez les comptes Gmail en 5 minutes grâce à nos identifiants développeur pré-vérifiés.
Google OAuth, simplifié : fait maison ou géré – expédier maintenant ou attendre des semaines ?
Si votre application a besoin d'un accès Gmail pour des utilisateurs externes, vous avez deux options : soit gérer votre propre projet Google Cloud et passer par le processus complet de vérification d'application OAuth de Google (6 à 12 semaines), soit vous appuyer sur une plateforme qui dispose déjà d'une clé OAuth certifiée CASA de niveau 2 (1 à 2 jours). Voici comment se déroule chaque option – et pourquoi elles ne s'excluent pas mutuellement.
La lecture stratégique : Le chemin DIY (Do It Yourself) est logique à long terme si vous souhaitez une propriété complète de votre marque OAuth et de votre écran de consentement. Le chemin géré (Unipile) est logique lorsque vous devez livrer rapidement, éviter le plafond de 100 utilisateurs ou reporter le coût de niveau 2 CASA. Ces chemins ne s'excluent pas mutuellement – vous pouvez développer sur Unipile aujourd'hui et effectuer votre propre certification en parallèle, puis passer à vos propres identifiants (Bring Your Own Credentials) lorsque votre application est vérifiée.
Si votre cas d'utilisation est limité à Workspace (outils internes, automatisation RH, sans consentement par utilisateur), l'alternative serveur à serveur est un compte de service avec délégation à l'échelle du domaine - consultez notre Compte de service Gmail et guide DWD.
Note de conformité : Unipile est un intermédiaire technique indépendant, non affilié, approuvé ou sponsorisé par Google. Le client OAuth Google d'Unipile est certifié CASA Tier 2, permettant à vos utilisateurs d'autoriser l'accès à Gmail sans voir l'avertissement "application non vérifiée". Il ne s'agit pas d'une solution de contournement pour l'examen de sécurité de Google : l'examen s'applique toujours si vous créez votre propre application Google Cloud ; Unipile l'a déjà passé pour les connexions qu'il négocie en votre nom. Les utilisateurs peuvent révoquer l'accès à tout moment via la page des autorisations de leur compte Google.
Testez maintenant sur Unipile's clé certifiée, certifier en parallèle, basculer lorsque prêt
Vous n'avez pas à choisir entre une expédition rapide et la propriété de vos identifiants Google. Unipile agit en tant qu'intermédiaire technique indépendant – son client OAuth Google est déjà certifié CASA Tier 2 – ainsi vos utilisateurs ne voient jamais l'avertissement d'application non vérifiée et il n'y a pas de limite de 100 utilisateurs. Exécutez votre propre vérification d'application Google en parallèle, puis basculez vers vos propres identifiants (Bring Your Own Credentials) à tout moment. Voici le parcours en 3 étapes.
Test sur la clé certifiée - expédition en quelques minutes
Créez un compte Unipile gratuit et générez une clé API. Utilisez le point de terminaison d'authentification hébergé pour générer une URL à lien unique pour chaque utilisateur. Redirigez votre utilisateur vers cette URL : l'écran de consentement Google OAuth d'Unipile (déjà certifié CASA Tier 2) se charge de l'autorisation. Votre utilisateur ne verra jamais s'afficher d'avertissement indiquant " application non vérifiée ".
Lorsque l'autorisation est terminée, Unipile envoie un webhook à votre serveur avec l'ID du compte lié. À partir de ce moment, votre application peut lire, envoyer et synchroniser Gmail via l'API unifiée d'Unipile - sans créer le moindre projet Google Cloud.
// Étape 1 : générer une URL d'authentification unique pour votre utilisateur
const res = await fetch('https://api.unipile.com/api/v1/hébergé/comptes', {
method: POST,
headers : {
'X-API-KEY': process.env.UNIPILE_API_KEY,
'Content-Type': 'application/json'
},
body: JSON.stringify({
type : 'Google',
nom : 'utilisateur-456', // votre identifiant utilisateur interne
expire le : '2027-01-01',
URL de notification : 'https://yourapp.com/webhooks/unipile'
})
});
const { url } = await res.json();
// Redirigez l'utilisateur vers `url` - l'écran de consentement certifié d'Unipile s'occupe du reste.Exécutez votre propre vérification Google OAuth en parallèle
Pendant que votre produit est en ligne et que les utilisateurs sont actifs, lancez la configuration de votre propre projet Google Cloud et soumettez votre application pour la vérification OAuth de Google. Suivez la procédure de configuration des identifiants en 5 étapes décrite ci-dessus. Si votre application utilise des champs d'application restreints, lancez votre évaluation en libre-service CASA de niveau 2 via un laboratoire agréé par Google.
Il y a pas d'urgence À ce stade, tant que vous utilisez la clé certifiée d'Unipile, vos utilisateurs ne sont pas bloqués, ils ne reçoivent aucun avertissement et il n'y a pas de limite du nombre d'utilisateurs. Menez ce processus au rythme qui convient à votre équipe : généralement 2 à 4 semaines pour les périmètres sensibles, et 4 à 12 semaines si le niveau 2 de la CASA est requis.
Pour des conseils sur la sélection de la portée, consultez notre Guide des scopes de l'API Gmail - choisir des portée minimales peut vous faire passer de la piste restreinte (requise par la CASA) à la piste sensible (examen gratuit), ce qui permet d'économiser du temps et de l'argent.
Passez à vos propres identifiants (BYOC) - un changement de configuration
Une fois que votre application Google Cloud a été vérifiée et que vous disposez de votre propre client_id et secret_client, configurez Unipile pour qu'il utilise vos propres identifiants OAuth lors de la connexion à de nouveaux comptes. Il s'agit du modèle « Bring Your Own Credentials » (BYOC) : Unipile continue de fonctionner comme un intermédiaire technique indépendant traitement des requêtes pour chaque utilisateur authentifié, en utilisant désormais vos identifiants vérifiés au lieu de la clé partagée.
Les comptes liés existants restent actifs. Le changement n'affecte que les nouvelles autorisations. Vos utilisateurs voient le nom de votre application vérifiée sur l'écran de consentement, remplaçant l'écran de marque Unipile. Vous avez choisi quand investir dans la vérification - pas dès le premier jour, quand vous aviez besoin de lancer.
Microsoft est différent : pourquoi Azure n'a pas besoin d'un examen de type CASA
Si votre application doit accéder à la fois à Gmail et à Outlook, la charge liée à la vérification est asymétrique. La vérification des applications via OAuth de Google – y compris un éventuel audit CASA de niveau 2 – ne s'applique qu'à Google. L'approche de Microsoft Azure en matière d'enregistrement des applications et de consentement OAuth est d'une architecture différente et ne nécessite pas d'audit de sécurité externe équivalent.
Toute application qui sollicite des autorisations Gmail sensibles ou restreintes auprès d'utilisateurs externes doit satisfaire à l'évaluation de sécurité de Google. Les autorisations restreintes nécessitent en outre la certification CASA de niveau 2.
- Avertissement d'application non vérifiée présenté aux utilisateurs
- Plafond de 100 utilisateurs difficiles jusqu'à vérification
- Certification CASA de niveau 2 requise pour les périmètres restreints (~$540-$1k en libre-service)
- Nouvel examen requis lors de l'ajout de nouveaux champs d'application sensibles
- Durée : entre 2 et 12 semaines ou plus, selon le niveau de complexité
Azure Active Directory (désormais Microsoft Entra ID) utilise un modèle de consentement administratif pour les périmètres de privilèges élevés. Il n'existe aucune exigence d'audit externe de type CASA pour les périmètres d'accès standard à la messagerie.
- Aucun avertissement concernant les applications non vérifiées pour les flux standard
- Pas de limite du nombre d'utilisateurs pendant la phase de développement
- Aucun audit de sécurité externe obligatoire
- Consentement de l'administrateur requis pour les autorisations à l'échelle du locataire dans les locataires d'entreprise
- Microsoft 365 couvre à la fois Outlook personnel et Exchange Online d'entreprise via le même flux OAuth
Implication pratique pour les applications multi-fournisseurs : Si vous développez un produit qui lit les e-mails des comptes Gmail et Outlook, le calendrier de vérification de votre application Google OAuth régit votre date de lancement, et non celui de Microsoft. C'est l'un des arguments les plus solides en faveur de l'API unifiée d'Unipile : les deux fournisseurs sont gérés via une intégration unique, et la clé certifiée d'Unipile couvre l'exigence CASA Tier 2 de Google d'emblée, la retirant ainsi entièrement de votre chemin critique.
Pour une analyse approfondie du côté Microsoft de l'équation, y compris l'enregistrement d'applications Azure, les flux de consentement et l'accès à l'API Microsoft Graph, consultez notre Guide OAuth de Microsoft Graph.
Comment Unipile gère vos données
Unipile est un intermédiaire technique indépendant. Les trois notes suivantes expliquent précisément comment les données circulent, ce qu'Unipile stocke, et quelles sont vos responsabilités en tant que client - dans le contexte de l'accès via Google OAuth et l'API Gmail.
Ce que Unipile stocke – et ce qu'il ne stocke pas
Unipile ne maintient aucune archive parallèle ni copie indépendante des données Gmail de vos utilisateurs. Lorsque votre application demande des données d'e-mails via l'API Unipile, Unipile les récupère à partir des serveurs de Google. au nom de l'utilisateur authentifié et le renvoie à votre application. Les données sont strictement limitées à la session de l'utilisateur authentifié et aux autorisations qu'il a accordées pendant le flux OAuth. Unipile ne conserve pas le contenu des messages au-delà de ce qui est nécessaire pour répondre à la réponse de l'API.
Intermédiaire technique indépendant - pas un partenaire Google
Unipile fonctionne en tant que intermédiaire technique indépendant, agissant pour le compte de chaque utilisateur authentifié qui a accordé l'accès via l'écran de consentement OAuth. Unipile est n'est ni affilié à Google, ni approuvé par Google, ni parrainé par Google. Unipile ne partage pas les identifiants entre les utilisateurs - chaque compte lié utilise ses propres jetons OAuth, limités à l'autorisation de cet utilisateur. Votre application n'accède aux données Gmail que pour les utilisateurs qui ont explicitement terminé le flux OAuth et accordé les autorisations demandées.
Les limites de débit de Google s'appliquent - les décisions d'utilisation vous appartiennent
Unipile relaie les limites de débit et les contraintes de quota de l'API Gmail de Google à votre application. L'API Gmail applique des quotas par utilisateur (par exemple, 250 unités de quota par seconde par utilisateur, 1 000 000 000 unités de quota par jour par projet). Unipile présente ces limites mais ne les remplace pas. Les décisions concernant la fréquence des requêtes, le volume de données et la portée du consentement de l'utilisateur restent une décision côté client. Vous êtes responsable de vous assurer que votre application respecte les conditions d'utilisation de l'API de Google et les attentes de vos utilisateurs telles qu'indiquées dans votre politique de confidentialité concernant l'utilisation des données Gmail.
Pour un aperçu complet des capacités de l'API de messagerie - y compris l'envoi, la lecture et la synchronisation sur Gmail, Outlook et IMAP - consultez notre Guide de l'API e-mail.
Construire avec UnipileFoire aux questions Google OAuth pour les développeurs
Réponses aux questions les plus fréquentes concernant la vérification des applications via Google OAuth, les identifiants de l'API Gmail et la gestion d'OAuth via Unipile.
Votre application doit être soumise à la vérification OAuth de Google si elle est configurée pour Externe l'utilisateur tape sur l'écran de consentement OAuth et demande des champs d'application Gmail sensibles ou restreints à des utilisateurs extérieurs à votre organisation Google Workspace. Si votre application ne demande que des champs d'application de base (openid, l'email, profil) ou est défini sur Interne, aucune vérification n'est requise. Toute étendue qui accorde l'accès à la boîte aux lettres d'un utilisateur, telle que gmail.lecture seule, gmail.envoyer, gmail.modifierou mail.google.com, est sensible ou restreint et déclenche la nécessité.
La chronologie dépend du niveau de portée que votre application utilise. Vérification de la marque (périmètres non sensibles) : 2-3 jours ouvrables. Examen du périmètre sensible (gmail.envoyer, gmail.lecture seule, gmail.modifier: généralement 2 à 4 semaines une fois votre soumission complète. CASA Niveau 2 + portées sensibles/restreintes (mail.google.com): 4-12 semaines au total. Les soumissions incomplètes, telles qu'une politique de confidentialité manquante, des justifications de portée vagues ou des domaines autorisés non concordants, relancent le processus.
La propre évaluation de sécurité de Google (pour les scopes sensibles tels que gmail.envoyer et gmail.lecture seule) est gratuit. La vérification de marque est également gratuite. Si votre application utilise des étendues restreintes (mail.google.com), vous avez besoin d'un audit CASA de niveau 2 par un laboratoire approuvé par Google. Le parcours autonome CASA de niveau 2 pour 2026 coûte environ de $540 à $1 000 en frais de laboratoire. L'évaluation manuelle héritée précédemment requise pour la même portée de cours coûtait $15 000 à $75 000 et cette piste hérité s'applique toujours à certains cas limites et applications existantes.
Vous ne pouvez pas contourner la vérification de l'application Google pour une application de production servant des utilisateurs externes avec des scopes Gmail sensibles. Le plafond de 100 utilisateurs et l'avertissement d'application non vérifiée s'appliquent jusqu'à ce que votre application soit vérifiée. Les alternatives conformes sont : régler votre application sur Interne (si cela ne sert qu'aux utilisateurs de votre propre espace de travail), utilisez Clé OAuth CASA certifiée de niveau 2 par Unipile tant que votre propre vérification s'exécute en parallèle, ou demandez uniquement des scopes non sensibles qui ne déclenchent pas de vérification. La création de plusieurs projets Cloud pour y répartir les utilisateurs est interdite par les politiques de Google et peut entraîner la suspension du compte.
Voir Le point d'accès de l'API Gmail géré par Unipile.L'avertissement "Application non vérifiée" de l'API Gmail apparaît lorsque votre écran de consentement OAuth est défini sur "Externe" et que votre application demande des champs d'application Gmail sensibles ou restreints mais n'a pas encore terminé le processus de vérification de Google. Il est affiché à tous les utilisateurs en dehors de votre liste de 100 utilisateurs de test. Pour le résoudre : soumettez votre application pour Vérification de l'application Google OAuth via la Google Cloud Console, ou en vous basant sur la clé OAuth pré-validée de niveau 2 certifiée CASA d'Unipile. Les utilisateurs se connectant via le flux d'authentification hébergé d'Unipile ne voient jamais cet avertissement.
CASA Niveau 2 (Évaluation de la sécurité des applications cloud) est un audit de sécurité indépendant requis par Google pour les applications qui demandent des étendues restreintes, principalement https://mail.google.com/, qui accorde un accès complet à Gmail au niveau IMAP. Il est mené par un laboratoire approuvé par Google. En 2026, une voie libre-service sera disponible à environ de $540 à $1 000. Vous n'avez besoin de CASA Tier 2 que si votre application demande le mail.google.com portée des utilisateurs externes. Si vous n'utilisez que des portées sensibles (gmail.envoyer, gmail.lecture seule, gmail.modifier), CASA Tier 2 n'est pas requis. L'évaluation de sécurité gratuite standard de Google s'applique à la place.
Une Clé API Gmail est destiné aux requêtes publiques, non spécifiques à l'utilisateur, et n'accorde pas l'accès à la boîte aux lettres d'un utilisateur. Identifiants OAuth pour l'API Gmail (client_id + secret_client) sont utilisés pour obtenir une autorisation par utilisateur d'accéder à leurs données Gmail en leur nom. Pour toute fonctionnalité qui lit, envoie ou modifie les e-mails d'un utilisateur, vous avez besoin d'identifiants OAuth, et non d'une clé API. Pour une comparaison détaillée, consultez notre Clé API Gmail vs OAuth : guide.
Vous avez encore des questions sur la vérification d'applications Google OAuth ou sur la gestion des e-mails Gmail OAuth ? Notre équipe est là pour vous aider.
Parler à un expert
FR 
EN 
ES 
DE 
IT 
BR 
NL 
PL 
TR