Google setzt sich dafür ein, die Rassengerechtigkeit für schwarze Gemeinschaften zu fördern. Siehe wie.

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.

Rufen Sie zunächst die OAuth 2.0-Client-Anmeldeinformationen von Google API Console ab . Anschließend fordert Ihre Clientanwendung ein Zugriffstoken vom Google-Autorisierungsserver an, extrahiert ein Token aus der Antwort und sendet das Token an die Google-API, auf die Sie zugreifen möchten. Für eine interaktive Demonstration der Verwendung von OAuth 2.0 mit Google (einschließlich der Option, Ihre eigenen Client-Anmeldeinformationen zu verwenden), experimentieren Sie mit dem OAuth 2.0 Playground .

Diese Seite bietet einen Überblick über die von Google unterstützten OAuth 2.0-Autorisierungsszenarien und enthält Links zu ausführlicheren Inhalten. Einzelheiten zur Verwendung von OAuth 2.0 für die Authentifizierung finden Sie unter OpenID Connect .

Grundlagen

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

1. Rufen Sie die OAuth 2.0-Anmeldeinformationen von Google API Console ab.

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

2. Rufen Sie ein Zugriffstoken vom Google-Autorisierungsserver ab.

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

Es gibt mehrere Möglichkeiten, diese Anfrage zu stellen, und sie variieren je nach Art der Anwendung, die Sie erstellen. Beispielsweise kann eine JavaScript-Anwendung mithilfe einer Browserweiterleitung an Google ein Zugriffstoken anfordern, während eine Anwendung, die auf einem Gerät ohne Browser installiert ist, Webdienstanfragen verwendet.

Einige Anfragen erfordern einen Authentifizierungsschritt, bei dem sich der Nutzer mit seinem Google-Konto anmeldet. Nach der Anmeldung 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-Autorisierungsserver Ihrer Anwendung ein Zugriffstoken (oder einen Autorisierungscode, mit dem Ihre Anwendung ein Zugriffstoken abrufen kann) und eine Liste der Zugriffsbereiche, die von diesem Token gewährt werden. Wenn der Benutzer die Berechtigung nicht erteilt, gibt der Server einen Fehler zurück.

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

3. Überprüfen Sie die vom Benutzer gewährten Zugriffsbereiche.

Vergleichen Sie die in der Zugriffstokenantwort enthaltenen Bereiche mit den Bereichen, die für den Zugriff auf Funktionen und Funktionen Ihrer Anwendung erforderlich sind, abhängig vom Zugriff auf eine zugehörige 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. Die für den Zugriff erforderlichen Bereiche finden Sie in der Dokumentation zu jeder Google API. Eine API kann mehrere Bereichszeichenfolgenwerte einem einzelnen Zugriffsbereich zuordnen und dieselbe Bereichszeichenfolge für alle in der Anfrage zulässigen Werte zurückgeben. Beispiel: Die Google People API kann einen Bereich von https://www.googleapis.com/auth/contacts wenn eine App einen Nutzer auffordert, einen Bereich von https://www.google.com/m8/feeds/ autorisieren; die Google People API-Methode people.updateContact erfordert einen gewährten Umfang von https://www.googleapis.com/auth/contacts .

4. Senden Sie das Zugriffstoken an eine API.

Nachdem eine Anwendung ein Zugriffstoken erhalten hat, sendet sie das Token in einem HTTP-Autorisierungsanfrageheader an eine Google-API. Es ist möglich, Token als URI-Abfragezeichenfolgenparameter zu senden, aber wir empfehlen dies nicht, da URI-Parameter in Protokolldateien landen können, die nicht vollständig sicher sind. Außerdem ist es eine gute REST-Praxis, unnötige URI-Parameternamen zu vermeiden. Beachten Sie, dass die Unterstützung für Abfragezeichenfolgen am 1. Juni 2021 eingestellt wird.

Zugriffstoken sind nur für die im scope der Tokenanforderung beschriebenen Operationen und Ressourcen gültig. Wenn beispielsweise ein Zugriffstoken für die Google Kalender-API ausgestellt wird, gewährt es keinen Zugriff auf die Google-Kontakte-API. Sie können dieses Zugriffstoken jedoch für ähnliche Vorgänge mehrmals an die Google Kalender-API senden.

