LinkedIn
Instagram
WhatsApp
Telegram
Gmail
Outlook
Google Agenda
Rejoindre la communauté SlackGoogle OAuth Limite de 100 utilisateursComment dépasser le plafond (2026)
Votre application a atteint la limite de 100 utilisateurs de test Google OAuth. L'autorisation échoue, les utilisateurs sont bloqués, et le piège de l'expiration à 7 jours aggrave la situation. Voici les 3 voies vers un nombre illimité d'utilisateurs - classées par rapidité et coût.
Quel est la limite de 100 utilisateurs de Google OAuth ?
Si votre application est en Test Le statut de publication sur l'écran de consentement OAuth, Google vous limite strictement à exactement 100 utilisateurs de test. Une fois ce nombre atteint, tout nouvel utilisateur tentant d'autoriser votre application reçoit une erreur. C'est la limite de 100 utilisateurs OAuth de Google - et elle surprend la plupart des développeurs en plein lancement.
Le Limite d'utilisateurs Google OAuth 100 (également appelé le " plafond d'utilisateurs OAuth ") limite les applications en mode test à un maximum de 100 utilisateurs autorisés. Il s'applique, quel que soit le nombre d'adresses électroniques d'utilisateurs de test que vous ajoutez à la console Google Cloud. Lorsque le plafond est atteint, les nouveaux utilisateurs ne peuvent pas terminer le flux OAuth : l'autorisation échoue immédiatement.
Le plafonnement empêche les applications non examinées d'accéder à des données utilisateur sensibles à grande échelle. Il oblige les développeurs à passer par le processus de vérification avant d'atteindre une utilisation de niveau production.
En Test statut : difficile plafond de 100 utilisateurs. En Production statut : le plafond est supprimé pour les étendues approuvées uniquement. Les étendues sensibles non approuvées restent plafonnées même en production.
Google Cloud Console - APIs et services - Écran de consentement OAuth - Onglet Public. La section "Utilisateurs de test" indique combien d'emplacements sur 100 sont utilisés.
La limite de 100 utilisateurs de Google OAuth apparaît dans la console sous **"Identifiants"** ou **"Écrans de consentement OAuth"**. Plus précisément, vous la trouverez généralement dans la section de configuration de votre écran de consentement OAuth. Lorsque vous accédez à cette section, vous pouvez voir les détails de votre projet et les restrictions associées à votre application, y compris les limites d'utilisation.
Naviguer vers API et services dans le menu de gauche, puis cliquez Écran de consentement OAuth.
Si votre application affiche Test Sous "Statut de publication", le plafond d'utilisateurs Google OAuth est actif. Vous êtes limité à 100 utilisateurs autorisés maximum.
Cliquer Public (anciennement appelé " Utilisateurs de test "). Ici, vous voyez les e-mails de vos utilisateurs de test ajoutés et le total cumulé par rapport à la limite de 100 utilisateurs.
Lorsque le plafond est atteint, les utilisateurs voient : "Cap d'utilisateurs OAuth atteint" ou "accès_refusé : cette application n'a pas été vérifiée". Les deux confirment que la limite de 100 utilisateurs de Google pour OAuth est en vigueur.
Pourquoi vous atteignez le plafond (même après vérification)
Le cap des utilisateurs Google OAuth n'est pas toujours causé par le mode test. Il existe 4 scénarios distincts qui déclenchent le cap, et savoir lequel s'applique à vous détermine la solution correcte. De nombreux développeurs sont surpris de constater que le cap persiste même après avoir terminé la vérification.
Votre application se trouve dans Test statut de publication. C'est la cause la plus fréquente de la limite de 100 utilisateurs pour l'authentification Google. Quelle que soit le nombre d'e-mails que vous ajoutez à la liste des utilisateurs de test, le nombre d'autorisations est plafonné à 100. La solution : passer en Production via la vérification de l'application.
Le plus courantPerspicacité critique : Même si votre application est en production, l'utilisation d'étendues sensibles (telles que la lecture/envoi d'e-mails Gmail, le calendrier, Drive) qui n'ont jamais été vérifiées réapplique le plafond d'utilisateurs OAuth. Le plafond est spécifique à l'étendue, pas seulement au statut. C'est pourquoi certaines applications vérifiées atteignent toujours le plafond d'utilisateurs OAuth de Google.
Souvent négligéVous avez soumis votre application pour vérification mais Google ne l'a pas encore approuvée. Le plafonnement reste fermement en place jusqu'à la fin de l'examen. Les examens de portée sensible prennent des semaines ; les portées restreintes nécessitant une évaluation CASA de niveau 2 peuvent prendre des mois. Aucune solution de contournement n'existe pendant cette période.
Jeu d'attenteVous étiez en production avec des périmètres approuvés, puis vous avez ajouté un nouveau périmètre sensible (par exemple, l'ajout d'un accès Gmail à une application qui n'utilisait auparavant que le profil de base). Le nouveau périmètre déclenche une nouvelle exigence de révision, et le plafond d'utilisateurs OAuth Google s'applique à nouveau aux utilisateurs autorisant l'ensemble de périmètres élargi jusqu'à l'approbation du nouveau périmètre.
Risque d'expansionLa recherche de "limite atteinte d'utilisateurs bien que vérifié" est une frustration courante pour les développeurs. La réponse est presque toujours le scénario 02 : l'application est vérifiée, mais les scopes spécifiques demandés ne faisaient pas partie de l'ensemble des scopes vérifiés. Le plafond de Google est granulaire : il s'applique par scope non approuvé, et non par application. Vérifiez votre liste exacte de scopes par rapport à votre lettre d'approbation de vérification.
Ignorer entièrement les 4 scénarios. Les identifiants pré-vérifiés d'Unipile signifient que vos utilisateurs n'atteindront jamais la limite de 100 utilisateurs Google OAuth, quels que soient les champs dont vous avez besoin.
Construire sans le bouchonLe piège caché de l'expiration de 7 jours
Il y a un deuxième problème qui rend la limite de 100 utilisateurs de Google OAuth encore pire pour les produits SaaS. Même si vos 100 créneaux ne sont pas tous occupés, les autorisations accordées par les utilisateurs de test expirent automatiquement après 7 jours. Cela signifie que vos utilisateurs doivent consentir à nouveau chaque semaine, ce qui interrompt complètement tout flux de travail de production.
La documentation de Google cache ceci : les jetons de rafraîchissement pour les applications en mode test sont automatiquement invalidés après 7 jours. Votre utilisateur a accordé l'accès lundi ? Le lundi suivant, votre application n'est plus autorisée. L'appel de rafraîchissement de votre jeton renvoie grant_invalide. L'utilisateur doit revenir à l'écran de consentement et ré-autoriser. Pour toute application gérant la synchronisation des e-mails, cela constitue un blocage complet.
L'utilisateur termine le flux OAuth. Jeton d'accès + jeton de rafraîchissement accordés. L'application fonctionne parfaitement.
L'application actualise le jeton d'accès à l'aide du jeton d'actualisation. Aucune action de l'utilisateur n'est nécessaire. Semble stable.
Le renouvellement du jeton fonctionne toujours. Demain, tout tombera en panne. Aucun avertissement à l'utilisateur ou au développeur.
La réinitialisation du jeton échoue avec grant_invalide. L'utilisateur est effectivement déconnecté. Doit donner son consentement à nouveau.
Les applications synchronisant Gmail ou Outlook perdent l'accès après 7 jours. La synchronisation historique peut se déclencher à nouveau à partir de zéro, provoquant des doublons de données et des utilisateurs confus.
Il n'y a pas d'e-mail ni de notification à l'utilisateur. L'application commence simplement à échouer lors des appels d'API. Les utilisateurs découvrent le problème lorsqu'une fonctionnalité cesse de fonctionner, et non avant.
Les utilisateurs sont redirigés vers l'écran de consentement de Google chaque semaine. Cela détruit la rétention. La plupart des utilisateurs ne réautoriseront pas. Perte d'utilisateurs directement causée par la limite d'utilisateurs de test OAuth de Google.
En bref : L'ajout d'utilisateurs de test à votre limite de 100 utilisateurs Google OAuth est une solution de contournement temporaire, pas une solution. L'expiration de 7 jours rend impossible l'exécution de toute charge de travail de production réelle avec des identifiants en mode test. Les trois solutions valables sont : achever la vérification Google, passer à des scopes non sensibles, ou utiliser un fournisseur avec des identifiants pré-vérifiés. Nous abordons les trois en détail ci-dessous.
Comment ajouter des utilisateurs de test à Google OAuth
Avant de chercher une solution permanente, vous devrez peut-être ajouter des utilisateurs de test à Google OAuth pour débloquer des personnes spécifiques pendant le développement. Voici le processus exact - ainsi que les mises en garde critiques qui signifient que ce n'est jamais une véritable solution pour les applications de production.
Aller à console.cloud.google.com et sélectionnez le projet auquel appartiennent vos identifiants OAuth. Assurez-vous d'être dans le bon projet, celui où votre ID client OAuth 2.0 a été créé.
Dans la barre latérale gauche : API et services puis cliquez Écran de consentement OAuth. Si vous ne voyez pas cette option, assurez-vous que l'API Google+ ou l'API appropriée est activée dans votre projet.
Dans les paramètres de l'écran de consentement OAuth, trouvez le Public onglet (précédemment intitulé " Utilisateurs de test " dans les anciennes versions de la console). C'est ici que la limite de 100 utilisateurs de Google OAuth est gérée. Vous verrez votre statut de publication actuel et le nombre d'utilisateurs de test.
Voir aussi : Guide complet de la configuration de l'écran de consentement Google OAuth
Sous la section " Utilisateurs de test ", cliquez sur + AJOUTER DES UTILISATEURS bouton. Une boîte de dialogue apparaît où vous pouvez saisir des adresses e-mail. Vous devez utiliser les adresses e-mail exactes de votre compte Google (comptes gmail.com ou Google Workspace).
Entrez une ou plusieurs adresses électroniques (vous pouvez coller une liste). Cliquez Ajouter, puis Économiser. Les utilisateurs sont désormais autorisés à terminer votre flux OAuth même lorsque l'application est en statut de test. Ils verront l'écran d'avertissement "application non vérifiée" mais pourront continuer.
Vérification Google - Le Chemin Officiel
La manière canonique d'augmenter la limite d'utilisateurs Google OAuth est de terminer le processus de vérification. Une fois approuvée, la limite de 100 utilisateurs est supprimée pour vos champs d'application vérifiés, et les autorisations n'expirent plus après 7 jours. C'est la bonne approche si vous avez besoin de vos propres identifiants Google à long terme, mais ce n'est pas rapide.
Remplissez intégralement l'écran de consentement OAuth. Indiquez clairement l'URL de votre page d'accueil, votre politique de confidentialité et vos conditions d'utilisation. Précisez exactement les champs d'application dont votre application a besoin et expliquez pourquoi chacun d'entre eux est nécessaire. Les formulaires incomplets constituent la principale cause de rejet.
Cliquez sur " Publier l'application " sur l'écran de consentement OAuth pour déclencher la vérification. Google vous enverra un e-mail avec les prochaines étapes. Pour les champs d'application de base (e-mail, profil), l'examen est automatisé. Pour les champs d'application sensibles (Gmail, Agenda, Drive), un examen manuel commence.
Pour des scopes comme gmail.lecture seule, calendrier.événements, ou les champs d'accès Drive, l'équipe de Google évalue manuellement votre application. Attendez-vous à des échanges d'e-mails, des vidéos de démonstration et des documents justificatifs. Cela peut prendre 4 à 6 semaines.
Pour les périmètres restreints (envoi via Gmail, accès complet au compte), vous devez passer par une évaluation de sécurité CASA de niveau 2. Des évaluateurs agréés par Google vérifient la sécurité de votre application. L'auto-évaluation via la défense des applications de niveau 2 est gratuite, mais prend beaucoup de temps. Les évaluateurs tiers coûtent entre 1 415 et 1 475 000 USD.
| Type de portée | Exemples | Temps de révision | Coût | Casquette retirée ? |
|---|---|---|---|---|
| Non-sensible | courriel, profil, openid | Automatique (instantané) | Gratuit | Oui (Production) |
| Sensible | Gmail en lecture seule, Calendrier lecture | 4-6 semaines (manuel) | Gratuit | Oui (si approuvé) |
| Accès restreint | Accès complet à Gmail, envoyer | 2-6 mois (CASA Tier 2) | $0-$75k | Oui (si approuvé) |
Restreindre aux scopes non sensibles - La Solution de contournement
Certaines applications peuvent supprimer la limite de 100 utilisateurs de Google OAuth sans passer par la vérification en limitant leurs demandes de portée à des portées non sensibles uniquement. C'est la voie la plus rapide vers un nombre illimité d'utilisateurs, mais cela se fait au détriment de la possibilité de lire ou d'écrire des données Gmail, Calendar ou Drive.
| Portée | Données consultées | Sensibilité | Vérification ? | Chapeau appliqué ? |
|---|---|---|---|---|
| openid | Identité de l'utilisateur | Non-sensible | Pas nécessaire | Sans mentir |
| l'email | Adresse courriel uniquement | Non-sensible | Pas nécessaire | Sans mentir |
| profil | Nom, photo | Non-sensible | Pas nécessaire | Sans mentir |
| gmail.lecture seule | Lire tout le contenu de l'e-mail | Sensible | Requis | Cas s'applique |
| gmail.envoyer | Envoyer un e-mail en tant qu'utilisateur | Accès restreint | CASA Niveau 2 | Cas s'applique |
| gmail.modifier | Lire/écrire tous les e-mails | Accès restreint | CASA Niveau 2 | Cas s'applique |
| calendrier.événements | Lire/écrire des événements de calendrier | Sensible | Requis | Cas s'applique |
Si votre application n'a besoin que d'identifier l'utilisateur (SSO, "Se connecter avec Google"), en utilisant openid email profil donne des utilisateurs illimités sans aucune vérification. Parfait pour les flux d'authentification où vous n'avez pas besoin d'accéder au contenu des e-mails.
Si votre produit lit ou envoie des e-mails Gmail, synchronise des événements de calendrier ou accède à des fichiers Drive, il n'y a pas d'échappatoire aux scopes sensibles. La limitation des scopes non sensibles n'est pas une option viable pour la synchronisation des e-mails, l'enrichissement CRM ou les applications de planification de calendrier.
gmail.lecture seule, ce qui constitue une portée sensible nécessitant une vérification. Voir le document complet Guide des étendues de l'API Gmail Pour la ventilation complète des portées qui nécessitent quel niveau d'approbation. Si vous avez besoin d'un accès par e-mail sans attendre la vérification, l'option 3 (ci-dessous) est votre seule véritable alternative.
Utiliser un fournisseur OAuth pré-vérifié - Le raccourci
Le moyen le plus rapide de supprimer complètement la limite de 100 utilisateurs de Google OAuth est d'utiliser un fournisseur qui a déjà terminé la vérification de Google et l'évaluation CASA de niveau 2 avec ses propres identifiants. Au lieu d'attendre des semaines ou des mois, vos utilisateurs peuvent s'autoriser immédiatement sans limite, sans expiration de 7 jours et avec un accès complet aux API Gmail et Calendar dès le premier jour.
Le fournisseur géré utilise ses propres identifiants Google pré-vérifiés. Sa vérification couvre toutes les étendues Gmail et Agenda. Vos utilisateurs s'autorisent par rapport à des identifiants qui n'avaient pas de plafond de 100 utilisateurs et n'en ont jamais eu.
Les identifiants vérifiés par la production émettent des jetons de rafraîchissement avec une expiration standard (en mois, pas en jours). Les utilisateurs n'ont jamais besoin de consentir à nouveau chaque semaine. La synchronisation Gmail s'exécute en continu sans interruption.
Une fois votre propre vérification terminée, migrez vers vos propres identifiants Google sans aucune interruption de service. Aucune réauthentification requise pour vos utilisateurs. Coût de migration nul.
Comment connecter les comptes Gmail avec Unipile (sans limite, sans attente)
Inscription à tableau de bord.unipile.com/inscription et obtenez votre clé d'API. Prend moins de 2 minutes. Pas de carte de crédit requise pour l'essai.
Appel POST /v1/comptes avec "fournisseur": "GOOGLE_OAUTH" et "utiliser les identifiants unipile": true. Unipile gère le flux OAuth avec ses identifiants certifiés CASA Tier 2. Pas de limite de 100 utilisateurs. Voir Documentation Google OAuth Unipile pour la référence API complète.
Une fois le compte lié, appelez GET /v1/emails pour lire des messages ou POST /v1/emails à envoyer. Vous avez un accès complet à Gmail dès le premier appel API. Explorez Guide de l'API e-mail pour tous les points d'accès disponibles.
Lorsque votre vérification Google sera terminée (quelques semaines ou mois plus tard), mettez à jour le compte de liaison pour utiliser vos propres identifiants OAuth. Les comptes de liaison existants continuent de fonctionner. Vos utilisateurs ne remarqueront jamais la transition. Voir la démarche complète Guide d'intégration de Google OAuth pour les étapes de migration des identifiants.
Des semaines de vérification.
Utilisez La clé d'Unipile et commencez maintenant.
Ne perdez pas de clients en attendant les avis de Google. Connectez les comptes Gmail en 5 minutes grâce à nos identifiants développeur pré-vérifiés. Zéro limite de 100 utilisateurs Google OAuth, jamais.
3 façons de dépasser le plafond d'utilisateurs de Google OAuth
Voici une comparaison honnête des trois méthodes pour supprimer la limite de 100 utilisateurs de Google OAuth. Choisissez en fonction de votre calendrier, de votre budget et de la nécessité d'accéder à Gmail ou au calendrier.
| Fonctionnalité | Option 1 : Vérification Google | Option 2 : Portées non sensibles | Option 3 : Fournisseur géré (Unipile) |
|---|---|---|---|
| Il est temps d'avoir des utilisateurs illimités | 4 semaines à 6 mois | Instant | Moins de 5 minutes |
| Coût | De $0 à $75 000 (évaluation CASA) | Gratuit | Par abonnement |
| Accès Gmail/Calendrier | Accès complet (si approuvé) | Non, authentification basique uniquement | Accès complet immédiat |
| Problème d'expiration de 7 jours | Résolu après approbation | Sans objet | Jamais d'expiration |
| Effort du développeur | Très élevé (docs, critiques, CASA) | Aucun (restreindre uniquement les étendues) | Un appel API |
| Identifiants personnels | Oui, | Oui, | Initialement partagé, changer plus tard |
| Meilleur pour | Applications nécessitant la pleine propriété du flux OAuth à long terme | Applications d'authentification uniquement qui n'ont pas besoin de contenu d'e-mail/calendrier | Produits SaaS qui ont besoin d'un accès Gmail dès le premier jour |
Si vous construisez un produit à long terme et que vous avez besoin d'un contrôle total sur le flux OAuth, la vérification est l'objectif final approprié, mais planifiez le calendrier.
Si votre application a seulement besoin d'identifier les utilisateurs (sans lire leurs e-mails), les champs d'autorisation non sensibles contournent le plafond sans aucun travail supplémentaire.
Si vous avez besoin d'un accès à Gmail ou au Calendrier et que vous ne pouvez pas attendre des mois, les identifiants pré-vérifiés d'Unipile suppriment immédiatement le plafond d'utilisateurs de Google OAuth.
Erreurs courantes liées aux casquettes et leurs solutions
La limite de 100 utilisateurs de Google OAuth apparaît dans plusieurs messages d'erreur différents, selon l'étape du processus où le plafond est atteint. Voici les 4 erreurs les plus courantes – avec la cause exacte et la solution pour chacune.
Le plafond strict de 100 utilisateurs autorisés a été atteint. Vu par les utilisateurs qui tentent d'autoriser votre application alors qu'elle est en mode Test et que 100 utilisateurs ont déjà terminé le flux OAuth.
Votre application est en production, mais vous rencontrez toujours des erreurs liées aux limites. Cela se produit lorsque vous demandez des champs d'application qui n'étaient pas inclus dans l'approbation initiale de votre vérification. La limite s'applique champ d'application par champ d'application.
Un utilisateur essaie d'autoriser mais reçoit un message d'erreur d'accès refusé, même si le quota n'est pas entièrement atteint. Habituellement, l'e-mail de l'utilisateur n'est pas dans la liste des utilisateurs de test, ou vous avez dépassé le nombre de 100 utilisateurs de test.
Votre application fonctionnait, et maintenant les rafraîchissements de jetons échouent avec grant_invalide. Ceci est le piège de l'expiration de 7 jours pour les applications en mode test. Le jeton d'actualisation a été révoqué automatiquement par Google après 7 jours.
grant_invalide et redirige l'utilisateur.Google OAuth 100 utilisateurs limite - FAQ
Réponses aux questions les plus fréquentes concernant le plafond d'utilisateurs de l'authentification Google (OAuth), comment ajouter des utilisateurs de test à l'authentification Google, et comment dépasser la limite.
Le Limite d'utilisateurs Google OAuth 100 une restriction s'applique aux applications en statut de publication de test sur l'écran de consentement OAuth. Lorsque votre application est en mode Test, un maximum de 100 utilisateurs peuvent l'autoriser. Une fois ce nombre atteint, les nouveaux utilisateurs reçoivent un accès_refusé erreur et ne peut pas terminer le flux OAuth. Ce plafond utilisateur google oauth existe pour empêcher les applications non examinées d'accéder à des données utilisateur sensibles à grande échelle. Voir notre guide complet sur Google OAuth pour le processus de vérification complet.
À ajouter des utilisateurs de test à Google OAuth1) Accédez à la console Google Cloud. 2) Accédez à API et services puis Écran de consentement OAuth. 3) Cliquez sur le Public tab. 4) Cliquer Ajouter des utilisateurs. 5) Entrez les e-mails du compte Google et enregistrez. Remarque : la liste maximale est de 100 e-mails, et la limite de 100 utilisateurs pour Google OAuth suit les autorisations réelles et non les e-mails simplement listés. Voir guide d'écran de consentement pour les détails complets de la configuration.
Google invalide automatiquement les jetons d'actualisation des applications dans Mode test après 7 jours. Ceci est une mesure de sécurité pour empêcher les accès de longue durée par des applications non vérifiées. Après 7 jours, les appels de rafraîchissement de jetons renvoient grant_invalide, et les utilisateurs doivent se réautoriser. Cela rend le mode Test totalement inadapté à tout flux de travail SaaS de production qui nécessite un accès continu. Passer à la production via la vérification, ou utiliser des identifiants de fournisseur pré-vérifiés, résout ce problème de manière permanente.
Oui, vous pouvez augmenter la limite d'utilisateurs d'authentification Google en complétant le processus de vérification de Google et en passant au statut de production. Une fois approuvé, le plafond de 100 utilisateurs est levé pour vos scopes et tokens vérifiés, qui n'expirent plus chaque semaine. Alternativement, l'utilisation des identifiants pré-vérifiés d'Unipile vous donne immédiatement un nombre illimité d'utilisateurs sans attente. La limite de 100 utilisateurs de Google OAuth ne peut pas être augmentée en mode test, 100 est une limite absolue stricte.
Le le plafond d'utilisateurs Google OAuth est supprimé après vérification pour les étendues approuvées uniquement. Si votre application demande des autorisations qui n'étaient pas incluses dans l'approbation de vérification initiale, le plafond s'applique à nouveau pour ces autorisations non approuvées. C'est pourquoi certains développeurs voient le message "oauth user cap reached" même après avoir été vérifiés : ils ont ajouté une nouvelle autorisation (comme une autorisation Gmail à une application initialement vérifiée uniquement pour Gmail) sans faire approuver la nouvelle autorisation. Faites toujours correspondre exactement votre demande OAuth à votre liste d'autorisations approuvées.
Il y a 3 façons de supprimer le plafond d'utilisateurs de Google OAuth: (1) Vérification complète - soumettez votre application à l'examen de Google, obtenez le statut de production (4 semaines à 6 mois). (2) Utiliser uniquement des champs d'application non sensibles - restreindre à openid, email, profile (pas d'accès à Gmail/Calendrier, mais sans limite). (3) Utilisez les identifiants pré-vérifiés d'Unipile - Connectez les comptes Gmail immédiatement avec nos clés certifiées CASA Tier 2. Sans limite, sans expiration de 7 jours, accès complet à Gmail dès le premier appel API.
Portées non sensibles ne nécessitant aucune vérification et sans limite d'utilisateurs : openid, l'email, profil. Celles-ci vous donnent uniquement des informations d'identité. Toute portée accédant au contenu de Gmail (gmail.lecture seule, gmail.envoyer), Calendrier (calendrier.événements), ou Drive est sensible ou restreint et nécessite une vérification. Voir la Guide des étendues de l'API Gmail pour l'analyse complète de la sensibilité de la portée. Pour les applications qui ont besoin du contenu des e-mails, il n'y a pas d'alternative à la vérification ou à l'utilisation d'un fournisseur pré-vérifié.
Chronologie de vérification Google OAuth dépend du type de portée : les portées non sensibles (e-mail, profil) sont approuvées automatiquement instantanément lorsque vous publiez l'application. Les portées sensibles comme la lecture seule de Gmail ou les événements du calendrier prennent 4 à 6 semaines pour un examen manuel par l'équipe de Google. Les champs d'application restreints tels que gmail.envoyer ou un accès complet à Gmail nécessite un Évaluation de sécurité CASA de niveau 2 Ce processus prend entre 2 et 6 mois et peut coûter entre 1 400 TP (en libre-service) et 175 000 TP (évaluateur tiers). Prévoyez en conséquence et utilisez des identifiants provisoires pendant la durée de la vérification.
Non. La limite de 100 utilisateurs de Google OAuth en mode test est une limite stricte et absolue. - il ne peut être augmenté en mode Test par aucun moyen. Google n'offre aucune exception, mise à niveau ou solution de contournement pour cette limite en mode Test. La seule façon de dépasser 100 utilisateurs autorisés est de passer au statut Production via la vérification, ou d'utiliser des identifiants pré-vérifiés auprès d'un fournisseur comme Unipile. Il n'existe aucune option payante ni de remplacement manuel pour augmenter le plafond en mode Test.
La façon la plus rapide de connecter des comptes Gmail illimités sans la limite de 100 utilisateurs OAuth de Google est d'utiliser API Gmail d'Unipile. Unipile utilise des identifiants Google pré-vérifiés, certifiés CASA Tier 2. Vous effectuez un appel API avec utiliser_les_identifiants_unipile: vrai et les utilisateurs peuvent autoriser immédiatement. Pas de limite de 100 utilisateurs, pas d'expiration de jeton de 7 jours, accès complet en lecture/envoi à Gmail dès le premier appel. Vous pouvez passer à vos propres identifiants Google vérifiés plus tard sans aucune réauthentification utilisateur. Voir la documentation complète de l'API pour commencer.
Vous avez encore des questions sur la limite de 100 utilisateurs pour Google OAuth ? Notre équipe est là pour vous aider.
FR 
EN 
ES 
DE 
IT 
BR 
NL 
PL 
TR