Google setzt sich für die Förderung der Rassengerechtigkeit für schwarze Gemeinschaften ein. Siehe wie.

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

Google APIs verwenden , um 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.

OAuth 2.0 - Client - Anmeldeinformationen aus dem beginnen, erhalten Google API Console . 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 von OAuth 2.0 mit Google verwenden (einschließlich der Möglichkeit , Ihre eigenen Client - Anmeldeinformationen zu verwenden), experimentiert mit dem OAuth 2.0 Spielplatz .

Diese Seite bietet einen Überblick über die von Google unterstützten OAuth 2.0-Autorisierungsszenarien und enthält Links zu ausführlicheren Inhalten. Einzelheiten zu OAuth 2.0 für Authentifizierung finden 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:

Erhalten Sie OAuth 2.0 - Anmeldeinformationen 1. vom Google API Console.

Besuchen Sie das Google API Console OAuth 2.0 - Anmeldeinformationen zu erhalten , wie zum Beispiel eines Client - ID und Client - Geheimnis , dass sowohl Google und Ihre 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. Eine variable Parameter namens scope steuert die Menge von Ressourcen und Operationen , die ein Zugriffstoken zulässt. Während die Zugriffstoken Anforderung sendet Ihre Anwendung eines oder mehr Werte im scope Parameter.

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 ein Zugriffstoken über eine Browserweiterleitung an Google 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 von Ihrer Anwendung angefordert werden. Dieser Prozess wird die Zustimmung der Nutzer aufgerufen.

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 die Schaltfläche "Zum Kalender hinzufügen" drückt. siehe Incremental Genehmigung .

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 API Menschen einen Umfang von zurückgeben kann https://www.googleapis.com/auth/contacts , wenn eine Anwendung ein Benutzer einen Umfang von autorisieren angeforderten https://www.google.com/m8/feeds/ ; die Google Menschen API - Methode people.updateContact erfordert ein erteiltes Umfang von https://www.googleapis.com/auth/contacts .

4. Senden Sie das Zugriffstoken an eine API.

Nachdem eine Anwendung einen Zugriffstoken erhält, sendet er das Token an ein Google - API in einer Request - Header HTTP - Autorisierung . 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 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, 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 Verwendung von OAuth 2.0 für Web - Server - Anwendungen .

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 durch das Erstellen Google API Console an , dass dies eine installierte Anwendung ist, dann wählen Sie Android, Chrome App, iOS, Universal Windows - Plattform (UWP) oder Desktop - App als Anwendungstyp.

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 Verwendung 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 in eine Google API-Anfrage aufgenommen wird. 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 Verwendung 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 Verwendung 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, 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 müssen Sie ein Dienstkonto, das ist ein Konto , das statt auf einen einzelnen Endbenutzer Ihre Anwendung gehört. 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.)

Ein Dienstkontos Anmeldeinformationen, die Sie aus dem erhalten Google API Console, umfassen eine generierte E - Mail - Adresse , die einzigartig ist, ein 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 Einzelheiten 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

Zugriffstoken von Google Cloud zurück Security Token Service API sind so strukturiert , ähnlich wie Google API OAuth 2.0 Zugriffstoken haben aber unterschiedliche Token Größenbeschränkungen. Weitere Einzelheiten 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 funktioniert möglicherweise aus einem der folgenden Gründe nicht mehr:

  • Der Benutzer hat die App den Zugriff 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. Diese Grenze 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, Maschinen oder Geräte genehmigen müssen, ist eine Problemumgehung die Anzahl der Clients zu begrenzen , dass Sie pro Google - Konto auf 15 oder 20 autorisieren Wenn Sie ein sind Google Workspace Administrator , können Sie zusätzliche Benutzer 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 könnte häufige erneute Authentifizierung von Benutzern benötigt , während sie GCP - Ressourcen zugreifen, die mit Google Cloud Session - Control - Funktion . Diese Auswirkungen auf die Politik den Zugriff auf Google Cloud Console, das Google Cloud SDK (auch als gcloud CLI bekannt) und Dritte OAuth - Anwendung , die die Cloud - Plattform Rahmen erfordert. Wenn ein Benutzer eine Session - Control - Politik im Ort hat dann auf den Ablauf der Sitzungsdauer, wird die Fehler Ihre API - Aufrufe aus ähnlich dem , was passieren würde , wenn der Aktualisierungs - Token widerrufen wurde - der Anruf wird mit einer Fehlertyp nicht invalid_token ; der Unterfehlertyp kann verwendet werden, um zwischen einem Widerrufstoken und einem Fehler aufgrund einer Sitzungssteuerungsrichtlinie zu unterscheiden. 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 darüber , wie Sie Ihre Kunden implementieren diese Funktion helfen , finden Sie in diesem Admin-fokussierten 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.