OAuth E-mail API: E-mailboxen van gebruikers authenticeren De juiste manier
Stop met het opslaan van wachtwoorden. Een OAuth e-mail API laat je app veilig toegang krijgen tot de inboxen van gebruikers - met de mogelijkheid om tokens van Gmail, Outlook en IMAP providers in te trekken en met beperkte reikwijdte. Deze gids behandelt elke OAuth-flow, elke reikwijdte, elke valkuil, en hoe je binnen 5 minuten live kunt gaan met een uniforme, gehoste authenticatielaag.
// Koppel elke gebruikersmailbox via OAuth - 1 API-aanroep
const response = wacht op fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: POST,
headers: {
'X-API-KEY': 'JOUW_API_SLEUTEL',
'Content-Type': "toepassing/json
},
body: JSON.stringify({
type: 'GOOGLE', // of MICROSOFT, IMAP
naam: 'gebruiker_123'
})
}
);
const { url } = wacht op antwoord.json();
// Gebruiker omleiden naar url - OAuth afgehandeld door UnipileWat is een OAuth e-mail API?
Een OAuth e-mail API is een programmatische interface die uw applicatie toegang geeft tot gebruikersmailboxen met behulp van OAuth 2.0-tokens - zonder ooit het wachtwoord van de gebruiker te verwerken of op te slaan. In plaats van gebruikers om inloggegevens te vragen, leidt u hen door het toestemmingsscherm van de provider, ontvangt u een kortstondige toegangstoken en gebruikt u deze om namens hen e-mails te lezen, te verzenden of te synchroniseren. Het onderscheid is belangrijk: het gaat hier om toegang tot gebruikers-eigendom van e-mailboxen (Gmail, Outlook, persoonlijke e-mail), geen transactie-e-mails verzenden via SMTP-relaisdiensten zoals SendGrid.
Een OAuth e-mail API is een combinatie van een OAuth 2.0 autorisatiestroom (om een gebruiker te authenticeren en gedelegeerde toegang te verkrijgen) en een e-mail-API (om de mailbox van die gebruiker te lezen, verzenden, doorzoeken of synchroniseren). De OAuth-laag genereert een cryptografisch ondertekend, intrekbaar, scope-beperkt toegangstoken. De e-mail-API gebruikt dat token om te interageren met Gmail, Outlook of elke IMAP-compatibele mailbox - allemaal zonder ooit het wachtwoord van de gebruiker te kennen.
- Slaat platte tekst of versleutelde wachtwoorden op in je database
- Volledige toegang tot de mailbox - geen scopebeheer
- Geblokkeerd door Google/Microsoft sinds 2026
- Aansprakelijkheid voor het opslaan van inloggegevens onder de AVG/SOC2
- Geen wachtwoordopslag - alleen kortstondige tokens
- Granulaire scopes - alleen-lezen, alleen-verzenden, of volledig
- Te allen tijde herroepbaar door de gebruiker
- Voldoet aan de GDPR, SOC2
Waarom OAuth wachtwoordgebaseerde e-mailtoegang verving
IMAP gebruiken met een gebruikersnaam en wachtwoord was vroeger de standaardmanier om programmatisch toegang te krijgen tot e-mail van gebruikers. Dat tijdperk is voorbij. Google heeft basisauthenticatie voor Gmail in 2022 afgeschaft en Microsoft voltooide in oktober 2022 de stopzetting van basisauthenticatie voor Exchange Online, met de definitieve opruiming voor resterende protocollen in 2026. Als uw applicatie nog steeds afhankelijk is van IMAP-toegang op basis van wachtwoorden, is deze al defect of zal deze binnenkort defect raken.
OAuth-tokens zijn kortstondig (meestal 1 uur) en scope-begrensd. Zelfs als ze worden gelekt, kunnen ze niet worden gebruikt om als de gebruiker in te loggen, hun wachtwoord te wijzigen of toegang te krijgen tot andere services. Je raakt nooit de inloggegevens van de gebruiker aan.
Microsoft heeft in 2026 de beëindiging van basale authenticatie voor Exchange Online en verouderde IMAP voltooid. Elke app die nog steeds gebruikersnaam + wachtwoord gebruikt om toegang te krijgen tot Outlook- of Microsoft 365-mailboxen, zal 401 Unauthorized-fouten ontvangen.
Het opslaan van gebruikerswachtwoorden, zelfs gehasht, creëert een compliance-aansprakelijkheid. Het principe van gegevensminimalisatie van de AVG vereist dat je niet verzamelt wat je niet nodig hebt. SOC2-auditors signaleren opslag van inloggegevens.
Kritiek Google App-wachtwoorden en verouderde Microsoft-protocollen zijn niet langer voldoende voor productieapplicaties. Als u een product bouwt dat toegang heeft tot gebruikersmailboxen, een OAuth e-mail API is niet optioneel - het is het enige conforme pad vooruit in 2026.
Hoe OAuth werkt voor e-mail-API's (stap-voor-stap)
De autorisatiecode-stroom is de standaard OAuth 2.0-stroom voor server-side applicaties die toegang nodig hebben tot e-mail van gebruikers. Het end-to-end begrijpen helpt u deze correct te implementeren, fouten met tokens op te sporen en de stroom uit te leggen aan uw beveiligingsteam.
Je construeert een URL met je klant_id, een omleiding_uri, het gevraagde bereik, een willekeurig staat parameter (CSRF-bescherming), en response_type=code. De gebruiker wordt doorgestuurd naar het toestemmingsscherm van Google of Microsoft.
Het toestemmingsscherm toont de naam van je app, het logo en de exacte machtigingen die je hebt aangevraagd. De gebruiker keurt goed (geeft toestemming) of weigert. Te veel scopes aanvragen in deze stap is de meest voorkomende reden voor het weigeren van toestemming.
Na de toestemming stuurt de provider je door naar je omleiding_uri met een kortstondige code parameter (geldig voor ~10 minuten). Verifieer de staat parameter komt overeen met wat je hebt gestuurd om CSRF-aanvallen te voorkomen.
Een POST-verzoek van server naar server naar het token-eindpunt met uw klant_id, cliënt_geheim, de codeen grant_type=authorization_code. U ontvangt een toegangstoken en (als je offline toegang hebt aangevraagd) een vernieuwingstoken.
Geef het toegangstoken door in de Autorisatie: aan toonder header bij elke API-aanvraag. Wanneer deze verloopt (meestal na 1 uur), gebruik de refresh token om zonder gebruikersinteractie een nieuwe access token te verkrijgen.
Toegangstokens versus vernieuwingstokens: levenscyclus
Geldig gedurende 1 uur (Google) of 1 uur (Microsoft). Wordt bij elke API-aanroep doorgegeven in de Authorization-header. Wanneer de geldigheidsduur is verstreken, retourneert je OAuth-e-mail-API-aanroep een 401-foutmelding – het teken dat je de token moet vernieuwen.
Geldig tot intrekking (Google) of 90 dagen inactiviteit (Microsoft). Wordt nooit naar API-eindpunten verzonden - wordt alleen server-to-server gebruikt om nieuwe toegangstokens te verkrijgen. Moet versleuteld zijn tijdens rust.
Bouw een uniforme OAuth-stroom in minuten
Sla de per-provider autorisatie-implementatie over. Eén Unipile API-aanroep vervangt drie OAuth-integraties.
OAuth-stromen per provider: Google en Microsoft
Google en Microsoft implementeren OAuth 2.0 elk op een andere manier: verschillende autorisatie-eindpunten, verschillende scopes, verschillende token-eindpunten en verschillende verificatieprocessen. IMAP is de op inloggegevens gebaseerde alternatieve oplossing voor providers die geen gestandaardiseerde OAuth ondersteunen. Hieronder vind je wat je in elk geval moet weten.
De OAuth-implementatie van Google maakt gebruik van de standaardautorisatiecodestroom. Het token-eindpunt is https://oauth2.googleapis.com/token. De kritieke complexiteit is Google CASA (Cloud Application Security Assessment): zodra je app meer dan 100 gebruikers heeft, moet je een beveiligingsbeoordeling doorstaan. Voor gevoelige scopes zoals gmail-aanpassen of gmail.alleenlezen, App-verificatie is vereist vóór productiegebruik. Voor een volledige Gmail API-integratie een diepgaande analyse, zie onze speciale gids. Implementatiedetails staan in de Unipile Google OAuth-documentatie.
#-autorisatiecode voor toegang tot Gmail + vernieuwingstokens
krul -X POST https://oauth2.googleapis.com/token \
-d "code=AUTH_CODE" \
-d "client_id=JOUW_CLIENT_ID" \
-d "client_secret=JOUW_CLIENT_GEHEIM" \
-d "redirect_uri=https://yourapp.com/callback" \
-d "grant_type=authorization_code"
#-antwoord: { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }Microsoft maakt gebruik van zijn Identity Platform (voorheen Azure AD v2). Het token-eindpunt is https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. Er is een uitgeversverificatie vereist voordat uw OAuth-e-mail-API-app in de productieomgeving toegang kan aanvragen tot gevoelige e-mailbereiken. Microsoft heeft basisauthenticatie voor alle Exchange Online-protocollen afgeschaft – OAuth is verplicht. Zie onze Microsoft Graph e-mailgids voor alle details, en de Unipile Microsoft OAuth-documentatie ter referentie bij de implementatie.
#-uitwisselingscode voor Microsoft OAuth-tokens
krul -X POST https://login.microsoftonline.com/common/oauth2/v2.0/token \
-d "code=AUTH_CODE" \
-d "client_id=JOUW_CLIENT_ID" \
-d "client_secret=JOUW_CLIENT_GEHEIM" \
-d "redirect_uri=https://yourapp.com/callback" \
-d "grant_type=authorization_code" \
-d "scope=https://graph.microsoft.com/Mail.Read offline_access"
#-antwoord: { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }IMAP is geen OAuth-provider: het is een protocol dat authenticeert met gebruikersnaam/wachtwoord, of app-wachtwoorden (zoals een Google App-wachtwoord of een door iCloud gegenereerd wachtwoord). Het is de fallback voor aangepaste mailservers, bedrijfsdomeinen die niet op Microsoft 365 staan, en elke provider zonder een gestandaardiseerde OAuth-flow. XOAUTH2 bestond als een IMAP SASL-extensie voor een klein aantal providers, maar is grotendeels verlaten – Yahoo stopte in 2022 met zijn eigen implementatie. Voor de meeste IMAP-implementaties authenticeert Unipile rechtstreeks met inloggegevens. Zie de volledige IMAP-integratiehandleiding voor serverconfiguratie en authenticatiegegevens.
importeer base64, imaplib
# XOAUTH2-string samenstellen op basis van OAuth-toegangstoken
def build_xoauth2(user_e-mailadres, toegangstoken):
auth_str = user={user_email}\x01auth=Bearer {access_token}\x01\x01"
return base64.b64encode(auth_str.encode()).decode()
# Verbinding maken via IMAP met XOAUTH2
verbinden = imaplib.IMAP4_SSL("imap.mail.yahoo.com")
auth_str = build_xoauth2("user@yahoo.com", toegangstoken)
conn.authenticeren("XOAUTH2", lambda x: auth_str)De Verborgen Complexiteit van Multi-Provider OAuth
Het implementeren van een OAuth e-mail API voor één provider kost een paar dagen. Het correct implementeren hiervan voor Gmail, Outlook en IMAP - met productieklare tokenbeheer, foutafhandeling en naleving - kost doorgaans 4 tot 8 weken aan engineeringtijd. Hier leest u waarom.
Google Cloud Console, Azure Portal en Yahoo Developer Network zijn 3 volledig verschillende dashboards met verschillende gebruikerservaringen, verschillende workflows voor app-registratie en verschillende verificatievereisten. Elke rotatie van inloggegevens raakt alle 3.
Gmail's gevoelige bereiken (inclusief gmail.alleenlezen) worden beperkt tot 100 gebruikers totdat u een CASA Tier 2-beoordeling hebt doorlopen. Dit omvat een door CASA erkend laboratorium, een penetratietest en een formele beveiligingsbeoordeling – doorgaans 6 tot 12 weken en 10.000 tot 25.000 AUD.
Microsoft vereist Publisherverificatie voor apps die gevoelige Mail-scopes aanvragen. Zonder dit zien gebruikers een rode "geverifieerde uitgever" waarschuwing op het toestemmingsscherm. Het verificatieproces vereist een actief Microsoft Partner Network-account met een geverifieerd domein.
Google refresh tokens verlopen na 6 maanden inactiviteit (of onmiddellijk als de gebruiker ze intrekt). Microsoft tokens verlopen na 90 dagen inactiviteit. Yahoo/IMAP XOAUTH2 tokens hebben provider-specifieke levensduren. Uw tokenbeheerlaag moet met alle 3 verschillend omgaan.
Google, Microsoft en Yahoo tonen elk toestemmingsschermen anders - verschillende branding, verschillende beschrijvingen van de reikwijdte, verschillende UI-patronen. Uw gebruikers zien 3 verschillende flows, afhankelijk van hun e-mailprovider, wat zorgt voor een inconsistente gebruikerservaring en hogere afhaakpercentages.
OAuth-eindpunten veranderen. Scopenamen worden verouderd. Nieuwe beveiligingseisen worden toegevoegd. Elke provider kondigt ingrijpende wijzigingen aan op verschillende tijdlijnen. Iemand in je team moet 3 providerblogs, 3 wijzigingslogboeken en 3 compliancekalenders bijhouden - voor onbepaalde tijd.
Sla de OAuth-complexiteit volledig over
Gehoste authenticatie, scopebeheer, afhandeling van vernieuwingen. Unipile regelt het allemaal, zodat jij je kunt richten op je product.
OAuth E-mail API Architectuur: 3 Benaderingen Vergeleken
Er zijn 3 architecturen voor het bouwen van een OAuth e-mail API-laag. Elk heeft een fundamenteel andere kostenstructuur voor lancering, onderhoudslast en beveiligingsprofiel. De juiste keuze hangt af van of e-mailconnectiviteit uw kernproduct is of een functie die u naast uw hoofdproduct lanceert.
| Afmeting | Directe Provider OAuth (x3) | Zelf gehoste OAuth-gateway | Gecentraliseerde Gehoste OAuth (Unipile) Aanbevolen |
|---|---|---|---|
| Tijd tot eerste gekoppelde postvak | 3-7 dagen (per aanbieder) | 2-4 weken | 5 minuten |
| OAuth-stromen om te implementeren | 3 afzonderlijke stromen | 3 stromen + routeringslogica | 1 gehoste link-eindpunt |
| Google CASA beoordeling | Dat regel je zelf (6-12 weken, $10k+) | Jij regelt het | Afgehandeld door Unipile |
| Microsoft Publisher Verificatie | Jij regelt het | Jij regelt het | Afgehandeld door Unipile |
| Tokenvernieuwingsbeheer | 3 strategieën om te bouwen | Aanpassing per provider | Automatisch, transparant |
| E-mail lezen/verzenden API | 3 verschillende API's | Abstraheringslaag vereist | 1 uniforme REST API |
| Webhook bij nieuwe e-mails | Push/pull per provider | Aangepast | Geünificeerde webhook-gebeurtenissen |
| SOC2 / AVG-naleving | Uw verantwoordelijkheid | Uw verantwoordelijkheid | Unipile is SOC2 gecertificeerd |
| Lopend onderhoud | Hoog (3 wijzigingslogboeken van providers) | Hoog | Nul - afgehandeld door Unipile |
| Het beste voor | Eén-leverancier, e-mail-native producten | Grote teams met toegewijde infrastructuur | Elk team dat snel levert |
Build vs Buy: Gehoste OAuth E-mail API in 5 minuten
In plaats van 3 aparte OAuth-stromen te bouwen, biedt Unipile een gehoste authenticatielink die Google OAuth, Microsoft Identity en IMAP OAuth voor u afhandelt. Uw app genereert een link, leidt de gebruiker om en ontvangt een webhook wanneer de mailbox is gekoppeld. De OAuth e-mail API is vervolgens direct bruikbaar - geen console-instellingen, geen CASA-beoordeling, geen token-verversingslogica om te bouwen.
Stap 1: Genereer een gehoste authenticatielink
Eén API-oproep om een gehoste authenticatiesessie te creëren. Specificeer het provider type en een naam voor het account. Unipile retourneert een URL om uw gebruiker naar het OAuth-toestemmingsscherm te leiden.
// Gmail-gebruiker verbinden via Unipile gehoste OAuth e-mail-API
const response = wacht op fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: POST,
headers: {
'X-API-KEY': 'UW_UNIPILE_API_SLEUTEL',
'Content-Type': "toepassing/json
},
body: JSON.stringify({
type: 'GOOGLE',
naam: 'gebruiker_alice_123',
success_redirect_url: 'https://jouwapp.com/connected',
failure_redirect_url: 'https://jouwapp.nl/fout'
})
}
);
const { url, object } = wacht op antwoord.json();
// Gebruiker omleiden naar url - Unipile handelt OAuth-toestemming af
window.location.href = url;Stap 2: Verbind een Outlook-gebruiker
Hetzelfde eindpunt, hetzelfde patroon. Wijzigen type naar MICROSOFT. Geen Azure Portal, geen Publisher Verification om aan uw kant te beheren.
importeer verzoekt
#: Outlook-gebruiker verbinden via de Unipile OAuth-e-mail-API
response = verzoeken.post(
"https://api6.unipile.com:13226/api/v1/hosted/accounts/link",
headers={"X-API-SLEUTEL": "UW_UNIPILE_API_SLEUTEL"},
json={
"type": "MICROSOFT",
"naam": "gebruiker_bob_456",
"success_redirect_url": "https://jouwapp.nl/verbonden"
}
)
auth_url = response.json()["url"]
# Doorverwijzing naar auth_url - Microsoft-identiteitsstroom afgehandeld door UnipileStap 3: Ontvang de webhook op account.connected
Nadat je toestemming hebt gegeven via OAuth, stuurt Unipile een webhook naar jouw endpoint. De event payload bevat de nieuwe account_id - die je opslaat en gebruikt voor alle volgende e-mail API lezen en e-mail Verzenden API oproepen.
Webhookgebeurtenis: Wanneer een gebruiker OAuth voltooit, stuurt Unipile een account.verbonden gebeurtenis naar uw webhook-URL. De payload bevat de account_id (bewaar dit), de provider (GOOGLE / MICROSOFT / IMAP), en het gekoppelde e-mailadres. Dit is de enige status die u hoeft op te slaan - Unipile beheert alle OAuth-tokens intern.
Sla de 8 weken durende OAuth-implementatie over. Koppel e-mailaccounts in minuten.
De gehoste OAuth e-mail API van Unipile ondersteunt Google CASA, Microsoft Publisher Verification, XOAUTH2 en token vernieuwing voor alle providers. Uw gebruikers koppelen hun mailbox via een enkele gehoste flow - u krijgt een uniforme API om e-mails te lezen, te verzenden en te synchroniseren.
OAuth-tokens beheren: Vernieuwen, Intrekken, Roteren
Tokenbeheer is het meest operationeel veeleisende onderdeel van het bouwen van een OAuth e-mail API. Toegangstokens verlopen, vernieuwingstokens worden door gebruikers ingetrokken en uw systeem moet dit allemaal soepel afhandelen - anders loopt u het risico dat uw gebruikers stilzwijgend toegang tot hun mailboxen verliezen.
Beste praktijken voor tokenopslag
- Versleutel vernieuwingstokens in rust met AES-256 of een cloud KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault). Sla ze nooit in platte tekst op in uw database.
- Log nooit access tokens of refresh tokens. Gestructureerde logsytemen zoals Datadog of Splunk moeten tokenvelden maskeren of redigeren.
- Bewaar tokens in een speciale secrets store (Vault, AWS Secrets Manager) in plaats van in je hoofdapplicatie database, om het 'blast radius' (de mogelijke schade) te minimaliseren als de database gecompromitteerd wordt.
- Implementeer tokenrotatie: wanneer je een nieuwe refresh token ontvangt tijdens een refresh-oproep (sommige providers geven nieuwe refresh tokens uit bij elk gebruik), annuleer dan de oude direct.
Graceful omgang met verversingsfouten
Wanneer een vernieuwingstoken verloopt of wordt ingetrokken, retourneert uw vernieuwingsaanroep een 400- of 401-fout. Uw OAuth-e-mail-API moet dit opvangen en een herauthenticatiestroom voor de gebruiker activeren - niet stilzwijgend falen. Het slechtste scenario is een gebruiker die denkt dat e-mails worden gelezen, maar de token is al weken ingetrokken. Bouw een expliciete controle op de accountstatus en waarschuw gebruikers wanneer herauthenticatie nodig is.
OAuth Scopes: Wat te vragen (en wat niet)
Scope-minimalisatie is zowel een best practice voor beveiliging als een strategie voor toestemmingoptimalisatie. Het aanvragen van meer scopes dan nodig is, zorgt ervoor dat gebruikers aarzelen (of weigeren) op het toestemmingsscherm, en leidt tot verhoogde controle tijdens Google CASA- en Microsoft Publisher-beoordelingen.
| Reikwijdte | Provider | Gebruikssituatie | Gevoeligheid | CASA review? |
|---|---|---|---|---|
| gmail.alleenlezen | Gmail | Lees alle e-mails en metadata | Hoog | Ja - Niveau 2 |
| gmail.verzenden | Gmail | E-mail verzenden als de gebruiker | Hoog | Ja - Niveau 2 |
| gmail-aanpassen | Gmail | Lezen, verzenden, verwijderen, label | Hoog | Ja - Niveau 2 |
| gmail.labels | Gmail | Labels alleen lezen en beheren | Laag | Geen |
| Mail.lezen | Outlook | Lees alle e-mail | Medium | Uitgeversverificatie |
| Mail.verzenden | Outlook | E-mail verzenden als gebruiker | Medium | Uitgeversverificatie |
| Mail.ReadWrite | Outlook | Lezen, verzenden, verwijderen, mapbeheer | Hoog | Uitgeversverificatie |
| offline_access | Outlook | Verkrijg vernieuwingstokens | Laag | Geen |
| mail-r | IMAP (Yahoo) | E-mail lezen via IMAP/XOAUTH2 | Medium | Yahoo-ontwikkelaarsbeoordeling |
Tokens verfrist en geroteerd voor u
Stop met het schrijven van code voor de levenscyclus van tokens. Verbind een mailbox één keer, Unipile houdt de toegang levenslang actief bij alle providers.
Compliance: SOC2, AVG, CASA
Een OAuth e-mail API die gebruikersmailboxen beheert, bevindt zich op het snijvlak van beveiliging en naleving van privacy. Hier zijn de vier frameworks die de meeste zakelijke kopers zullen bespreken - en wat het tokenmodel van OAuth voor elk betekent.
SOC2-auditors kijken naar tokenbeheer als onderdeel van de criteria Beschikbaarheid en Vertrouwelijkheid. OAuth-tokens moeten versleuteld worden opgeslagen (AES-256 of KMS), toegangsgebeurtenissen moeten gelogd worden en er moet een formeel rotatiebeleid gelden. Het opslaan van refresh tokens in platte tekst leidt automatisch tot een bevinding. Het gebruik van een gehoste OAuth e-mail-API zoals Unipile (dat SOC2-gecertificeerd is) verlegt deze verantwoordelijkheid.
Onder de AVG is je app een gegevensverwerker wanneer deze toegang krijgt tot de e-mailinhoud van gebruikers. Je hebt een DPA (Data Processing Agreement) nodig met je OAuth e-mail API-infrastructuurprovider. De herroepbaarheid van OAuth voldoet direct aan Artikel 17 (recht op vergetelheid) – wanneer een gebruiker introkt, eindigt je toegang onmiddellijk. Documenteer je wettelijke grondslag voor de toegang tot e-mailgegevens (doorgaans toestemming via de OAuth-flow).
Zodra uw Gmail OAuth-e-mail-API-app meer dan 100 gebruikers met gevoelige scopes heeft, blokkeert Google het toevoegen van nieuwe gebruikers totdat u CASA Tier 2 hebt doorlopen. Hiervoor is een pentest door een door CASA geautoriseerd laboratorium vereist, evenals een beveiligingsvragenlijst en een formeel beoordelingsrapport dat bij Google moet worden ingediend. Doorlooptijd: 8-16 weken. Kosten: 10.000-25.000 THB. Geverifieerde apps krijgen het "Verified by Google"-badge op hun toestemmingsscherm.
OAuth E-mail API: Prijs- en Kostenmodellen
De "gratis" provider API's van Google en Microsoft verbergen aanzienlijke reële kosten. Hier is een realistisch kostenmodel voor het implementeren van een OAuth e-mail API op schaal - met de directe provider route versus uniforme API's.
De API’s van Google en Microsoft zijn technisch gezien gratis op het niveau van de API-aanroepen. Maar: Google CASA Tier 2 kost 10.000 tot 25.000 TP4T en 3+ maanden aan ontwikkelingswerk. Voor Publisher Verification bij Microsoft is een Partner Network-account en juridische domeinverificatie vereist. Ontwikkelingswerk voor het bouwen van 3 workflows, tokenbeheer en foutafhandeling: 6-10 weken. Jaarlijks onderhoud: 2-4 weken per jaar per aanbieder.
De OAuth e-mail API van Unipile omvat alle provider compliance (CASA, Publisher Verification), tokenbeheer en een uniforme e-mail API onder één abonnement. Voor teams die e-mailconnectiviteit als een functie (niet als een product) leveren, is de ROI-berekening eenvoudig: weken aan ontwikkeltijd bespaard versus maandelijkse API-kosten. Zie de E-mail API-providers vergelijken handleiding voor een volledige kostenanalyse.
Veelvoorkomende valkuilen bij het implementeren van OAuth-e-mail
Dit zijn de meest voorkomende fouten die ontwikkelaars maken bij het bouwen van een OAuth e-mail API voor de eerste keer - en wat je in plaats daarvan moet doen.
Google maakt refresh tokens ongeldig als de gebruiker je app 6 maanden niet heeft gebruikt. Je token refresh aanroep retourneert ongeldige_verlening. Oplossing: implementeer een periodieke "token health check" die minstens één keer per 30 dagen een lichtgewicht Gmail API-aanroep doet voor elke gekoppelde account om te voorkomen dat deze vervalt wegens inactiviteit.
Aanvraag gmail-aanpassen wanneer je alleen maar nodig hebt gmail.alleenlezen vergroot uw toestemmingsscherm en zorgt ervoor dat gebruikers de OAuth-stroom verlaten. Het verhoogt ook uw CASA-niveavereiste. Vraag altijd de minimaal benodigde scope aan. U kunt later incrementeel aanvullende scopes aanvragen.
De gevoelige scope-limiet van Gmail van 100 gebruikers is de meest voorkomende groeibelemmering voor implementaties van de OAuth e-mail-API. Plan voor de CASA-beoordeling voordat u 50 gebruikers bereikt - de beoordeling duurt 8-16 weken, en uw gebruikersgroei zal worden geblokkeerd terwijl deze in behandeling is.
Uitgebreide logregistratie van verzoeken die autorisatieheaders vastleggen, zal uw toegangstokens in platte tekst loggen. Implementeer scrub-middleware die rodeert Bearer [TOKEN] patronen voordat logboeken naar een persistente opslag worden geschreven.
Sommige zakelijke e-mailservers werken achter aangepaste IMAP-configuraties die OAuth niet ondersteunen. Uw OAuth e-mail-API moet een elegante terugvaloptie hebben voor IMAP-only providers. Bouw dit vanaf dag één in uw accountverbindingsstroom in, anders sluit u een aanzienlijk segment van B2B-gebruikers uit. Zie onze IMAP-integratie handleiding voor het volledige fallback-patroon.
Bouw in plaats van providers aan elkaar te plakken
Krijg vandaag nog een werkende OAuth e-mailintegratie. Gratis abonnement, geen creditcard nodig, volledige Gmail- en Microsoft-scopes beschikbaar.
Veelgestelde vragen
De meest voorkomende vragen die ontwikkelaars stellen bij het bouwen van een OAuth e-mail API-integratie - nauwkeurig beantwoord.
https://oauth2.googleapis.com/token, reikwijdte in de gmail.* Naamruimte. Voor Outlook (met betrekking tot Outlook.com, Microsoft 365 en Exchange Online): Microsoft Identity Platform, token-eindpunt https://login.microsoftonline.com/common/oauth2/v2.0/token, bereiken onder https://graph.microsoft.com/. Voor IMAP: IMAP is geen OAuth-provider. Het gebruikt gebruikersnaam/wachtwoord of app-wachtwoordgegevens. XOAUTH2 bestond als een SASL-extensie voor een klein aantal providers, maar is grotendeels verouderd.grant_type=refresh_token. Voor Google: POST naar https://oauth2.googleapis.com/token. Voor Microsoft: POST naar https://login.microsoftonline.com/common/oauth2/v2.0/token. Als u ontvangt ongeldige_verlening, de vernieuwingstoken is verlopen of ingetrokken - vraag de gebruiker om opnieuw te authenticeren.gmail.alleenlezen lezen, gmail.verzenden verzenden, gmail-aanpassen voor volledig lezen/schrijven/verwijderen. Voor Outlook: Mail.lezen lezen, Mail.verzenden verzenden, Mail.ReadWrite voor volledige toegang - plus offline_access om vernieuwingstokens te verkrijgen. Vraag altijd de minimale scope aan die uw use case vereist. Zie de e-mail API-pagina voor gebruiksgevals-specifieke scope-aanbevelingen.gmail.labels (niet onderworpen aan CASA), start het CASA-proces voordat je 50 gebruikers bereikt (het duurt 8-16 weken), of gebruik een gehoste OAuth e-mail API zoals Unipile, wiens infrastructuur de CASA-beoordeling al heeft doorstaan - waardoor deze eis voor je applicatie volledig komt te vervallen./api/v1/hosted/accounts/link. u passeert een type (GOOGLE, MICROSOFT, of IMAP) en Unipile genereert een gehoste authenticatie-URL. De gebruiker voltooit OAuth-toestemming op de infrastructuur van Unipile - die is geslaagd voor Google CASA en Microsoft Publisher Verification. Na toestemming stuurt Unipile een webhook met de account_id. Al het tokenbeheer en vernieuwen wordt intern afgehandeld.ongeldige_verlening. Uw OAuth e-mail API moet dit detecteren, het gekoppelde account markeren als losgekoppeld en de gebruiker notificeren met een herauthenticatiekoppeling. Met Unipile wordt er automatisch een herroeping webhook geactiveerd zodat uw systeem in realtime wordt geïnformeerd - er is geen polling vereist.