LinkedIn
Instagram
WhatsApp
Telegram
Google Agenda
Rejoindre la communauté SlackClé API Gmail vs OAuthPourquoi il ne faut pas ignorer OAuth
Pouvez-vous utiliser une clé API Google pour accéder à Gmail ? Réponse courte : non. L'API Gmail accède à des données utilisateur privées, ce qui signifie que chaque requête nécessite le consentement explicite de l'utilisateur via OAuth 2.0. Ce guide couvre l'erreur exacte que vous verrez si vous essayez une clé API, les 3 véritables chemins d'authentification disponibles aujourd'hui et comment connecter une boîte aux lettres Gmail en 3 lignes de code à l'aide d'un API unifiée pour les e-mails.
Clé API Gmail vs OAuth - le verdict
// ----------------------------------------
// INCORRECT : la clé API ne fonctionne PAS avec Gmail
const res = await fetch(
https://gmail.googleapis.com/gmail/v1/
users/me/messages?key=VOTRE_CLE_API`
);
// Renvoie : 401 Connexion requise
// CORRECT : Jeton d'accès OAuth 2.0
const res = await fetch(
'https://gmail.googleapis.com/gmail/v1/users/me/messages',
{ headers: {
'Authorization': Porteur ${accessToken}`
} }
);
// OU sautez OAuth entièrement - utilisez Unipile
const mails = await unipile.l'email.list(
{ idCompte: 'identifiant-compte-lié' }
);
Pouvez-vous utiliser une clé API avec l'API Gmail ?
Si vous avez déjà travaillé sur Google Cloud, vous savez que les clés API fonctionnent bien pour les cartes ou la traduction. Il est donc naturel d'essayer la même approche avec Gmail. Cela ne fonctionnera pas. Voici exactement ce qui se passe et pourquoi, avec le verdict en deux phrases avant d'entrer dans les détails.
Non. Les clés API Google ne peuvent pas s'authentifier auprès de l'API Gmail. Gmail accède aux données privées des utilisateurs, ce qui nécessite un consentement explicite de l'utilisateur via OAuth 2.0. Il n'existe aucun indicateur, aucun en-tête, aucune solution de contournement qui vous permette de remplacer une clé d'API par un jeton d'accès OAuth sur n'importe quel point de terminaison Gmail. L'API Gmail renverra un 401 Connexion requise ou Limite quotidienne de 403 pour utilisation non authentifiée dépassée erreur à chaque fois.
Clé API - Fonctionne pour les données publiques uniquement
Une clé API identifie votre projet Google Cloud pour la facturation et les quotas. Elle fonctionne avec les API publiques (Maps, Translate, données publiques YouTube) qui ne touchent pas aux comptes utilisateurs. Gmail ne contient jamais de données publiques.
OAuth 2.0 - Obligatoire pour l'API Gmail
OAuth 2.0 génère un jeton d'accès spécifique à l'utilisateur après que celui-ci a explicitement donné son consentement. L'API Gmail lit ce jeton à chaque requête pour vérifier l'identité de l'utilisateur et la portée de l'accès approuvé. Pas de jeton d'accès valide = pas de réponse.
Ce qu'une clé d'API fait réellement sur Google Cloud (et ne fait pas)
Les clés d'API et les jetons OAuth sont deux mécanismes distincts qui résolvent deux problèmes différents. Les confondre est l'une des erreurs les plus courantes lorsque l'on débute avec les API Google. Voici la séparation claire.
Plateforme Google Maps - Géocodage, Itinéraires, Lieux (aucun compte utilisateur nécessaire)
API de traduction automatique - Traduction de textes, détection de langues
API YouTube Data - Lecture des métadonnées publiques de vidéos, chaînes, listes de lecture
Cloud Vision / Langage naturel - API d'apprentissage automatique qui traitent le contenu que vous téléchargez
Facturation + Suivi des quotas - Toute utilisation de clé API est mesurée par rapport à votre projet
API Gmail - Lire, envoyer ou gérer la boîte aux lettres d'un utilisateur
API Calendrier Google - Lire ou écrire des événements du calendrier de n'importe quel utilisateur
API Google Drive - Accéder, télécharger ou lister les fichiers d'un utilisateur
Google Workspace Admin SDK - Toute opération d'étendue admin sur un domaine
API Personnes (données utilisateur) Tout point de terminaison qui touche les contacts ou le profil d'un utilisateur
La règle est simple : Si une API accède aux données du compte d'un utilisateur, Google exige que cet utilisateur s'authentifie via OAuth 2.0. Les clés d'API sont des identifiants de projet, pas des identifiants d'utilisateur. L'API Gmail concerne toujours les données de l'utilisateur. Aucune exception. Cette règle s'applique que votre application soit publique ou interne à votre entreprise.
Pourquoi Gmail exige OAuth 2.0
OAuth 2.0 n'est pas un obstacle bureaucratique inventé par Google pour vous ralentir. C'est la seule manière techniquement valable d'accorder un accès limité, révocable et vérifiable aux données privées des utilisateurs. Les trois exigences fondamentales de Gmail expliquent pourquoi une clé d'API ne peut jamais la remplacer.
Le consentement de l'utilisateur est non négociable
Les données Gmail appartiennent à l'utilisateur, pas à votre application. OAuth 2.0 est le mécanisme par lequel un utilisateur dit explicitement "oui, cette application peut lire ma boîte de réception". Pas de flux de consentement = pas d'accès. C'est une exigence légale en vertu du RGPD et une politique de la plateforme Google, pas seulement une restriction technique.
Accès limité et révocable
Les jetons OAuth portent des scopes – des déclarations précises de ce que l'application peut et ne peut pas faire (lecture seule, envoi, accès complet). Les utilisateurs peuvent voir exactement quel accès ils ont accordé et le révoquer à tout moment dans les paramètres de leur compte Google. Une clé API n'accorde rien et ne peut rien révoquer au niveau de l'utilisateur.
L'expiration des jetons protège les utilisateurs
Les jetons d'accès de l'API Gmail expirent (généralement au bout d'une heure). Cela signifie qu'un jeton volé est inutile après une courte période. Votre application doit actualiser silencieusement les jetons à l'aide d'un jeton d'actualisation, qui peut lui-même être révoqué. Les clés d'API, en revanche, sont des identifiants de projet à longue durée de vie sans mécanisme de révocation au niveau de l'utilisateur.
Google a déprécié l'authentification par nom d'utilisateur/mot de passe ("Authentification de base") pour Gmail en Septembre 2024. Si vous avez une intégration existante utilisant des identifiants stockés directement, elle a cessé de fonctionner. OAuth 2.0 est le seul mécanisme d'authentification restant pour l'API Gmail, à la fois pour les nouvelles intégrations et celles qui ont été migrées. Voir l'annonce officielle de Google.
Besoin de gérer l'OAuth pour plusieurs comptes Gmail dans votre SaaS ? Unipile gère l'écran de consentement, l'échange de jetons et le rafraîchissement silencieux pour chaque compte lié – ainsi, votre code ne touche jamais à un jeton.
Construisez-le avec UnipileLes 3 chemins d'authentification réels pour l'API Gmail
Une fois que vous avez accepté qu'OAuth est inévitable, la question devient : quelle voie OAuth correspond à votre cas d'utilisation ? Il existe trois options architecturalement distinctes, chacune avec des compromis différents en termes de complexité, de portée utilisateur et de maintenance.
| Critère | Identifiant client OAuth 2.0 (à 3 voies) | Compte de service + DWD | API Unifiée (Unipile) |
|---|---|---|---|
| Consentement de l'utilisateur requis ? | |||
| Fonctionne avec Gmail personnel ? | |||
| SaaS multi-locataire ? | |||
| Gestion des jetons | Votre code stocke et actualise les jetons Exigeant |
Clé JSON de compte de service Géré par l'administrateur |
Unipile gère tous les jetons Aucune maintenance |
| Examen de l'écran de consentement Google ? | |||
| Prend également en charge Outlook + IMAP ? | |||
| Temps de lecture du premier e-mail | 2-4 heures d'installation Application OAuth + étendues + écran de consentement |
1-2 heures de configuration Administrateur de l'espace de travail requis |
Moins de 15 minutes Clé API + compte lié |
| Meilleur pour | Applications SaaS connectant les Gmail des utilisateurs externes | Outils d'espace de travail interne pour votre organisation | Toute utilisation d'API d'e-mail - sans opérations OAuth |
Chemin 1 - ID client OAuth 2.0 (SaaS multi-locataire)
Si vous créez un produit SaaS où vos clients connectent leurs propres comptes Gmail, le flux d'autorisation par code OAuth 2.0 est la voie standard. Il s'agit du flux à 3 pattes : votre application, Google et l'utilisateur final. Il nécessite la configuration d'un projet Google Cloud et le passage par le processus de vérification de l'écran de consentement pour les scopes sensibles. Pour une plongée approfondie dans le Flux OAuth pour les API de messagerie en détail, consultez notre guide dédié.
Créer des identifiants OAuth 2.0 dans la Google Cloud Console
Accédez à API et services > Identifiants > Créer des identifiants > Identifiant client OAuth. Choisissez "Application web". Configurez les URI de redirection autorisées pour votre application. Cela génère votre client_id et secret_client.
Activez l'API Gmail et déclarez vos champs d'application
Accédez à API et services > Écran de consentement OAuth. Ajoutez les champs d'application Gmail dont vous avez besoin (par exemple. gmail.lecture seule, gmail.envoyer. Les portées sensibles et restreintes nécessitent une vérification de Google, un processus qui prend de quelques jours à quelques semaines.
Rediriger les utilisateurs vers l'URL d'autorisation de Google
Lorsque qu'un utilisateur clique sur " Connecter Gmail " dans votre application, redirigez-les vers Google avec votre client_id, portées, et uri_de_redirection. Une fois qu'ils ont approuvé, Google renvoie un code d'autorisation à votre URI de redirection.
Échangez le code contre des jetons et stockez le jeton d'actualisation
POSTez le code d'autorisation au point d'accès du jeton de Google. Vous recevez un access_token (expire ~1h) et un token_rafraîchissement (longue durée de vie). Stockez le jeton de rafraîchissement en toute sécurité – c'est ainsi que vous obtenez de nouveaux jetons d'accès sans redemander à l'utilisateur.
const { google } = require('googleapis');
const clientOAuth2 = new google.auth.OAuth2(
process.env.GMAIL_CLIENT_ID,
process.env.GMAIL_CLIENT_SECRET,
process.env.GMAIL_REDIRECT_URI
);
// Étape 1 : Construire l'URL d'autorisation
const authUrl = oauth2Client.générerURLAuthentification({
type_accès : 'hors ligne', // obtenir le jeton de rafraîchissement
portée : [
'https://www.googleapis.com/auth/gmail.readonly',
'https://www.googleapis.com/auth/gmail.send'
]
});
// Étape 2 : Échangez le code contre des jetons (dans votre gestionnaire de rappel)
async function gérerLeRappel{
const { jetons } = await oauth2Client.jeton(code);
oauth2Client.définirLesIdentifiantsjetons ;
// Stockez tokens.refresh_token en toute sécurité dans votre base de données
return jetons;
}
// Étape 3 : Utiliser le jeton d'accès pour appeler l'API Gmail
async function listerMessages(accessToken) {
const gmail = google.gmail({ version : 'v1', auth: oauth2Client });
const res = await gmail.users.messages.list({ userId: moi });
return res.data.messages;
}La gestion des jetons de rafraîchissement à grande échelle est le principal défi de #1 Dans Gmail auto-géré avec OAuth. La rotation des jetons, les migrations de base de données, les échecs silencieux sur les jetons expirés, tout cela est géré automatiquement lorsque vous utilisez un fournisseur d'API d'email unifiée.
Configurez votre intégration GmailChemin 2 - Compte de service + délégation à l'échelle du domaine (Interne Workspace)
Si votre cas d'utilisation est interne à une organisation Google Workspace - pensez aux outils internes, à l'automatisation des RH ou à un tableau de bord d'analyse des e-mails à l'échelle de l'entreprise - les comptes de service avec délégation à l'échelle du domaine (DWD) vous permettent d'accéder aux boîtes aux lettres sans flux de consentement par utilisateur. Un administrateur Workspace accorde la délégation une seule fois. La réserve cruciale : cette voie ne fonctionne pas pour les adresses Gmail personnelles.
Les comptes de service ne peuvent pas accéder aux comptes Gmail personnels (@gmail.com). DWD ne fonctionne qu'au sein d'un domaine Google Workspace. Si vos utilisateurs s'inscrivent avec des adresses Gmail personnelles, vous devez utiliser la voie 1 (ID client OAuth) ou la voie 3 (API unifiée). Tenter DWD sur un compte personnel renvoie une erreur 403.
Administrateur de l'espace de travail requis : DWD doit être configuré par un administrateur Google Workspace sur admin.google.com. Vous ne pouvez pas le faire en tant que développeur sans accès administrateur.
Sécurité des clés JSON : La clé JSON du compte de service est une credential à longue durée de vie. Traitez-la comme une clé privée : faites-la pivoter régulièrement et ne la commettez jamais dans le contrôle de code source.
Déclaration de portée requise : L'administrateur doit explicitement approuver chaque champ d'application Gmail lors de la configuration de DWD. Vous ne pouvez pas demander de champs d'application au moment de l'exécution. Voir Guide DWD de Google.
from google.oauth2 import compte de service
from googleapiclient.discovery import construire
# : chemin d'accès à la clé JSON de votre compte de service
FICHIER_COMPTE_SERVEUR = 'fichier-de-compte-service.json'
PORTÉES = [
'https://www.googleapis.com/auth/gmail.readonly'
]
# : Se faire passer pour un utilisateur du domaine de votre espace de travail
# (la délégation à l'échelle du domaine doit être activée par l'administrateur)
déf obtenir_le_service_gmail(adresse_email_utilisateur):
identifiants = service_account.Credentials.depuis_fichier_compte_service(
FICHIER_COMPTE_SERVICE,
lunettes de visée=PORTÉES
)
# Il s'agit d'une délégation à l'échelle du domaine : usurpation d'identité d'un utilisateur
créances déléguées = identifiants.avec_sujet(adresse_électronique_de_l'utilisateur)
return construire('Gmail', 'v1', identifiants=crédits délégués)
# : Liste des messages d'un utilisateur de l'espace de travail
service = obtenir_le_service_gmail('alice@yourcompany.com')
résultats = service.users().messages().list(
identifiantUtilisateur=moi
).exécutez()Chemin 3 - API d'e-mail unifiée (Évitez le code répétitif d'OAuth)
Si votre objectif est de lire, envoyer ou synchroniser des e-mails dans une application SaaS en production – et que vous préférez ne pas consacrer de cycles d'ingénierie à la gestion de l'infrastructure OAuth – une API d'e-mail unifiée comme Unipile abstrait toute la couche d'authentification. Comprendre comment la synchronisation des e-mails fonctionne en coulisses, ou passez directement au code. Cette approche vous permet également d'accéder à Gmail, Outlook et IMAP via une seule API, sans intégration distincte pour chaque fournisseur.
Aucune configuration Google Cloud requise
Aucun ID client OAuth, aucun écran de consentement, aucun examen de périmètre avec Google. L'application OAuth vérifiée d'Unipile gère l'autorisation de l'utilisateur.
Rotation automatique de jetons
Les jetons d'accès et les jetons de rafraîchissement sont entièrement gérés par Unipile. Votre base de données ne stocke jamais de jeton OAuth Google.
Fonctionne pour Gmail personnel + Outlook + IMAP
Une seule API, trois univers fournisseurs. Quand vous Comparer les fournisseurs d'API de synchronisation d'e-mails, le support multi-fournisseurs est un différenciateur majeur.
Livraison de webhook sur de nouveaux messages
Au lieu d'interroger l'API de Gmail, Unipile envoie des événements de nouveaux e-mails en temps réel à votre point de terminaison webhook, par compte lié.
// 3 lignes pour lire une boîte mail Gmail via Unipile
// Aucune configuration OAuth, aucune gestion de jeton
const { UnipileClient } = require('unipile-node-sdk');
const client = new UnipileClient({
jeton : process.env.UNIPILE_API_KEY
});
// Lister les e-mails d'un compte Gmail lié
// accountId = l'identifiant du compte lié Unipile
const courriels = await client.email.listerMessages({
account_id : 'identifiant-compte-lié',
limite : 20
});
Envoyer un e-mail au nom du compte lié
await client.email.envoyer({
account_id : 'identifiant-compte-lié',
to: 'recipient@example.com',
sujet : 'Bonjour de la part d'Unipile',
body: ' Aucun jeton OAuth en vue. '
});
// Fonctionne de manière identique pour Outlook et IMAP
// Il suffit d'échanger le account_idCréez votre intégration Gmail sans opérations OAuth
Commencez par le Guide complet d'intégration de l'API Gmail, puis déployez avec Unipile comme couche d'authentification et de synchronisation.
Erreurs courantes lorsque vous essayez d'utiliser une clé d'API avec Gmail
Si vous êtes tombé sur cet article parce que votre appel à l'API Gmail échoue, voici les deux erreurs que vous rencontrerez et ce que chacune d'elles signifie exactement - avec le corps brut de la réponse pour que vous puissiez les reconnaître instantanément.
Vous avez envoyé une requête à l'API Gmail avec une clé d'API?clé=AIza...) ou sans aucune autorisation. L'API Gmail nécessite un jeton d'accès OAuth 2.0 valide dans les Autorisation : Support en-tête. C'est la première erreur que vous verrez lors de la première expérimentation d'une clé d'API.
Réparer : Implémentez l'un des 3 chemins d'authentification ci-dessus. La clé API n'est pas la solution – vous avez besoin d'un jeton d'accès OAuth.
HTTP/1.1 401 Non autorisé
Content-Type : application/json
"erreur": {
"code": 401,
"message": "La requête est incomplète
car il manque une authentification
requise. Un jeton d'accès OAuth 2
, un cookie de connexion
ou toute autre information d'authentification valide est attendu. Voir https://
developers.google.com/
identity/sign-in/web/...",
"status": "UNAUTHENTICATED",
"errors": [{
"message": "Connexion requise",
"domain": "googleapis.com",
"reason": "required",
"location": "Authorization",
"locationType": "header"
}]
}
}Après des requêtes répétées non authentifiées (même avec une clé API), le système de quotas de Google bloque les appels non authentifiés ultérieurs depuis votre IP ou votre projet. Il ne s'agit pas d'une limite de débit pour les utilisateurs authentifiés - cela signifie spécifiquement que vos requêtes n'ont jamais été authentifiées et vous avez épuisé le petit quota gratuit pour les appels anonymes.
Réparer : Comme ci-dessus - votre approche de clé API ne fonctionnera jamais. Utilisez des jetons d'accès OAuth 2.0. Cette erreur disparaîtra une fois que vos requêtes porteront un jeton Bearer valide.
HTTP/1.1 403 Interdit
Content-Type : application/json
"erreur": {
"code": 403,},
"message": "Limite quotidienne d'utilisation non authentifiée dépassée.
Une utilisation continue nécessite une inscription.",
"status": "RESOURCE_EXHAUSTED",
"errors": [{
"message": "Limite quotidienne d'utilisation non authentifiée dépassée.",
"domain": "usageLimits",
"reason":
"dailyLimitExceededUnreg"
}]
}
}Portées de l'API Gmail dont vous aurez réellement besoin
Une fois que vous acceptez que OAuth est requis, la sélection des champs d'application est la prochaine décision critique. Google classe les champs d'application de Gmail en trois niveaux en fonction de la sensibilité des données qu'ils exposent. Demander plus que ce dont vous avez besoin déclenche un processus de vérification plus long et, dans certains cas, une évaluation complète de la sécurité par Google.
Portées sensibles (jaune) exiger que Google examine votre écran de consentement OAuth et vérifie la politique de confidentialité de votre application. Portées restreintes (rouge) nécessitent une évaluation de sécurité formelle, une démonstration vidéo et parfois un audit de sécurité tiers. Prévoyez un minimum de 2 à 6 semaines pour l'approbation d'un périmètre restreint. Si vous utilisez Unipile comme couche d'authentification, ce processus de vérification incombe à Unipile, et non à votre application.
| Portée | Niveau d'accès | Niveau | Cas d'utilisation |
|---|---|---|---|
| gmail.lecture seule | Lire tous les messages, fils de discussion, libellés, paramètres | Sensible | Analyse des e-mails, outils d'audit de la boîte de réception, synchronisation CRM (lecture seule) |
| gmail.envoyer | Envoyer un e-mail au nom de l'utilisateur | Sensible | Emails transactionnels côté utilisateur, suivis CRM, outils de prospection |
| gmail.rediger | Créer, lire, mettre à jour, supprimer des brouillons ; envoyer des messages | Sensible | Intégrations de compositeurs d'e-mails, gestion des brouillons |
| gmail.modifier | Lire, envoyer, modifier (étiqueter, archiver) - sans supprimer | Accès restreint | Gestion complète de la boîte de réception, synchronisation CRM avec écriture, flux d'archivage |
| mail.google.com | Accès complet - lire, écrire, supprimer, paramètres | Accès restreint | Clients de messagerie complets, outils de sauvegarde, migration d'administration |
| gmail.metadata | Métadonnées du message uniquement (pas de corps) | Non-sensible | Analyse du volume d'e-mails, des modèles d'expéditeurs/destinataires (sans contenu) |
Construire une SaaS multi-locataire qui a besoin de gmail.modify ou mail.google.com ? L'examen de périmètre restreint ajoute des semaines à votre calendrier de lancement. Avec Unipile, vous évitez complètement l'examen de l'écran de consentement - l'application OAuth vérifiée d'Unipile couvre les périmètres dont votre intégration a besoin.
Construire avec UnipileArbre de décision : Quelle méthode d'authentification pour votre cas d'utilisation ?
Répondez à trois questions et vous saurez exactement quel chemin d'authentification de l'API Gmail s'applique à votre projet. Il n'y a pas de réponse universelle - chaque chemin résout un problème différent. Pour le chemin complet Guide complet d'intégration de l'API Gmail, continuez vers le centre Gmail. Pour l'équivalent pour Outlook / Microsoft 365, consultez notre guide OAuth Microsoft Graph.
Application SaaS où les clients connectent leur propre Gmail
Vos utilisateurs sont-ils externes (pas vos employés) ?
Oui, ce sont vos clients qui possèdent un compte Gmail personnel ou un compte Google Workspace.
Faut-il prendre en charge de nombreux domaines Google différents ?
Oui - multi-tenant. Chaque utilisateur connecte son propre compte.
Ou Voie 3 (API unifiée) pour ignorer complètement l'infrastructure OAuth.
Outil interne pour votre propre organisation Google Workspace
Tous les utilisateurs sont-ils sur le même domaine d'espace de travail (vos employés) ?
Oui - comptes de company.com uniquement. Pas d'utilisateurs Gmail externes.
Avez-vous un administrateur Workspace qui peut configurer DWD ?
Oui - accès administrateur disponible dans admin.google.com.
Aucun flux de consentement par utilisateur. L'administrateur délègue une fois.
Application SaaS qui a besoin de Gmail + Outlook + IMAP sous une seule API
Vos utilisateurs ont-ils un mélange de comptes Gmail, Outlook et IMAP ?
Oui - on ne peut pas prédire à quel fournisseur chaque utilisateur se connectera.
Souhaitez-vous éviter de mettre en place des intégrations OAuth distinctes pour chaque fournisseur ?
Oui, la gestion de Google OAuth, Microsoft OAuth et IMAP est trop complexe.
Une clé API. Gmail, Outlook, IMAP. Aucune opération OAuth.
Commencez à intégrer Gmail dès aujourd'hui
Quel que soit le chemin que vous choisissez, Unipile vous offre une aperçu de l'API d'e-mail unifiée pour comprendre l'architecture avant de vous engager dans une approche. Ou passez directement au tableau de bord et liez votre premier compte en quelques minutes.
Questions fréquemment posées
Les questions les plus courantes sur l'authentification de l'API Gmail, les clés API par rapport aux jetons OAuth, et comment accéder à Gmail par programme sans gérer vous-même OAuth.
Puis-je utiliser une clé API Google pour accéder à Gmail ?
Non. Les clés d'API Google fonctionnent uniquement pour les API publiques et non spécifiques à l'utilisateur, telles que Maps, Translate ou YouTube Data (contenu public). L'API Gmail accède à données de la boîte aux lettres privée de l'utilisateur, qui nécessite un consentement explicite de l'utilisateur via OAuth 2.0. Envoyer une requête à l'API Gmail avec uniquement une clé API renvoie une 401 Connexion requise ou Limite quotidienne de 403 pour utilisation non authentifiée dépassée erreur - à chaque fois, sans exception.
L'API Gmail nécessite-t-elle OAuth 2.0 ?
Oui, toujours. L'accès à l'API Gmail est un accès aux données utilisateur, ce qui signifie que chaque requête doit être associée à un utilisateur authentifié qui a accordé son consentement via un flux OAuth 2.0. Il n'y a pas de contournement : pas de clé API, pas d'authentification de base (obsolète septembre 2024), pas d'en-tête magique. Les trois chemins d'authentification pris en charge sont : ID client OAuth 2.0 (multi-locataire), Compte de service avec délégation à l'échelle du domaine (uniquement pour Workspace), et une API d'email unifiée comme Unipile qui gère la couche OAuth pour vous.
Quelle est la différence entre une clé d'API et un ID client OAuth sur Google Cloud ?
Un Clé API identifie votre projet Google Cloud à des fins de facturation et de quotas. Il ne fonctionne que pour les API qui servent des données publiques (Maps, Translate, etc.). Un ID client OAuth est utilisé pour initier un flux de consentement où un utilisateur réel approuve l'accès de votre application à son compte. L'ID client OAuth génère le jeton d'accès et le jeton de rafraîchissement que l'API Gmail accepte réellement. Ce sont deux mécanismes entièrement différents : l'un identifie un projet, l'autre authentifie un utilisateur.
Un compte de service peut-il lire des e-mails Gmail sans le consentement de l'utilisateur ?
À condition que Délégation à l'échelle du domaine est activé par un administrateur Google Workspace. Un compte de service seul ne peut accéder à aucune boîte aux lettres Gmail. Avec DWD configuré, le compte de service peut usurper l'identité de n'importe quel utilisateur de l'organisation et accéder à sa boîte aux lettres sans consentement interactif. Limitation essentielle : cela ne fonctionne que pour les comptes Google Workspace (professionnels). Cela ne fonctionne pas pour les adresses Gmail personnelles (@gmail.com. Voir Documentation officielle DWD de Google.
Pourquoi l'API Gmail renvoie-t-elle "Login Required" avec ma clé API ?
Parce que L'API Gmail n'accepte pas les clés API. Le 401 Connexion requise erreur signifie que la requête ne contient pas de jeton d'accès OAuth 2.0 valide Authorization En-tête. L'API Gmail attend: Autorisation : Bearer {access_token} - où le jeton d'accès a été obtenu via un flux OAuth 2.0 (code d'autorisation, JWT de compte de service ou jeton d'API unifié). Il suffit de joindre ?clé=VOTRE_CLÉ_API l'URL de l'API Gmail ne fonctionnera pas et renverra 401 ou 403.
Existe-t-il un moyen d'utiliser l'API Gmail sans gérer moi-même OAuth ?
Oui. Une API d'email unifiée comme Unipile gère l'intégralité de la couche OAuth : l'écran de consentement, l'échange de jetons et la rotation silencieuse des jetons de rafraîchissement. Votre application ne stocke ni ne gère jamais les jetons d'accès ou les jetons de rafraîchissement. Vous appelez l'API Unipile avec votre propre clé d'API, et Unipile gère toute la communication OAuth avec Google en votre nom. comptes liés. Cela supprime le processus d'approbation de l'écran de consentement Google et la complexité de la gestion des jetons de votre code - et vous offre Gmail, Outlook et IMAP sous une interface unifiée.
FR 
EN 
ES 
DE 
IT 
BR 
NL 
PL 
TR