Google setzt sich dafür ein, die Rassengerechtigkeit für schwarze Gemeinschaften zu fördern. Siehe wie.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Verwenden von OAuth 2.0 für den Zugriff auf Google APIs

Google APIs verwenden das OAuth 2.0-Protokoll zur Authentifizierung und Autorisierung. Google unterstützt gängige OAuth 2.0-Szenarien, z. B. für Webserver-, clientseitige, installierte und Geräteanwendungen mit eingeschränkter Eingabe.

Beziehen Sie zunächst OAuth 2.0-Client-Anmeldeinformationen von Google API Console . Anschließend fordert Ihre Clientanwendung ein Zugriffstoken vom Google Authorization Server an, extrahiert ein Token aus der Antwort und sendet das Token an die Google-API, auf die Sie zugreifen möchten. Experimentieren Sie mit dem OAuth 2.0-Spielplatz, um eine interaktive Demonstration der Verwendung von OAuth 2.0 mit Google zu erhalten (einschließlich der Option, Ihre eigenen Client-Anmeldeinformationen zu verwenden).

Diese Seite bietet einen Überblick über die von Google unterstützten OAuth 2.0-Autorisierungsszenarien sowie Links zu detaillierteren Inhalten. Ausführliche Informationen zur Verwendung von OAuth 2.0 zur Authentifizierung finden Sie unter OpenID Connect .

Grundlagen

Alle Anwendungen folgen einem grundlegenden Muster beim Zugriff auf eine Google-API mit OAuth 2.0. Auf hohem Niveau folgen Sie fünf Schritten:

1. Beziehen Sie OAuth 2.0-Anmeldeinformationen von Google API Console.

Besuchen Sie die Google API Console , um OAuth 2.0-Anmeldeinformationen wie eine Client-ID und ein Client-Geheimnis zu erhalten, die sowohl Google als auch Ihrer Anwendung bekannt sind. Der Satz von Werten hängt davon ab, welche Art von Anwendung Sie erstellen. Beispielsweise benötigt eine JavaScript-Anwendung kein Geheimnis, eine Webserver-Anwendung jedoch.

2. Beziehen Sie ein Zugriffstoken vom Google Authorization Server.

Bevor Ihre Anwendung über eine Google-API auf private Daten zugreifen kann, muss sie ein Zugriffstoken erhalten, das den Zugriff auf diese API gewährt. Ein einzelnes Zugriffstoken kann mehreren APIs unterschiedlich viel Zugriff gewähren. Ein variabler Parameter namens scope steuert die Ressourcen und Operationen, die ein Zugriffstoken zulässt. Während der Zugriffstokenanforderung sendet Ihre Anwendung einen oder mehrere Werte im scope .

Es gibt verschiedene Möglichkeiten, diese Anforderung zu stellen. Diese hängen von der Art der Anwendung ab, die Sie erstellen. Beispielsweise kann eine JavaScript-Anwendung ein Zugriffstoken mithilfe einer Browserumleitung an Google anfordern, während eine Anwendung, die auf einem Gerät ohne Browser installiert ist, Webdienstanforderungen verwendet.

Einige Anfragen erfordern einen Authentifizierungsschritt, bei dem sich der Nutzer mit seinem Google-Konto anmeldet. Nach dem Anmelden wird der Benutzer gefragt, ob er bereit ist, eine oder mehrere Berechtigungen zu erteilen, die Ihre Anwendung anfordert. Dieser Vorgang wird als Benutzereinwilligung bezeichnet .

Wenn der Nutzer mindestens eine Berechtigung erteilt, sendet der Google Authorization Server Ihrer Anwendung ein Zugriffstoken (oder einen Autorisierungscode, mit dem Ihre Anwendung ein Zugriffstoken erhalten kann) und eine Liste der von diesem Token gewährten Zugriffsbereiche. Wenn der Benutzer die Berechtigung nicht erteilt, gibt der Server einen Fehler zurück.