5. Aktualisieren Sie bei Bedarf 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 abrufen. Mit einem Aktualisierungstoken kann Ihre Anwendung neue Zugriffstoken abrufen.

Szenarien

Webserveranwendungen

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 an eine Google-URL umleitet. die URL enthält Abfrageparameter, die die Art des angeforderten Zugriffs angeben. Google übernimmt die Benutzerauthentifizierung, die Sitzungsauswahl und die Zustimmung des Benutzers. Das Ergebnis ist ein Autorisierungscode, den die Anwendung gegen ein Zugriffstoken und ein Aktualisierungstoken eintauschen 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 Token-Anfrage an den Google-Autorisierungsserver, empfängt einen Autorisierungscode, tauscht den Code gegen ein Token aus und verwendet das Token, um einen Google-API-Endpunkt aufzurufen.

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 als Anwendungstyp Android, Chrome-App, iOS, Universelle Windows-Plattform (UWP) oder Desktop-App aus.

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

Die Autorisierungssequenz beginnt, wenn Ihre Anwendung einen Browser an eine Google-URL umleitet. die URL enthält Abfrageparameter, die die Art des angeforderten Zugriffs angeben. Google übernimmt die Benutzerauthentifizierung, die Sitzungsauswahl und die Zustimmung des Benutzers. Das Ergebnis ist ein Autorisierungscode, den die Anwendung gegen ein Zugriffstoken und ein Aktualisierungstoken eintauschen 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 Token-Anfrage an den Google-Autorisierungsserver, empfängt einen Autorisierungscode, tauscht den Code gegen ein Token aus und verwendet das Token, um einen Google-API-Endpunkt aufzurufen.

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 an eine Google-URL umleitet. die URL enthält Abfrageparameter, die die Art des angeforderten Zugriffs angeben. Google übernimmt die Benutzerauthentifizierung, die Sitzungsauswahl und die Zustimmung des Benutzers.

Das Ergebnis ist ein Zugriffstoken, das der Client validieren sollte, bevor er es in eine Google API-Anfrage einfügt. Wenn das Token abläuft, wiederholt die Anwendung den Vorgang.

Ihre JS-Anwendung sendet eine Token-Anfrage an den Google-Autorisierungsserver, empfängt ein Token, validiert das Token und verwendet das Token, um einen Google-API-Endpunkt aufzurufen.

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änkter Eingabe wie Spielekonsolen, Videokameras und Druckern ausgeführt werden.

Die Autorisierungssequenz beginnt damit, dass die Anwendung eine Webdienstanfrage an eine Google-URL für einen Autorisierungscode stellt. 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 Eingabemöglichkeiten. Der Benutzer startet einen Browser, navigiert zur angegebenen URL, meldet sich an und gibt den Code ein.

Währenddessen 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 an, das über einen Browser verfügt

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

Dienstkonten

Google APIs wie die Prediction API und Google Cloud Storage können im Namen Ihrer Anwendung agieren, ohne auf Nutzerinformationen zuzugreifen. In diesen Situationen muss Ihre Anwendung der API ihre eigene Identität nachweisen, aber es ist 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 , das zu Ihrer Anwendung gehört und nicht zu einem einzelnen Endbenutzer. Ihre Anwendung ruft Google APIs im Namen des Dienstkontos auf und es ist keine Zustimmung des Nutzers erforderlich. (In Szenarien ohne Dienstkonto ruft Ihre Anwendung Google APIs im Namen von Endnutzern auf, und manchmal ist die Zustimmung des Nutzers erforderlich.)

Die Anmeldeinformationen eines Dienstkontos, die Sie vom Google API Console erhalten, enthalten eine generierte eindeutige E-Mail-Adresse, eine Client-ID und mindestens ein öffentliches/privates Schlüsselpaar. Sie verwenden die Client-ID und einen privaten Schlüssel, um ein signiertes JWT zu erstellen und eine Zugriffstokenanforderung im entsprechenden Format zu erstellen. Ihre Anwendung sendet dann die Token-Anfrage 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-Autorisierungsserver anzufordern, und verwendet dann das Token, um einen Google-API-Endpunkt aufzurufen. Es ist kein Endbenutzer beteiligt.

