LinkedIn
Instagram
WhatsApp
Telegramm
Google Mail
Ausblick
Google Kalender
Slack-Gemeinschaft beitretenGoogle OAuth-Zustimmungsbildschirm Einrichtung, Fehlerbehebungen & Warum es nicht angezeigt wird (2026)
Der Google OAuth-Zustimmungsbildschirm wurde 2024 verschoben. Er befindet sich jetzt unter Google-Authentifizierungsplattform in der Cloud Console – nicht dort, wo Sie es früher gefunden haben. Diese Anleitung zeigt Ihnen genau, wohin Sie gehen müssen, wie Sie es Schritt für Schritt konfigurieren und wie Sie die häufigsten Probleme beheben (einschließlich der Fälle, in denen es sich weigert zu erscheinen).
Wo ist es? Seit 2024 befindet sich der Google OAuth-Zustimmungsbildschirm unter APIs & Dienste > Google Auth Platform in der Cloud Console – nicht der alte Menüpunkt "OAuth-Zustimmungsbildschirm". Die Einstellungen sind nun auf drei Tabs aufgeteilt: Branding (App-Name, Logo, Domänen), Publikum (Interner/externer Benutzertyp, Testbenutzer) und Kunden (OAuth-Client-IDs). Wenn das Menü gar nicht angezeigt wird, hat Ihr Projekt noch keine OAuth-kompatible API aktiviert, oder Ihrem Konto fehlt die Rolle "Inhaber" oder "Bearbeiter".
Wo ist der OAuth-Zustimmungsbildschirm im Jahr 2026?
Wenn Sie einem Tutorial gefolgt sind, das vor 2024 verfasst wurde und "OAuth-Zustimmungsbildschirm" nicht in der linken Seitenleiste finden können, bilden Sie sich nichts ein. Google benannte und strukturierte den gesamten Abschnitt um. Es lebt nun unter neuem Namen: Google-Authentifizierungsplattform. Das ist der häufigste Grund, warum Entwickler berichten, dass der Google OAuth-Zustimmungsbildschirm "nicht angezeigt" wird – er ist immer noch da, nur an einer anderen Stelle.
Schritt 1: Geh Konsole.cloud.google.com und stellen Sie sicher, dass Sie das richtige Projekt im oberen Projektwähler ausgewählt haben. Viele "wird nicht angezeigt"-Probleme werden einfach dadurch verursacht, dass Sie sich im falschen Projekt befinden.
Schritt 2: Klicken Sie in der linken Seitenleiste auf APIs & Services.
Schritt 3: Schau nach Google-Authentifizierungsplattform im Untermenü (früher "OAuth-Zustimmungsbildschirm" genannt). Wenn Sie es sehen, klicken Sie darauf. Wenn nicht, siehe den Abschnitt zur Fehlerbehebung unten.
Schritt 4: Sie landen auf dem Dashboard der Google Auth Platform. Die drei Tabs – Branding, Publikumund Kunden - die alte einseitige Einwilligungsbildschirmmaske ersetzen.
Der Tab "Zielgruppe" in der Google Auth Platform (früher "OAuth-Zustimmungsbildschirm") – hier wählen Sie den Nutzer-Typ "Intern" oder "Extern" aus und verwalten Testnutzer.
OAuth-Zustimmungsbildschirm wird nicht angezeigt oder leitet immer wieder weiter: So beheben Sie das Problem
Der Google OAuth-Einwilligungsbildschirm kann aus mehreren unterschiedlichen Gründen nicht angezeigt werden oder sich unerwartet verhalten. Nachstehend finden Sie jedes Fehlerbild mit seiner genauen Ursache und Behebung – formatiert, um so schnell wie möglich gescannt zu werden.
Die Google Cloud Console UI hat sich im Jahr 2024 geändert. Der alte Menüpunkt "OAuth-Zustimmungsbildschirm" wurde umbenannt in "Google Auth-Plattform". Ältere Tutorials verweisen noch auf den alten Namen.
In der linken Seitenleiste unter APIs & Services, scrolle, bis du siehst "Google Auth-Plattform". Wenn Sie es immer noch nicht sehen, müssen Sie möglicherweise zuerst mindestens eine Google API für Ihr Projekt aktivieren (der Abschnitt wird erst angezeigt, wenn eine OAuth-kompatible API aktiviert ist).
Ihr Google-Konto hat nicht die IAM-Rolle "Owner" oder "Editor" Auf dem Projekt. Konten mit der Betrachterrolle können die Einstellungen des Einwilligungsbildschirms nicht bearbeiten.
Bitten Sie den Projekteigentümer, Ihnen die ... zu gewähren Redakteur Rolle (oder höher) über IAM & Admin > IAM. Wenn Sie das Projekt selbst erstellt haben, stellen Sie sicher, dass Sie mit dem richtigen Google-Konto angemeldet sind – die Projektauswahl zeigt manchmal Projekte an, für die Sie nur Leseberechtigung haben.
Sie haben keine ausgewählt Benutzertyp (Intern vs. Extern) jedoch. In der neuen Benutzeroberfläche erwartet die Schaltfläche "Loslegen" auf der Übersichtsseite der Google Auth-Plattform, dass Sie zuerst den Schritt "Zielgruppe" abschließen.
Klicken Sie auf der Übersichtsseite der Google Authentifizierungsplattform auf "\"Erste Schritte\" Wenn Sie dazu aufgefordert werden, navigieren Sie zu Zielgruppen-Register und wählen Sie entweder Intern oder Extern. Sobald ein Benutzertyp gespeichert wurde, wird das vollständige Form.
Meine App ist in Teststatus (oder der Veröffentlichungsstatus ist "In Prüfung") und Sie fordern sensible oder eingeschränkte Bereiche an. Google zeigt das "Nicht verifizierte App"-Interstitial vor dem eigentlichen Zustimmungsbildschirm an.
Für die Entwicklung: fügen Sie die E-Mail des Testbenutzers zu Ihrer Testbenutzerliste (Zielgruppen-Tab). Für die Produktion: Reichen Sie Ihre App zur OAuth-Verifizierung bei Google ein. Nutzer, die als Testnutzer aufgeführt sind, sehen weiterhin eine Warnung, können aber fortfahren, indem sie auf "Erweitert > Weiter zu [App-Name]" klicken. Die Warnung verschwindet, sobald Ihre App verifiziert und veröffentlicht wurde.
Dies ist das erwartete Verhalten. Sobald ein Nutzer die Zustimmung erteilt hat, speichert Google diese Zustimmung und überspringt den Bildschirm bei nachfolgenden Anmeldungen. Der Zustimmungsbildschirm wird nur erneut angezeigt, wenn der Nutzer den Zugriff widerruft oder Sie neue Bereiche (Scopes) anfordern.
Um zum Testen eine erneute Anzeige zu erzwingen, fügen Sie hinzu Zustimmung in Ihre Autorisierungs-URL-Parameter. In der Produktion verwenden Sie nur Zustimmung beim ersten Autorisierungsaufruf (um die Aktualisierungsschlüssel) - nicht bei jedem Login.
Zugriff verweigert Fehler stattdessen. Interne Apps sind standardmäßig auf Benutzer innerhalb Ihres Google Workspace-Mandanten beschränkt. Wechseln Sie zu "Extern", wenn Sie Benutzer außerhalb von Workspace unterstützen möchten.Unipiles vorkonfigurierter OAuth-Schlüssel eliminiert diese Fehlerszenarien aus Ihrem Setup – keine Konfiguration der Zustimmungsanzeige auf Ihrer Seite, da wir als unabhängiger technischer Vermittler im Namen jedes authentifizierten Benutzers handeln.
So richten Sie den OAuth-Zustimmungsbildschirm Schritt für Schritt ein
Dieser Abschnitt behandelt die Konfiguration des vollständigen Zustimmungsbildschirms – den Teil, den Sie nach der Erstellung eines Google Cloud-Projekts und der Aktivierung einer Google API abschließen müssen. Wenn Sie diese Schritte noch nicht durchgeführt haben, siehe Vollständiger Google OAuth-Leitfaden welcher die Projekterstellung und API-Aktivierung zuerst behandelt.
Im Zielgruppen-Register, die erste Entscheidung ist, ob Ihre App Nutzer innerhalb Ihrer Google Workspace Organisation oder beliebige Google-Kontoinhaber bedient:
- Intern Nur Nutzer innerhalb Ihrer Google Workspace Organisation. Keine Verifizierung erforderlich. Ideal für interne Tools, Admin-Panels oder Unternehmensanwendungen, die nur von Ihren eigenen Mitarbeitern genutzt werden. Nicht verfügbar, wenn Ihr Projekt mit einem persönlichen Gmail-Konto verknüpft ist (nur Workspace-Konten).
- Extern: Jeder Google-Kontoinhaber. Apps starten im "Testmodus" mit einer Beschränkung auf 100 Nutzer. Sensible oder eingeschränkte Scopes erfordern den Verifizierungsprozess von Google, bevor die App für alle Nutzer veröffentlicht werden kann.
Zielgruppen-Tab: Wählen Sie "Intern" (nur Workspace) oder "Extern" (beliebiges Google-Konto). Diese Entscheidung wirkt sich auf Ihre Verifizierungsanforderungen aus.
Tipp: Sie können später von "Intern" auf "Extern" umstellen, aber Sie können nicht von "Extern" zurück auf "Intern" wechseln, sobald Benutzer Ihre App autorisiert haben. Wählen Sie sorgfältig.
Im Branding-Tab, füllen Sie die folgenden Felder aus. Diese sieht der Nutzer auf dem Google OAuth-Zustimmungsbildschirm, wenn er Ihre App autorisiert:
- App-Name: der oben auf dem Einwilligungsbildschirm prominent angezeigte Name. Verwenden Sie Ihren Produktnamen, keine technische Kennung.
- Support-E-Mail auf dem Zustimmungsbildschirm als Ansprechpartner für Nutzer angezeigt, die Fragen zu den Zugriffsanfragen Ihrer App haben. Verwenden Sie eine überwachte Alias-Adresse oder Verteilerliste – keine persönliche E-Mail-Adresse.
- App-Logo Ein quadratisches PNG oder JPG, mindestens 120x120 Pixel. Erscheint auf dem Zustimmungsbildschirm und in der Liste der autorisierten Apps des Google-Kontos. Optional, aber für das Vertrauen der Nutzer dringend empfohlen.
Branding-Tab – App-Informationen: Geben Sie den App-Namen, das Logo und die Support-E-Mail-Adresse genau so ein, wie sie auf dem Zustimmungsbildschirm für Benutzer angezeigt werden sollen.
Noch im Branding-Tab, Der Abschnitt "App-Domäne" erfordert die folgenden Links:
- Anwendungs-Homepage-URL: die öffentliche Homepage Ihrer App oder Ihres Produkts. Muss eine Live-, zugängliche URL sein (keine Anmeldeseite).
- Link zur Datenschutzerklärung: erforderlich für alle externen Apps, die nach grundlegenden Anmeldungen hinausgehende Berechtigungen anfordern. Darin müssen die von Ihnen angeforderten Google-Berechtigungen und die Verwendung der Daten ausdrücklich genannt werden. Das Google-Verifizierungsteam prüft dies sorgfältig – eine fehlende oder vage Datenschutzrichtlinie ist der häufigste Ablehnungsgrund.
- Link zu den Nutzungsbedingungen: optional, aber für Produktions-Apps empfohlen.
App-Domäne: Stellen Sie Live-URLs für Ihre Homepage, Ihre Datenschutzrichtlinie und Ihre Nutzungs.
Die Autorisierte Domains Abschnitt (unter App-Domäne) steuert, welche Domänen in Ihren OAuth-Weiterleitungs-URIs und in den obigen App-Domänenlinks verwendet werden können. Fügen Sie die Stammdomäne Ihrer Anwendung hinzu (z. B. yourapp.com).
Autorisierte Domains: Fügen Sie Ihre Stammdomain hinzu. Nur Umleitungs-URIs und App-URLs von dieser Domain werden von Google akzeptiert.
Tipp: autorisierte Domains und Redirect URIs (im Tab "Clients" festgelegt) müssen übereinstimmen. Wenn Ihre Redirect URI https://app.yourapp.com/callback, Sie müssen autorisieren yourapp.com hier, nicht app.ihreapp.de.
Außerdem in der Branding-Tab, stellen Sie eine Entwicklerkontakt-E-Mail bereit. Dies ist die Adresse, die Google zum Senden verwendet:
- Statusaktualisierungen der Verifizierung (Genehmigung, Ablehnung oder Klärungsanfragen)
- Richtlinienkonformitätshinweise
- Benachrichtigungen über Änderungen am OAuth-Status Ihrer App
Entwicklerkontakt: Verwenden Sie eine überwachte Verteilerliste. Kritische Google-Bestätigungs-E-Mails können als Spam gefiltert werden – überprüfen Sie Ihr Spam-Verzeichnis während Ihres Überprüfungszeitraums.
Das ist wichtig: Nutzen Sie eine Verteilerliste oder ein freigegebenes Postfach, keine persönliche E-Mail. Das Verifizierungsteam von Google kann während der Geschäftszeiten in einer anderen Zeitzone E-Mails senden. Wenn Sie das Antwortfenster verpassen, kann Ihre Verifizierung um Wochen verzögert werden.
Bereiche definieren, auf welche Daten Ihre App im Namen des Nutzers zugreifen kann. In der neuen Google Auth Platform-Oberfläche können Bereiche pro OAuth-Client konfiguriert werden (unter dem Kunden-Tab Client auswählen > Umfänge). Klicken Sie auf "Geltungsbereiche hinzufügen oder entfernen" um den Bereichsauswähler zu öffnen.
Geltungsbereiche, die Ihren Verifizierungspfad beeinflussen:
- Unkritische Bereiche (z. B.
openid,E-Mail,Profil): Nur grundlegende Anmeldung. Keine Verifizierung erforderlich. App wird sofort veröffentlicht. - Sensible Bereiche (z. B.
gmail.readonly,Gmail senden,Gmail-Labels): erfordert eine Google-Sicherheitsüberprüfung (OAuth-Verifizierung). Die App bleibt bis zur Verifizierung im Testmodus. - Eingeschränkte Bereiche (z. B.
mail.google.com,Gmail ändern): erfordert sowohl die Google OAuth-Verifizierung als auch eine CASA Tier 2-Sicherheitsüberprüfung. Dauert deutlich länger.
Geltungsbereichsauswahl: Wählen Sie die minimalen Geltungsbereiche aus, die Ihre App tatsächlich benötigt. Jeder sensible oder eingeschränkte Geltungsbereich fügt Verifizierungsanforderungen hinzu. Planen Sie dies, bevor Sie aufbauen.
Für eine vollständige Übersicht über Gmail-spezifische Scopes, welche APIs sie jeweils freischalten und wie Sie diese in Ihrer Autorisierungs-URL anfordern, siehe Gmail API Scopes Leitfaden.
Prinzip der geringsten Rechte Fordere nur die Bereiche an, die deine App derzeit nutzt. Das Hinzufügen eines eingeschränkten Bereichs nach dem Start bedeutet einen vollständigen Neustart des Verifizierungsprozesses, einschließlich einer neuen CASA-Audit der Stufe 2.
Im Zielgruppen-Register, der / die / das Testbenutzer Bereich können Sie Google-Konto-E-Mails hinzufügen, die Ihre App autorisieren können, während sie sich im Teststatus.
Wichtige Regeln zur Begrenzung von Testbenutzern:
- Maximal 100 Testnutzer kann zu einer externen Anwendung im Teststatus hinzugefügt werden. Dies ist ein striktes Google-Limit – Sie können es nicht erhöhen, ohne Ihre App zu veröffentlichen.
- Testbenutzer sehen den Warnbildschirm "Nicht verifizierte App", können Ihre App aber durch Klicken auf die Warnung autorisieren.
- Zugriffstoken für Testbenutzer im Testmodus verfallen nach 7 Tage. Benutzer müssen sich neu autorisieren, wenn der Token abläuft.
- Sobald Sie die Verifizierung einreichen und Google Ihre App genehmigt, wird die Begrenzung auf 100 Nutzer aufgehoben und die 7-Tage-Gültigkeit entfällt.
Falls Sie mehr als 100 Nutzer vor der Verifizierung benötigen: Die einzige Option ist, Ihre App zur Google-Verifizierung einzureichen. Es gibt keine Umgehungslösung innerhalb der Systeme von Google. Alternativ sollten Sie prüfen, ob der vorab verifizierte OAuth-Schlüssel von Unipile (nächster Abschnitt) den OAuth-Flow für Sie übernehmen kann und somit sowohl das Limit als auch die Verifizierungszeit entfällt.
Möchten Sie diesen gesamten Prozess der Konfiguration des OAuth-Einwilligungsbildschirms überspringen?
Verwenden Sie stattdessen den verifizierten OAuth-Schlüssel von Unipile – keine Einrichtung eines Zust.
Intern vs. extern: Welches sollten Sie wählen?
Die Wahl zwischen "intern" und "extern" auf dem Google OAuth „Consent Screen“ ist eine der folgenschwersten Entscheidungen bei der Einrichtung. Sie bestimmt Ihren Verifizierungspfad, Ihre Benutzerbasis und ob Sie während der Entwicklung eine Begrenzung auf 100 Benutzer haben werden. Hier ist das Gesamtbild.
Überspringen Sie die Entscheidung intern/extern vollständig
Mit dem vorab geprüften OAuth-Schlüssel von Unipile bedienen Sie externe Benutzer ohne Google-Verifizierung – Unipile agiert im Namen jedes authentifizierten Benutzers als unabhängiger technischer Vermittler.
Nach der Zustimmungsanzeige: Verifizierung und CASA
Die Konfiguration des Google OAuth-Zustimmungsbildschirms ist nicht das Ende des Prozesses für externe Anwendungen, die sensible oder eingeschränkte Bereiche anfordern. Was als Nächstes kommt, hängt von den von Ihnen gewählten Bereichen ab. Hier ist die Kurzfassung – die vollständige Überprüfung und der CASA-Walkthrough finden Sie im Google OAuth Hub.
Nachdem du die OAuth-Einwilligungsbildschirm konfiguriert hast, ist deine externe App im Teststatus. Nur die von Ihnen zur Liste der Testbenutzer hinzugefügten Benutzer (bis zu 100) können Ihre App autorisieren. Dies ist für die Entwicklung und erste Tests in Ordnung.
Wenn du bereit bist, deine App für mehr Nutzer zu öffnen, klicke auf "Vorbereitung für die Verifizierung" (oder "Zur Überprüfung einreichen") in der Übersicht der Google Auth-Plattform. Google prüft die Datenschutzrichtlinie Ihrer App, autorisierte Domains, angeforderte Bereiche und wie Ihre App die Daten verwendet. Die Prüfungszeit variiert – in der Regel 2-6 Wochen, bei eingeschränkten Bereichen manchmal länger.
Wenn Ihre App eingeschränkte Bereiche anfordert (wie z. B. mail.google.com oder Gmail ändern), Google benötigt zusätzlich ein CASA Tier 2 Sicherheitsprüfung durch einen zugelassenen Gutachter eines Drittanbieters. Dies beinhaltet eine Überprüfung der Sicherheitslage Ihrer App, der Datenverarbeitung und der Zugriffskontrollen.
Nach erfolgreicher Verifizierung wird Ihre App veröffentlicht. Der Bildschirm mit der Warnung "Nicht verifizierte App" verschwindet. Die 100-Benutzer-Beschränkung wird aufgehoben. Die 7-tägige Token-Gültigkeit für Testbenutzer entfällt. Benutzer sehen Ihren markengeschützten Zustimmungsbildschirm ohne Warnungen.
Um einen umfassenderen Überblick darüber zu erhalten, wie Google OAuth in die E-Mail-API-Architektur passt – einschließlich des einheitlichen Zugriffs auf Anbieter über Gmail, Outlook und IMAP –, siehe E-Mail-API-Leitfaden.
Unipile hat die CASA Tier 2-Prüfung für die Google OAuth-Integration bereits abgeschlossen. Das bedeutet, wenn Sie Unipile als unabhängiger technischer Vermittler, handelnd im Namen jedes authentifizierten Benutzers, Sie müssen den CASA-Prozess nicht selbst durchlaufen. Sehen Sie sich die Vollständiges Google OAuth-Zentrum für die Details zum Zertifizierungsweg von Unipile und wie der POC / später zertifizieren / Wechsel-Workflow funktioniert.
Überspringen Sie die Einrichtung des Zustimmungsbildschirms vollständig
Wenn Ihr Produkt auf die Gmail- oder Google Kalenderdaten der Nutzer zugreifen muss, können Sie die Einrichtung des Google OAuth-Bestätigungsbildschirms selbst vornehmen – oder Sie können Unipile als unabhängiger technischer Vermittler, handelnd im Namen jedes authentifizierten Benutzers, mit einem vorab verifizierten OAuth-Schlüssel, der bereits die CASA-Zertifizierung der Stufe 2 hat. Dies ist keine Umgehung der Sicherheitsüberprüfung von Google. Unipile hat diese Überprüfung für Sie abgeschlossen – das ist das Produkt.
Unipile ist nicht mit Google verbunden, wird von Google nicht unterstützt und von Google nicht gesponsert. Unipile fungiert als unabhängiger technischer Vermittler zwischen Ihrer Anwendung und der Google OAuth-Infrastruktur.
Verbinden Sie die Google-Konten Ihrer Nutzer über die verifizierte OAuth-Integration von Unipile. Ihre Nutzer autorisieren einmalig – Unipile übernimmt den Rest als unabhängiger technischer Vermittler im Namen jedes authentifizierten Nutzers.
Google OAuth-Zustimmungsbildschirm - FAQ
Die häufigsten Fragen zur Konfiguration, Fehlerbehebung und Navigation des Google OAuth-Zustimmungsbildschirms im Jahr 2026.
Es gibt fünf häufige Gründe: (1) Sie suchen das alte Menü "OAuth-Zustimmungsbildschirm" – es wurde umbenannt in "Google Auth-Plattform" im Jahr 2024. (2) Sie sind im falschen Projekt – überprüfen Sie die Projektauswahl oben. (3) Ihr Konto hat keine Eigentümer- oder Editor-IAM-Rolle. (4) Es wurde noch keine OAuth-kompatible API für das Projekt aktiviert. Der Abschnitt Google Auth-Plattform wird erst angezeigt, wenn eine API aktiviert wurde. (5) Ihre App ist als intern konfiguriert, aber Sie testen mit einem externen Google-Konto – interne Apps blockieren standardmäßig alle Nicht-Workspace-Benutzer. Detaillierte Fehlerbehebungen finden Sie unter Fehlerbehebungsabschnitt oben.
Seit 2024, navigieren Sie zu APIs & Dienste > Google Auth Platform. Der alte Menüpunkt "OAuth-Zustimmungsbildschirm" existiert nicht mehr – er wurde durch die Google Auth Platform ersetzt, die die Einstellungen in drei Tabs organisiert: Branding (App-Name, Logo, Domänen), Publikum (Interner/externer Benutzertyp, Testbenutzer) und Kunden OAuth Client-IDs und Weiterleitungs-URIs. Diese Umstrukturierung der Benutzeroberfläche ist die mit Abstand größte Ursache für die Suche "Google OAuth-Zustimmungsbildschirm wird nicht angezeigt" im Jahr 2026.
Mehr dazu in unserem Vollständige Google OAuth Playground-Anleitung.Internalle Nutzer befinden sich in Ihrer Google Workspace Organisation, niemals erforderliche Verifizierung, keine Testbenutzerbeschränkung, keine Warnung vor nicht verifizierten Nutzern. Am besten für interne Tools. Erfordert ein Workspace-Konto (kein persönliches Gmail).
Extern: Jeder Google-Konto-Inhaber kann Ihre App nutzen. Startet im Testmodus (Limit von 100 Nutzern). Sensible Geltungsbereiche erfordern eine Google-Verifizierung (2-6 Wochen). Eingeschränkte Geltungsbereiche benötigen zusätzlich CASA Tier 2. Wählen Sie „Extern“ für alle öffentlich oder kundenorientierten Anwendungen.
Die Obergrenze beträgt 100 Testnutzer für externe Apps im Teststatus. Diese Grenze wird von Google festgelegt und kann nicht umgangen werden. Testbenutzer können Ihre App weiterhin autorisieren, sehen jedoch zuerst einen Warnbildschirm. Ihre Token laufen nach 7 Tage (anstelle der normalen Gültigkeitsdauer des Aktualisierungs-Tokens). Um die Einschränkung aufzuheben, reichen Sie Ihre App zur OAuth-Verifizierung bei Google ein. Nach der Veröffentlichung gibt es keine Benutzerbeschränkung.
Das hängt von Ihrer Konfiguration ab: Interne Apps nie eine Verifizierung benötigen. Externe Apps mit nur Basis-Bereichen (openid, E-Mail, Profil) kann ohne Verifizierung veröffentlichen. Externe Apps mit Anfragen für sensible Bereiche wie Gmail senden, gmail.readonly) müssen die OAuth-Verifizierung von Google bestehen, bevor die Grenze von 100 Benutzern aufgehoben wird. Externe Apps, die eingeschränkte Bereiche anfordern wie mail.google.com) zusätzlich eine CASA Tier 2 Sicherheitsprüfung erfordern – zusätzlich zur Standardüberprüfung. Siehe die Gmail API Scopes Leitfaden für die vollständige Geltungsbereichsklassifizierung.
Sie können die Google OAuth-Zustimmungsaufforderung nicht innerhalb der eigenen Infrastruktur von Google überspringen – dies ist ein notwendiger Schritt für jeden OAuth 2.0-Flow. Sie können jedoch die Konfiguration und die eigene Verifizierung vermeiden, indem Sie Unipiles vorab geprüfter OAuth-Schlüssel. Unipile fungiert als unabhängiger technischer Vermittler im Namen jedes authentifizierten Nutzers, wobei die Google-Verifizierung und die CASA Tier 2-Zertifizierung bereits abgeschlossen sind. Dies ist keine Sicherheitslösung - Unipile hat den vollständigen Überprüfungsprozess von Google durchlaufen. Ihre Nutzer sehen weiterhin einen Zustimmungsbildschirm (den verifizierten von Unipile), Sie müssen nur keinen eigenen erstellen und verifizieren.
Entdecken Produktionsbereite Integration der Gmail API.Haben Sie noch Fragen zur Google OAuth-Einrichtung? Unser Team hilft Ihnen gerne weiter.
DE 
EN 
FR 
ES 
IT 
BR 
NL 
PL 
TR