Es ist im Allgemeinen eine bewährte Methode, Bereiche schrittweise anzufordern, wenn ein Zugriff erforderlich ist, und nicht im Voraus. Beispielsweise sollte eine App, die das Speichern eines Ereignisses in einem Kalender unterstützen möchte, den Google Kalenderzugriff erst anfordern, wenn der Benutzer auf die Schaltfläche "Zum Kalender hinzufügen" klickt. Siehe Inkrementelle Autorisierung .

3. Untersuchen Sie die vom Benutzer gewährten Zugriffsbereiche.

Vergleichen Sie die Bereiche, die in der Antwort auf das Zugriffstoken enthalten sind, mit den Bereichen, die für den Zugriff auf Features und Funktionen Ihrer Anwendung erforderlich sind, abhängig vom Zugriff auf eine verwandte Google-API. Deaktivieren Sie alle Funktionen Ihrer App, die ohne Zugriff auf die zugehörige API nicht funktionieren können.

Der in Ihrer Anfrage enthaltene Bereich stimmt möglicherweise nicht mit dem in Ihrer Antwort enthaltenen Bereich überein, selbst wenn der Benutzer alle angeforderten Bereiche gewährt hat. In der Dokumentation zu jeder Google-API finden Sie Informationen zu den für den Zugriff erforderlichen Bereichen. Eine API kann mehrere Bereichszeichenfolgenwerte einem einzelnen Zugriffsbereich zuordnen und für alle in der Anforderung zulässigen Werte dieselbe Bereichszeichenfolge zurückgeben. Beispiel: Die Google People-API gibt möglicherweise einen Bereich von https://www.googleapis.com/auth/contacts wenn eine App einen Benutzer auffordert, einen Bereich von https://www.google.com/m8/feeds/ autorisieren. Für die Google People-API-Methode people.updateContact ein people.updateContact Bereich von https://www.googleapis.com/auth/contacts erforderlich.

4. Senden Sie das Zugriffstoken an eine API.

Nachdem eine Anwendung ein Zugriffstoken erhalten hat, sendet sie das Token in einem HTTP-Autorisierungsanforderungsheader an eine Google-API. Es ist möglich, Token als URI-Abfragezeichenfolgenparameter zu senden, wir empfehlen dies jedoch nicht, da URI-Parameter in Protokolldateien enden können, die nicht vollständig sicher sind. Es ist auch eine gute REST-Praxis, das Erstellen unnötiger URI-Parameternamen zu vermeiden. Beachten Sie, dass die Unterstützung für Abfragezeichenfolgen am 1. Juni 2021 veraltet ist.

Zugriffstoken gilt nur für den Satz von Operationen und Ressourcen in dem beschriebenen scope der Token - Anfrage. Wenn beispielsweise ein Zugriffstoken für die Google Kalender-API ausgestellt wird, wird kein Zugriff auf die Google Kontakte-API gewährt. Sie können dieses Zugriffstoken jedoch für ähnliche Vorgänge mehrmals an die Google Kalender-API senden.

5. Aktualisieren Sie gegebenenfalls das Zugriffstoken.

Zugriffstoken haben eine begrenzte Lebensdauer. Wenn Ihre Anwendung über die Lebensdauer eines einzelnen Zugriffstokens hinaus Zugriff auf eine Google-API benötigt, kann sie ein Aktualisierungstoken erhalten. Mit einem Aktualisierungstoken kann Ihre Anwendung neue Zugriffstoken erhalten.

Szenarien

Webserver-Anwendungen

Der Google OAuth 2.0-Endpunkt unterstützt Webserveranwendungen, die Sprachen und Frameworks wie PHP, Java, Python, Ruby und ASP.NET verwenden.

Die Autorisierungssequenz beginnt, wenn Ihre Anwendung einen Browser auf eine Google-URL umleitet. Die URL enthält Abfrageparameter, die die Art des angeforderten Zugriffs angeben. Google kümmert sich um die Benutzerauthentifizierung, die Sitzungsauswahl und die Zustimmung der Nutzer. Das Ergebnis ist ein Autorisierungscode, den die Anwendung gegen ein Zugriffstoken und ein Aktualisierungstoken austauschen kann.

