Zugriffstoken google api

Hinweis: Die Verwendung der Google-Implementierung von OAuth 2.0 unterliegt den OAuth 2.0-Richtlinien.

Google APIs verwenden das OAuth 2.0-Protokoll für die Authentifizierung und Autorisierung. Google unterstützt gängige OAuth 2.0-Szenarien, z. B. für Webserver-, clientseitige, installierte und gerätegestützte Anwendungen mit eingeschränkter Eingabe.

Rufen Sie zunächst die Anmeldedaten für den OAuth 2.0-Client über die Google API Console ab. 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. Eine interaktive Demonstration der Verwendung von OAuth 2.0 mit Google (einschließlich der Option, Ihre eigenen Client-Anmeldeinformationen zu verwenden) finden Sie mit dem OAuth 2.0 Playground.

Diese Seite gibt einen Überblick über die OAuth 2.0-Autorisierungsszenarien, die Google unterstützt, und Bietet Links zu detaillierteren Inhalten. Weitere Informationen zur Verwendung von OAuth 2.0 für die Authentifizierung finden Sie unter OpenID Connect.

Hinweis: Angesichts der Auswirkungen auf die Sicherheit einer korrekten Implementierung empfehlen wir Ihnen dringend, OAuth 2.0-Bibliotheken zu verwenden, wenn Sie mit den OAuth 2.0-Endpunkten von Google interagieren. Es ist eine bewährte Methode, gut debuggten Code zu verwenden, der von anderen bereitgestellt wird, und es wird Ihnen helfen, sich und Ihre Benutzer zu schützen. Weitere Informationen finden Sie unter Clientbibliotheken.

Grundlegende Schritte

Alle Anwendungen folgen einem grundlegenden Muster beim Zugriff auf eine Google API mit OAuth 2.0. Auf einer hohen Ebene befolgst du fünf Schritte:

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

Rufen Sie die Google API Console auf, um OAuth 2.0-Anmeldeinformationen wie eine Client-ID und einen geheimen Clientschlüssel abzurufen, die sowohl Google als auch Ihrer Anwendung bekannt sind. Der Satz von Werten variiert je nach Art der Anwendung Sie bauen.

Sie müssen einen OAuth-Client erstellen, der für die Plattform geeignet ist, auf der Ihre App ausgeführt wird, z. B

.: 2. Rufen Sie ein Zugriffstoken vom Google Authorization Server ab.

Bevor Ihre Anwendung über eine Google API auf private Daten zugreifen kann, muss sie ein Zugriffstoken abrufen, das Zugriff auf diese API gewährt. Ein einzelnes Zugriffstoken kann unterschiedlichen Zugriffsgrad auf mehrere APIs gewähren. Ein variabler Parameter namens steuert die Menge von Ressourcen und Vorgängen, die ein Zugriffstoken zulässt. Während der Zugriffstokenanforderung sendet die Anwendung einen oder mehrere Werte im Parameter.

Es gibt mehrere Möglichkeiten, diese Anforderung zu stellen, und sie variieren je nach Art der Anwendung, die Sie erstellen.

Für einige Anfragen ist ein Authentifizierungsschritt erforderlich, bei dem sich der Nutzer mit seinem Google-Konto anmeldet. Nach dem Einloggen wird der Benutzer gefragt, ob er bereit ist, eine oder mehrere Berechtigungen, die Ihre Anwendung anfordert. Dieser Vorgang wird als bezeichnet.

