OAuth E-mail API: Authenticeer Mailboxen van Gebruikers op de Juiste Manier (2026)

OAuth E-mail API Gids 2026

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.

connect-mailbox.js
// 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 Unipile
Gmail, Outlook, IMAP - één gehoste authenticatiestroom
Werkt met: Gmail Outlook IMAP
Definitie

Wat 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.

Canonieke definitie

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.

IMAP-toegang op basis van wachtwoord
  • 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
OAuth e-mail API-toegang
  • 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
Context

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.

Beveiliging: geen wachtwoordopslag

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.

De deadline van 2026: Microsoft basic auth zonsondergang

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.

Compliance: AVG & SOC2

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 het werkt

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.

01
Uw app stuurt de gebruiker door naar de autorisatie-URL van de provider

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.

02
De gebruiker beoordeelt en keurt de aangevraagde scopes goed

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.

03
De provider stuurt een autorisatiecode naar je redirect URI

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.

04
Je backend vervangt de code door tokens

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.

05
Gebruik het toegangstoken om de e-mail-API aan te roepen

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

Toegangssleutel
Tijdelijke inloggegevens

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.

Vernieuw Token
Verificatiegegevens met een lange geldigheidsduur

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.

Bouw het nu
Per aanbieder

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.

Google OAuth 2.0 (Gmail)
Autorisatie: accounts.google.com/o/oauth2/v2/auth

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.

gmail.alleenlezen gmail.verzenden gmail-aanpassen gmail.labels
gmail-token-exchange.sh
#-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 Identity Platform (Outlook)
Omvat Outlook.com, Microsoft 365 en Exchange Online

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.

Mail.lezen Mail.verzenden Mail.ReadWrite offline_access
microsoft-token-exchange.sh
#-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: Wanneer OAuth niet beschikbaar is
Gebruikersnaam/wachtwoord of app-wachtwoord authenticatie

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.

gebruikersnaam/wachtwoord app-wachtwoord IMAP4_SSL STARTTLS
imap-credentials.py
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 werkelijke kosten

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.

3 aparte ontwikkelaarsconsoles

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.

Google CASA Niveau 2 beveiligingsbeoordeling

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 Publisher Verificatie

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.

3 verschillende tokenvernieuwingsstrategieën

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.

UX-verschillen op het toestemmingsscherm

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.

Lopende onderhoudskosten

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.

Bouwen met Unipile
Architectuur

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
Implementatie

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.

connect-gmail.js
// 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;
Herleidt gebruiker naar Gmail-toestemmingsscherm - geen client_id of client_secret nodig

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.

connect-outlook.py
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 Unipile
Werkt voor Outlook.com en Microsoft 365 - dezelfde oproep

Stap 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.

Hosted OAuth E-mail API

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.

Tokenbeheer

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.

Beginnen met bouwen
Naleving

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 Type II

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.

GDPR

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).

Google CASA Niveau 2

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.

Directe provider OAuth: verborgen kosten

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.

Geconsolideerde gehoste OAuth API: totale kosten

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.

01
Google-vernieuwingssleutel verloopt na 6 maanden inactiviteit

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.

02
Scope creep - te veel vragen leidt tot afwijzing van toestemming

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.

03
Ontbrekende CASA-verificatie - 100 gebruikerslimiet blokkeert groei

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.

04
Tokenlek via applicatielogboeken

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.

05
Geen IMAP-fallbackstrategie

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.

Gratis bouwen
FAQ

Veelgestelde vragen

De meest voorkomende vragen die ontwikkelaars stellen bij het bouwen van een OAuth e-mail API-integratie - nauwkeurig beantwoord.

01
Wat is een OAuth e-mail-API?
Een OAuth e-mail-API is een combinatie van een OAuth 2.0 autorisatiestroom – waarmee een gebruiker uw app gemachtigd toegang tot hun mailbox kan verlenen zonder hun wachtwoord te delen – en een e-mail-API die die mailbox leest, verzendt of synchroniseert. De OAuth-laag produceert een scope-beperkt, intrekbaar toegangstoken. De e-mail-API gebruikt dat token om namens de gebruiker te interageren met Gmail, Outlook of IMAP-providers.
02
Waarom OAuth gebruiken in plaats van je IMAP-wachtwoord?
IMAP-wachtwoordtoegang vereist het opslaan van het platte tekst- of versleutelde wachtwoord van de gebruiker - een kritieke beveiligings- en compliance-aansprakelijkheid. OAuth-tokens zijn kortstondig (1 uur), reikwijdte-beperkt en kunnen op elk moment door de gebruiker worden ingetrokken. Google heeft basale authenticatie voor Gmail in 2022 uitgeschakeld en Microsoft voltooide de uitschakeling van basale authenticatie voor Exchange Online in 2026. OAuth is nu de enige conforme methode voor toegang tot gebruikerspostbussen via API.
03
Welke OAuth-flow moet ik gebruiken voor Gmail en Outlook? En voor IMAP?
Voor Gmail: Google OAuth 2.0 autorisatiecodestroom, token-eindpunt 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.
04
Hoe vernieuw ik verlopen toegangstokens?
Wanneer een toegangstoken verloopt (doorgaans na 1 uur), gebruik dan de vernieuwingstoken om een nieuwe aan te vragen door de token-eindpunt aan te roepen met 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.
05
Welke scopes heb ik nodig om e-mails te lezen of te verzenden?
Voor Gmail: 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.
06
Is OAuth vereist voor Microsoft 365 in 2026?
Ja. Microsoft heeft de uitfasering van basisverificatie voor Exchange Online voltooid in 2026. Dit heeft gevolgen voor alle oudere protocollen, waaronder IMAP, POP3 en SMTP AUTH, wanneer deze worden gebruikt met gebruikersnaam/wachtwoord. Elke toepassing die via basisverificatie verbinding maakt met Microsoft 365-postvakken, ontvangt 401 Unauthorized-fouten. OAuth via het Microsoft Identity Platform is de enige ondersteunde methode voor de toekomst.
07
Hoe vermijd ik de CASA-beveiligingsreview van Google?
CASA Tier 2 is vereist voor gevoelige Gmail-scopes boven 100 gebruikers - je kunt dit niet op schaal omzeilen. Opties: gebruik alleen niet-gevoelige scopes zoals 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.
08
Kan ik Yahoo of AOL via OAuth verbinden?
Yahoo Mail ondersteunde historisch gezien XOAUTH2 voor IMAP-authenticatie, maar dit is sinds 2022 grotendeels afgeschaft. In de praktijk gebruiken IMAP-verbindingen met Yahoo en AOL nu app-wachtwoorden die via accountbeveiligingsinstellingen worden gegenereerd - geen OAuth-tokens. Unipile beheert Yahoo en AOL via IMAP met app-wachtwoordgegevens.
09
Hoe gaat Unipile om met multi-provider OAuth?
Unipile biedt een gehoste OAuth e-mail API via een enkel eindpunt: /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.
10
Wanneer een gebruiker OAuth-toegang intrekt.
Wanneer een gebruiker toegang intrekt via de instellingen van hun Google-, Microsoft- of Yahoo-account, wordt de vernieuwingstoken onmiddellijk ongeldig. Je volgende tokenvernieuwingsaanroep retourneert 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.
Heb je nog vragen? Ons team kan u begeleiden bij de implementatie van OAuth voor uw specifieke use case.
nl_NLNL