LinkedIn
Instagram
WhatsApp
Telegram
Google Agenda
Word lid van de Slack-gemeenschapGmail API-sleutel versus OAuthWaarom je OAuth niet kunt overslaan
Kan je een Google API-sleutel gebruiken om toegang te krijgen tot Gmail? Kort antwoord: nee. De Gmail API geeft toegang tot privé gebruikersgegevens, wat betekent dat elke aanvraag expliciete toestemming van de gebruiker vereist via OAuth 2.0. Deze handleiding behandelt de exacte fout die je ziet als je een API-sleutel probeert, de 3 echte authenticatiepaden die vandaag beschikbaar zijn, en hoe je een Gmail-mailbox kunt verbinden in 3 regels code met behulp van een unificerende e-mail-API.
// Gmail API Sleutel vs OAuth - het oordeel
// ----------------------------------------
// FOUT: API-sleutel werkt NIET met Gmail
const res = wacht op fetch(
https://gmail.googleapis.com/gmail/v1/
gebruikers/mijn/berichten?key=JE_API_SLEUTEL`
);
// Geeft terug: 401 Login Vereist
// CORRECT: OAuth 2.0 toegangstoken
const res = wacht op fetch(
'https://gmail.googleapis.com/gmail/v1/users/me/messages',
{ headers: {
'Authorization': Drager ${toegangstoken}`
} }
);
// OF sla OAuth volledig over - gebruik Unipile
const e-mails = wacht op eenpaal.e-mail.list(
{ accountId: 'gekoppeld-account-id' }
);
Kun je een API-sleutel gebruiken met de Gmail API?
Als je al eerder op Google Cloud hebt gebouwd, weet je dat API-sleutels prima werken voor Maps of Translate. Het is dus logisch om dezelfde aanpak te proberen met Gmail. Het zal niet werken. Hier is precies wat er gebeurt en waarom - plus het oordeel van twee zinnen voordat we dieper ingaan.
Nee. Google API-sleutels kunnen niet worden geauthenticeerd tegen de Gmail API. Gmail heeft toegang tot privégebruikersgegevens, waarvoor expliciete toestemming van de gebruiker nodig is via OAuth 2.0. Er is geen vlag, geen header, geen oplossing die u een API-sleutel laat inwisselen voor een OAuth-toegangstoken op een Gmail-eindpunt. De Gmail API zal een 401 Inloggen Vereist of 403 Dagelijkse limiet voor niet-geauthenticeerd gebruik overschreden fout, elke keer weer.
API-sleutel - Werkt alleen voor openbare gegevens
Een API-sleutel identificeert uw Google Cloud-project voor facturering en quota. Het werkt met openbare API's (Maps, Translate, YouTube openbare gegevens) die geen gebruikersaccounts aanraken. Gmail is nooit openbare data.
OAuth 2.0 - Vereist voor Gmail API
OAuth 2.0 genereert een door de gebruiker specifieke toegangstoken nadat de gebruiker expliciet toestemming heeft gegeven. De Gmail API leest die token bij elke aanvraag om zowel de identiteit van de gebruiker als de goedgekeurde toegangsmachtigingen te verifiëren. Geen geldige toegangstoken = geen reactie.
Wat een API-sleutel daadwerkelijk doet (en niet doet) op Google Cloud
API-sleutels en OAuth-tokens zijn twee afzonderlijke mechanismen die twee verschillende problemen oplossen. Ze verwarren is een van de meest voorkomende fouten bij het beginnen met Google API's. Hier is de duidelijke scheiding.
Google Maps Platform Geocodering, Routes, Plaatsen (geen gebruikersaccount nodig)
Cloud Vertalings-API - Teksten vertalen, talen detecteren
YouTube Data API - Publieke videometadata, kanalen, afspeellijsten lezen
Cloud Vision / Natuurlijke Taal - ML API's die inhoud verwerken die u uploadt
Facturering + Quota bijhouden - Al het API-sleutelgebruik wordt gemeten tegen uw project
Gmail API - Het lezen, verzenden of beheren van de mailbox van een gebruiker
Google Agenda API - Lees- of schrijf toegang tot de agenda-afspraken van een gebruiker
Google Drive API - Toegang krijgen tot, uploaden of een lijst maken van de bestanden van een gebruiker
Google Workspace Admin SDK - Elke beheerdersspecifieke bewerking op een domein
Mensen API (gebruikersgegevens) - Elk eindpunt dat toegang heeft tot de contacten of het profiel van een gebruiker
De regel is simpel: Als een API de gegevens van het account van een gebruiker aanraakt, vereist Google dat die gebruiker zich authenticeert via OAuth 2.0. API-sleutels zijn projectgegevens, geen gebruikersgegevens. De Gmail API bevat altijd gebruikersgegevens. Geen uitzonderingen. Deze regel geldt, ongeacht of uw app openbaar is of intern binnen uw bedrijf.
Waarom Gmail OAuth 2.0 Vereist
OAuth 2.0 is geen bureaucratische hindernis die Google heeft bedacht om je te vertragen. Het is de enige technisch verantwoorde manier om beperkte, intrekbare, controleerbare toegang te verlenen tot privégebruikersgegevens. De drie kernvereisten van Gmail leggen uit waarom een API-sleutel nooit een substituut kan zijn.
Gebruikersinstemming is niet onderhandelbaar
Gmail-gegevens behoren toe aan de gebruiker, niet aan uw toepassing. OAuth 2.0 is het mechanisme waarmee een gebruiker expliciet zegt "ja, deze toepassing mag mijn inbox lezen". Geen toestemmingsstroom = geen toegang. Dit is een wettelijke vereiste onder de AVG en een beleidsregel van het Google-platform, niet slechts een technische beperking.
Gelimiteerde, intrekbare toegang
OAuth-tokens bevatten "scopes" - precieze verklaringen van wat de app wel en niet kan doen (alleen-lezen, verzenden, volledige toegang). Gebruikers kunnen precies zien welke toegang ze hebben verleend en deze te allen tijde intrekken in de instellingen van hun Google-account. Een API-sleutel verleent niets en kan niets op gebruikersniveau intrekken.
Token-verloop beschermt gebruikers
Gmail API-toegangstokens verlopen (meestal na 1 uur). Dit betekent dat een gestolen token na een korte periode nutteloos is. Je app moet tokens stilzwijgend vernieuwen met een vernieuwingstoken - dat zelf ingetrokken kan worden. API-sleutels daarentegen zijn langdurige projectreferenties zonder mechanisme voor intrekking op gebruikersniveau.
Google heeft authenticatie via gebruikersnaam/wachtwoord ("Basic Auth") voor Gmail uitgefaseerd in September 2024. Als je legacy-integraties hebt die direct gebruikmaken van opgeslagen inloggegevens, is dit gestopt met werken. OAuth 2.0 is het enige resterende authenticatiemechanisme voor de Gmail API - zowel voor nieuwe integraties als voor gemigreerde integraties. Zie Google's officiële aankondiging.
OAuth afhandelen voor meerdere Gmail-accounts in uw SaaS? Unipile beheert het toestemmingsscherm, de tokenuitwisseling en het stilzwijgend vernieuwen voor elk gekoppeld account - zodat uw code nooit een token hoeft aan te raken.
Bouw het met UnipileDe 3 echte authenticatiepaden voor de Gmail API
Als je eenmaal hebt geaccepteerd dat OAuth onvermijdelijk is, wordt de vraag: welk OAuth-pad past bij jouw use case? Er zijn drie architectonisch onderscheidende opties - elk met verschillende afwegingen tussen complexiteit, gebruikersbereik en onderhoudslast.
| Criterium | OAuth 2.0 Client ID (3-legged) | Serviceaccount + DWD | Verenigde API (Unipile) |
|---|---|---|---|
| Toestemming van de gebruiker vereist? | |||
| Werkt met persoonlijke Gmail? | |||
| Multi-tenant SaaS? | |||
| Tokenbeheer | Uw code slaat tokens op en vernieuwt ze Veeleisend |
Serviceaccount JSON-sleutel Beheerder-beheerd |
Unipile beheert alle tokens Geen onderhoud |
| Google toestemmingsscherm beoordeling? | |||
| Ondersteunt ook Outlook + IMAP? | |||
| Tijd tot eerste e-mail gelezen | 2-4 uur installatie OAuth-app + scopes + toestemmingsscherm |
1-2 uur installatie Workspace beheerder vereist |
Onder de 15 minuten API-sleutel + gekoppelde account |
| Het beste voor | SaaS-apps die de Gmail-accounts van externe gebruikers koppelen | Interne Workspace-tools voor uw organisatie | Elke e-mail API-gebruikssituatie - geen OAuth-bewerkingen |
Pad 1 - OAuth 2.0 Client ID (Multi-Tenant SaaS)
Als je een SaaS-product bouwt waarbij klanten hun eigen Gmail-accounts koppelen, is de OAuth 2.0 autorisatiecode-flow de standaardprocedure. Dit is de 3-legged flow: jouw app, Google en de eindgebruiker. Het vereist het instellen van een Google Cloud-project en het doorlopen van het instemmingsscherm verificatieproces voor gevoelige scopes. Voor een diepere duik in de OAuth-stroom voor e-mail-API's in detail, zie onze speciale gids.
Maak OAuth 2.0-referenties in Google Cloud Console aan
Ga naar API's en services > Referenties > Referenties maken > OAuth-client-id. Kies "Webtoepassing". Configureer de geautoriseerde omleidings-URI's voor uw app. Hiermee wordt uw klant_id en cliënt_geheim.
Schakel de Gmail-API in en definieer je scopes
Ga naar API's en services > OAuth-toestemmingsscherm. Voeg de benodigde Gmail-bereiken toe (bijv. gmail.alleenlezen, gmail.verzenden). Gevoelige en beperkte bereiken vereisen Google-verificatie, een proces dat dagen tot weken duurt.
Gebruikers doorverwijzen naar de autorisatie-URL van Google
Wanneer een gebruiker in jouw app op "Gmail verbinden" klikt, leid je deze door naar Google met jouw klant_id, scopes en omleiding_uri. Nadat ze goedkeuren, stuurt Google een autorisatiecode terug naar je doorverwijzings-URI.
Wissel de code in voor tokens en sla het vernieuwingstoken op
POST de autorisatiecode naar de token-eindpunt van Google. Je ontvangt een toegangstoken (verloopt ~1u) en een vernieuwingstoken (langdurig). Sla de refresh token veilig op – het is de manier om nieuwe access tokens te verkrijgen zonder de gebruiker opnieuw te hoeven vragen.
const { google } = require('googleapis');
const oauth2Client = nieuw google.auth.OAuth2(
process.env.GMAIL_CLIENT_ID,
process.env.GMAIL_CLIENT_SECRET,
process.env.GMAIL_REDIRECT_URI
);
// Stap 1: Bouw de autorisatie-URL
const authUrl = oauth2Client.genereerAuthUrl({
toegangstype: 'offline', // vernieuwingstoken ophalen
bereik: [
'https://www.googleapis.com/auth/gmail.readonly',
'https://www.googleapis.com/auth/gmail.send'
]
});
// Stap 2: Wissel code in voor tokens (in uw callback handler)
async function handleCallback(code) {
const { tokens } = wacht op oauth2Client.token_ophalen(code);
oauth2Client.stuurAanmeldgegevens(tokens);
// Bewaar tokens.refresh_token veilig in uw DB
return tokens;
}
// Stap 3: Gebruik het toegangstoken om de Gmail API aan te roepen
async function lijstBerichten(accessToken) {
const gmail = google.gmail({ versie: 'v1', auth: oauth2Client });
const res = wacht op gmail.users.messages.list({ gebruikerId: "mij });
return res.data.berichten;
}Het op grote schaal beheren van vernieuwingstokens is het grootste struikelblok In zelf beheerd Gmail OAuth. Tokenrotatie, database migraties, stille fouten bij verlopen tokens - dit alles wordt automatisch afgehandeld wanneer u gebruik maakt van een verenigde e-mail API-provider.
Bouw uw Gmail-integratiePad 2 - Serviceaccount + Domeinbrede delegatie (Workspace Intern)
Als uw toepassing binnen een Google Workspace-organisatie wordt gebruikt – denk aan interne tools, HR-automatisering of een bedrijfsbreed dashboard voor e-mailanalyses – kunt u met serviceaccounts met Domain-Wide Delegation (DWD) toegang krijgen tot mailboxen zonder dat daarvoor toestemming van elke gebruiker afzonderlijk nodig is. Een Workspace-beheerder verleent de delegatie eenmalig. Belangrijk: deze methode werkt niet voor persoonlijke Gmail-adressen.
Serviceaccounts hebben geen toegang tot persoonlijke Gmail-accounts (@gmail.com). DWD werkt alleen binnen een Google Workspace-domein. Als uw gebruikers zich aanmelden met een persoonlijk Gmail-adres, moet u methode 1 (OAuth-client-ID) of methode 3 (Unified API) gebruiken. Als u DWD probeert te gebruiken op een persoonlijk account, krijgt u een 403-foutmelding.
Beheerder van de werkruimte vereist: DWD moet worden geconfigureerd door een Google Workspace-beheerder op admin.google.com. Als ontwikkelaar zonder beheerdersrechten kun je dit niet doen.
JSON-sleutelbeveiliging: De JSON-sleutel van de serviceaccount is een langdurig geldig inloggegeven. Behandel het als een privésleutel: roteer het regelmatig en check het nooit in bij broncodebeheer.
Scopeverklaring vereist: De beheerder moet elke Gmail-scope expliciet goedkeuren tijdens de DWD-configuratie. Je kunt geen scopes aanvragen tijdens runtime. Zie Google's DWD-handleiding.
van google.oauth2 importeer serviceaccount
van googleapiclient.discovery importeer bouwen
# Pad naar de JSON-sleutel van uw serviceaccount
SERVICEACCOUNT_BESTAND = 'service-account.json'
SCOPES = [
'https://www.googleapis.com/auth/gmail.readonly'
]
# Je voordoen als een gebruiker in je Workspace-domein
# (domeinbrede delegatie moet door de beheerder worden ingeschakeld)
def gmail_service_ophalen(user_email):
credit = service_account.Credentials.van_serviceaccountbestand(
SERVICE_ACCOUNT_BESTAND,
scopes=SCOPES
)
# Dit is domeinbrede delegatie: zich voordoen als gebruiker
gedelegeerde_inloggegevens = credits.met_onderwerp(e-mailadres_gebruiker)
return bouwen('Gmail', 'v1', inloggegevens=gedelegeerde_aanmeldingen
# Lijst met berichten voor een gebruiker van de werkruimte
service = gmail_service_ophalen('alice@yourcompany.com')
resultaten = service.users().berichten().list(
gebruikersId="mij
).uitvoeren()Pad 3 - Unified E-mail API (Sla de OAuth Boilerplate over)
Als het uw doel is om e-mail te lezen, te verzenden of te synchroniseren in een productie SaaS-applicatie - en u liever geen engineeringcycli besteedt aan het beheren van OAuth-infrastructuur - abstraheert een uniforme e-mail-API zoals Unipile de gehele authenticatielaag. Begrijp hoe e-mail synchronisatie onder de motorkap werkt, of ga direct naar de code. Deze aanpak geeft je ook Gmail, Outlook en IMAP onder één API - geen aparte integratie voor elke provider.
Geen Google Cloud-installatie vereist
Geen OAuth-client-id, geen instemmingsscherm, geen scope review met Google. Unipile's eigen geverifieerde OAuth-app regelt gebruikersautorisatie.
Automatische tokenrotatie
Access tokens en refresh tokens worden volledig beheerd door Unipile. Je database slaat nooit een Google OAuth-token op.
Werkt voor persoonlijke Gmail + Outlook + IMAP
Eén API, drie provider-universums. Wanneer u e-mail synchronisatie API-providers vergelijken, cross-providerondersteuning is een belangrijke onderscheidende factor.
Webhooklevering bij nieuwe berichten
In plaats van de API van Gmail te bevragen, stuurt Unipile nieuwe e-mailgebeurtenissen in realtime naar uw webhook-endpoint, per gekoppeld account.
// 3 regels om een Gmail mailbox te lezen via Unipile
// Geen OAuth-instelling, geen tokenbeheer
const { UnipileClient } = require('unipile-node-sdk');
const klant = nieuw UnipileClient({
token: process.env.UNIPILE_API_KEY
});
E-mails uit een gekoppeld Gmail-account weergeven
// accountId = de Unipile gelinkte account-ID
const e-mails = wacht op client.e-mail.lijstBerichten({
account_id: 'gekoppeld-account-id',
beperken: 20
});
// Verzenden van een e-mail namens het gekoppelde account
wacht op client.e-mail.verzenden({
account_id: 'gekoppeld-account-id',
to: 'recipient@example.com',
onderwerp: 'Hallo van Unipile',
body: 'Geen OAuth-token in zicht.'
});
// Werkt identiek voor Outlook en IMAP
// Wissel alleen de account_idBouw uw Gmail-integratie zonder OAuth-operaties
Begin met de Volledige integratiehandleiding voor de Gmail API, dien deze vervolgens in met Unipile als uw authenticatie- en synchronisatielaag.
Veelvoorkomende fouten bij het gebruik van een API-sleutel met Gmail
Als u op dit artikel bent gestuit omdat uw Gmail API-aanroep mislukt, vindt u hier de twee fouten die u zult tegenkomen en wat elke fout precies betekent - met de volledige responsbody zodat u ze direct herkent.
U stuurde een verzoek naar de Gmail API met een API-sleutel?sleutel=AIza...) of zonder enige autorisatie. Gmail API vereist een geldig OAuth 2.0 toegangstoken in de Autorisatie: aan toonder kop. Dit is de eerste fout die je zult zien bij het experimenteren met een API-sleutel voor de eerste keer.
Repareren: Implementeer een van de 3 bovenstaande authenticatiepaden. De API-sleutel is niet de oplossing - je hebt een OAuth-toegangstoken nodig.
HTTP/1.1 401 Niet geautoriseerd
Content-Type: application/json
{
"fout": {
"code": 401,
"message": "Verzoek mist
vereiste authenticatie
referentie. Verwacht OAuth 2
toegangstoken, login cookie
of andere geldige authenticatie
referentie. Zie https://
developers.google.com/
identity/sign-in/web/...",
"status": "UNAUTHENTICATED",
"errors": [{
"message": "Login vereist",
"domain": "googleapis.com",
"reason": "vereist",
"location": "Authorization",
"locationType": "header"
}]
}
}Na herhaaldelijk ongeauthenticeerde verzoeken (zelfs met een API-sleutel) blokkeert Google's quotumsysteem verdere ongeauthenticeerde aanroepen vanaf uw IP-adres of project. Dit is geen snelheidslimiet voor gemachtigde gebruikers - het betekent specifiek dat uw verzoeken zijn nooit geauthentiseerd en je hebt de kleine gratis limiet voor anonieme oproepen opgebruikt.
Repareren: Hetzelfde als hierboven - uw API-sleutelbenadering zal nooit werken. Gebruik OAuth 2.0-toegangstokens. Deze fout zal verdwijnen zodra uw verzoeken een geldig Bearer-token bevatten.
HTTP/1.1 403 Verboden
Content-Type: application/json
{
"fout": {
"code": 403,{
"message": "Daglimiet voor
niet-geauthenticeerd gebruik overschreden.
Voortgezet gebruik vereist
registratie.",
"status": "RESOURCE_EXHAUSTED",
"errors": [{
"message": "Daglimiet voor
niet-geauthenticeerd gebruik
overschreden.",
"domain": "usageLimits",
"reason":
"dailyLimitExceededUnreg"
}]
}
}Gmail API Scopes Die Je Echt Nodig Hebt
Zodra je accepteert dat OAuth vereist is, is de keuze van de scope de volgende cruciale beslissing. Google classificeert Gmail-scopes in drie niveaus op basis van de gevoeligheid van de gegevens die ze blootleggen. Het aanvragen van meer dan je nodig hebt, leidt tot een langer verificatieproces - en in sommige gevallen, een volledige veiligheidsbeoordeling door Google.
Gevoelige bereiken (geel) vereist dat Google uw OAuth-instemmingsscherm beoordeelt en uw privacybeleid van de app verifieert. Beperkte bereiken (rood) vereist een formele beveiligingsbeoordeling, een videog demonstratie en soms een beveiligingsaudit door derden. Plan minimaal 2-6 weken voor goedkeuring met een beperkte scope. Als je Unipile gebruikt als je authenticatielaag, valt dit verificatieproces op Unipile - niet op je app.
| Reikwijdte | Toegangsniveau | Niveau | Gebruikscasus |
|---|---|---|---|
| gmail.alleenlezen | Lees alle berichten, threads, labels, instellingen | Gevoelig | E-mailanalyses, inbox audit tools, CRM-synchronisatie (alleen-lezen) |
| gmail.verzenden | E-mail verzenden namens de gebruiker | Gevoelig | Transactionele e-mails aan de gebruikerskant, CRM-follow-ups, outreach-tools |
| gmail_opstellen | Concepten maken, lezen, bijwerken, verwijderen; berichten verzenden | Gevoelig | E-mailcomponistintegraties, conceptbeheer |
| gmail-aanpassen | Lezen, verzenden, wijzigen (labels, archiveren) - niet verwijderen | Beperkt | Volledig e-mailinboxbeheer, CRM-synchronisatie met schrijfcapaciteit, archiveringsworkflows |
| mail.google.com | Volledige toegang - lezen, schrijven, verwijderen, instellingen | Beperkt | Volwaardige e-mailclients, back-uptools, migratie voor beheerders |
| gmail.metadata | Alleen berichtmetadata (geen inhoud) | Niet-gevoelig | Analyses van e-mailvolume, afzender/ontvangerpatronen (geen inhoud) |
Een multi-tenant SaaS bouwen dat Gmail.modify of mail.google.com nodig heeft? De beperkte scope review voegt weken toe aan je lanceringsschema. Met Unipile sla je de beoordeling van het toestemmingsscherm volledig over - de geverifieerde OAuth-app van Unipile dekt de scopes die je integratie nodig heeft.
Bouwen met UnipileBeslissingsboom: Welke Authenticatiemethode voor Uw Gebruikssituatie?
Beantwoord drie vragen en je weet precies welk Gmail API-authenticatiepad van toepassing is op je project. Er is geen universeel antwoord - elk pad lost een ander probleem op. Voor de volledige Volledige integratiehandleiding voor de Gmail API, ga verder naar de Gmail hub. Voor de equivalent voor Outlook / Microsoft 365, zie onze Microsoft Graph OAuth-handleiding.
SaaS-app waarbij klanten hun eigen Gmail koppelen
Zijn uw gebruikers extern (geen werknemers)?
Ja - het zijn jouw klanten met persoonlijke Gmail- of Google Workspace-accounts.
Moet je veel verschillende Google-domeinen ondersteunen?
Ja - multi-tenant. Elke gebruiker verbindt zijn eigen account.
Of Pad 3 (Unified API) om de OAuth-infrastructuur volledig over te slaan.
Interne tool voor je eigen Google Workspace-organisatie
Zijn alle gebruikers in hetzelfde Workspace domein (uw medewerkers)?
Ja - alleen accounts van company.com. Geen externe Gmail-gebruikers.
Heeft u een Workspace-beheerder die DWD kan configureren?
Ja - beheerders toegang is beschikbaar in admin.google.com.
Geen toestemmingsstromen per gebruiker. Beheerder delegeert eenmalig.
SaaS-app die Gmail, Outlook en IMAP onder één API nodig heeft
Hebben uw gebruikers een mix van Gmail-, Outlook- en IMAP-accounts?
Ja - je kunt niet voorspellen met welke provider de gebruiker verbinding zal maken.
Wil je het vermijden om aparte OAuth-integraties per provider te draaien?
Ja - het beheren van Google OAuth + Microsoft OAuth + IMAP is te veel complexiteit.
Eén API-sleutel. Gmail, Outlook, IMAP. Geen OAuth-bewerkingen.
Begin vandaag nog met het bouwen van uw Gmail-integratie
Welk pad je ook kiest, Unipile geeft je een overzicht unified email API om de architectuur te begrijpen voordat u zich aan een aanpak committeert. Of ga rechtstreeks naar het dashboard en koppelt u uw eerste account binnen enkele minuten.
Veelgestelde vragen
De meest gestelde vragen over Gmail API-authenticatie, API-sleutels versus OAuth-tokens, en hoe programmatisch toegang te krijgen tot Gmail zonder zelf OAuth te beheren.
Kan ik een Google API-sleutel gebruiken om toegang te krijgen tot Gmail?
Nee. Google API-sleutels werken alleen voor openbare, niet-gebruiker-specifieke API's, zoals Maps, Translate of YouTube Data (openbare inhoud). De Gmail API heeft toegang tot privégegevens van de mailbox van de gebruiker, waarvoor expliciete toestemming van de gebruiker vereist is via OAuth 2.0. Het verzenden van een verzoek naar de Gmail API met alleen een API-sleutel retourneert een 401 Inloggen Vereist of 403 Dagelijkse limiet voor niet-geauthenticeerd gebruik overschreden fout - elke keer, zonder uitzondering.
Vereist de Gmail API OAuth 2.0?
Ja, altijd. Gmail API-toegang is toegang tot gebruikersgegevens, wat betekent dat elke aanvraag gekoppeld moet zijn aan een geauthenticeerde gebruiker die toestemming heeft gegeven via een OAuth 2.0-stroom. Er is geen omweg: geen API-sleutel, geen Basic Auth (verouderd september 2024), geen magische header. De drie ondersteunde authenticatiepaden zijn: OAuth 2.0 Client ID (multi-tenant), Service Account met domeinbrede delegatie (alleen Workspace) en een uniforme e-mail-API zoals Unipile die de OAuth-laag voor u afhandelt.
Wat is het verschil tussen een API-sleutel en een OAuth-client-ID op Google Cloud?
Een API-sleutel identificeert uw Google Cloud-project voor facturering en quota. Het werkt alleen voor API's die openbare gegevens leveren (Maps, Translate, enz.). Een OAuth-client-ID wordt gebruikt om een toestemmingsstroom te starten waarbij een echte gebruiker de toegang van uw app tot hun account goedkeurt. De OAuth-client-ID genereert de toegangstoken en vernieuwingstoken die de Gmail API daadwerkelijk accepteert. Dit zijn twee volledig verschillende mechanismen: de ene identificeert een project, de andere authenticatieert een gebruiker.
Kan een serviceaccount Gmail lezen zonder toestemming van de gebruiker?
Alleen indien Domeinwijde delegatie (DWD) wordt ingeschakeld door een Google Workspace-beheerder. Een serviceaccount kan op zichzelf geen toegang krijgen tot een Gmail-inbox. Met DWD geconfigureerd, kan het serviceaccount elke gebruiker in de organisatie imiteren en toegang krijgen tot hun postvak zonder interactieve toestemming. Cruciale beperking: dit werkt alleen voor Google Workspace (zakelijke) accounts. Het werkt niet voor persoonlijke Gmail-adressen (@gmail.com). Zie Officiële DWD-documentatie van Google.
Waarom retourneert de Gmail API "Login Required" met mijn API-sleutel?
Omdat Gmail API accepteert geen API-sleutels. De 401 Inloggen Vereist fout betekent dat het verzoek een ongeldige OAuth 2.0 toegangstoken mist in de Authorization header. Gmail API verwacht: Autorisatie: Bearer {access_token} - waar de toegangstoken werd verkregen via een OAuth 2.0-stroom (autorisatiecode, serviceaccount JWT of een uniforme API-token). Eenvoudigweg toevoegen ?sleutel=JOUW_API_SLEUTEL naar de Gmail API URL zal niet werken en zal 401 of 403 retourneren.
Is er een manier om de Gmail API te gebruiken zonder OAuth zelf te beheren?
Ja. Een uniforme e-mail-API zoals Eenpaal behandelt de gehele OAuth-laag: het toestemmingsscherm, de tokenuitwisseling en de stille rotatie van de vernieuwingstokens. Uw applicatie slaat nooit toegangstokens of vernieuwingstokens op of beheert deze. U roept de Unipile API aan met uw eigen API-sleutel en Unipile regelt alle OAuth-communicatie met Google namens uw gekoppelde accounts. Dit verwijdert het goedkeuringsproces van het Google-toestemmingsscherm en de complexiteit van het tokenbeheer uit uw codebase - en biedt u Gmail, Outlook en IMAP onder één uniforme interface.
NL 
EN 
FR 
ES 
DE 
IT 
BR 
PL 
TR