Die Anwendung sollte das Aktualisierungstoken für die zukünftige Verwendung speichern und das Zugriffstoken verwenden, um auf eine Google-API zuzugreifen. Sobald das Zugriffstoken abläuft, verwendet die Anwendung das Aktualisierungstoken, um ein neues zu erhalten.

Ihre Anwendung sendet eine Tokenanforderung an den Google Authorization Server, empfängt einen Autorisierungscode, tauscht den Code gegen ein Token aus und ruft mit dem Token einen Google API-Endpunkt auf.

Weitere Informationen finden Sie unter Verwenden von OAuth 2.0 für Webserveranwendungen .

Installierte Anwendungen

Der Google OAuth 2.0-Endpunkt unterstützt Anwendungen, die auf Geräten wie Computern, Mobilgeräten und Tablets installiert sind. Wenn Sie eine Client-ID über Google API Console erstellen , geben Sie an, dass es sich um eine installierte Anwendung handelt, und wählen Sie dann Android, Chrome, App, iOS, UWP (Universal Windows Platform) oder Desktop-App als Anwendungstyp aus.

Der Prozess führt zu einer Client-ID und in einigen Fällen zu einem Client-Geheimnis, das Sie in den Quellcode Ihrer Anwendung einbetten. (In diesem Zusammenhang wird das Kundengeheimnis offensichtlich nicht als Geheimnis behandelt.)

Die Autorisierungssequenz beginnt, wenn Ihre Anwendung einen Browser auf eine Google-URL umleitet. Die URL enthält Abfrageparameter, die die Art des angeforderten Zugriffs angeben. Google kümmert sich um die Benutzerauthentifizierung, die Sitzungsauswahl und die Zustimmung der Nutzer. Das Ergebnis ist ein Autorisierungscode, den die Anwendung gegen ein Zugriffstoken und ein Aktualisierungstoken austauschen kann.

Die Anwendung sollte das Aktualisierungstoken für die zukünftige Verwendung speichern und das Zugriffstoken verwenden, um auf eine Google-API zuzugreifen. Sobald das Zugriffstoken abläuft, verwendet die Anwendung das Aktualisierungstoken, um ein neues zu erhalten.

Ihre Anwendung sendet eine Tokenanforderung an den Google Authorization Server, empfängt einen Autorisierungscode, tauscht den Code gegen ein Token aus und ruft mit dem Token einen Google API-Endpunkt auf.

Weitere Informationen finden Sie unter Verwenden von OAuth 2.0 für installierte Anwendungen .

Clientseitige (JavaScript) Anwendungen

Der Google OAuth 2.0-Endpunkt unterstützt JavaScript-Anwendungen, die in einem Browser ausgeführt werden.

Die Autorisierungssequenz beginnt, wenn Ihre Anwendung einen Browser auf eine Google-URL umleitet. Die URL enthält Abfrageparameter, die die Art des angeforderten Zugriffs angeben. Google kümmert sich um die Nutzerauthentifizierung, Sitzungsauswahl und Nutzergenehmigung.

Das Ergebnis ist ein Zugriffstoken, das der Client überprüfen sollte, bevor er in eine Google API-Anforderung aufgenommen wird. Wenn das Token abläuft, wiederholt die Anwendung den Vorgang.

Ihre JS-Anwendung sendet eine Tokenanforderung an den Google Authorization Server, empfängt ein Token, überprüft das Token und verwendet das Token zum Aufrufen eines Google API-Endpunkts.

Weitere Informationen finden Sie unter Verwenden von OAuth 2.0 für clientseitige Anwendungen .

Anwendungen auf Geräten mit begrenzter Eingabe

Der Google OAuth 2.0-Endpunkt unterstützt Anwendungen, die auf Geräten mit eingeschränkten Eingaben wie Spielekonsolen, Videokameras und Druckern ausgeführt werden.

Die Autorisierungssequenz beginnt damit, dass die Anwendung eine Webdienstanforderung an eine Google-URL für einen Autorisierungscode sendet. Die Antwort enthält mehrere Parameter, einschließlich einer URL und eines Codes, den die Anwendung dem Benutzer anzeigt.