Wenn der Nutzer mindestens eine Berechtigung erteilt, sendet der Google-Autorisierungsserver Ihrer Anwendung ein Zugriffstoken (oder einen Autorisierungscode, mit dem die Anwendung ein Zugriffstoken abrufen 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 inkrementell anzufordern, und zwar zu dem Zeitpunkt, zu dem der Zugriff erforderlich ist, und nicht im Voraus. Eine App, die das Speichern eines Termins in einem Kalender unterstützen möchte, sollte beispielsweise erst dann Zugriff auf Google Kalender anfordern, wenn der Nutzer auf die Schaltfläche "Zum Kalender hinzufügen" klickt. Siehe Inkrementelle Autorisierung.

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

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

Der in Ihrer Anforderung 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 der einzelnen Google APIs finden Sie die für den Zugriff erforderlichen Bereiche. Eine API kann mehrere Bereichszeichenfolgenwerte einem einzelnen Zugriffsbereich zuordnen und dieselbe Bereichszeichenfolge für alle in der Anforderung zulässigen Werte zurückgeben. Beispiel: Die Google People API gibt möglicherweise einen Bereich von zurück, wenn eine App einen Nutzer aufgefordert hat, einen Bereich von zu autorisieren. Für die Google People API-Methode ist der zulässige Gültigkeitsbereich von .

4. Senden Sie das Zugriffstoken an eine API.

Nachdem eine Anwendung ein Zugriffstoken abgerufen hat, sendet sie das Token in einem HTTP-Autorisierungsanforderungsheader an eine Google API. Es ist möglich, Token als URI-Abfragezeichenfolgenparameter zu senden, aber wir tun dies nicht Ich empfehle es, da URI-Parameter in Protokolldateien landen können, die nicht vollständig sicher sind. Außerdem empfiehlt es sich, das Erstellen unnötiger URI-Parameternamen zu vermeiden.

Zugriffstoken sind nur für die Vorgänge und Ressourcen gültig, die in der Tokenanforderung beschrieben werden. Wenn beispielsweise ein Zugriffstoken für die Google Kalender API ausgestellt wird, gewährt es keinen Zugriff auf die Google Contacts API. Sie können dieses Zugriffstoken jedoch mehrmals an die Google Kalender API senden, um ähnliche Vorgänge durchzuführen.

5. Aufbereitung 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. Ein Aktualisierungstoken ermöglicht es Ihrer Anwendung, neue Zugriffstoken abzurufen.

Hinweis: Speichern Sie Aktualisierungstoken in einem sicheren Langzeitspeicher und verwenden Sie sie so lange wie möglich. Sie behalten ihre Gültigkeit. Grenzwerte gelten für die Anzahl der Aktualisierungstoken, die pro Client-Benutzer-Kombination und pro Benutzer über alle Clients hinweg ausgestellt werden, und diese Grenzwerte sind unterschiedlich. Wenn Ihre Anwendung genügend Aktualisierungstoken anfordert, um einen der Grenzwerte zu überschreiten, funktionieren ältere Aktualisierungstoken nicht mehr.

Szenarien

Webserveranwendungen

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

Die Autorisierungssequenz beginnt, wenn Ihre Anwendung einen Browser zu einer Google-URL weiterleitet. Die URL enthält Abfrageparameter, die die Art des angeforderten Zugriffs angeben. Google kümmert sich um die Nutzerauthentifizierung, die Sitzungsauswahl und die Einwilligung des Nutzers. Das Ergebnis ist ein Autorisierungscode, den die Anwendung gegen ein Zugriffstoken und ein Aktualisierungstoken austauschen kann.

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

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 die Google API-Konsole erstellen, geben Sie an, dass es sich um eine installierte Anwendung handelt, und wählen Sie dann Android, Chrome-App, iOS, Universelle Windows-Plattform (UWP) oder Desktop-App als Anwendungstyp aus.

Der Prozess führt zu einer Client-ID und in einigen Fällen zu einem geheimen Clientschlüssel, den Sie in den Quellcode Ihrer Anwendung einbetten. (In diesem Zusammenhang wird der geheime Clientschlüssel offensichtlich nicht als geheimer Schlüssel behandelt.)

Die Autorisierungssequenz beginnt, wenn Ihr Die Anwendung leitet einen Browser auf eine Google-URL weiter; Die URL enthält Abfrageparameter, die die Art des angeforderten Zugriffs angeben. Google kümmert sich um die Nutzerauthentifizierung, die Sitzungsauswahl und die Einwilligung des Nutzers. 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 für den Zugriff auf eine Google API verwenden. Sobald das Zugriffstoken abläuft, verwendet die Anwendung das Aktualisierungstoken, um ein neues Token abzurufen.

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

Das Google OAuth 2.

Die Autorisierungssequenz beginnt, wenn Ihre Anwendung einen Browser zu einer Google-URL weiterleitet. Die URL enthält Abfrageparameter, die die Art des angeforderten Zugriffs angeben. Google kümmert sich um die Nutzerauthentifizierung, die Sitzungsauswahl und die Einwilligung des Nutzers.

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.

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

Anwendungen auf Geräten mit eingeschränkter Eingabe

Der Google OAuth 2.0-Endpunkt unterstützt Anwendungen, die auf Geräten mit eingeschränkter Eingabe ausgeführt werden, z. B. Spielekonsolen, Videokameras und Drucker.

Die Autorisierungssequenz beginnt damit, dass die Anwendung eine Webdienstanfrage an eine Google-URL sendet, um einen Autorisierungscode zu erhalten. Die Antwort enthält mehrere Parameter, darunter eine URL und einen Code, den die Anwendung dem Benutzer anzeigt.

Der Benutzer ruft die URL und den Code vom Gerät ab und wechselt dann zu einem separaten Gerät oder Computer mit umfangreicheren Eingabefunktionen. Der Benutzer startet einen Browser, navigiert zur angegebenen URL, Melden Sie sich an und geben Sie 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 für den Zugriff auf eine Google API verwenden. Sobald das Zugriffstoken abläuft, verwendet die Anwendung das Aktualisierungstoken, um ein neues Token abzurufen.

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

Dienstkonten

:

Google-APIs, wie z. B. die Prediction API und Google Cloud Storage, können im Namen Ihrer Anwendung handeln, ohne auf Nutzerinformationen zugreifen zu müssen. In diesen Situationen muss Ihre Anwendung ihre eigene Identität gegenüber der API nachweisen, aber es ist keine Zustimmung des Benutzers erforderlich. In ähnlicher Weise kann Ihre Anwendung in Unternehmensszenarien delegierten Zugriff auf einige Ressourcen anfordern.

Für diese Typen Für 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, und die Zustimmung des Nutzers ist nicht erforderlich. In Szenarien ohne Dienstkonto ruft Ihre Anwendung Google APIs im Namen von Endnutzern auf, und manchmal ist die Zustimmung des Nutzers erforderlich.

Hinweis: Für diese Dienstkontoszenarien ist es erforderlich, dass Anwendungen JSON Web Tokens (JWTs) erstellen und kryptografisch signieren. Es wird dringend empfohlen, eine Bibliothek zu verwenden, um diese Aufgaben auszuführen. Wenn Sie diesen Code schreiben, ohne eine Bibliothek zu verwenden, die die Tokenerstellung und -signierung abstrahiert, können Fehler auftreten, die sich erheblich auf die Sicherheit Ihrer Anwendung auswirken. Eine Liste der Bibliotheken, die dieses Szenario unterstützen, finden Sie in der Dokumentation zum Dienstkonto.

Die Anmeldeinformationen eines Dienstkontos, die Sie von in der Google API-Konsole eine generierte E-Mail-Adresse, die eindeutig ist, eine Client-ID und mindestens ein öffentliches/privates Schlüsselpaar enthalten. 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 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.

Weitere Informationen finden Sie in der Dokumentation zum Dienstkonto.

Hinweis: Sie können zwar Dienstkonten in Anwendungen verwenden, die über eine Google Workspace-Domain ausgeführt werden, aber Dienstkonten sind nicht Mitglieder Ihres Google Workspace-Kontos und unterliegen nicht den Domainrichtlinien, die von Google Workspace-Administratoren festgelegt wurden. Beispiel: Eine Richtlinie, die in der Google Workspace-Admin-Konsole festgelegt ist, um die Die Möglichkeit für Google Workspace-Endnutzer, Dokumente außerhalb der Domain freizugeben, gilt nicht für Dienstkonten.

Tokengröße

Die Größe der Token kann variieren und gilt bis zu den folgenden Grenzwerten:

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

Zugriffstoken, die von der Security Token Service API von Google Cloud zurückgegeben werden, sind ähnlich wie Google API OAuth 2.0-Zugriffstoken strukturiert, haben jedoch andere Tokengrößenbeschränkungen. 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 variable Tokengrößen entsprechend unterstützen.

Ablauf des Aktualisierungstokens

: Sie müssen Ihren Code so schreiben, dass die Möglichkeit vorhergesehen wird, dass ein gewährtes Aktualisierungstoken möglicherweise nicht mehr funktioniert. Ein Aktualisierungstoken funktioniert möglicherweise für eines der folgenden Geräte nicht mehr Gründe:

Für ein Google Cloud Platform-Projekt mit einem OAuth-Einwilligungsbildschirm, der für einen externen Nutzertyp konfiguriert ist, und dem Veröffentlichungsstatus "Testen" wird ein Aktualisierungstoken ausgestellt, das in 7 Tagen abläuft, es sei denn, die einzigen angeforderten OAuth-Bereiche sind eine Teilmenge von Name, E-Mail-Adresse und Nutzerprofil (über die Bereiche oder deren OpenID Connect-Entsprechungen).

Derzeit gilt ein Limit von 100 Aktualisierungstoken pro Google-Konto und OAuth 2.0-Client-ID. Wenn der Grenzwert erreicht ist, wird beim Erstellen eines neuen Aktualisierungstokens das älteste Aktualisierungstoken automatisch und ohne Warnung ungültig. Dieser Grenzwert gilt nicht für Dienstkonten.

Es gibt auch einen größeren Grenzwert für die Gesamtzahl der Aktualisierungstoken, die ein Benutzerkonto oder Dienstkonto über alle Clients verfügen kann. Die meisten normalen Benutzer werden dieses Limit nicht überschreiten, aber das Konto eines Entwicklers, das zum Testen einer Implementierung verwendet wird, könnte dies tun.

Wenn Sie mehrere Programme autorisieren müssen, Computer oder Geräte können Sie dieses Problem umgehen, indem 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 diese verwenden, um einige der Clients zu autorisieren.

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

Administratoren von GCP-Organisationen müssen Nutzer möglicherweise häufig erneut authentifizieren, wenn sie mit der Google Cloud-Sitzungssteuerungsfunktion auf GCP-Ressourcen zugreifen. Diese Richtlinie wirkt sich auf den Zugriff auf die 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, treten bei Ihren API-Aufrufen nach Ablauf der Sitzungsdauer Fehler auf, ähnlich wie bei einem Widerruf des Aktualisierungstokens: Der Aufruf schlägt mit einem Fehlertyp ; Das Feld kann verwendet werden, um zwischen einem widerrufenen Token und einem Fehler aufgrund einer Sitzungssteuerungsrichtlinie (z. B. ) zu unterscheiden. Da die Sitzungsdauer sehr begrenzt sein kann (zwischen 1 Stunde und 24 Stunden), muss dieses Szenario ordnungsgemäß behandelt werden, indem eine Authentifizierungssitzung neu gestartet wird.

Ebenso dürfen Sie Benutzeranmeldeinformationen für die Server-zu-Server-Bereitstellung nicht verwenden oder deren Verwendung fördern. Wenn Benutzeranmeldeinformationen auf einem Server für Aufträge oder Vorgänge mit langer Ausführungszeit bereitgestellt werden und ein Kunde Sitzungssteuerungsrichtlinien auf diese Benutzer anwendet, schlägt die Serveranwendung fehl, da es keine Möglichkeit gibt, den Benutzer nach Ablauf der Sitzungsdauer erneut zu authentifizieren.

Weitere Informationen darüber, wie Sie Ihre Kunden bei der Bereitstellung dieser Funktion unterstützen können, finden Sie in diesem Hilfeartikel für Administratoren.

Client-Bibliotheken

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