LinkedIn
Instagram
WhatsApp
Telegramm
Google Kalender
Slack-Gemeinschaft beitretenGoogle OAuth Verifizierung & Gmail API-Anmeldedaten
Schritt für Schritt: Erstellen Sie Gmail API OAuth-Anmeldeinformationen, überstehen Sie die Google App-Verifizierung und die CASA Tier 2-Überprüfung – oder nutzen Sie heute den bereits zertifizierten OAuth-Schlüssel von Unipile und zertifizieren Sie Ihren eigenen später.
// Überspringe die Google Cloud-Einrichtung vollständig.Der zertifizierte OAuth-Schlüssel von Unipile kümmert sich darum. const response = await fetch('https://api.unipile.com/api/v1/hosted/accounts', { method: 'POST', Kopfzeilen: { 'X-API-KEY': process.env.UNIPILE_API_KEY, 'Content-Type': 'application/json' }, body: JSON.stringify({ Typ: 'GOOGLE', Name: 'benutzer-123', gültigBis: '2026-12-31' })}); const { url } = await Antwort.json();// Leiten Sie Ihren Benutzer zu `url` weiter - erledigt.Was ist die Google OAuth-Verifizierung eigentlich
Die Google OAuth-Verifizierung ist der formelle Genehmigungsprozess, durch den Google bestätigt, dass Ihre Anwendung Benutzerdaten gemäß seinen Richtlinien verarbeitet. Bis Ihre App diese Überprüfung bestanden hat, gilt sie als nicht verifiziert – das bedeutet, dass Benutzer einen Warnbildschirm sehen und Sie auf maximal 100 Testbenutzer beschränkt sind. Die Überprüfung ist zwingend erforderlich, wenn Ihre App sensible oder eingeschränkte Gmail API-Bereiche von externen (Nicht-internen) Benutzern anfordert.
Sensible Bereiche: was sie sind
Sensible Bereiche ermöglichen Ihrer Anwendung, Benutzerdaten über grundlegende Profilinformationen hinaus zu lesen oder zu ändern. Für Gmail umfassen diese:
gmail.readonly- alle Nachrichten lesenGmail sendenE-Mail im Namen des Benutzers sendenGmail ändernlesen, verfassen, archivierenmail.google.com- Voller Zugang (eingeschränkt)
Sensible Bereiche erfordern eine Google-Sicherheitsüberprüfung. Eingeschränkte Bereiche (wie voller IMAP-Zugriff) erfordern zusätzlich eine CASA Tier 2-Prüfung. Siehe die vollständige Referenz der Bereiche in unserem Gmail API Scopes Leitfaden.
Warum löst die Gmail API dies immer aus
Im Gegensatz zu einem grundlegenden Google-Anmeldevorgang (der nur Profildaten anfordert) fordert die Gmail-API immer Scopes an, die Zugriff auf den Inhalt des Postfachs eines Nutzers gewähren. Google behandelt jede Berechtigung auf Postfachebene per Definition als sensibel.
Das bedeutet: Jeder Entwickler, der die Gmail API für externe Nutzer verwenden möchte, muss die Google OAuth App-Verifizierung durchlaufen – es gibt keine Version der Gmail API, die diese Anforderung für die produktive Nutzung umgeht.
Sie sind sich nicht sicher, ob Sie OAuth-Anmeldeinformationen oder einen einfachen API-Schlüssel benötigen? Lesen Sie unsere Gmail API Schlüssel vs. OAuth-Leitfaden.
Schlüsselunterscheidung: Die Google OAuth-Verifizierung ist kein einmaliges Ereignis. Wenn Sie neue Bereiche zu einer bereits verifizierten Anwendung hinzufügen, müssen Sie die Anwendung zur erneuten Überprüfung mithilfe dieser zusätzlichen Bereiche einreichen. Planen Sie Ihre Bereichsstrategie, bevor Sie mit dem Prozess beginnen – das spart Wochen.
Wochen der Verifizierung.
Verwenden Sie Unipiles Schlüssel und jetzt beginnen.
Verlieren Sie keine Kunden, weil sie auf eine Google-Bewertung warten. Verbinden Sie Gmail-Konten in 5 Minuten mit unseren vorab geprüften Entwickleranmeldedaten.
So erhalten Sie Gmail API-Anmeldeinformationen: Schritt für Schritt
Für die Erlangung von Gmail API OAuth-Anmeldeinformationen sind sechs seperate Schritte in der Google Cloud Console erforderlich. Hier ist die vollständige Sequenz – von der Erstellung Ihres Projekts bis hin zu einem funktionierenden client_id und kunden_geheimnis.
- Erstellen Sie ein Google Cloud-Projekt - Ihr isolierter Abrechnungs- und API-Container.
- Gmail API aktivieren - Aktivieren Sie die API in der API-Bibliothek für Ihr Projekt.
- Konfigurieren Sie den OAuth-Zustimmungsbildschirm - App-Typ auswählen (extern vs. intern), App-Namen, Support-E-Mail und autorisierte Domains eingeben.
- Bereiche hinzufügen - Wählen Sie die Gmail-Berechtigungsbereiche aus, die Ihre App benötigt. Dies bestimmt, ob eine Sicherheitsüberprüfung erforderlich ist.
- Erstellen Sie eine OAuth Client ID - Anwendungsart auswählen (Web, Desktop oder iOS/Android) und Ihre Weiterleitungs-URIs registrieren.
- Zur Überprüfung einreichen - wenn Ihre App extern ist und sensible Anwendungsbereiche verwendet, reichen Sie diese über das Verifizierungsportal von Google ein.
Geh Konsole.cloud.google.com, klicken Sie auf den Projektauswahl-Button in der oberen Navigationsleiste und wählen Sie "Neues Projekt". Geben Sie ihm einen Namen, der Ihr Produkt widerspiegelt – dieser Name wird auf dem OAuth-Zustimmungsbildschirm angezeigt, den die Nutzer sehen.
Aktivieren Sie die Abrechnung für das Projekt, auch wenn Sie davon ausgehen, dass Sie die kostenlosen Kontingente nicht ausschöpfen werden. Viele APIs (einschließlich Gmail) erfordern die Verknüpfung mit einem Abrechnungskonto, bevor sie aktiviert werden können, selbst bei einer Nutzung von $0.
Google Cloud Console: Erstellen Sie ein neues Projekt über die Projektauswahl in der oberen Navigationsleiste.
Navigieren Sie in der Google Cloud Console zu "APIs & Dienste" > "Bibliothek". Suchen Sie nach "Gmail API" und klicken Sie auf "Aktivieren". Wahrscheinlich möchten Sie auch die Google People API aktivieren, wenn Sie neben E-Mail auch Kontaktdaten benötigen.
Nach der Aktivierung wird die Gmail API in Ihrem "Aktivierte APIs"-Dashboard angezeigt. API-Aufrufe ohne gültige Anmeldedaten geben einen 403 ZugriffNichtKonfiguriert Fehler auch in dieser Phase – Anmeldedaten folgen.
Google API-Bibliothek: Suchen Sie nach "Gmail API" und klicken Sie auf Aktivieren, um sie für Ihr Projekt zu aktivieren.
Gehen Sie zu "APIs & Dienste" > "OAuth-Zustimmungsbildschirm". Wählen Sie Ihren Nutzertyp aus:
- Intern – Nur Benutzer innerhalb Ihrer Google Workspace-Organisation. Keine Überprüfung erforderlich.
- Extern - beliebiges Google-Konto. Verifizierung für sensible/eingeschränkte Bereiche über 100 Testbenutzer hinaus erforderlich.
OAuth-Zustimmungsbildschirm: Wählen Sie als Nutzertyp Intern (nur Workspace) oder Extern (jedes Google-Konto).
Füllen Sie die FelderAppName, User support email und developer contact email aus. Diese Felder erscheinen auf dem Einwilligungsbildschirm, den Benutzer sehen, wenn sie Ihre App autorisieren. Fügen Sie Ihre autorisierte Domain hinzu (die Domain Ihrer Homepage und Ihrer Datenschutzrichtlinien-URL).
Für eine detaillierte Einführung in jedes Feld, das 100-Benutzer-Limit und die Wahl zwischen intern und extern, siehe unser Einrichtungsleitfaden für den Zustimmungsbildschirm.
App-Informationen: Geben Sie den App-Namen, das Logo und die Support-E-Mail genau so ein, wie sie auf dem Zustimmungsbildschirm erscheinen sollen.
App-Bereich: Stellen Sie Live-URLs für Ihre Homepage, Ihre Datenschutzrichtlinie und Ihre Nutzungsbedingungen bereit. Das Überprüfungsteam von Google prüft diese.
Autorisierte Domains: Fügen Sie die Stammdomain Ihrer App hinzu. Nur URIs aus dieser Domain können als Redirect-URIs verwendet werden.
Kontaktinformationen für Entwickler: Google verwendet diese E-Mail, um Sie über Änderungen am Verifizierungsstatus Ihrer App zu informieren.
Tipp: Der Abschnitt "App-Domain" akzeptiert mehrere Links (Startseite, Datenschutzrichtlinie, Nutzungsbedingungen). Das Verifizierungsteam von Google prüft, ob diese URLs erreichbar sind und die von Ihnen angeforderten Geltungsbereiche widerspiegeln. Eine fehlende oder fehlerhafte Datenschutzrichtlinien-URL ist einer der häufigsten Gründe für abgelehnte Verifizierungen.
Klicken Sie in der Konfiguration des Zustimmungsbildschirms auf "Scopes hinzufügen oder entfernen". Verwenden Sie den Filter, um Gmail-Scopes zu finden. Der von Ihnen gewählte Scope hat direkten Einfluss auf Ihren Verifizierungspfad:
Gmail sendenodergmail.readonly- Sensibel, erfordert Sicherheitsbewertung.Gmail ändernodermail.google.comeingeschränkt, erfordert zusätzlich CASA Tier 2.openid email profilnur - keine Verifizierung erforderlich (einfache Anmeldung).
Scopes hinzufügen oder entfernen: Wählen Sie die Gmail-Scopes aus, die Ihre App benötigt. Die Auswahl von Scopes bestimmt direkt Ihren Verifizierungspfad.
Planen Sie die Scope-Auswahl sorgfältig. Das spätere Hinzufügen eines eingeschränkten Scopes bedeutet, dass die gesamte App erneut zur Überprüfung durch die CASA Tier 2 eingereicht werden muss. Für den vollständigen Scope-Verweis und die APIs, die jeder Scope freischaltet, siehe unsere Gmail API Scopes Leitfaden.
Gehen Sie zu "APIs & Services" > "Anmeldedaten" > "Anmeldedaten erstellen" > "OAuth-Client-ID". Wählen Sie Ihren Anwendungstyp aus:
- Webanwendung - für serverseitige Apps. Registrieren Sie Ihre Weiterleitungs-URIs (z. B.
https://yourapp.com/oauth/callback). - Desktop-App - für installierte Anwendungen. Nutzt Loopback-Umleitung.
- iOS / Android - mobile Apps, verwenden benutzerdefinierte URI-Schemas.
Anmeldeinformationsbereich: Wählen Sie "OAuth-Client-ID" aus, um die client_id und den client_secret zu generieren, die Ihre App benötigt.
Nach der Erstellung laden Sie die JSON-Anmeldedatei herunter. Sie enthält Ihre client_id, kunden_geheimnis, und registrierte Redirect-URIs. Speichern Sie sie sicher – committen Sie sie niemals in die Quellcodeverwaltung.
Für eine ausführliche Betrachtung des Unterschieds zwischen diesem Anmeldetyp und einem einfachen API-Schlüssel siehe unsere Gmail API Schlüssel vs. OAuth-Anmeldeinformationen – Leitfaden.
Zugriffstoken und Aktualisierungstoken: wenn ein Benutzer den OAuth-Flow abschließt, erhalten Sie einen kurzlebigen Zugriffstoken (gültig ~1 Stunde) und ein Aktualisierungsschlüssel (lang beständig, serverseitig gespeichert). Ihr Server verwendet den Refresh-Token, um neue Zugriffstokens zu erhalten, ohne den Benutzer erneut zur Eingabe aufzufordern. Fordern Sie immer an access_type=offline und Zustimmung Bei der ersten Autorisierung, den Refresh-Token zu erhalten. Speichern Sie Refresh-Token verschlüsselt im Ruhezustand.
Für einen breiteren Überblick, wie OAuth in die E-Mail-API-Architektur passt – einschließlich Synchronisationsstrategien und Anbieterunterschieden – siehe unser OAuth E-Mail-API-Anleitung.
Verwenden Sie den Schlüssel von UnipileDie Warnung "Diese App ist nicht verifiziert", die Obergrenze von 100 Benutzern und Ausnahmen
Bevor Ihre App die Google OAuth-App-Überprüfung besteht, sehen alle Benutzer, die versuchen, sie zu autorisieren, einen Warnbildschirm. Google erzwingt außerdem eine harte 100-Benutzer-Grenze für nicht verifizierte externe Apps. Hier ist genau, was das bedeutet und wann es nicht gilt.
Auf dem Bildschirm steht: "Diese App ist nicht verifiziert. Diese App wurde nicht von Google verifiziert. Sie fordert möglicherweise Zugriff auf sensible Informationen an. Informieren Sie sich über die Risiken." Benutzer müssen auf "Erweitert" und dann auf "Zu [App-Name] (unsicher)" klicken, um fortzufahren. Die meisten nicht-technischen Benutzer werden hier stoppen – dies sind die tatsächlichen Kosten für das Überspringen oder Verzögern der Verifizierung.
Wenn die Google OAuth App-Überprüfung NICHT erforderlich ist
Nur zur internen Verwendung
Wenn Sie Ihren OAuth-Zustimmungsbildschirm auf "Intern" einstellen und Ihre App nur Nutzer innerhalb Ihrer eigenen Google Workspace Organisation bedient, ist keine Verifizierung erforderlich – unabhängig davon, welche Scopes Sie anfordern. Das ist der schnellste Weg für interne Tools.
Testmodus (unter 100 Nutzern)
Eine nicht verifizierte externe App kann über die Google Cloud Console mit bis zu 100 Testnutzern versehen werden. Diese spezifischen Nutzer können die App autorisieren, ohne eine harte Blockade zu sehen – sie sehen die Warnung, können aber fortfahren. Nützlich für die Entwicklung und private Beta mit einem kleinen Team.
Nur grundlegende Bereiche
Wenn Ihre App nur nicht sensible Anwendungsbereiche anfordert (openid, email, profile – grundlegende Google-Anmeldung), ist keine Verifizierung erforderlich, selbst für externe Nutzer in beliebiger Größenordnung. Eine Verifizierung wird speziell durch sensible und eingeschränkte Anwendungsbereiche ausgelöst.
Wichtige Einbettung: Die Absicht der 100-Nutzer-Obergrenze und des Warnbildschirms ist es, Nutzer zu schützen, während eine App überprüft wird. Die richtige Reaktion auf das Erreichen des Limits ist die Einreichung deiner App zur Google OAuth App-Verifizierung – nicht die Erstellung mehrerer Google Cloud-Projekte, um Nutzer auf diese zu verteilen. Google verbietet diesen Ansatz ausdrücklich und er kann zur Sperrung deines Entwicklerkontos führen. Der konforme Weg ist entweder die Verifizierung deiner App oder die Nutzung einer Plattform, die bereits einen verifizierten OAuth-Schlüssel bereitstellt, wie z.B. Unipile.
Google App-Verifizierung: Zeitplan & Kosten im Jahr 2026
Die Überprüfung von Google-Apps ist kein einzelner Prozess – sie hat drei verschiedene Wege, je nachdem, welche Bereiche Ihre App anfordert. Jeder Weg hat seine eigene Zeitachse und Kosten. Hier ist, was Sie im Jahr 2026 erwarten können.
Wenn Ihre App nur nicht sensible Bereiche verwendet (einfaches Google-Sign-In), kann Google dennoch eine Markenverifizierung verlangen, um die Identität Ihrer App und die Domain Ihrer Homepage zu bestätigen. Dies ist in der Regel ein 2-3 Werktage dauernder Prozess, der über Ihre Zeit hinaus keine Kosten verursacht.
Sie müssen den Domainbesitz über die Google Search Console verifizieren und sicherstellen, dass Ihr OAuth-Zustimmungsbildschirm Ihre App genau beschreibt.
Apps, die sensible Gmail-Bereiche anfordern, müssen eine vollständige Sicherheitsüberprüfung durch Google durchlaufen. Das Team von Google prüft die Praktiken Ihrer App zur Datenverarbeitung, Ihre Datenschutzrichtlinie und die Begründung für jeden von Ihnen angeforderten Bereich.
Typische Bearbeitungszeit beträgt 2-4 Wochen Wenn Ihre Einreichung abgeschlossen ist. Unvollständige Einreichungen (fehlende Datenschutzrichtlinie, vage Begründungen des Umfangs, nicht übereinstimmende autorisierte Domains) starten die Uhr neu. Google kann während dieses Zeitraums eine Demo oder zusätzliche Dokumentation anfordern.
Apps, die eingeschränkte Bereiche anfordern – hauptsächlich https://mail.google.com/ (vollständiger IMAP-Zugriff) - muss eine CASA Tier 2 Sicherheitsbewertung Zusätzlich zur eigenen Überprüfung durch Google ist CASA (Cloud Application Security Assessment) ein unabhängiges Sicherheitsaudit, das von einem von Google zugelassenen Labor durchgeführt wird.
Im Jahr 2026 bietet Google ein Selbstbedienungs-CASA-Tier-2-Pfad über zugelassene Labore, normalerweise kosten $540–$1.000 (Laborgebühren für automatisiertes Scannen). Dies ist eine deutliche Verbesserung gegenüber dem alten System. Die ältere, manuell durchgeführte Sicherheitsbewertung, die Google zuvor für die gleiche Umfangsklasse erforderte, kostete $15.000–$75.000 und dauerte Monate – diese Legacy-Spur gilt immer noch für einige Bestandsanwendungen und Enterprise-Sonderfälle. Bestätigen Sie bei der Budgetierung mit Ihrem ausgewählten Labor, welche Spur für Ihre Anwendung gilt.
Gesamtzeitrahmen einschließlich der eigenen Überprüfung durch Google nach CASA: 4-12 Wochen von der ersten Einreichung bis zur Genehmigung.
Kostenzusammenfassung: Google OAuth App-Verifizierung im Jahr 2026
| Verifizierungsspur | Geltungsbereich Stufe | Zeitstrahl | Kosten |
|---|---|---|---|
| Markenverifizierung | Nicht-sensibel (openid, email, profile) | 2-3 Werktage | Kostenlos |
| Sicherheitsbewertung | Sensibel (gmail.send, gmail.readonly, gmail.modify) | 2-4 Wochen | Kostenlos |
| CASA Tier 2 (Self-Service, 2026) | Eingeschränkt (mail.google.com) | 4-8 Wochen | ~$540–$1.000 |
| CASA Stufe 2 (alte Anleitung, vor 2025) | Eingeschränkt (mail.google.com) | 8-12 Wochen | $15k–$75k |
Quellen Google OAuth 2.0 Richtlinien (developers.google.com) und Google Cloud – Überblick zur OAuth-App-Überprüfung (support.google.com). Die Preise für CASA Tier 2 im Self-Service-Modell basieren auf den genehmigten Labortarifen zum Stand des ersten Quartals 2026 und können je nach Labor und Anzahl der App-Umfänge variieren. Der bisherige Tarif $15k-$75k galt für Apps, die das frühere obligatorische Programm zur Sicherheitsbewertung durch Drittanbieter von Google durchlaufen hatten, bevor die CASA-Self-Service-Option verfügbar wurde.
Wartezeit überspringenGängige Google OAuth-Fehler, auf die Sie stoßen werden
Wenn Sie Ihr eigenes Google Cloud-Projekt verwalten, treten während der Entwicklung und nach der Live-Schaltung wiederholt einige Fehler auf. Hier ist eine Kurzübersicht über die sechs häufigsten Fehler.
Die Umleitungs-URI in Ihrer Anfrage stimmt nicht genau mit einer in der Google Cloud Console registrierten überein (Protokoll, nachgestellter Schrägstrich und Port sind relevant).
Der Google Workspace-Administrator des Nutzers hat Drittanbieter-OAuth-Apps blockiert oder die spezifischen Bereiche eingeschränkt, die Ihre App anfordert.
Ihre App verwendet sensible oder eingeschränkte Bereiche, hat jedoch den Verifizierungsprozess von Google nicht abgeschlossen, weshalb Google die Zustimmung für neue Nutzer blockiert.
Der Refresh-Token ist abgelaufen oder wurde widerrufen (Benutzer hat das Passwort geändert, den Zugriff widerrufen oder der Token war 6 Monate lang inaktiv). Der Benutzer muss sich erneut authentifizieren.
Der Einwilligungsbildschirm ist in der Google Cloud Console falsch konfiguriert: falscher Benutzertyp (intern vs. extern), fehlende Testbenutzer oder die App ist noch im Entwurfsstatus.
Ein Scope-String enthält einen Tippfehler oder die entsprechende API (z. B. Gmail API) wurde in der Google Cloud Console für Ihr Projekt nicht aktiviert.
Brauchen Sie die vollständige Diagnose? Jeder dieser Fehler hat eine spezifische Lösung. Sehen Sie sich unseren vollständigen Leitfaden an, um Häufige Google OAuth- und Gmail API-Fehler und wie Sie jeden beheben können.
Wenn OAuth von Unipile gehandhabt wird, einem unabhängigen technischen Vermittler, der im Namen jedes authentifizierten Benutzers handelt, werden diese Fehler auf der API-Ebene verwaltet. Unipile ist bereits CASA Tier 2 zertifiziert, sodass die Verifizierungshürden einmal und nicht pro Projekt bewältigt werden.
Wochen der Verifizierung.
Verwenden Sie Unipiles Schlüssel und jetzt beginnen.
Verlieren Sie keine Kunden, weil sie auf eine Google-Bewertung warten. Verbinden Sie Gmail-Konten in 5 Minuten mit unseren vorab geprüften Entwickleranmeldedaten.
Google OAuth, vereinfacht: DIY vs. verwaltet – sofort veröffentlichen oder Wochen warten?
Wenn Ihre App für externe Nutzer Zugriff auf Gmail benötigt, stehen Ihnen zwei Wege offen: Sie können Ihr eigenes Google Cloud-Projekt mit dem vollständigen Google OAuth-App-Verifizierungsprozess durchlaufen (6-12 Wochen) oder auf einer Plattform aufbauen, die bereits über einen CASA Tier 2-zertifizierten OAuth-Schlüssel verfügt (1-2 Tage). Hier erfahren Sie, wie sich jeder Weg darstellt – und warum sie sich nicht gegenseitig ausschließen.
Die strategische Lektüre: Der DIY-Pfad ist auf lange Sicht sinnvoll, wenn Sie die volle Kontrolle über Ihre OAuth-Marke und Ihren Zustimmungsbildschirm haben möchten. Der verwaltete Pfad (Unipile) ist sinnvoll, wenn Sie sofort etwas auf den Markt bringen müssen, die 100-Benutzer-Obergrenze vermeiden oder die Kosten für CASA Tier 2 aufschieben möchten. Diese Pfade schließen sich nicht gegenseitig aus – Sie können noch heute auf Unipile aufbauen und parallel Ihre eigene Zertifizierung durchführen, und dann zu Ihren eigenen Anmeldedaten wechseln (Bring Your Own Credentials), sobald Ihre Anwendung verifiziert ist.
Wenn Ihr Anwendungsfall nur auf Workspace beschränkt ist (interne Tools, HR-Automatisierung, keine Zustimmung pro Benutzer), ist die Server-zu-Server-Alternative ein Dienstkonto mit Domain-Wide Delegation - siehe unsere Gmail-Dienstkonto & DWD-Anleitung.
Compliance-Hinweis: Unipile ist ein unabhängiger technischer Vermittler, der nicht mit Google verbunden, von Google nicht unterstützt oder von Google gesponsert wird. Der Google OAuth-Client von Unipile ist CASA Tier 2-zertifiziert, wodurch Ihre Benutzer den Zugriff auf Gmail autorisieren können, ohne die Warnung "unverifizierte App" zu sehen. Dies ist kein Workaround für die Sicherheitsüberprüfung von Google – die Überprüfung gilt weiterhin, wenn Sie Ihre eigene Google Cloud-App erstellen; Unipile hat diese bereits für die Verbindungen bestanden, die es in Ihrem Namen vermittelt. Benutzer können den Zugriff jederzeit über die Berechtigungsseite ihres Google-Kontos widerrufen.
Testen Sie jetzt auf Unipiles zertifizierter Schlüssel, parallel zertifizieren, umschalten, wenn bereit
Sie müssen sich nicht zwischen schnellem Versand und dem Besitz Ihrer Google-Anmeldedaten entscheiden. Unipile fungiert als unabhängiger technischer Vermittler – sein Google OAuth-Client ist bereits CASA Tier 2 zertifiziert –, sodass Ihre Benutzer nie die Warnung über nicht verifizierte Apps sehen und es keine Begrenzung von 100 Benutzern gibt. Führen Sie Ihre eigene Google-App-Verifizierung parallel durch und wechseln Sie dann jederzeit zu Ihren eigenen Anmeldedaten (Bring Your Own Credentials). Hier ist der 3-stufige Ablauf.
Test auf dem zertifizierten Schlüssel – Versand in Minuten
Erstellen Sie ein kostenloses Unipile-Konto und generieren Sie einen API-Schlüssel. Verwenden Sie den gehosteten Auth-Endpunkt, um für jeden Benutzer eine One-Link-URL zu generieren. Leiten Sie Ihren Benutzer zu dieser URL weiter – Unipiles Google OAuth-Zustimmungsbildschirm (bereits CASA Tier 2 zertifiziert) kümmert sich um die Autorisierung. Ihr Benutzer sieht keine Warnung vor einer "unverifizierten App".
Wenn die Autorisierung abgeschlossen ist, sendet Unipile einen Webhook an Ihren Server mit der ID des verknüpften Kontos. Ab diesem Zeitpunkt kann Ihre App Gmail über die einheitliche API von Unipile lesen, senden und synchronisieren. ohne ein einziges Google Cloud-Projekt zu erstellen.
// Schritt 1: Generieren Sie eine Ein-Link-Authentifizierungs-URL für Ihren Benutzer
const res = await fetch('https://api.unipile.com/api/v1/hosted/accounts', {
method: 'POST',
Kopfzeilen: {
'X-API-KEY': process.env.UNIPILE_API_KEY,
'Content-Type': 'application/json'
},
body: JSON.stringify({
Typ: 'GOOGLE',
Name: 'Nutzer-456', // Ihre interne Benutzerkennung
gültigBis: '2027-01-01',
notify_url: 'https://your-app.com/webhooks/unipile'
})
});
const { url } = await res.json();
// Leiten Sie den Benutzer zu `url` weiter – das zertifizierte Zustimmungsfenster von Unipile erledigt den Rest.Führen Sie Ihre eigene Google OAuth-Verifizierung parallel aus
Während Ihr Produkt live ist und Benutzer aktiv sind, beginnen Sie mit der Einrichtung Ihres eigenen Google Cloud-Projekts und reichen Sie Ihre App zur Verifizierung Ihrer Google OAuth-App ein. Befolgen Sie die obige 5-stufige Anmeldeinformationseinrichtung. Wenn Ihre App eingeschränkte Bereiche verwendet, initiieren Sie Ihre CASA Tier 2 Self-Service-Bewertung über ein von Google genehmigtes Labor.
Es gibt keine Eile zu diesem Schritt, während Sie sich auf den zertifizierten Schlüssel von Unipile befinden – Ihre Benutzer sind nicht blockiert, sie sehen keine Warnung und es gibt keine Benutzerbeschränkung. Führen Sie den Prozess in dem Tempo durch, das am besten zu Ihrem Team passt: typischerweise 2–4 Wochen für sensible Bereiche, 4–12 Wochen, wenn CASA Tier 2 benötigt wird.
Für Anleitungen zur Auswahl des Geltungsbereichs siehe unser Gmail API Scopes Leitfaden - Die Wahl minimaler Scopes kann Sie vom eingeschränkten (CASA-pflichtigen) Track auf den sensiblen (freie Überprüfung) Track bringen, was Zeit und Kosten spart.
Verwenden Sie Ihre eigenen Anmeldedaten (BYOC) – eine Konfigurationsänderung
Sobald Ihre Google Cloud-App verifiziert ist und Sie Ihre eigene client_id und kunden_geheimnis, Konfigurieren Sie Unipile so, dass es Ihre eigenen OAuth-Anmeldeinformationen für neue Kontoverbindungen verwendet. Dies ist das Bring Your Own Credentials (BYOC)-Modell: Unipile agiert weiterhin als unabhängiger technischer Vermittler Anfragen im Namen jedes authentifizierten Benutzers bearbeiten, wobei nun Ihre verifizierten Anmeldedaten anstelle des gemeinsam genutzten Schlüssels verwendet werden.
Bestehende verknüpfte Konten bleiben aktiv. Der Wechsel betrifft nur neue Autorisierungen. Ihre Nutzer sehen Ihren verifizierten App-Namen auf dem Zustimmungsbildschirm anstelle des mit Unipile gekennzeichneten Bildschirms. Sie haben entschieden, wann Sie in die Verifizierung investieren möchten - nicht am ersten Tag, an dem Sie versenden mussten.
Microsoft ist anders: warum Azure keine CASA-ähnliche Überprüfung benötigt
Wenn Ihre Anwendung sowohl auf Gmail als auch auf Outlook zugreifen muss, ist der Verifizierungsaufwand asymmetrisch. Die Verifizierung von Google OAuth-Apps – einschließlich einer möglichen CASA Tier 2-Prüfung – gilt nur für Google. Der Ansatz von Microsoft Azure zur App-Registrierung und OAuth-Zustimmung ist architektonisch anders und erfordert keine gleichwertige externe Sicherheitsprüfung.
Jede App, die sensible oder eingeschränkte Gmail-Umfänge von externen Nutzern anfordert, muss die Sicherheitsbewertung von Google bestehen. Eingeschränkte Umfänge erfordern zusätzlich CASA Tier 2.
- Warnung vor nicht verifizierter App für Benutzer angezeigt
- Maximal 100 Benutzer, bis zur Verifizierung
- CASA Tier 2 für eingeschränkte Anwendungsbereiche erforderlich (~$540-$1k Selbstbedienung)
- Erneute Überprüfung erforderlich, wenn neue sensible Bereiche hinzugefügt werden
- Zeitplan: 2-12+ Wochen je nach Umfangsstufe
Azure Active Directory (jetzt Microsoft Entra ID) verwendet ein Admin-Zustimmungsmodell für Berechtigungen mit hohen Privilegien. Für Standardzugriffsberechtigungen für E-Mails gibt es keine externen Audit-Anforderungen im CASA-Stil.
- Keine Warnung vor nicht verifizierter App für Standardabläufe
- Keine Nutzerbeschränkung während der Entwicklung
- Keine verpflichtende externe Sicherheitsüberprüfung
- Administratorzustimmung für mandantenweite Berechtigungen in Enterprise-Mandanten erforderlich
- Microsoft 365 deckt sowohl persönliche Outlook- als auch Unternehmens-Exchange Online-Konten über denselben OAuth-Flow ab
Praktische Implikation für Multi-Provider-Apps: Wenn Sie ein Produkt erstellen, das E-Mails sowohl von Gmail- als auch von Outlook-Konten liest, bestimmt die Überprüfung Ihrer Google OAuth-App Ihren Starttermin – nicht die von Microsoft. Dies ist einer der stärksten Vorteile der einheitlichen API von Unipile: Beide Anbieter werden über eine einzige Integration abgewickelt, und der zertifizierte Schlüssel von Unipile erfüllt sofort die CASA Tier 2-Anforderung von Google, wodurch diese aus Ihrem kritischen Pfad entfernt wird.
Für eine eingehende Betrachtung der Microsoft-Seite dieser Gleichung – einschließlich der Azure-App-Registrierung, der Zustimmungsflüsse und des Zugriffs auf die Microsoft Graph API – siehe unser Microsoft Graph OAuth-Leitfaden.
Wie Unipile Ihre Daten handhabt
Unipile ist ein unabhängiger technischer Vermittler. Die folgenden drei Notizen erklären genau, wie Daten fließen, was Unipile speichert und welche Verantwortlichkeiten Sie als Kunde haben - im Kontext von Google OAuth und dem Zugriff auf die Gmail API.
Was Unipile speichert – und was nicht
Unipile pflegt kein paralleles Archiv oder eine unabhängige Kopie der Gmail-Daten Ihrer Benutzer. Wenn Ihre Anwendung über die Unipile-API auf E-Mail-Daten zugreift, ruft Unipile diese von den Servern von Google ab. im Namen des authentifizierten Benutzers und gibt sie an Ihre Anwendung zurück. Daten sind streng auf die Sitzung des authentifizierten Benutzers und die Berechtigungen beschränkt, die er während des OAuth-Flows gewährt hat. Unipile behält keinen Nachrichteninhalt über das hinaus bei, was zur Erfüllung der API-Antwort erforderlich ist.
Unabhängiger technischer Vermittler – kein Google-Partner
Unipile fungiert als unabhängiger technischer Vermittler, handelt im Auftrag jedes authentifizierten Benutzers, der Zugriff über den OAuth-Zustimmungsbildschirm gewährt hat. Unipile ist nicht mit Google verbunden, von Google unterstützt oder von Google gesponsert. Unipile teilt keine Anmeldeinformationen zwischen Benutzern – jedes verknüpfte Konto verwendet seine eigenen OAuth-Token, die auf die Autorisierung dieses Benutzers beschränkt sind. Ihre Anwendung greift nur auf Gmail-Daten von Benutzern zu, die den OAuth-Flow explizit abgeschlossen und die angeforderten Berechtigungen erteilt haben.
Googles Ratenbegrenzungen gelten – Nutzungsentscheidungen liegen bei Ihnen
Unipile leitet die Grenzwert- und Quotenbeschränkungen der Gmail API von Google an Ihre Anwendung weiter. Die Gmail API erzwingt pro Benutzer Quoten (z. B. 250 Quotenpunkte pro Sekunde und Benutzer, 1.000.000.000 Quotenpunkte pro Tag und Projekt). Unipile zeigt diese Limits an, überschreibt sie jedoch nicht. Entscheidungen über die Anfragesequenz, das Datenvolumen und den Geltungsbereich der Benutzerzustimmung bleiben eine wichtige Kundenentscheidung. Sie sind dafür verantwortlich, sicherzustellen, dass Ihre Anwendung die Gmail-Daten in Übereinstimmung mit den API-Nutzungsbedingungen von Google und den Erwartungen Ihrer Nutzer gemäß Ihrer Datenschutzrichtlinie verwendet.
Für einen vollständigen Überblick über die Funktionen der E-Mail-API, einschließlich Senden, Lesen und Synchronisieren über Gmail, Outlook und IMAP, siehe unser E-Mail-API-Leitfaden.
Bauen mit UnipileGoogle OAuth für Entwickler FAQ
Antworten auf die häufigsten Fragen zu Google OAuth App-Verifizierung, Gmail API-Anmeldedaten und verwaltetem OAuth über Unipile.
Ihre App benötigt eine Google OAuth App-Überprüfung, wenn sie so eingestellt ist Extern Benutzertyp auf dem OAuth-Zustimmungsbildschirm und fordert sensible oder eingeschränkte Gmail-Bereiche von Nutzern außerhalb Ihrer eigenen Google Workspace-Organisation an. Wenn Ihre App nur grundlegende Bereiche anfordert (openid, E-Mail, Profiloder auf Intern gesetzt ist, ist keine Verifizierung erforderlich. Jeder Geltungsbereich, der Zugriff auf das Postfach eines Benutzers gewährt, wie z. B. gmail.readonly, Gmail senden, Gmail ändern, oder mail.google.com, ist sensibel oder eingeschränkt und löst die Anforderung aus.
Der Zeitplan hängt von der von Ihrer App verwendeten Geltungsbereichsstufe ab. Markenverifizierung (nicht sensible Bereiche): 2-3 Werktage. Sensible Umfangsüberprüfung (Gmail senden, gmail.readonly, Gmail ändern): in der Regel 2-4 Wochen nach vollständiger Einreichung. CASA Tier 2 + sensible/eingeschränkte Geltungsbereiche (mail.google.com): 4-12+ Wochen gesamt. Unvollständige Einreichungen, wie z. B. fehlende Datenschutzrichtlinien, unklare Begründungen des Umfangs oder nicht übereinstimmende autorisierte Domains, setzen die Uhr zurück.
Googles eigene Sicherheitsbewertung (für sensible Gültigkeitsbereiche wie Gmail senden und gmail.readonly) ist kostenlos. Die Markenverifizierung ist ebenfalls kostenlos. Wenn Ihre App eingeschränkte Bereiche verwendet (mail.google.com), benötigen Sie eine CASA Tier 2 Prüfung durch ein von Google genehmigtes Labor. Der Weg über die Self-Service CASA Tier 2 im Jahr 2026 kostet ungefähr $540 bis $1.000 in Laborgebühren. Die bisherige manuelle Bewertung, die für dieselbe Umfangsklasse erforderlich war, kostete $15.000 bis $75.000 und diese Legacy-Track gilt immer noch für einige Sonderfälle und ältere Anwendungen.
Sie können die Google App-Verifizierung für eine Produktions-App, die externe Benutzer mit sensiblen Gmail-Bereichen bedient, nicht überspringen. Die 100-Benutzer-Grenze und die Warnung vor nicht verifizierten Apps gelten, bis Ihre App verifiziert ist. Die konformen Alternativen sind: stellen Sie Ihre App auf Intern (wenn es nur für Ihre eigenen Workspace-Nutzer bestimmt ist), verwenden Sie Unipiles CASA Tier 2-zertifizierter OAuth-Schlüssel während Ihre eigene Verifizierung parallel läuft, oder fordern Sie nur nicht sensible Bereiche an, die keine Verifizierung auslösen. Die Erstellung mehrerer Cloud-Projekte, um Benutzer auf diese zu verteilen, ist nach den Richtlinien von Google verboten und kann zur Sperrung Ihres Kontos führen.
See Unipiles verwalteter Gmail API-Endpunkt.Die Warnung "Gmail API: Nicht verifizierte App" erscheint, wenn Ihr OAuth-Zustimmungsbildschirm auf "Extern" gesetzt ist und Ihre App sensible oder eingeschränkte Gmail-Bereiche anfordert, aber den Verifizierungsprozess von Google noch nicht abgeschlossen hat. Sie wird allen Nutzern außerhalb Ihrer Liste von 100 Testnutzern angezeigt. Zur Behebung: reichen Sie Ihre App zur Verifizierung ein Google OAuth App-Überprüfung über die Google Cloud Console oder auf dem vorkonfigurierten, CASA Tier 2-zertifizierten OAuth-Schlüssel von Unipile aufbauen. Benutzer, die sich über den gehosteten Authentifizierungsablauf von Unipile verbinden, sehen diese Warnung nie.
CASA Stufe 2 (Cloud Application Security Assessment) ist eine unabhängige Sicherheitsprüfung, die von Google für Apps erforderlich ist, die eingeschränkte Zugriffsberechtigungen anfordern, hauptsächlich https://mail.google.com/, wodurch vollständiger IMAP-Zugriff auf Gmail gewährt wird. Dies wird von einem von Google zugelassenen Labor durchgeführt. 2026 ist ein Self-Service-Weg verfügbar für ungefähr $540 bis $1.000. Sie benötigen CASA Tier 2 nur, wenn Ihre App die mail.google.com Umfang externer Nutzer. Wenn Sie nur sensible Scopes verwenden (Gmail senden, gmail.readonly, Gmail ändern), CASA Tier 2 ist nicht erforderlich. Stattdessen gilt die kostenlose Standard-Sicherheitsbewertung von Google.
A Gmail API-Schlüssel ist für öffentliche, nicht benutzerspezifische Anfragen und gewährt keinen Zugriff auf das Postfach eines Benutzers. Gmail API OAuth-Anmeldeinformationen (client_id + kunden_geheimnis) werden verwendet, um die Autorisierung pro Nutzer zu erhalten, um auf deren Gmail-Daten in deren Namen zuzugreifen. Für alle Funktionen, die E-Mails eines Nutzers lesen, senden oder ändern, benötigen Sie OAuth-Anmeldedaten, keine API-Schlüssel. Eine detaillierte Gegenüberstellung finden Sie in unseren Gmail API Schlüssel vs. OAuth-Leitfaden.
Haben Sie noch Fragen zur Google OAuth App-Verifizierung oder zu Managed Gmail OAuth? Unser Team hilft Ihnen gerne weiter.
Sprechen Sie mit einem Experten
DE 
EN 
FR 
ES 
IT 
BR 
NL 
PL 
TR