Der Benutzer erhält die URL und den Code vom Gerät und wechselt dann zu einem separaten Gerät oder Computer mit umfangreicheren Eingabefunktionen. Der Benutzer startet einen Browser, navigiert zur angegebenen URL, meldet sich an und gibt den Code ein.

In der Zwischenzeit fragt die Anwendung in einem bestimmten Intervall eine Google-URL ab. Nachdem der Nutzer den Zugriff genehmigt hat, enthält die Antwort vom Google-Server ein Zugriffstoken und ein Aktualisierungstoken. Die Anwendung sollte das Aktualisierungstoken für die zukünftige Verwendung speichern und das Zugriffstoken verwenden, um auf eine Google-API zuzugreifen. Sobald das Zugriffstoken abläuft, verwendet die Anwendung das Aktualisierungstoken, um ein neues zu erhalten.

Der Benutzer meldet sich auf einem separaten Gerät mit einem Browser an

Weitere Informationen finden Sie unter Verwenden von OAuth 2.0 für Geräte .

Dienstkonten

Google-APIs wie die Vorhersage-API und Google Cloud Storage können im Namen Ihrer Anwendung handeln, ohne auf Benutzerinformationen zuzugreifen. In diesen Situationen muss Ihre Anwendung der API ihre eigene Identität nachweisen, es ist jedoch keine Zustimmung des Benutzers erforderlich. Ebenso kann Ihre Anwendung in Unternehmensszenarien delegierten Zugriff auf einige Ressourcen anfordern.

Für diese Art von Server-zu-Server-Interaktionen benötigen Sie ein Dienstkonto , bei dem es sich um ein Konto handelt, das zu Ihrer Anwendung und nicht zu einem einzelnen Endbenutzer gehört. Ihre Anwendung ruft Google APIs im Namen des Dienstkontos auf. Eine Zustimmung des Benutzers ist nicht erforderlich. (In Szenarien ohne Dienstkonto ruft Ihre Anwendung Google-APIs im Namen von Endbenutzern auf, und manchmal ist eine Zustimmung der Benutzer erforderlich.)

Die Anmeldeinformationen eines Dienstkontos, die Sie vom Google API Console erhalten, umfassen eine generierte E-Mail-Adresse, die eindeutig ist, eine Client-ID und mindestens ein öffentliches / privates Schlüsselpaar. Sie verwenden die Client-ID und einen privaten Schlüssel, um eine signierte JWT zu erstellen und eine Zugriffstokenanforderung im entsprechenden Format zu erstellen. Ihre Anwendung sendet dann die Tokenanforderung an den Google OAuth 2.0-Autorisierungsserver, der ein Zugriffstoken zurückgibt. Die Anwendung verwendet das Token, um auf eine Google-API zuzugreifen. Wenn das Token abläuft, wiederholt die Anwendung den Vorgang.

Ihre Serveranwendung verwendet ein JWT, um ein Token vom Google Authorization Server anzufordern, und verwendet das Token dann, um einen Google API-Endpunkt aufzurufen. Es ist kein Endbenutzer beteiligt.

Einzelheiten finden Sie in der Dokumentation zum Dienstkonto .

Token-Größe

Die Größe der Token kann bis zu den folgenden Grenzen variieren:

  • Autorisierungscodes: 256 Bytes
  • Zugriffstoken: 2048 Bytes
  • Token aktualisieren: 512 Bytes

Zugriffstoken, die von der Security Token Service API von Google Cloud zurückgegeben werden, sind ähnlich wie OAuth 2.0-Zugriffstoken von Google API strukturiert, haben jedoch unterschiedliche Grenzwerte für die Tokengröße. Einzelheiten finden Sie in der API-Dokumentation .

Google behält sich das Recht vor, die Tokengröße innerhalb dieser Grenzen zu ändern. Ihre Anwendung muss variable Tokengrößen entsprechend unterstützen.

Token-Ablauf aktualisieren

