LinkedIn
Instagram
WhatsApp
Telegram
Google Agenda
Rejoindre la communauté SlackScopes de l'API Gmail expliqués : Choisissez celui qui Gérer les autorisations pour Votre Application
Chaque portée de l'API Gmail documentée : de gmail.lecture seule à mail.google.com. Comprenez les 3 niveaux de sensibilité, choisissez la portée minimale dont votre application a réellement besoin et accélérez votre flux OAuth.
// Demander les étendues des API Gmail dans le flux OAuth
const PORTÉES = [
'https://www.googleapis.com/auth/gmail.readonly',
'https://www.googleapis.com/auth/gmail.send',
'https://www.googleapis.com/auth/gmail.labels',
];
const authUrl = oauth2Client.générerURLAuthentification({
type_accès : 'hors ligne',
portée : SCOPES,
Veuillez fournir le texte que vous souhaitez traduire en français. 'consentement',
});Quels sont les scopes de l'API Gmail ?
Avant d'écrire la moindre ligne de code OAuth, vous devez comprendre ce que sont les champs d'application de l'API Gmail et pourquoi choisir le mauvais champ d'application peut empêcher votre application d'être mise en production. Cette section vous donne les connaissances fondamentales en moins de deux minutes.
Portées de l'API Gmail sont des chaînes d'autorisation OAuth 2.0 qui définissent exactement quelles ressources Gmail votre application peut accéder au nom d'un utilisateur. Lorsqu'un utilisateur autorise votre application, Google présente un écran de consentement listant les scopes de l'API Gmail que votre application a demandés. L'utilisateur accorde ou refuse l'accès en fonction de ces scopes. Une fois accordé, votre jeton d'accès est limité exactement aux actions autorisées par ces scopes, rien de plus.
Les champs d'application de l'API Gmail créent une limite stricte autour de ce que votre jeton peut faire. Même si votre serveur est compromis, un attaquant disposant d'un gmail.lecture seule le jeton ne peut pas envoyer ou supprimer d'e-mails. Les portées sont appliquées côté serveur par Google.
Les champs d'application Gmail API restreints exigent que votre application réussisse l'évaluation de sécurité de Google avant de pouvoir les utiliser en production avec plus de 100 utilisateurs de test. Un choix de champ d'application incorrect peut ajouter des semaines ou des mois à votre calendrier de lancement.
Demander plus de permissions de l'API Gmail que votre application n'en a besoin déclenche un avertissement "Cette application souhaite un accès étendu à votre compte Google". Des portées minimales de l'API Gmail produisent un écran de consentement plus simple, augmentant la conversion et la confiance des utilisateurs.
Ignorer entièrement la gestion du périmètre. Unipile gère l'authentification OAuth de Gmail et les champs d'autorisation en interne - votre équipe se concentre sur la logique produit, pas sur les chaînes d'autorisations.
Construisez-le avec UnipileLes 3 niveaux de sensibilité expliqués
Google classe toutes les étendues de l'API Gmail en 3 niveaux de sensibilité. Chaque niveau détermine les exigences de vérification avant que votre application ne puisse être mise en production. Comprendre cette classification est la décision la plus importante que vous prendrez lors de la planification de votre intégration Gmail.
Le niveau de risque le plus bas. Ces scopes accèdent à des données Gmail limitées et non personnelles. Google ne requiert pas d'évaluation de sécurité formelle pour les utiliser en production.
Niveau de risque moyen. Ces champs d'application accèdent aux données des messages Gmail susceptibles d'exposer des informations personnelles. Une vérification supplémentaire est requise avant l'utilisation en production.
Classe de risque la plus élevée. Ces champs d'application accordent un accès large ou sensible aux données Gmail. Google exige une évaluation formelle de la sécurité par un auditeur tiers approuvé.
| Critères | Non-sensible | Sensible | Accès restreint |
|---|---|---|---|
| Accéder au corps du message | Non | Parfois | Oui, |
| Évaluation de sécurité requise | Non | Non | Oui, |
| Examen de l'application requis | Oui, | Oui, | Oui, |
| Recertification annuelle | Non | Non | Oui, |
| Niveau d'avertissement de l'écran de consentement | Standard | Standard + divulgation | Avertissement d'accès général |
| Coût typique de vérification | Gratuit | Gratuit | ~1 TP4T500/an (évaluateur) |
Référence complète des champs d'application de l'API Gmail
La liste complète des étendues de l'API Gmail, regroupées par niveau de sensibilité. Utilisez ce tableau comme référence unique lors du choix des autorisations de l'API Gmail pour votre application. Les étendues marquées "2026" reflètent les derniers ajouts à la liste des étendues de Google.
| URI de portée | Niveau d'accès | Ce à quoi il accède | Quand l'utiliser |
|---|---|---|---|
| gmail.addons.current.action.compose | Non-sensible | Permet aux modules complémentaires de composer et d'envoyer des e-mails lors d'une action de composition. | Extensions Gmail qui rédigent ou envoient des e-mails au nom de l'utilisateur dans la fenêtre de composition |
| gmail.addons.current.message.action | Non-sensible | Permet aux modules complémentaires de consulter l'e-mail actuel lors d'une action de message | Extensions Gmail qui réagissent à une action sur un message (archivage, étiquetage) dans le contexte du message |
| libellés gmail 2026 | Non-sensible | Voir et modifier les étiquettes (créer, renommer, supprimer), mais pas le contenu des messages | Applications qui organisent les e-mails avec des étiquettes sans avoir besoin de lire le corps des messages |
| URI de portée | Niveau d'accès | Ce à quoi il accède | Quand l'utiliser |
|---|---|---|---|
| gmail.addons.current.message.metadata | Sensible | En-têtes et métadonnées d'e-mail (De, À, Objet, Date) dans le contexte d'un module complémentaire - pas le corps du message | Compléments qui affichent des informations contextuelles basées sur l'expéditeur ou l'objet sans lire le corps du message |
| gmail.addons.current.message.readonly | Sensible | Accès complet en lecture à l'e-mail actuel, y compris le corps et les pièces jointes, dans le contexte du module complémentaire | Extensions qui analysent ou extraient des données du message actuellement ouvert |
| gmail.envoyer | Sensible | Envoyer un e-mail au nom de l'utilisateur authentifié - aucun accès en lecture ou modification | Applications qui envoient uniquement des e-mails transactionnels ou de prospection et n'ont pas besoin de lire la boîte de réception |
| URI de portée | Niveau d'accès | Ce à quoi il accède | Quand l'utiliser |
|---|---|---|---|
| mail.google.com/ | Accès restreint | Accès complet à la boîte aux lettres : lire, composer, envoyer et supprimer définitivement les e-mails et les paramètres | Seulement lorsque vous avez besoin de toutes les capacités de Gmail dans un seul périmètre - généralement les intégrations existantes |
| gmail.lecture seule | Accès restreint | Accès en lecture seule à tous les messages, fils de discussion, étiquettes et paramètres - impossible d'envoyer ou de modifier | Outils d'analyse, d'archivage, de recherche ou d'intelligence électronique qui ne lisent que les données des boîtes de réception |
| gmail.rediger | Accès restreint | Créer et gérer des brouillons, et envoyer ces brouillons - aucun accès aux e-mails existants | Outils de gestion de brouillons, concepteurs d'e-mails ou applications qui mettent les e-mails en file d'attente avant de les envoyer |
| gmail.insérer 2026 | Accès restreint | Insérer des messages dans la boîte aux lettres Gmail uniquement - ne peut pas lire ou envoyer d'e-mails existants | Outils ou systèmes de migration qui importent les e-mails dans Gmail à partir de sources externes |
| gmail.modifier | Accès restreint | Lire, composer, envoyer et gérer des e-mails et des étiquettes - impossible de supprimer définitivement | Clients de messagerie complets, outils de synchronisation CRM, intégrations de helpdesk nécessitant lecture+envoi+étiquetage |
| gmail.metadata | Accès restreint | En-têtes et étiquettes uniquement - pas d'accès au corps des e-mails ou aux pièces jointes | Applications qui classent ou routent les e-mails en fonction des métadonnées sans lire le contenu privé |
| Paramètres de base de Gmail | Accès restreint | Gérer les paramètres de base de Gmail : filtres, règles de transfert, paramètres POP/IMAP | Outils de productivité pour courriel qui configurent le routage ou le filtrage de Gmail pour le compte des utilisateurs |
| gmail.paramètres.partage | Accès restreint | Gestion des paramètres sensibles : alias d'envoi, délégués, réponses d'absence (administrateur du domaine uniquement) | Outils d'administration de l'espace de travail uniquement - nécessite les privilèges d'administrateur du domaine pour activer |
Ne gérez pas ces champs d'application de l'API Gmail manuellement. L'intégration Gmail d'Unipile gère automatiquement les requêtes de portée OAuth, le rafraîchissement des jetons et les flux de réautorisation sur les comptes liés de vos utilisateurs.
Créez votre application GmailDe quel périmètre d'API Gmail avez-vous besoin ?
Le principe le plus important dans la sélection de la portée de l'API Gmail est le principe d'accès minimal : demandez uniquement les autorisations de l'API Gmail dont votre application a réellement besoin. Ce tableau associe les cas d'utilisation courants à la portée minimale recommandée, vous aidant ainsi à éviter une surcharge de vérification inutile et à protéger la confiance des utilisateurs.
| Cas d'utilisation | Portée minimale | Niveau de vérification | Notes |
|---|---|---|---|
| Envoyer des e-mails uniquement (ne pas lire la boîte de réception) | gmail.envoyer | Sensible | Idéal pour les outils transactionnels ou d'approche. Pas d'accès aux messages existants. |
| Lire la boîte de réception pour les analyses ou la recherche | gmail.lecture seule | Accès restreint | Accès complet en lecture à tous les messages et paramètres. Nécessite une évaluation annuelle de sécurité. |
| Client de messagerie complet (lire + envoyer + étiqueter) | gmail.modifier | Accès restreint | Préféré à mail.google.com/ car il exclut la suppression permanente. Couvre la plupart des cas d'utilisation des CRM et des helpdesks. |
| Archiver ou sauvegarder des courriels de manière permanente | mail.google.com/ | Accès restreint | À n'utiliser que lorsque vous avez vraiment besoin d'un accès de suppression. Déclenche l'avertissement de consentement Google le plus large. |
| Organiser les étiquettes uniquement | libellés gmail | Non-sensible | Nouveau en 2026. Permissions minimales pour la gestion des étiquettes sans lecture des messages. |
| Gestion des brouillons (file d'attente avant envoi) | gmail.rediger | Accès restreint | Accès aux brouillons et capacité d'envoi, mais aucun accès en lecture aux messages existants. |
| Routage ou catégorisation des métadonnées | gmail.metadata | Accès restreint | En-têtes et étiquettes uniquement - pas d'accès au corps. Idéal pour les moteurs de routage qui respectent la confidentialité des messages. |
| Migration / importation d'e-mails dans Gmail | gmail.insérer | Accès restreint | Nouveau en 2026. Accès en insertion uniquement - alternative mieux ciblée à mail.google.com/ pour les outils d'importation. |
| Configurer les filtres et le transfert de Gmail | Paramètres de base de Gmail | Accès restreint | Gérer les filtres, les étiquettes, les règles de transfert. Pas d'accès au corps des messages. |
| Module complémentaire Gmail : afficher le contexte de l'expéditeur | gmail.addons.current.message.metadata | Sensible | En-têtes uniquement dans le contexte du module complémentaire. Évite l'accès complet au message. |
Vous pouvez combiner plusieurs portées de l'API Gmail dans une seule requête OAuth (par exemple, gmail.envoyer + libellés gmail), mais chaque étendue ajoute à la divulgation de l'écran de consentement. Auditez toujours votre liste d'étendues avant de mettre en production. Si vous créez un produit de synchronisation Gmail complet, le Guide de l'API OAuth pour les e-mails couvre le flux complet, y compris la gestion des jetons et la réautorisation des portées.
Vérification de portée restreinte : ce que cela signifie pour votre application
Si votre application a besoin de l'une des scopes restreintes de l'API Gmail, y compris gmail.lecture seule, gmail.modifierou mail.google.com/ - vous devez terminer le processus d'évaluation de sécurité de Google avant de passer en production pour plus de 100 utilisateurs test. Voici à quoi ressemble ce processus et comment minimiser la charge de travail.
Créez un projet, activez l'API Gmail et configurez l'écran de consentement OAuth. Remplissez tous les champs requis : nom de l'application, e-mail de prise en charge, domaines autorisés et URL de la politique de confidentialité. Cette étape est requise pour tout niveau de périmètre de l'API Gmail.
Dans l'écran de consentement OAuth, cliquez sur " Préparer la vérification ". Déclarez chaque champ d'application de l'API Gmail restreint et fournissez une justification expliquant pourquoi votre application en a besoin. L'équipe de Google examine cela avant de vous orienter vers un évaluateur de sécurité.
Google confie les applications à portée restreinte à un évaluateur agréé (Leviathan Security, Coalfire, etc.). L'évaluation coûte environ 1 450 £ par an. Vous devez fournir une démonstration, expliquer vos pratiques en matière de traitement des données et passer avec succès un examen technique de votre implémentation OAuth.
La portée restreinte de l'API Gmail nécessite une recertification annuelle. Si vous manquez la fenêtre de renouvellement, Google peut révoquer l'accès de production de votre application. Prévoyez ce coût récurrent et ce cycle de conformité dès le premier jour de votre architecture d'intégration Gmail.
Choisir gmail.envoyer sur gmail.modifier lorsque votre application envoie uniquement des e-mails et n'a pas besoin de lire la boîte de réception. gmail.envoyer est une étendue sensible (non restreinte) et saute entièrement l'évaluation de sécurité.
Utilisez gmail.metadata au lieu de gmail.lecture seule si votre application route ou catégorise des e-mails sans lire le contenu du corps. Vous avez toujours besoin d'une vérification, mais le champ d'application est plus restreint et plus facile à justifier auprès de Google.
Utilisez une plate-forme qui détient déjà la vérification Google. Lorsque vous construisez sur Intégration Gmail d'Unipile, votre application bénéficie des identifiants OAuth pré-vérifiés d'Unipile, vous n'avez donc pas à passer vous-même par l'évaluation des périmètres limités. C'est la voie la plus rapide vers la production pour la plupart des produits SaaS.
Restez dans la fenêtre de test de 100 utilisateurs lors du développement initial. Vous pouvez tester des étendues limitées de l'API Gmail avec jusqu'à 100 comptes Google sans avoir à effectuer la vérification complète. Ajoutez des comptes de test dans les paramètres de l'écran de consentement OAuth de la Google Cloud Console.
Ignorer complètement le processus de vérification de Google. La connexion Gmail OAuth hébergée par Unipile est déjà vérifiée pour les champs d'application Gmail restreints. Vos comptes liés se connectent immédiatement sans évaluation supplémentaire.
Commencez à construire dès aujourd'huiComment demander des champs d'application Gmail dans votre flux OAuth
Une fois que vous savez quels scopes OAuth Gmail votre application nécessite, vous les déclarez lors de la génération de l'URL d'autorisation. Voici des exemples de code fonctionnels en Node.js et en Python montrant exactement comment transmettre les autorisations de l'API Gmail à l'écran de consentement OAuth.
// Node.js — Portées de l’API Gmail dans le flux OAuth
// Utilise google-auth-library (client officiel de Google)
const { OAuth2Client } = require('bibliothèque-d'authentification-google');
const oauth2Client = new OAuth2Client(
process.env.GOOGLE_CLIENT_ID,
process.env.GOOGLE_CLIENT_SECRET,
process.env.REDIRECT_URI
);
// Définir les portées de l'API Gmail dont votre application a besoin
// Principe : demander le périmètre minimum requis
const PORTÉES = [
'https://www.googleapis.com/auth/gmail.readonly', // restreint
'https://www.googleapis.com/auth/gmail.send', // sensible
'https://www.googleapis.com/auth/gmail.labels', // non-sensible
];
// Générer l'URL d'autorisation OAuth
const authUrl = oauth2Client.générerURLAuthentification({
type_accès : 'hors ligne', // requête de renouvellement de jeton
portée : PORTÉES,
Veuillez fournir le texte que vous souhaitez traduire en français. 'consentement', // forcer le consentement pour obtenir le jeton de rafraîchissement
});
console.log('Rediriger l'utilisateur vers :', url_authentification);
// Après que l'utilisateur ait autorisé, échanger le code contre des jetons
async function getTokens{
const { jetons } = await oauth2Client.jeton(code);
oauth2Client.définirLesIdentifiantsjetons ;
return jetons;
}# Python — Domaines d'application de l'API Gmail dans le flux OAuth
# utilise google-auth-oauthlib (bibliothèque officielle de Google)
from google_auth_oauthlib.flow import FluxApplicationInstallée
from google.oauth2.credentials import Indentifications
from google.auth.transport.requests import Requête
import système d'exploitation
# Définir les champs d'application de l'API Gmail : ne demandez que ce dont vous avez besoin
PORTÉES = [
'https://www.googleapis.com/auth/gmail.readonly', # (accès restreint)
'https://www.googleapis.com/auth/gmail.send', sensible au #
'https://www.googleapis.com/auth/gmail.labels', # non sensible
]
déf obtenir_les_identifiants_gmail():
identifiants = Aucun
# Charger le jeton existant s'il est disponible
si os.path.existe('token.json'):
crédits = Identifiants.depuis_fichier_utilisateur_autorise(
'token.json', PORTEES
)
# Actualiser ou demander de nouveaux identifiants
si non identifiants ou pas crédits.valides :
si identifiants et crédits expirés et crédits.actualiser_jeton:
identifiants.Actualiser(Requête())
sinon:
# : Afficher l'écran de consentement OAuth avec les champs d'application déclarés
flux = FluxInstallé.des_secrets_du_fichier_client(
'credentials.json', PORTEES
)
créds = flow.lancer le serveur local(port=0)
# : jeton de persistance pour les exécutions futures
avec ouvrir('token.json', 'w') comme jeton :
jeton.écriscrédits.to_json())
return identifiantsImportant : Le consentement' (Node.js) ou exécuter_serveur_local appeler (Python) force l'affichage de l'écran de consentement Google même si l'utilisateur a déjà autorisé. Ceci est requis pour obtenir de manière fiable un token_rafraîchissement. Sans jeton de rafraîchissement, votre jeton d'accès expire après 1 heure et les utilisateurs doivent ré-autoriser. Pour un guide complet sur la gestion du rafraîchissement des jetons et la ré-autorisation des portées, consultez le Guide de l'API OAuth pour les e-mails et le Documentation Google OAuth Unipile.
Principe de portée minimale et conformité
Le principe de portée minimale n'est pas seulement une recommandation de Google - il affecte directement votre conformité RGPD et SOC 2. Demander des autorisations excessives pour l'API Gmail crée des risques inutiles d'exposition des données et complique vos accords de traitement des données avec les utilisateurs finaux.
Le principe de portée minimale reflète le concept de sécurité du privilège minimum. Votre intégration de l'API Gmail devrait demander la Portée d'API Gmail à permission minimale qui active la fonctionnalité. Si votre CRM n'envoie que des e-mails de suivi, gmail.envoyer suffit - gmail.modifier est excessif et crée un risque inutile.
Google affiche directement vos scopes d'API Gmail déclarés sur l'écran de consentement. Des scopes plus larges déclenchent un langage plus alarmant (" Cette application souhaite accéder à votre boîte de réception Gmail entière "). Scopes OAuth Gmail minimaux créer des écrans de consentement plus simples et moins intimidants, ce qui permet généralement d'améliorer les taux de conversion des autorisations de 15 à 30 % dans les flux OAuth destinés aux utilisateurs.
Votre politique de confidentialité et votre accord de traitement des données (DPA) doivent refléter avec précision quelles données Gmail votre application peut consulter. Si votre application demande gmail.lecture seule mais votre politique de confidentialité ne mentionne que "l'envoi d'e-mails", vous avez une lacune dans votre documentation RGPD. Faites correspondre vos autorisations Gmail API déclarées à vos pratiques de données publiées.
Les exigences de portée de l'API Gmail évoluent à mesure que des fonctionnalités sont ajoutées ou supprimées. Effectuez un audit des portées à chaque version majeure : supprimez toutes les autorisations de l'API Gmail dont votre ensemble de fonctionnalités actuel n'a plus besoin. Les portées inutilisées dans votre déclaration OAuth constituent un risque de conformité : elles représentent un accès aux données que vous prétendez nécessiter mais que vous n'utilisez pas.
gmail.metadata au lieu de gmail.lecture seule quand l'accès au corps n'est pas nécessaire
Intégration Gmail prête pour la conformité. L'implémentation de l'API Gmail par Unipile suit par défaut le principe de portée minimale : votre application ne demande que les scopes OAuth Gmail nécessaires aux fonctionnalités que vous activez.
Créer des applications Gmail conformesScopes Gmail API avec Unipile : simplifiez la complexité des scopes
Gérer manuellement les scopes de l'API Gmail signifie naviguer dans le processus de vérification de Google, gérer le renouvellement des tokens lors des changements de scope et mettre à jour votre documentation de traitement des données chaque fois que vous ajoutez une fonctionnalité. Unipile abstrait tout cela, votre équipe se concentre sur le produit, pas sur les chaînes d'autorisation.
Gmail
Outlook
IMAP
Unipile détient la vérification OAuth de Google pour les champs d'application restreints de l'API Gmail. Votre application bénéficie immédiatement sans avoir à réaliser une évaluation de sécurité distincte. La recertification annuelle est gérée par l'équipe de conformité d'Unipile.
Unipile gère le rafraîchissement des jetons OAuth, la validation des scopes et les flux de ré-autorisation pour les comptes liés de chacun de vos utilisateurs. Lorsque Google met à jour les exigences des scopes, Unipile s'adapte sans casser votre intégration.
Les mêmes appels d'API Unipile fonctionnent pour Gmail, Outlook et IMAP. Vous écrivez votre fonctionnalité de messagerie une seule fois et elle fonctionne sur tous les fournisseurs, sans gestion de portée d'API Gmail séparée par fournisseur, sans branches de code spécifiques au protocole.
Pour les équipes qui doivent utiliser leurs propres identifiants Google, Unipile prend en charge la configuration OAuth en marque blanche. Vos utilisateurs voient votre marque sur l'écran de consentement tandis qu'Unipile gère la déclaration des scopes et le cycle de vie des tokens en arrière-plan.
L'intégration Gmail d'Unipile ne demande que les autorisations de l'API Gmail requises pour les fonctionnalités que vous activez. Lire, envoyer, synchroniser, chaque capacité correspond à la portée la plus restreinte possible, afin de maintenir un profil de conformité propre.
Recevez les nouveaux messages Gmail dès leur arrivée via les webhooks Unipile. Pas de requêtes répétées, pas de gestion manuelle des abonnements Pub/Sub de Gmail. Fonctionne avec le même jeton OAuth que votre application utilise déjà pour d'autres opérations de l'API Gmail.
Questions fréquemment posées sur les scopes de l'API Gmail
Questions fréquentes sur les champs d'application de l'API Gmail, les champs d'application OAuth Gmail et le processus de vérification - réponses concises pour les développeurs créant des intégrations Gmail.
gmail.lecture seule et gmail.modifier sont des champs d'application restreints de l'API Gmail. gmail.lecture seule fournit un accès en lecture seule à tous les messages, fils de discussion, étiquettes et paramètres - votre application ne peut rien envoyer ni modifier. gmail.modifier ajoute la possibilité de lire, de composer, d'envoyer des e-mails et de gérer les libellés, mais exclut la suppression permanente des messages. Si votre application a besoin de lire et d'envoyer sans supprimer, gmail.modifier est préférée au plus large mail.google.com/ portée. Voir notre comment lire les e-mails des utilisateurs via une API unifiée.libellés gmail nécessitent uniquement un examen standard de l'application OAuth. Les scopes sensibles comme gmail.envoyer requis le processus de vérification OAuth de Google mais pas d'évaluation de sécurité. Portées restreintes - y compris gmail.lecture seule, gmail.modifier, gmail.rediger, gmail.metadata, gmail.insérer, ou encore mail.google.com/ - exiger le processus d'évaluation complet. Plus d'informations à ce sujet dans notre modèles d'API de messagerie sécurisée pour les industries réglementées.gmail.modifier scope accorde un accès en lecture, composition, envoi et gestion des libellés à Gmail, mais exclut la possibilité de supprimer définitivement les messages. C'est la portée restreinte recommandée pour les intégrations de messagerie complètes telles que Synchronisation d'e-mails CRM, outils de helpdesk et clients de messagerie qui doivent à la fois lire et envoyer des messages. Il est préférable à mail.google.com/ car cela limite l'exposition des données en excluant la fonctionnalité de suppression définitive. Connexe : envoi d'e-mails au nom des utilisateurs.portée paramètre. Par exemple, vous pouvez demander gmail.envoyer + libellés gmail ensemble. Cependant, la combinaison de scopes augmente les autorisations affichées sur l'écran de consentement de Google et peut déclencher des exigences de vérification supplémentaires si l'un des scopes combinés est restreint. Demandez toujours la combinaison minimale dont votre application a réellement besoin. Pour le côté Microsoft, voir Étendues OAuth Microsoft Graph équivalentes.gmail.metadata scope est une portée restreinte de l'API Gmail qui accorde l'accès à en-têtes d'e-mail et étiquettes uniquement, sans aucun accès au contenu du corps de l'e-mail ou aux pièces jointes. Il est utile pour les moteurs de routage, les systèmes de catégorisation ou les outils d'analyse qui traitent les e-mails en fonction de l'expéditeur, du destinataire, de l'objet ou des étiquettes sans lire le contenu des messages privés. Malgré sa restriction, il a une empreinte de données plus restreinte que gmail.lecture seule et pourrait être plus facile à justifier dans une évaluation de sécurité. Nous approfondissons notre API de synchronisation d'e-mails pour synchronisation complète de la boîte de réception.gmail.envoyer portée est un portée sensible de l'API Gmail qui permet à votre application d'envoyer des e-mails au nom d'un utilisateur authentifié, sans accorder d'accès en lecture ou en modification aux messages existants. C'est la portée minimale recommandée pour les applications qui envoient uniquement des e-mails - outils de prospection, systèmes de notification ou automatisation de suivi. Utiliser gmail.envoyer au lieu de gmail.modifier évite complètement le périmètre de sécurité restreint, accélérant ainsi considérablement votre chemin vers la mise en production. Voir notre Guide dédié à l'API d'envoi d'e-mails.
FR 
EN 
ES 
DE 
IT 
BR 
NL 
PL 
TR