LinkedIn
Instagram
WhatsApp
Telegramm
Google Mail
Ausblick
Google Kalender
Slack-Gemeinschaft beitretenDie Google OAuth Playground ist Googles offizielles Sandbox-Tool zum Testen von OAuth 2.0-Autorisierungsabläufen, ohne eine einzige Zeile Backend-Code schreiben zu müssen. Diese Anleitung führt Sie durch jedes Feature: Auswahl von Bereichen (Scopes), Austausch von Autorisierungscodes gegen Token, Ausführung von Live-API-Aufrufen und Verständnis, wann Sie von der Playground-Umgebung zu einer produktionsreifen Lösung wechseln müssen.
Was ist das Google OAuth Playground?
Die Google OAuth Playground ist ein kostenloses, browserbasiertes Werkzeug unter developers.google.com/oauthplayground mit dem Entwickler den vollständigen OAuth 2.0-Autorisierungsfluss gegen jede Google API testen können, ohne einen Back-End-Server einzurichten, eine App zu registrieren oder Code auf der Serverseite zu schreiben.
Im Kern ist dieses Tool eine grafische Benutzeroberfläche für den Three-Legged OAuth 2.0-Flow. Sie wählen die gewünschten Google API-Bereiche aus, klicken auf "APIs autorisieren", schließen den Google-Zustimmungsbildschirm ab und tauschen dann den resultierenden Autorisierungscode gegen ein Zugriffstoken und ein Aktualisierungstoken ein. Von da an können Sie authentifizierte API-Anfragen direkt im Browser stellen und die rohen Anfrage- und Antwortnutzlasten inspizieren.
Es ist besonders nützlich für Teams, die auf Gmail, Google Kalender, Google Drive oder jeder anderen Google Workspace API aufbauen. Anstatt Token-Flows in der Produktion zu debuggen, können Sie alles zuerst in einer sicheren Sandbox testen. Die Google OAuth 2.0-Sandbox unterstützt jeden veröffentlichten Google OAuth-Bereich und zeigt in jedem Schritt des Flows die genauen HTTP-Header und JSON-Payloads an.
Warum Entwickler den Google OAuth Playground nutzen
Der OAuth2 Playground löst vier spezifische Entwicklerprobleme. Wenn Sie verstehen, welches auf Sie zutrifft, können Sie das Beste aus jeder Sitzung herausholen und wissen, wann Sie zu einem Produktionssetup übergehen sollten.
Bevor Sie Ihre App versenden, müssen Sie genau wissen, welcher OAuth-Bereich Zugriff auf welche Daten gewährt. Die Playground-Umgebung ermöglicht Ihnen den Vergleich gmail.readonly gegen Gmail ändern gegen Gmail senden nebeneinander, indem Sie die eigentliche Gmail-API aufrufen und prüfen, welche jeder Umfang preisgibt. Dies verhindert Überberechtigungen (Anfordern zu vieler Umfänge, was zu mehr Überprüfung durch das Google-Review-Team führt) und Unterberechtigungen (Anfordern zu weniger, was zu Laufzeitfehlern für Ihre Nutzer führt).
Das Einrichten eines vollständigen OAuth-Redirect-Flows lokal nimmt Zeit in Anspruch: Sie benötigen einen HTTP-Server, eine Callback-URL, Sitzungsverwaltung und Token-Speicherung. Der Playground umgeht all dies. Sie authentifizieren sich einmal im Browser, erhalten Ihre Token und führen dann jeden Google API-Endpunkt direkt über das Bedienfeld "Anfrage senden" aus. Dies ist besonders nützlich zur Fehlersuche bei unerwarteten 403-Fehlern oder zum Verständnis der Struktur von API-Antworten, bevor Sie die Parsing-Logik in Ihrer Anwendung schreiben.
Der Playground ist eines der besten Lernwerkzeuge, um zu verstehen, wie OAuth 2.0 tatsächlich funktioniert. Die schrittweise Benutzeroberfläche macht den abstrakten Ablauf konkret: Sie sehen, wie die Autorisierungs-URL mit den von Ihnen gewählten Bereichen aufgebaut wird, Sie sehen den Autorisierungscode, der bei der Weiterleitung zurückgegeben wird, und Sie sehen, wie dieser Code gegen ein Zugriffstoken und ein Aktualisierungstoken ausgetauscht wird. Für Teams, die Ingenieure einarbeiten, die noch keine Erfahrung mit OAuth haben, ersetzt eine 30-minütige Sitzung im Playground stundenlanges Lesen von Dokumentationen. Lesen Sie unseren Leitfaden zu Google OAuth 2.0 in Ihre App integrieren für die vollständige Produktionsimplementierung.
Manchmal benötigen Sie nur ein gültiges Zugriffstoken, um ein einmaliges Datenmigrationsskript auszuführen, eine Webhook-Nutzlast zu testen oder eine API-Integration manuell zu überprüfen. Die Playground-Umgebung generiert ein funktionierendes Zugriffstoken in weniger als 60 Sekunden. Kopieren Sie es, fügen Sie es in Ihren Curl-Befehl oder Postman ein und schon sind Sie fertig. Der Nachteil ist, dass Playground-Token (unter Verwendung der Standardanmeldeinformationen von Google) nach Ablauf ablaufen 24 Stunden für den Aktualisierungstoken, und der Zugriffstoken läuft nach 1 Stunde ab – dieser Ansatz ist daher auf kurzlebige Skripte beschränkt.
Schnellstart: Ihre erste Playground-Sitzung in 3 Minuten
Befolgen Sie diese fünf Schritte, um von Null zu einem funktionierenden API-Aufruf in der Playground-Umgebung zu gelangen. Für diesen grundlegenden Ablauf ist keine Einrichtung der Google Cloud Console erforderlich.
Öffnen Sie developers.google.com/oauthplayground in Ihrem Browser. Sie sehen die Hauptoberfläche, die in drei Abschnitte unterteilt ist: Schritt 1 (APIs auswählen und autorisieren), Schritt 2 (Autorisierungscode gegen Token austauschen) und Schritt 3 (Anfrage an API konfigurieren). Auf der rechten Seite befindet sich das OAuth 2.0-Konfigurationsfenster, das über das Zahnradsymbol aufgerufen werden kann. Stellen Sie sicher, dass Sie bei Ihrem Google-Konto angemeldet sind, bevor Sie fortfahren.
Klicken Sie im Fenster "Schritt 1" durch die Liste der Google APIs oder verwenden Sie das Suchfeld. Klicken Sie auf Gmail API v1 erweitern. Auswählen https://www.googleapis.com/auth/gmail.readonly um mit schreibgeschütztem Zugriff zu beginnen. Sie können mehrere Bereiche aus mehreren APIs in einer Sitzung auswählen – sie werden alle in einer einzigen Autorisierungsanfrage zusammengefasst. Sobald Sie Ihren/Ihre Bereich/e ausgewählt haben, klicken Sie auf das blaue "APIs autorisieren" Knopf.
Sie werden zur Google-Einwilligungsmaske weitergeleitet. Dies ist dieselbe OAuth-Zustimmungsbildschirm Ihre Endbenutzer sehen dies in Ihrer Produktions-App – das Playground verwendet lediglich den Google-Namen anstelle Ihres eigenen. Wählen Sie Ihr Google-Konto aus, überprüfen Sie die angeforderten Berechtigungen und klicken Sie auf "Zulassen". Google leitet Sie mit einem Autorisierungscode in der URL zurück zum Playground.
Sie sind jetzt in Schritt 2. Die Playground-Umgebung hat den Autorisierungscode automatisch erfasst. Klicken Sie auf "Autorisierungscode gegen Token austauschen". Der Spielplatz sendet eine POST-Anfrage an https://oauth2.googleapis.com/token und zeigt sowohl die Rohdaten der Anfrage als auch die Antwort an. Sie werden Ihre Zugriffstoken (gültig für 1 Stunde) und Ihr Aktualisierungsschlüssel im Antwortbereich. Notiere dir diese, falls du sie außerhalb des "Playgrounds" wiederverwenden möchtest.
Geben Sie in Schritt 3 den Gmail API-Endpunkt im Feld "Request URI" ein: https://gmail.googleapis.com/gmail/v1/users/me/messages. Die HTTP-Methode als belassen GET und klicken Sie auf "Anfrage senden". Die Playground-Umgebung fügt Ihr Zugriffstoken automatisch als Bearer-Header ein. Im Antwortbereich wird die JSON-Nutzlast der Gmail API angezeigt – eine Liste von Nachrichten-IDs aus Ihrem Posteingang. Sie haben gerade einen vollständigen OAuth 2.0-Flow in der Playground-Umgebung abgeschlossen.
Schritt für Schritt: OAuth-Bereiche im Google OAuth Playground testen
Die Auswahl des Geltungsbereichs ist die wichtigste Entscheidung bei Ihrer OAuth-Integration. Ist er zu breit gefasst, wird das Review-Team von Google Ihre App beanstanden. Ist er zu eng gefasst, geben Ihre API-Aufrufe 403-Fehler zurück. Mit der Playground können Sie jede Kombination testen, bevor Sie sich festlegen. Eine vollständige Referenz aller Gmail-Geltungsbereiche finden Sie in unserem Gmail API Scopes Leitfaden.
gmail.readonly vor dem Testen Gmail ändern. Dieses Prinzip der geringsten Rechte reduziert die Angriffsfläche Ihrer App und vereinfacht die Sicherheitsüberprüfung durch Google. Mehr zum Überprüfungsprozess: Google OAuth Verifizierungshandbuch.| Umfang | Zugriffsebene | Empfindlichkeit | Anwendungsfall |
|---|---|---|---|
gmail.readonly |
Alle Nachrichten und Einstellungen lesen | Empfindlich | E-Mail-Analysen, Posteingangs-Synchronisierung |
Gmail ändern |
Lesen, Labels ändern, Nachrichten löschen | Eingeschränkt | CRM-Integration, Triage-Apps |
Gmail senden |
Nur Nachrichten senden | Eingeschränkt | Transaktionale Sendungen im Auftrag des Benutzers |
Gmail verfassen |
Entwürfe erstellen, lesen, aktualisieren und löschen | Empfindlich | KI-E-Mail-Assistenten, Entwurfsverwaltung |
Gmail-Labels |
Labels erstellen, lesen, aktualisieren und löschen | Empfindlich | Automatisierung, Organisationstools |
gmail.metadaten |
Nur Metadaten der Nachricht lesen (Header, Labels) | Unempfindlich | E-Mail-Präsenzanzeigen, Thread-Verfolgung |
Die Testumgebung funktioniert ebenso gut für das Testen der Kalender-API. Um den Lesezugriff auf den Kalender zu testen, wählen Sie https://www.googleapis.com/auth/calendar.readonly. Für vollständigen Lese-/Schreibzugriff, einschließlich Erstellung und Löschung von Ereignissen, verwenden Sie https://www.googleapis.com/auth/calendar. Kalenderbereiche folgen demselben Muster: beginne mit Schreibgeschützt, dann eskalieren Sie nur, wenn Schreiboperationen erforderlich sind. Ein häufiger Fehler ist die Anforderung des vollständigen Kalender Bereich, wenn Sie nur die Verfügbarkeit lesen müssen – dies löst unnötigerweise eine invasivere Sicherheitsüberprüfung aus.
Der Playground akzeptiert auch benutzerdefinierte Scope-URLs, die nicht im Standardmenü aufgeführt sind. Suchen Sie im Schritt-1-Bedienfeld nach dem Feld "Eigene Scopes eingeben" am unteren Rand. Fügen Sie eine beliebige gültige Scope-URL ein – zum Beispiel einen Scope aus dem Google Workspace Admin SDK oder einen Scope aus der Google People API –, und er wird zusammen mit allen zuvor ausgewählten Scopes in der Autorisierungsanforderung hinzugefügt. Dies ist nützlich für das Testen weniger gängiger Google APIs, die nicht prominent in der Playground-Oberfläche dargestellt werden.
Integrieren Sie Gmail mit UnipileSchritt für Schritt: Generierung von Zugriffstoken und Aktualisierungstoken
Der zweite Schritt des Playgrounds ist der Ort, an dem die eigentliche OAuth-Magie geschieht. Nach der Autorisierung liegt ein Autorisierungscode im Playground bereit, um ausgetauscht zu werden. Dieser Abschnitt erklärt die beiden erhaltenen Token, wie Sie einen Aktualisierungstoken erzwingen können und wie Sie den Austausch in Ihrem Produktionscode replizieren können.
Die Zugriffstoken eine kurzlebige Anmeldeinformation (standardmäßig 3600 Sekunden), die als Trägertoken verwendet wird in Authorization Header jeder API-Anfrage. Wenn er abläuft, gibt die API einen 401-Fehler zurück. Sie verwenden den Refresh-Token, um einen neuen Access-Token zu erhalten, ohne dass der Benutzer die erneute Autorisierung durchführen muss. Im Playground führt die Schaltfläche "Access-Token aktualisieren" dies automatisch in Schritt 2 durch.
Die Aktualisierungstoken ist eine langlebige Anmeldeinformation, mit der Ihre App neue Zugriffstoken ohne Benutzerinteraktion abrufen kann. Sie läuft in der Produktion nie ab (sofern sie nicht vom Benutzer widerrufen wird oder die App 6 Monate lang inaktiv war). Im Playground laufen mit den Standardanmeldeinformationen von Google abgerufene Aktualisierungstoken jedoch ab nach 24 Stunden. Dies ist eine playground-spezifische Einschränkung, keine Produktionsbeschränkung.
Standardmäßig gibt Google nur einen Refresh-Token zurück, der Premieren Ein Nutzer autorisiert Ihre App. Bei nachfolgenden Autorisierungen (wenn der Nutzer bereits zugestimmt hat) überspringt Google den Refresh-Token. Um das Playground-Tool zu zwingen, in Schritt 2 immer einen Refresh-Token zurückzugeben, klicken Sie auf das Zahnradsymbol, um die OAuth 2.0-Konfiguration zu öffnen, und aktivieren Sie beides "Kraftaufforderung" und "Zugriffsart: offline". Mit diesen Einstellungen gibt jeder Autorisierungsfluss einen neuen Aktualisierungstoken zurück.
Die Playground zeigt Ihnen genau den POST-Request, den sie sendet, um den Autorisierungscode auszutauschen. Sie können diesen Curl-Befehl direkt in Ihrem Backend replizieren:
Vorbehalt für 24-Stunden-Refresh-Token: Wenn Sie die Standard-Google-Anmeldeinformationen des Spielplatzes verwenden (die gängigste Einrichtung), beschränkt Google die Lebensdauer von Aktualisierungstoken auf 24 Stunden. Dies ist beabsichtigt: Der Spielplatz verwendet eine einzige, gemeinsam genutzte OAuth-Client-ID, und Google widerruft Token aus Sicherheitsgründen häufig. Wenn Sie ein Aktualisierungstoken benötigen, das länger als 24 Stunden gültig ist, aktivieren Sie in den Spielplatzeinstellungen die Option "Verwenden Sie Ihre eigenen OAuth-Anmeldeinformationen" – dies wird im nächsten Abschnitt behandelt.
Verwenden Sie Ihre eigenen OAuth-Anmeldedaten im Google OAuth Playground
Das Standard-Playground-Setup verwendet die gemeinsamen Entwickleranmeldedaten von Google, was zur 24-stündigen Ablauffrist für das Aktualisierungstoken führt. Der Wechsel zu Ihrer eigenen OAuth-Client-ID löst dieses Problem und macht das Verhalten des Playgrounds identisch mit Ihrer Produktionsanwendung. Dies ist der richtige Ansatz, wenn Sie testen müssen. API-Schlüssel im Vergleich zu OAuth-Unterschieden oder das vollständige durcharbeiten Google OAuth Integrationsfluss.
https://developers.google.com/oauthplayground. Dies ist die spezifische Umleitungs-URI, die das Playground erwartet.Gmail ändern) erfordert eine verifizierte App. Mit Ihren eigenen Anmeldeinformationen können Sie im Entwicklungsmodus mit bis zu 100 Testbenutzern testen, ohne die vollständige Verifizierung durchlaufen zu müssen.client_id, kunden_geheimnisund redirect_uri die Ihre Produktions-Backend verwenden wird. Sie können den Austauschcode direkt in Ihre App kopieren.https://developers.google.com/oauthplayground/ aber das Playground leitet zur URL ohne den Schrägstrich um, Sie erhalten eine redirect_uri_mismatch Fehler. Fügen Sie beide Versionen hinzu, wenn Sie unsicher sind. Für einen tieferen Einblick in die Fehlercodes von Google siehe unseren Leitfaden zu Gängige Google OAuth-Fehler.Häufige Fehler im Google OAuth Playground
Das sind die sechs Fehler und Stolperfallen, die Entwickler am häufigsten in der Playground aus der Bahn werfen. Jeder einzelne hat eine spezifische Lösung, die weniger als 2 Minuten in Anspruch nimmt.
Wenn Sie die Standard-Playground-Anmeldeinformationen von Google verwenden, wird Ihr Aktualisierungstoken nach 24 Stunden ungültig. Jedes Skript oder jede Integration, die auf diesem Token basiert, gibt dann 401 ungültig_grant Fehler am nächsten Tag.
Wenn Sie Ihre eigenen Anmeldedaten verwenden, gibt Google zurück error=redirect_uri_mismatch während des Autorisierungsschritts. Das bedeutet, dass die weiterleitende URI in Ihrem Cloud Console OAuth-Client nicht exakt mit derjenigen übereinstimmt, die das Playground sendet.
https://developers.google.com/oauthplayground als autorisierte Umleitungs-URI (ohne nachgestellten Schrägstrich). Siehe unsere Anleitung zur OAuth-Fehler für mehr.Der API-Aufruf in Schritt 3 gibt 403 unzureichendeBerechtigungen. Dies geschieht, wenn Sie einen Endpunkt aufrufen, der einen in Schritt 1 nicht enthaltenen Geltungsbereich erfordert, oder wenn Sie vergessen haben, nach dem Hinzufügen eines neuen Geltungsbereichs auf "APIs autorisieren" zu klicken.
Zugriffstoken sind nur 3600 Sekunden lang gültig. Wenn Ihre Testsitzung länger dauert, beginnen Aufrufe in Schritt 3 fehlerhafte Rückgaben zu liefern. 401 Ungültige Anmeldeinformationen obwohl Ihr Refresh-Token noch gültig ist.
Einige Google APIs haben versionierte Scope-Anforderungen. Zum Beispiel verwenden die Google Calendar API v3 und ältere Versionen unterschiedliche Basis-URLs. Die Verwendung eines für v1 entwickelten Scopes für einen v3-Endpunkt kann zu unerwarteten Fehlern oder unvollständigen Daten führen.
Sie sehen CORS-bezogene Fehler in den DevTools, wenn Sie die Funktion "Anfrage senden" des Playgrounds in bestimmten Netzwerkumgebungen (Unternehmensproxy, VPNs) verwenden. Dies ist ein browserspezifisches Verhalten des Playgrounds und kein Problem der Google API.
Spielplatz vs. Produktion: Wenn der Google OAuth Playground nicht mehr ausreicht
Der Spielplatz ist ein ausgezeichnetes Testwerkzeug – nicht für den Produktionseinsatz konzipiert. Hier ist ein ehrlicher Vergleich, was sich ändert, wenn Sie vom Testen im Spielplatz zu einer echten OAuth-Integration übergehen, die reale Benutzer bedient.
| Merkmal | OAuth Sandbox | Produktions-App |
|---|---|---|
| Aktualisierungs-Token-Lebensdauer | 24h max (mit den Anmeldeinformationen von Google) Unbegrenzt mit eigenen Anmeldedaten |
Unbegrenzt bis der Nutzer widerruft oder 6 Monate Inaktivität |
| Benutzerbasis | 1 Nutzer (nur Ihr Google-Konto) | N Benutzer – beliebig viele Nutzerkonten können Ihre Anwendung autorisieren |
| OAuth-Verifizierung | Nicht erforderlich - Spielplatzumgehungen Überprüfung | Erforderlich nach 100 Testnutzern, für eingeschränkte Bereiche |
| CASA Tier 2 Sicherheitsüberprüfung | Nicht zutreffend – die Playground-Umgebung ist ein eigenes Tool von Google. | Erforderlich für Apps, die eingeschränkte Gmail- oder Kalenderbereiche anfordern |
| Einwilligungsbildschirm-Branding | Zeigt "Google OAuth 2.0 Playground" als App-Namen an | Zeigt den Namen Ihrer App, ihr Logo und ihre Datenschutzrichtlinie an |
| Anforderungs-/Antwortsichtbarkeit | Volle Sichtbarkeit - Alle HTTP-Header und Nutzdaten anzeigen | Für Endbenutzer nicht sichtbar – nur Ihr Backend sieht die Rohtokens und API-Antworten |
| API-Ratenbegrenzungen | Standard-Google-API-Kontingente (geteilt mit anderen Playground-Nutzern bei Verwendung von Googles Anmeldedaten) | Ihr eigener Projekt-Quota – keine Freigabe für andere Entwickler |
| Verwendungszweck | Testen, Debuggen, Lernen, einmalige Token generieren | Endbenutzer im großen Maßstab mit persistenter, mandantenfähiger Tokenverwaltung bedienen |
Die Faustregel: Nutzen Sie die Playground-Umgebung, bis Ihre Integrationslogik bestätigt ist, und wechseln Sie dann für benutzersichtbare Elemente zu einem Produktions-OAuth-Flow. Der größte Stolperstein in der Produktion ist der Verifizierungsprozess von Google – bei Apps, die sensible oder eingeschränkte Scopes anfordern, kann dies Wochen dauern. Hier kann eine Lösung wie Unipile helfen: Nutzen Sie vorab verifizierte Anmeldeinformationen und überspringen Sie die Überprüfung vollständig, während Sie die Produkt-Markt-Fit-Validierung vornehmen. Sehen Sie sich unseren vollständigen Leitfaden an auf OAuth E-Mail-API-Integration für eine eingehende Untersuchung von Produktionsmustern.
Wochen der Verifizierung.
Verwenden Sie Unipiles Schlüssel und jetzt beginnen.
Sie haben im Playground getestet – nun gehen Sie produktiv, ohne die 6-monatige Google-Verzögerungsprüfung. Verbinden Sie Gmail-Konten in 5 Minuten mit unseren vorab verifizierten Entwickler-Anmeldedaten.
Vom Google OAuth Playground zur Produktion: Überspringen Sie die Verifizierungswartezeit
Der Spielplatz hat bestätigt, dass Ihre Integrationslogik funktioniert. Der nächste Schritt ist die Verbindung echter Benutzerkonten in der Produktion. Aber hier ist das Problem: Der OAuth-Verifizierungsprozess von Google für Apps, die sensible oder eingeschränkte Gmail-Bereiche anfordern, kann dauern 4 bis 12 Wochen, und erfordert eine CASA Tier 2-Sicherheitsüberprüfung für eingeschränkte Bereiche wie Gmail ändern und Gmail senden.
Unipile löst dies mit vorab geprüften Google OAuth-Zugangsdaten. Anstatt Monate auf die Genehmigung Ihrer App durch Google zu warten, verwenden Sie Unipiles CASA Tier 2 zertifizierter Entwicklerschlüssel um Gmail-Konten sofort zu verbinden. Ihre Nutzer autorisieren über die Standard-Zustimmungsoberfläche von Google, Ihre Anwendung liest und sendet E-Mails über die API von Unipile, und Sie können jederzeit zu Ihren eigenen verifizierten Anmeldeinformationen wechseln, wenn Sie bereit sind. Dies ist der gleiche Ansatz, den Teams verfolgen, die auf unseren Plattformen aufbauen Google OAuth-Integration und unsere breitere E-Mail-API-Plattform.
Google OAuth Playground - Häufig gestellte Fragen
Antworten auf die häufigsten Fragen zu Tests, Tokens, Scopes und der Umstellung auf die Produktion vom Playground aus.
Die Google OAuth Playground ist ein kostenloses, browserbasiertes Werkzeug unter developers.google.com/oauthplayground ermöglicht es Entwicklern, OAuth 2.0-Autorisierungsabläufe gegen jede Google API zu testen. Wählen Sie Scopes, autorisieren Sie Ihr Google-Konto, tauschen Sie den Autorisierungscode gegen Tokens und führen Sie Live-API-Aufrufe durch – alles, ohne Backend-Code schreiben zu müssen. Es wird von Google gepflegt und unterstützt jeden veröffentlichten Google API-Scope.
Zugangsberechtigungsscheine ablaufen nach 1 Stunde (3600 Sekunden). Aktualisierungstoken Die Standard-Playground-Anmeldedaten von Google laufen nach 24 Stunden ab – dies ist eine playgroundspezifische Einschränkung. Wenn Sie den Playground so konfigurieren, dass er Ihre eigenen OAuth-Anmeldedaten (Client-ID und Client-Geheimnis aus der Google Cloud Console) verwendet, verhalten sich Refresh-Token genau wie Produktions-Token ohne 24-Stunden-Ablauf. Sie können auch jederzeit in Schritt 2 auf "Zugriffstoken aktualisieren" klicken, um ein neues Zugriffstoken zu erhalten, ohne die Autorisierung erneut durchführen zu müssen.
Nein. Der Spielplatz ist ein Test- und Debugging-Tool. Es ist auf ein Benutzerkonto (Ihr eigenes) beschränkt, Token laufen bei Standardanmeldedaten schnell ab und es werden keine Multi-User-Autorisierungsabläufe unterstützt, die für Produktions-Apps erforderlich sind. Für die Produktion müssen Sie Ihre eigene OAuth-App registrieren, den Autorisierungs-Redirect-Flow in Ihrem Backend implementieren und für sensible Scopes wie Gmail ändern, schließen Sie den Verifizierungsprozess von Google ab. Alternativ nutzen Sie einen Dienst wie Unipiles vorab geprüfte OAuth-Anmeldeinformationen schneller zu versenden.
Erstellen Sie in der Google Cloud Console eine OAuth 2.0-Webanwendungsberechtigung und fügen Sie https://developers.google.com/oauthplayground als autorisierte Weiterleitungs-URI. Kopieren Sie die Client-ID und das Client-Geheimnis. Klicken Sie im Playground auf die Zahnrad-Symbol, aktivieren Sie "Eigene OAuth-Anmeldedaten verwenden" und fügen Sie Ihre Client-ID und Ihr Client-Geheimnis ein. Klicken Sie auf "Schließen" und fahren Sie dann wie gewohnt mit der Auswahl des Geltungsbereichs und der Autorisierung in Schritt 1 fort. Ihre Token haben nun Produktions-äquivalente Lebensdauern.
Die 24-stündige Ablaufzeit ist, weil Sie die Standard-Zugangsdaten der Freifläche (Googles eigener OAuth-Client). Google schränkt diese gemeinsam genutzten Token aus Sicherheitsgründen absichtlich ein. So funktionieren OAuth-Token für Produktionsumgebungen nicht. Die Lösung besteht darin, in den Playground-Einstellungen die Option "Eigene OAuth-Zugangsdaten verwenden" zu aktivieren und die eigene Client-ID sowie das eigene Client-Secret anzugeben. Mit eigenen Zugangsdaten sind Refresh-Token gültig, bis der Nutzer den Zugriff explizit widerruft oder die Anwendung 6 Monate lang inaktiv ist.
Ja, voll und ganz. Im Playground Schritt 1, erweitern "Gmail API v1" und wähle einen beliebigen Gmail-Bereich (gmail.readonly, Gmail ändern, Gmail senden, usw.). Nach der Autorisierung geben Sie in Schritt 3 die Endpunkt-URL ein, z. B. https://gmail.googleapis.com/gmail/v1/users/me/messages und klicken Sie auf "Anfrage senden". Sie sehen die Live-Antwort aus Ihrem Gmail-Posteingang. Eine vollständige Referenz zu Gmail-Bereichen und deren Berechtigungen finden Sie in unserer Gmail API Scopes Leitfaden.
Die Playgrounds unterstützen alle veröffentlichten Google API-Bereiche. Die integrierte Liste umfasst die Gmail API, Google Kalender, Google Drive, Google Tabellen, Google Docs, Google Präsentationen, Google Admin SDK, Google People API, Google Tasks, YouTube und viele andere. Sie können auch benutzerdefinierte Bereiche testen, indem Sie die vollständige Bereichs-URL manuell in das Feld "Eigene Bereiche eingeben" eingeben. Mehrere Bereiche aus verschiedenen APIs können in einer einzigen Autorisierungsanforderung kombiniert werden.
Dieser Fehler tritt nur auf, wenn Sie Ihre eigenen OAuth-Zugangsdaten verwenden. Gehen Sie zu Google Cloud-Konsole, öffnen Sie die Einstellungen Ihres OAuth-Clients und fügen Sie hinzu https://developers.google.com/oauthplayground als autorisierte Weiterleitungs-URI. Speichern Sie, warten Sie einige Minuten, bis die Änderungen übernommen wurden, und versuchen Sie es dann erneut. Wenn der Fehler weiterhin besteht, versuchen Sie auch, die Version mit einem nachgestellten Schrägstrich hinzuzufügen. Weitere OAuth-Fehlerbehebungen finden Sie in unserem Google OAuth Fehlerleitfaden.
Ja, die Google OAuth Playground ist völlig frei. Für die Nutzung der Playground-Oberfläche selbst ist kein Konto erforderlich – navigieren Sie einfach zu developers.google.com/oauthplayground und melden Sie sich mit einem beliebigen Google-Konto an. Die API-Aufrufe, die Sie über das Playground-Tool tätigen, werden auf die Kontingente Ihres Google Cloud-Projekts angerechnet (das für die meisten APIs eine großzügige kostenlose Stufe hat), aber das Playground-Tool selbst ist kostenlos. Für eine vollständig verwaltete Alternative siehe Unipiles produktionsreife Gmail API.
Für SaaS-Anwendungen, die Gmail- oder Google Kalender-Konten für mehrere Endbenutzer verbinden, Unipile bietet eine produktionsbereite OAuth-API mit vorab verifizierten Google-Anmeldeinformationen (CASA Tier 2 zertifiziert, SOC 2, DSGVO-konform). Anstatt des 4-12-wöchigen Google-Verifizierungsprozesses für eingeschränkte Bereiche können Sie Gmail-Konten von Nutzern sofort verbinden. Sie können auch Lesen Sie die Unipile Google OAuth-Dokumentation um die genauen API-Aufrufe zu sehen. Wechseln Sie jederzeit mit keinerlei Ausfallzeiten zu Ihren eigenen verifizierten Anmeldeinformationen.
Haben Sie noch Fragen zu Google OAuth oder dem Playground?
DE 
EN 
FR 
ES 
IT 
BR 
NL 
PL 
TR