Sie müssen Ihren Code schreiben, um die Möglichkeit vorwegzunehmen, dass ein gewährtes Aktualisierungstoken möglicherweise nicht mehr funktioniert. Ein Aktualisierungstoken funktioniert möglicherweise aus einem der folgenden Gründe nicht mehr:

  • Der Benutzer hat den Zugriff Ihrer App widerrufen .
  • Das Aktualisierungstoken wurde seit sechs Monaten nicht mehr verwendet.
  • Der Benutzer hat die Kennwörter geändert und das Aktualisierungstoken enthält Google Mail-Bereiche.
  • Das Benutzerkonto hat eine maximale Anzahl von gewährten (Live-) Aktualisierungstoken überschritten.
  • Der Nutzer gehört zu einer Google Cloud Platform-Organisation, für die Richtlinien zur Sitzungssteuerung gelten.

Ein Google Cloud Platform-Projekt mit einem OAuth-Zustimmungsbildschirm, der für einen externen Benutzertyp konfiguriert ist, und dem Veröffentlichungsstatus "Testen" erhält ein Aktualisierungstoken, das innerhalb von 7 Tagen abläuft.

Derzeit gibt es ein Limit von 50 Aktualisierungstoken pro Google-Konto und OAuth 2.0-Client-ID. Wenn das Limit erreicht ist, macht das Erstellen eines neuen Aktualisierungstokens das älteste Aktualisierungstoken automatisch ohne Vorwarnung ungültig. Diese Begrenzung gilt nicht für Dienstkonten .

Es gibt auch eine größere Begrenzung für die Gesamtzahl der Aktualisierungstoken, die ein Benutzerkonto oder Dienstkonto auf allen Clients haben kann. Die meisten normalen Benutzer werden dieses Limit nicht überschreiten, aber ein Entwicklerkonto, das zum Testen einer Implementierung verwendet wird, kann dies tun.

Wenn Sie mehrere Programme, Computer oder Geräte autorisieren müssen, besteht eine Problemumgehung darin, die Anzahl der Clients, die Sie pro Google-Konto autorisieren, auf 15 oder 20 zu beschränken. Wenn Sie ein Google Workspace-Administrator sind , können Sie zusätzliche Benutzer mit Administratorrechten und erstellen Verwenden Sie sie, um einige der Clients zu autorisieren.

Umgang mit Sitzungssteuerungsrichtlinien für Google Cloud Platform (GCP) -Organisationen

Administratoren von GCP-Organisationen müssen Benutzer möglicherweise häufig erneut authentifizieren, während sie mithilfe der Google Cloud-Sitzungssteuerungsfunktion auf GCP-Ressourcen zugreifen . Diese Richtlinie wirkt sich auf den Zugriff auf Google Cloud Console, das Google Cloud SDK (auch als gcloud CLI bezeichnet) und alle OAuth-Anwendungen von Drittanbietern aus, für die der Cloud Platform-Bereich erforderlich ist. Wenn ein Benutzer über eine Sitzungssteuerungsrichtlinie verfügt, werden Ihre API-Aufrufe nach Ablauf der Sitzungsdauer ähnlich wie beim Widerruf des Aktualisierungstokens fehlerhaft ausgeführt. Da die Sitzungsdauer sehr begrenzt sein kann (zwischen 1 Stunde und 24 Stunden), muss dieses Szenario durch Neustart einer Authentifizierungssitzung ordnungsgemäß behandelt werden.

Ebenso dürfen Sie Benutzeranmeldeinformationen für die Server-zu-Server-Bereitstellung nicht verwenden oder deren Verwendung fördern. Wenn Benutzeranmeldeinformationen für lange laufende Jobs oder Vorgänge auf einem Server bereitgestellt werden und ein Kunde Sitzungssteuerungsrichtlinien auf diese Benutzer anwendet, schlägt die Serveranwendung fehl, da der Benutzer nach Ablauf der Sitzungsdauer nicht erneut authentifiziert werden kann.

Weitere Informationen dazu, wie Sie Ihren Kunden bei der Bereitstellung dieser Funktion helfen können, finden Sie in diesem adminorientierten Hilfeartikel.

Client-Bibliotheken

Die folgenden Client-Bibliotheken lassen sich in gängige Frameworks integrieren, wodurch die Implementierung von OAuth 2.0 vereinfacht wird. Mit der Zeit werden den Bibliotheken weitere Funktionen hinzugefügt.