LinkedIn
Instagram
WhatsApp
Telegramm
Google Kalender
Slack-Gemeinschaft beitretenOAuth-E-Mail-API: E-Mail-Konten von Benutzern authentifizieren Der richtige Weg
Speichern Sie keine Passwörter mehr. Eine OAuth-E-Mail-API ermöglicht Ihrer App den sicheren Zugriff auf Benutzer-Postfächer – über widerrufbare, auf bestimmte Bereiche beschränkte Token von Gmail, Outlook und IMAP-Anbietern. Diese Anleitung behandelt jeden OAuth-Flow, jeden Bereich, jede Fallstricke und wie Sie mit einer vereinheitlichten gehosteten Authentifizierungsschicht in 5 Minuten versenden können.
// Beliebige Benutzer-Mailbox per OAuth verbinden - 1 API-Aufruf
const response = await fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: 'POST',
headers: {
'X-API-KEY': 'DEIN_API_SCHLÜSSEL',
'Content-Type': 'application/json'
},
body: JSON.stringify({
Typ: 'GOOGLE', // oder MICROSOFT, IMAP
Name: 'Benutzer_123'
})
}
);
const { url } = await Antwort.json();
// Benutzer zu URL weiterleiten - OAuth wird von Unipile behandelt
Was ist eine OAuth-E-Mail-API?
Eine OAuth-E-Mail-API ist eine programmatische Schnittstelle, die Ihrer Anwendung über OAuth 2.0-Token Zugriff auf Benutzer-E-Mail-Konten gewährt – ohne jemals das Passwort des Benutzers zu verarbeiten oder zu speichern. Anstatt Benutzer nach Anmeldedaten zu fragen, leiten Sie sie durch den Einwilligungsbildschirm des Anbieters, erhalten ein kurzlebiges Zugriffstoken und verwenden dieses, um E-Mails in ihrem Namen zu lesen, zu senden oder zu synchronisieren. Die Unterscheidung ist wichtig: Hier geht es um den Zugriff auf benutzereigene Mailboxen (Gmail, Outlook, persönliche E-Mail), keine Transaktions-E-Mails über SMTP-Relaydienste wie SendGrid senden.
Eine OAuth-E-Mail-API ist eine Kombination aus einem OAuth 2.0-Autorisierungsfluss (zur Authentifizierung eines Benutzers und zur Erlangung delegierten Zugriffs) und einer E-Mail-API (zum Lesen, Senden, Suchen oder Synchronisieren des Postfachs dieses Benutzers). Die OAuth-Schicht generiert ein kryptografisch signiertes, widerrufbares, bereichsbeschränktes Zugriffstoken. Die E-Mail-API verwendet dieses Token, um mit Gmail, Outlook oder jedem IMAP-kompatiblen Postfach zu interagieren – und das alles, ohne jemals das Passwort des Benutzers zu kennen.
- Speichert Klartext- oder verschlüsselte Passwörter in Ihrer Datenbank
- Voller Zugriff auf das Postfach – keine Bereichssteuerung
- Blockiert von Google/Microsoft seit 2026
- Haftung für die Speicherung von Zugangsdaten gemäß DSGVO/SOC2
- Passwortspeicher-Null – nur kurzlebige Token
- Granulare Bereiche – schreibgeschützt, nur Senden oder Vollzugriff
- Jederzeit vom Nutzer widerrufbar
- DSGVO-konform, SOC2
Warum OAuth den passwortbasierten E-Mail-Zugriff ersetzt hat
Die Nutzung von IMAP mit Benutzername und Passwort war früher der Standardweg, um programmgesteuert auf E-Mails von Benutzern zuzugreifen. Diese Ära ist vorbei. Google hat die Basisauthentifizierung für Gmail im Jahr 2022 abgeschafft, und Microsoft hat im Oktober 2022 die Stilllegung der Basisauthentifizierung für Exchange Online abgeschlossen, mit einer endgültigen Bereinigung für verbleibende Protokolle im Jahr 2026. Wenn Ihre Anwendung immer noch auf passwortbasierte IMAP-Zugriffe angewiesen ist, ist sie entweder bereits defekt oder wird bald defekt sein.
OAuth-Token sind kurzlebig (typischerweise 1 Stunde) und auf bestimmte Bereiche beschränkt. Selbst wenn sie durchsickern, können sie nicht verwendet werden, um sich als Benutzer anzumelden, sein Passwort zu ändern oder auf andere Dienste zuzugreifen. Sie greifen niemals auf die Anmeldeinformationen des Benutzers zu.
Microsoft hat die Abschaltung der Basisauthentifizierung für Exchange Online und ältere IMAP-Protokolle im Jahr 2026 abgeschlossen. Jede Anwendung, die weiterhin Benutzername+Passwort verwendet, um auf Outlook- oder Microsoft 365-Postfächer zuzugreifen, erhält 401 Unauthorized-Fehler.
Die Speicherung von Benutzerpasswörtern - selbst gehasht - birgt Compliance-Risiken. Das Prinzip der Datenminimierung der DSGVO verlangt, dass Sie nichts sammeln, was Sie nicht benötigen. SOC2-Prüfer beanstanden die Speicherung von Anmeldedaten.
Kritisch: Google App-Passwörter und Microsoft Legacy-Protokolle reichen für Produktionsanwendungen nicht mehr aus. Wenn Sie ein Produkt entwickeln, das auf Benutzer-Mailboxen zugreift, OAuth-E-Mail-API ist keine Option – er ist der einzig konforme Weg für 2026.
Wie OAuth für E-Mail-APIs funktioniert (Schritt für Schritt)
Der "Authorization Code"-Flow ist der Standard-OAuth 2.0-Flow für serverseitige Anwendungen, die auf die E-Mail-Adresse des Benutzers zugreifen müssen. Wenn Sie diesen Flow vollständig verstehen, können Sie ihn korrekt implementieren, Token-Fehler beheben und den Flow Ihrem Sicherheitsteam erklären.
Du erstellst eine URL mit deinen client_id, ein redirect_uri, die angeforderte Umfang, ein zufälliger Zustand Parameter (CSRF-Schutz) und Antworttyp=Code. Der Nutzer wird zur Zustimmungsseite von Google oder Microsoft weitergeleitet.
Der Einwilligungsbildschirm zeigt den Namen Ihrer App, Ihr Logo und die von Ihnen angeforderten Berechtigungen an. Der Nutzer genehmigt (erteilt Einwilligung) oder lehnt ab. Zu viele Umfänge in diesem Schritt sind die häufigste Ursache für die Ablehnung der Einwilligung.
Nach der Zustimmung leitet der Anbieter zu Ihrer redirect_uri mit einem kurzlebigen Code Parameter (gültig für ca. 10 Minuten). Überprüfen Sie die Zustand Der Parameter stimmt mit dem überein, was Sie gesendet haben, um CSRF-Angriffe zu verhindern.
Server-zu-Server-POST an den Token-Endpunkt mit Ihrem client_id, kunden_geheimnis, der / die / das Codeund grant_type=authorization_code. Sie erhalten eine Zugriffstoken und (falls Sie Offline-Zugriff angefordert haben) eine Aktualisierungsschlüssel.
Übergeben Sie das Zugriffstoken in der Autorisierung: Träger Header bei jeder API-Anfrage. Wenn er abläuft (normalerweise nach 1 Stunde), verwenden Sie den Refresh-Token, um ohne Benutzerinteraktion einen neuen Access-Token zu erhalten.
Zugriffstoken vs. Aktualisierungstoken: Lebenszyklus
Gültig für 1 Stunde (Google) oder 1 Stunde (Microsoft). Übergeben im Authorization-Header bei jedem API-Aufruf. Wenn er abläuft, gibt Ihr OAuth-E-Mail-API-Aufruf einen 401-Fehler zurück – das Signal zum Aktualisieren.
Gültig bis zum Widerruf (Google) oder 90 Tage Inaktivität (Microsoft). Niemals an API-Endpunkte gesendet – nur server-zu-server zur Abfrage neuer Zugriffstoken verwendet. Muss im Ruhezustand verschlüsselt sein.
Einen einheitlichen OAuth-Flow in Minuten erstellen
Überspringen Sie die protokollspezifische Autorisierungsstruktur. Ein Unipile API-Aufruf ersetzt drei OAuth-Integrationen.
OAuth-Flows nach Anbieter: Google und Microsoft
Google und Microsoft implementieren OAuth 2.0 jeweils anders – unterschiedliche Autorisierungsendpunkte, unterschiedliche Scopes, unterschiedliche Token-Endpunkte und unterschiedliche Verifizierungsprozesse. IMAP ist das Anmeldeinformations-basierte Fallback für Anbieter ohne standardisiertes OAuth. Hier ist, was Sie für jeden Fall wissen müssen.
Googles OAuth-Implementierung nutzt den Standard-Autorisierungscodefluss. Der Token-Endpunkt ist https://oauth2.googleapis.com/token. Die kritische Komplexität ist Google CASA (Cloud Application Security Assessment): Sobald Ihre App mehr als 100 Benutzer überschreitet, müssen Sie eine Sicherheitsüberprüfung bestehen. Für sensible Bereiche wie Gmail ändern oder gmail.readonly, Die App-Verifizierung ist vor der Produktionsnutzung erforderlich. Für eine vollständige Gmail API-Integration im Detail, siehe unseren Leitfaden. Implementierungsdetails finden Sie in der Unipile Google OAuth Dokumentation.
#-Autorisierungscode für den Zugriff auf Gmail + Aktualisierungstoken
locken. -X POST https://oauth2.googleapis.com/token \
-d "code=AUTH_CODE" \
-d "client_id=DEINE_CLIENT_ID" \
-d "client_secret=DEIN_CLIENT_SECRET" \
-d "redirect_uri=https://yourapp.com/callback" \
-d "grant_type=authorization_code"
#-Antwort: { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }
Microsoft nutzt seine Identity Platform (ehemals Azure AD v2). Der Token-Endpunkt ist https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token. Die Publisher-Verifizierung ist erforderlich, bevor Ihre OAuth-E-Mail-API-App in der Produktion sensible E-Mail-Bereiche anfordern kann. Microsoft hat die Basisauthentifizierung für alle Exchange Online-Protokolle als veraltet erklärt – OAuth ist zwingend erforderlich. Sehen Sie sich unsere Vollständige Microsoft Graph E-Mail-Anleitung Für vollständige Details und das Unipile Microsoft OAuth-Dokumentation zur Implementierungsreferenz.
#-Austauschcode für Microsoft-OAuth-Token
locken. -X POST https://login.microsoftonline.com/common/oauth2/v2.0/token \
-d "code=AUTH_CODE" \
-d "client_id=DEINE_CLIENT_ID" \
-d "client_secret=DEIN_CLIENT_SECRET" \
-d "redirect_uri=https://yourapp.com/callback" \
-d "grant_type=authorization_code" \
-d "scope=https://graph.microsoft.com/Mail.Read offline_access"
#-Antwort: { "access_token": "...", "refresh_token": "...", "expires_in": 3600 }
IMAP ist kein OAuth-Anbieter: Es ist ein Protokoll, das sich mit Benutzername/Passwort oder App-Passwörtern authentifiziert (wie z. B. ein Google App-Passwort oder ein von iCloud generiertes Passwort). Es ist die Fallback-Lösung für benutzerdefinierte Mailserver, Unternehmensdomänen, die nicht auf Microsoft 365 laufen, und jeden Anbieter ohne standardisierten OAuth-Flow. XOAUTH2 gab es als IMAP SASL-Erweiterung für eine kleine Anzahl von Anbietern, aber es wurde weitgehend aufgegeben – Yahoo hat seine eigene Implementierung 2022 eingestellt. Bei den meisten IMAP-Bereitstellungen authentifiziert sich Unipile direkt mit Anmeldedaten. Sehen Sie die vollständige IMAP-Integrationsanleitung für Serverkonfiguration und Authentifizierungsdetails.
import base64, imaplib
# XOAUTH2-Zeichenkette aus OAuth-Zugriffstoken erstellen
def build_xoauth2(benutzer_email, zugriffstoken)
Authentifizierungsstring = user={user_email}\x01auth=Bearer {access_token}\x01\x01"
return base64.b64encode(auth_str.encode()).decode()
# Verbindung über IMAP mit XOAUTH2
Verbindung = imaplib.IMAP4_SSL("imap.mail.yahoo.com")
Authentifizierungsstring = build_xoauth2("user@yahoo.com", access_token)
conn.authentifizieren("XOAUTH2", Lambda x: auth_str)Die verborgene Komplexität von Multi-Provider-OAuth
Die Implementierung einer OAuth-E-Mail-API für einen Anbieter dauert ein paar Tage. Die korrekte Implementierung für Gmail, Outlook und IMAP – mit produktionsreifer Token-Verwaltung, Fehlerbehandlung und Compliance – dauert normalerweise 4 bis 8 Wochen Entwicklungszeit. Hier ist der Grund dafür.
Google Cloud Console, Azure Portal und Yahoo Developer Network sind 3 völlig unterschiedliche Dashboards mit unterschiedlicher UX, unterschiedlichen Flows zur App-Registrierung und unterschiedlichen Verifizierungsanforderungen. Jede Rotation von Anmeldedaten berührt alle 3.
sensible GMail-Bereiche (einschließlich gmail.readonly) sind auf 100 Benutzer begrenzt, bis Sie eine CASA-Tier-2-Prüfung bestanden haben. Diese umfasst ein von CASA autorisiertes Labor, einen Penetrationstest und eine formelle Sicherheitsüberprüfung – in der Regel dauert dies 6 bis 12 Wochen und kostet zwischen 10.000 und 25.000 AUD.
Microsoft verlangt die Überprüfung des Herausgebers für Apps, die sensible Mail-Bereiche anfordern. Ohne diese sehen Benutzer auf dem Zustimmungsbildschirm eine rote Warnung "Nicht verifizierter Herausgeber". Der Verifizierungsprozess erfordert ein aktives Microsoft Partner Network-Konto mit einer verifizierten Domäne.
Google-Refresh-Tokens verfallen nach 6 Monaten Inaktivität (oder sofort, wenn der Benutzer sie widerruft). Microsoft-Tokens verfallen nach 90 Tagen Inaktivität. Yahoo/IMAP XOAUTH2-Tokens haben anbieterspezifische Lebensdauern. Ihre Token-Management-Schicht muss alle 3 unterschiedlich behandeln.
Google, Microsoft und Yahoo stellen jeweils unterschiedliche Einwilligungsbildschirme dar – unterschiedliches Branding, unterschiedliche Geltungsbereichsbeschreibungen, unterschiedliche UI-Muster. Ihre Nutzer sehen 3 verschiedene Abläufe je nach E-Mail-Anbieter, was zu inkonsistenten UX und höheren Abbruchraten führt.
OAuth-Endpunkte ändern sich. Scope-Namen werden veraltet. Neue Sicherheitsanforderungen werden hinzugefügt. Jeder Anbieter kündigt Breaking Changes zu unterschiedlichen Zeitpunkten an. Jemand in Ihrem Team muss auf unbestimmte Zeit 3 Anbieter-Blogs, 3 Changelogs und 3 Compliance-Kalender verfolgen.
Die OAuth-Komplexität gänzlich überspringen
Gehostete Authentifizierung, Umfangsverwaltung, Handhabung von Aktualisierungen. Unipile kümmert sich um all das, damit Sie sich auf Ihr Produkt konzentrieren können.
OAuth E-Mail-API-Architektur: 3 Ansätze im Vergleich
Es gibt 3 Architekturen für den Aufbau einer OAuth-E-Mail-API-Schicht. Jede hat unterschiedliche Kosten für die Implementierung, den Wartungsaufwand und das Sicherheitsprofil. Die richtige Wahl hängt davon ab, ob die E-Mail-Konnektivität Ihr Kernprodukt ist oder eine Funktion, die Sie neben Ihrem Hauptprodukt anbieten.
| Dimension | Direkter Anbieter OAuth (x3) | Selbst gehostetes OAuth-Gateway | Vereinigte gehostete OAuth (Unipile) Empfohlen |
|---|---|---|---|
| Zeit bis zur ersten verbundenen Mailbox | 3-7 Tage (pro Anbieter) | 2-4 Wochen | 5 Minuten |
| OAuth-Flows implementieren | 3 separate Strömungen | 3 Abläufe + Routing-Logik | 1 gehosteter Link-Endpunkt |
| Google CASA Bewertung | Das schaffst du schon (6–12 Wochen, $10k+) | Du regelst das | Bearbeitet von Unipile |
| Microsoft Publisher-Überprüfung | Du regelst das | Du regelst das | Bearbeitet von Unipile |
| Token-Refresh-Management | 3 Strategien zum Aufbauen | Benutzerdefiniert pro Anbieter | Automatisch, transparent |
| E-Mail Lese-/Sendefunktion | 3 verschiedene APIs | Abstraktionsschicht erforderlich | 1 einheitliche REST-API |
| Webhook bei neuen E-Mails | Push/Pull pro Anbieter | Benutzerdefiniert | Vereinheitlichte Webhook-Ereignisse |
| SOC2 / DSGVO-Konformität | Ihre Verantwortung | Ihre Verantwortung | Unipile ist SOC2-zertifiziert |
| Laufende Wartung | Hoch (3 Anbieter-Änderungsprotokolle) | Hoch | Null - bearbeitet von Unipile |
| Am besten für | Produkte mit einem einzigen Anbieter, die native E-Mails nutzen | Große Teams mit engagierter Infrastruktur | Ein Team, das schnell liefert |
Build vs Buy: Gehostete OAuth-E-Mail-API in 5 Minuten
Anstatt 3 separate OAuth-Flows zu erstellen, bietet Unipile einen gehosteten Authentifizierungslink, der Google OAuth, Microsoft Identity und IMAP OAuth für Sie übernimmt. Ihre App generiert einen Link, leitet den Benutzer weiter und erhält einen Webhook, sobald das Postfach verknüpft ist. Die OAuth-E-Mail-API ist sofort einsatzbereit – keine Konsolen-Einrichtung, keine CASA-Überprüfung, keine Token-Aktualisierungslogik zum Erstellen.
Schritt 1: Generieren Sie einen gehosteten Authentifizierungslink
Ein API-Aufruf zum Erstellen einer gehosteten Authentifizierungssitzung. Geben Sie den Anbietertyp und einen Namen für das Konto an. Unipile gibt eine URL zurück, zu der Ihr Benutzer zur OAuth-Zustimmungsseite umgeleitet wird.
// Gmail-Benutzer über die Unipile gehostete OAuth E-Mail-API verbinden
const response = await fetch(
'https://api6.unipile.com:13226/api/v1/hosted/accounts/link',
{
method: 'POST',
headers: {
'X-API-KEY': 'DEIN_UNIPILE_API_SCHLÜSSEL',
'Content-Type': 'application/json'
},
body: JSON.stringify({
Typ: 'GOOGLE',
Name: 'Benutzer_Alice_123',
success_redirect_url: 'https://ihreapp.com/connected',
failure_redirect_url: 'https://deineapp.com/fehler'
})
}
);
const { url, objekt } = await Antwort.json();
// Benutzer zu URL weiterleiten - Unipile handelt OAuth-Zustimmung ab
window.location.href = URL;Schritt 2: Einen Outlook-Benutzer verbinden
Gleicher Endpunkt, gleiches Muster. Ändern Typ zu MICROSOFT. Kein Azure Portal, keine Publisher-Verifizierung, die Sie auf Ihrer Seite verwalten müssen.
import Anfragen
#: Outlook-Benutzer über die Unipile OAuth-E-Mail-API verbinden
response = Anfragen.Beitrag(
"https://api6.unipile.com:13226/api/v1/hosted/accounts/link",
Kopfzeilen={"X-API-KEY": "DEIN_UNIPILE_API_SCHLÜSSEL"},
json={
"Typ": "MICROSOFT",
"Name": "user_bob_456",
"Erfolgs-Weiterleitungs-URL": "https://yourrorient.com/konektiert"
}
)
auth_url = response.json()["url"]
# Weiterleitung an auth_url – Microsoft-Identitätsablauf, abgewickelt von UnipileSchritt 3: Empfangen des Webhooks bei account.connected
Nach der OAuth-Zustimmung sendet Unipile einen Webhook an Ihren Endpunkt. Die Ereignisnutzlast enthält die neuen account_id - die Sie speichern und für alle nachfolgenden E-Mail-API lesen und E-Mail senden API Anrufe.
Webhook-Ereignis: Nach Abschluss des OAuth-Vorgangs sendet Unipile eine account.connected Ereignis an Ihre Webhook-URL. Die Nutzlast enthält die account_id speichern Sie dies, das provider (GOOGLE / MICROSOFT / IMAP) und die verknüpfte E-Mail-Adresse. Dies ist der einzige Zustand, den Sie speichern müssen – Unipile verwaltet alle OAuth-Token intern.
Überspringen Sie die 8-wöchige OAuth-Implementierung. Verbinden Sie Postfächer in wenigen Minuten.
Die gehostete OAuth-E-Mail-API von Unipile unterstützt Google CASA, Microsoft Publisher Verification, XOAUTH2 und Token-Aktualisierung für alle Anbieter. Ihre Benutzer verbinden ihre Mailbox über einen einzigen gehosteten Flow – Sie erhalten eine einheitliche API zum Lesen, Senden und Synchronisieren.
Verwaltung von OAuth-Tokens: Aktualisieren, Widerrufen, Rotieren
Tokenmanagement ist der operativ anspruchsvollste Teil beim Aufbau einer OAuth-E-Mail-API. Zugriffstoken verfallen, Aktualisierungstoken werden von Benutzern widerrufen, und Ihr System muss all dies reibungslos handhaben – andernfalls riskieren Sie, dass Ihre Benutzer still und leise den Zugriff auf ihre Postfächer verlieren.
Bewährte Praktiken für die Token-Speicherung
- Aktualisierungstoken im Ruhezustand mit AES-256 oder einem Cloud-KMS (AWS KMS, GCP Cloud KMS, Azure Key Vault) verschlüsseln. Speichern Sie sie niemals im Klartext in Ihrer Datenbank.
- Protokollieren Sie niemals Access-Tokens oder Refresh-Tokens. Strukturierte Protokollsysteme wie Datadog oder Splunk sollten Token-Felder maskieren oder schwärzen.
- Speichern Sie Tokens stattdessen in einem dedizierten Secrets Store (Vault, AWS Secrets Manager) und nicht in Ihrer Hauptanwendungsdatenbank, um den potenziellen Schaden (Blast Radius) bei einer Kompromittierung der Datenbank zu minimieren.
- Implementiere die Token-Rotation: Wenn Sie bei einem Refresh-Aufruf einen neuen Refresh-Token erhalten (manche Anbieter geben bei jeder Nutzung neue Refresh-Token aus), machen Sie den alten sofort ungültig.
Fehlerbehandlung bei Aktualisierungen ohne Abstürze
Wenn ein Aktualisierungstoken abläuft oder widerrufen wird, gibt Ihr Aktualisierungsaufruf einen Fehler 400 oder 401 zurück. Ihre OAuth-E-Mail-API muss dies abfangen und einen erneuten Authentifizierungsfluss für den Benutzer auslösen – kein stilles Fehlschlagen. Das schlechteste Ergebnis ist ein Benutzer, der glaubt, dass E-Mails gelesen werden, aber das Token seit Wochen widerrufen wurde. Erstellen Sie eine ausdrückliche Überprüfung des Kontozustands und benachrichtigen Sie Benutzer, wenn eine erneute Authentifizierung erforderlich ist.
OAuth-Bereiche: Was man verlangen sollte (und was nicht)
Scope-Minimierung ist sowohl eine bewährte Sicherheitspraxis als auch eine Strategie zur Optimierung von Einwilligungen. Das Anfordern von mehr Scopes als benötigt, führt zu Zögern (oder Ablehnungen) seitens der Nutzer auf dem Einwilligungsbildschirm und löst eine erhöhte Überprüfung während der Google CASA- und Microsoft Publisher-Bewertungen aus.
| Umfang | Anbieter | Anwendungsfall | Empfindlichkeit | CASA-Bewertung? |
|---|---|---|---|---|
| gmail.readonly | Google Mail | Lies alle E-Mails und Metadaten | Hoch | Ja – Stufe 2 |
| Gmail senden | Google Mail | E-Mail als Benutzer senden | Hoch | Ja – Stufe 2 |
| Gmail ändern | Google Mail | Lesen, senden, löschen, kennzeichnen | Hoch | Ja – Stufe 2 |
| Gmail-Labels | Google Mail | Labels nur lesen und verwalten | Niedrig | Nein |
| Mail.Lesen | Ausblick | Alle E-Mails lesen | Mittel | Verlagskontrolle |
| Mail.Senden | Ausblick | E-Mail als Benutzer senden | Mittel | Verlagskontrolle |
| Mail.ReadWrite | Ausblick | Lesen, Senden, Löschen, Ordnerverwaltung | Hoch | Verlagskontrolle |
| Offline-Zugriff | Ausblick | Aktualisierungstoken abrufen | Niedrig | Nein |
| E-Mail-Runde | IMAP (Yahoo) | E-Mail über IMAP/XOAUTH2 lesen | Mittel | Yahoo Entwicklerüberprüfung |
Tokens aufgefrischt und für Sie rotiert
Hören Sie auf, Code für den Token-Lebenszyklus zu schreiben. Verbinden Sie einmal eine Mailbox, Unipile hält den Zugriff über alle Anbieter hinweg aufrecht.
Compliance: SOC2, DSGVO, CASA
Eine OAuth-E-Mail-API, die Benutzer-Mailboxen verwaltet, befindet sich an der Schnittstelle von Sicherheit und Datenschutzkonformität. Hier sind die vier Frameworks, nach denen die meisten Unternehmenskäufer fragen werden – und was das Token-Modell von OAuth für jedes einzelne bedeutet.
SOC2-Auditoren betrachten die Token-Verarbeitung im Rahmen der Kriterien Verfügbarkeit und Vertraulichkeit. OAuth-Token müssen im Ruhezustand verschlüsselt werden (AES-256 oder KMS), protokollert und einer formalen Rotationsrichtlinie unterliegen. Die Speicherung von Refresh-Tokens im Klartext führt automatisch zu einem Beanstandungspunkt. Die Verwendung einer gehosteten OAuth-E-Mail-API wie Unipile (die SOC2-zertifiziert ist) verlagert diese Verantwortung.
Gemäß der DSGVO ist Ihre App ein Datenverarbeiter, wenn sie auf E-Mail-Inhalte von Nutzern zugreift. Sie benötigen eine Auftragsverarbeitungsvereinbarung (AVV) mit Ihrem OAuth-Infrastrukturanbieter für die E-Mail-API. Die Widerrufbarkeit von OAuth erfüllt direkt Artikel 17 (Recht auf Löschung) – wenn ein Nutzer widerruft, endet Ihr Zugriff sofort. Dokumentieren Sie Ihre Rechtsgrundlage für den Zugriff auf E-Mail-Daten (typischerweise die Einwilligung über den OAuth-Flow).
Sobald Ihre Gmail-OAuth-E-Mail-API-App mehr als 100 Nutzer mit sensiblen Zugriffsbereichen hat, sperrt Google das Hinzufügen weiterer Nutzer, bis Sie die CASA-Stufe 2 bestanden haben. Dazu sind ein Penetrationstest durch ein von CASA autorisiertes Labor, ein Sicherheitsfragebogen und ein formeller Bewertungsbericht erforderlich, die bei Google eingereicht werden müssen. Zeitrahmen: 8–16 Wochen. Kosten: 10.000–25.000 THB. Verifizierte Apps erhalten das Abzeichen "Verified by Google" auf ihrem Einwilligungsbildschirm.
OAuth E-Mail-API: Preis- und Kostenmodelle
Die "kostenlosen" Anbieter-APIs von Google und Microsoft verbergen erhebliche tatsächliche Kosten. Hier ist ein realistisches Kostenmodell für die Implementierung einer OAuth-E-Mail-API im großen Maßstab – unter Berücksichtigung des direkten Anbieterwegs im Vergleich zu einheitlichen APIs.
Die APIs von Google und Microsoft sind auf der Ebene der API-Aufrufe technisch gesehen kostenlos. Allerdings: Google CASA Tier 2 kostet 1.400–2.500 Euro und erfordert mehr als drei Monate Entwicklungszeit. Die Publisher-Verifizierung für Microsoft erfordert ein Partner Network-Konto und eine rechtliche Domain-Verifizierung. Entwicklungszeit für die Erstellung von drei Abläufen, die Token-Verwaltung und die Fehlerbehandlung: 6–10 Wochen. Jährliche Wartung: 2–4 Wochen pro Jahr und Anbieter.
Die OAuth-E-Mail-API von Unipile beinhaltet die vollständige Einhaltung von Anbieterstandards (CASA, Publisher Verification), Token-Management und eine einheitliche E-Mail-API unter einem einzigen Abonnement. Für Teams, die E-Mail-Konnektivität als Funktion (nicht als Produkt) anbieten, ist die ROI-Berechnung einfach: Wochen an Entwicklungszeit gespart im Vergleich zu monatlichen API-Kosten. Siehe das E-Mail-API-Anbieter vergleichen Leitfaden für eine vollständige Kostenaufschlüsselung.
Häufige Fallstricke bei der Implementierung von OAuth-E-Mails
Das sind die häufigsten Fehler, die Entwickler machen, wenn sie zum ersten Mal eine OAuth-E-Mail-API erstellen – und was sie stattdessen tun sollten.
Google macht Refresh-Tokens ungültig, wenn der Nutzer Ihre App 6 Monate lang nicht genutzt hat. Ihr Token-Refresh-Aufruf gibt zurück ungültiger_grant. Behebung: Implementierung eines periodischen "Token-Gesundheitschecks", der mindestens alle 30 Tage für jedes verknüpfte Konto einen leichten Gmail API-Aufruf durchführt, um eine Inaktivitätsablauf zu verhindern.
Anforderung Gmail ändern wenn Sie nur brauchen gmail.readonly vergrößert Ihre Zustimmungserklärung und führt dazu, dass Nutzer den OAuth-Flow abbrechen. Dies erhöht auch Ihre CASA-Stufenanforderung. Fordern Sie immer den minimal benötigten Geltungsbereich an. Sie können später inkrementell zusätzliche Geltungsbereiche anfordern.
Die Beschränkung des sensiblen Geltungsbereichs von Gmail auf 100 Nutzer ist der häufigste Wachstumshemmer für OAuth-E-Mail-API-Implementierungen. Planen Sie die CASA-Überprüfung, bevor Sie 50 Nutzer erreichen – die Überprüfung dauert 8-16 Wochen und Ihr Nutzerwachstum wird blockiert, während sie aussteht.
Ausführliche Protokollierung, die Autorisierungsheader erfasst, protokolliert Ihre Zugriffstoken im Klartext. Implementieren Sie Middleware zur Protokollbereinigung, die diese schwärzt Träger [TOKEN] Muster, bevor Protokolle in einem persistenten Speicher geschrieben werden.
Einige Firmenserver laufen hinter benutzerdefinierten IMAP-Konfigurationen, die OAuth nicht unterstützen. Ihre OAuth-E-Mail-API muss einen reibungslosen Fallback-Pfad für reine IMAP-Anbieter haben. Bauen Sie dies von Anfang an in Ihren Account-Verbindungsfluss ein, sonst schließen Sie ein erhebliches Segment von B2B-Nutzern aus. Sehen Sie sich unser IMAP-Integration Leitfaden für das vollständige Fallback-Muster.
Aufbauen statt Anbieter zusammenzufügen
Holen Sie sich noch heute eine funktionierende OAuth-E-Mail-Integration. Kostenlose Stufe, keine Kreditkarte, volle Gmail- und Microsoft-Scopes verfügbar.
Häufig gestellte Fragen
Die häufigsten Fragen von Entwicklern beim Erstellen einer OAuth-E-Mail-API-Integration – präzise beantwortet.
https://oauth2.googleapis.com/token, Bereiche in der gmail.* Namespace. Für Outlook (umfasst Outlook.com, Microsoft 365 und Exchange Online): Microsoft Identity Platform, Tokenendpunkt https://login.microsoftonline.com/common/oauth2/v2.0/token, Bereiche unter https://graph.microsoft.com/. Für IMAP: IMAP ist kein OAuth-Anbieter. Es verwendet Anmeldeinformationen für Benutzername/Passwort oder App-Passwort. XOAUTH2 gab es als SASL-Erweiterung für eine kleine Anzahl von Anbietern, wurde aber weitgehend veraltet.grant_type=refresh_token. Für Google: POST zu https://oauth2.googleapis.com/token. Für Microsoft: POST an https://login.microsoftonline.com/common/oauth2/v2.0/token. Wenn Sie erhalten ungültiger_grant, Der Aktualisierungstoken ist abgelaufen oder wurde widerrufen – fordern Sie den Benutzer zur erneuten Authentifizierung auf.gmail.readonly lesen, Gmail senden senden, Gmail ändern Für vollständige Lese-/Schreib-/Löschberechtigungen. Für Outlook: Mail.Lesen lesen, Mail.Senden senden, Mail.ReadWrite für vollen Zugriff - plus Offline-Zugriff um Aktualisierungstoken zu erhalten. Fordern Sie stets den für Ihren Anwendungsfall erforderlichen Mindestumfang an. Sehen Sie sich die E-Mail-API-Seite für anwendungsfallspezifische Umfangsempfehlungen.Gmail-Labels (nicht CASA-pflichtig), starten Sie den CASA-Prozess, bevor Sie 50 Benutzer erreichen (dies dauert 8-16 Wochen), oder verwenden Sie eine gehostete OAuth-E-Mail-API wie Unipile, deren Infrastruktur bereits die CASA-Prüfung bestanden hat - wodurch diese Anforderung für Ihre Anwendung vollständig entfällt./api/v1/hosted/konten/link. Du kommst an einem Typ (GOOGLE, MICROSOFT oder IMAP) und Unipile generiert eine gehostete Authentifizierungs-URL. Der Nutzer schließt die OAuth-Zustimmung auf der Infrastruktur von Unipile ab – die Google CASA und die Microsoft Publisher Verification bestanden hat. Nach der Zustimmung sendet Unipile einen Webhook mit dem account_id. Die gesamte Tokenverwaltung und -aktualisierung erfolgt intern.ungültiger_grant. Ihre OAuth-E-Mail-API muss dies erkennen, das verknüpfte Konto als getrennt markieren und den Benutzer mit einem Re-Authentifizierungslink benachrichtigen. Mit Unipile wird automatisch ein Widerrufs-Webhook ausgelöst, sodass Ihr System in Echtzeit benachrichtigt wird – keine Abfrage erforderlich.
DE 
EN 
FR 
ES 
IT 
BR 
NL 
PL 
TR