Weitere Informationen finden Sie in der Service-Account-Dokumentation .

Tokengröße

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

  • Autorisierungscodes: 256 Byte
  • Zugriffstoken: 2048 Byte
  • Aktualisierungstoken: 512 Byte

Zugriffstokens, die von der Security Token Service API von Google Cloud zurückgegeben werden, sind ähnlich strukturiert wie die OAuth 2.0-Zugriffstokens von Google API, haben jedoch andere Beschränkungen für die Tokengröße. Weitere Informationen finden Sie in der API-Dokumentation .

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

Ablauf des Tokens aktualisieren

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

  • Der Nutzer hat den Zugriff auf Ihre App widerrufen .
  • Das Aktualisierungstoken wurde sechs Monate lang nicht verwendet.
  • Der Nutzer hat die Passwörter geändert und das Aktualisierungstoken enthält Gmail-Bereiche.
  • Das Benutzerkonto hat eine maximale Anzahl von gewährten (Live-)Aktualisierungstoken überschritten.
  • Der Nutzer gehört einer Google Cloud Platform-Organisation an, für die Richtlinien zur Sitzungssteuerung gelten.

Ein Google Cloud Platform-Projekt mit einem für einen externen Nutzertyp konfigurierten OAuth-Zustimmungsbildschirm und dem Veröffentlichungsstatus "Testing" erhält ein Aktualisierungstoken, das in 7 Tagen abläuft.

Derzeit gilt 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 automatisch das älteste Aktualisierungstoken ohne Warnung ungültig. Dieses Limit gilt nicht für Dienstkonten .

Es gibt auch ein höheres Limit für die Gesamtzahl der Aktualisierungstoken, die ein Benutzerkonto oder Dienstkonto für alle Clients haben kann. Die meisten normalen Benutzer überschreiten dieses Limit nicht, aber ein Entwicklerkonto, das zum Testen einer Implementierung verwendet wird, könnte dies tun.

Wenn Sie mehrere Programme, Computer oder Geräte autorisieren müssen, können Sie die Anzahl der Clients, die Sie pro Google-Konto autorisieren, auf 15 oder 20 begrenzen. Wenn Sie ein Google Workspace-Administrator sind , können Sie zusätzliche Nutzer mit Administratorrechten erstellen und verwenden Sie sie, um einige der Clients zu autorisieren.

Umgang mit Richtlinien zur Sitzungssteuerung für Organisationen der Google Cloud Platform (GCP)

Administratoren von GCP-Organisationen benötigen möglicherweise eine häufige erneute Authentifizierung der Nutzer, während sie auf GCP-Ressourcen zugreifen, indem sie die Sitzungssteuerungsfunktion von Google Cloud verwenden . Diese Richtlinie wirkt sich auf den Zugriff auf die Google Cloud Console, das Google Cloud SDK (auch bekannt als gcloud CLI) und alle OAuth-Anwendungen von Drittanbietern aus, die den Umfang der Cloud Platform erfordern. Wenn ein Benutzer über eine Richtlinie zur Sitzungssteuerung verfügt, werden Ihre API-Aufrufe nach Ablauf der Sitzungsdauer ähnlich wie beim Widerrufen des Aktualisierungstokens fehlschlagen. Da die Sitzungsdauer sehr begrenzt sein kann (zwischen 1 Stunde und 24 Stunden), muss dieses Szenario durch einen Neustart einer Authentifizierungssitzung ordnungsgemäß gehandhabt werden.

Ebenso dürfen Sie keine Benutzeranmeldeinformationen für die Server-zu-Server-Bereitstellung verwenden oder deren Verwendung fördern. Wenn Benutzeranmeldeinformationen auf einem Server für lang laufende Jobs oder Vorgänge bereitgestellt werden und ein Kunde Sitzungssteuerungsrichtlinien auf solche 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 auf Administratoren ausgerichteten Hilfeartikel.

Clientbibliotheken

Die folgenden Clientbibliotheken lassen sich in gängige Frameworks integrieren, wodurch die Implementierung von OAuth 2.0 einfacher wird. Im Laufe der Zeit werden den Bibliotheken weitere Funktionen hinzugefügt.