In diesem Dokument wird beschrieben, wie Sie die OAuth 2.0-Autorisierung implementieren, um über eine JavaScript-Webanwendung auf die YouTube Data API zuzugreifen. Mit OAuth 2.0 können Nutzer bestimmte Daten für eine Anwendung freigeben, während ihre Nutzernamen, Passwörter und andere Informationen privat bleiben. Eine Anwendung kann beispielsweise OAuth 2.0 verwenden, um die Berechtigung zum Hochladen von Videos auf den YouTube-Kanal eines Nutzers zu erhalten.
Dieser OAuth 2.0-Vorgang wird als impliziter Berechtigungsfluss bezeichnet. Sie ist für Anwendungen konzipiert, die nur dann auf APIs zugreifen, wenn der Nutzer die Anwendung verwendet. Diese Anwendungen können keine vertraulichen Informationen speichern.
Bei diesem Ablauf öffnet Ihre App eine Google-URL, in der Ihre App und die Art des API-Zugriffs, den die App benötigt, über Abfrageparameter identifiziert werden. Sie können die URL im aktuellen Browserfenster oder in einem Pop-up-Fenster öffnen. Der Nutzer kann sich bei Google authentifizieren und die angeforderten Berechtigungen gewähren. Google leitet den Nutzer dann zurück zu Ihrer App. Die Weiterleitung enthält ein Zugriffstoken, das Ihre App prüft und dann zum Senden von API-Anfragen verwendet.
Google APIs Client Library und Google Identity Services
Wenn Sie die Google API-Clientbibliothek für JavaScript verwenden, um autorisierte Aufrufe an Google zu senden, sollten Sie die JavaScript-Bibliothek von Google Identity Services verwenden, um den OAuth 2.0-Ablauf zu verarbeiten. Weitere Informationen finden Sie im Tokenmodell von Google Identity Services, das auf dem OAuth 2.0-Vorgang Implicit Grant basiert.
Vorbereitung
Die APIs für Ihr Projekt aktivieren
Für jede Anwendung, die Google APIs aufruft, müssen diese APIs in der API Consoleaktiviert werden.
So aktivieren Sie eine API für Ihr Projekt:
- Open the API Library in der Google API Console.
- If prompted, select a project, or create a new one.
- Die YouTube Data API auf der Seite Bibliothek suchen und aktivieren Suchen Sie nach anderen APIs, die von Ihrer Anwendung verwendet werden, und aktivieren Sie diese ebenfalls.
Anmeldedaten für die Autorisierung erstellen
Für jede Anwendung, die OAuth 2.0 für den Zugriff auf Google APIs verwendet, müssen Autorisierungsanmeldedaten vorhanden sein, mit denen die Anwendung beim OAuth 2.0-Server von Google identifiziert wird. In den folgenden Schritten wird erläutert, wie Sie Anmeldedaten für Ihr Projekt erstellen. Ihre Anwendungen können dann mit den Anmeldedaten auf APIs zugreifen, die Sie für dieses Projekt aktiviert haben.
- Go to the Credentials page.
- Klicken Sie auf Create Client.
- Wählen Sie den Anwendungstyp Webanwendung aus.
- Füllen Sie es aus. In Anwendungen, in denen mit JavaScript autorisierte Google API-Anfragen gestellt werden, müssen autorisierte JavaScript-Quellen angegeben werden. Die Ursprünge identifizieren die Domains, von denen Ihre Anwendung Anfragen an den OAuth 2.0-Server senden kann. Diese Ursprünge müssen den Validierungsregeln von Google entsprechen.
Zugriffsbereiche ermitteln
Mithilfe von Bereichen wird ermöglicht, dass eine Anwendung nur für benötigte Ressourcen den Zugriff anfordern kann, während Nutzer wiederum steuern können, wie viel Zugriff sie der Anwendung gewähren. Daher kann es ein umgekehrtes Verhältnis zwischen der Anzahl der angeforderten Bereiche und der Wahrscheinlichkeit geben, dass die Einwilligung des Nutzers eingeholt wird.
Bevor Sie mit der Implementierung der OAuth 2.0-Autorisierung beginnen, empfehlen wir Ihnen, die Bereiche zu identifizieren, für die Ihre Anwendung eine Zugriffsberechtigung benötigt.
Die YouTube Data API v3 verwendet die folgenden Bereiche:
Umfang | Beschreibung |
---|---|
https://www. |
YouTube-Konto verwalten |
https://www. |
Hiermit wird eine Liste der aktuell aktiven Mitglieder des Kanals, ihre Stufe und das jeweilige Abonnementdatum abgerufen |
https://www. |
Ihre YouTube-Videos, -Bewertungen, -Kommentare und -Untertitel ansehen, bearbeiten oder dauerhaft löschen |
https://www. |
YouTube-Konto abrufen |
https://www. |
YouTube-Videos verwalten |
https://www. |
Ihre Inhalte und zugehörigen Content bei YouTube abrufen und verwalten |
https://www. |
Private Informationen aus dem YouTube-Kanal abrufen, die während des Prüfprozesses durch einen YouTube-Partner relevant sind |
Das Dokument OAuth 2.0-API-Bereiche enthält eine vollständige Liste der Bereiche, die Sie für den Zugriff auf Google-APIs verwenden können.
OAuth 2.0-Zugriffstokens abrufen
In den folgenden Schritten wird beschrieben, wie Ihre Anwendung mit dem OAuth 2.0-Server von Google interagiert, um die Zustimmung eines Nutzers zum Ausführen einer API-Anfrage in seinem Namen einzuholen. Ihre Anwendung muss diese Einwilligung haben, bevor sie eine Google API-Anfrage ausführen kann, für die eine Nutzerautorisierung erforderlich ist.
Schritt 1: Weiterleitung zum OAuth 2.0-Server von Google
Wenn Sie die Berechtigung für den Zugriff auf die Daten eines Nutzers anfordern möchten, leiten Sie den Nutzer zum OAuth 2.0-Server von Google weiter.
OAuth 2.0-Endpunkte
Generieren Sie eine URL, um Zugriff vom OAuth 2.0-Endpunkt von Google unter https://accounts.google.com/o/oauth2/v2/auth
anzufordern. Dieser Endpunkt ist über HTTPS zugänglich. Einfache HTTP-Verbindungen werden abgelehnt.
Der Google-Autorisierungsserver unterstützt die folgenden Abfragestringparameter für Webserveranwendungen:
Parameter | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
client_id |
Erforderlich
Die Client-ID für Ihre Anwendung. Sie finden diesen Wert in der . |
||||||||||||||||
redirect_uri |
Erforderlich
Bestimmt, wohin der API-Server den Nutzer weiterleitet, nachdem der Nutzer den Autorisierungsvorgang abgeschlossen hat. Der Wert muss genau mit einem der autorisierten Weiterleitungs-URIs für den OAuth 2.0-Client übereinstimmen, den Sie in der Ihres Clients konfiguriert haben. . Wenn dieser Wert nicht mit einem autorisierten Weiterleitungs-URI für die angegebene Das Schema |
||||||||||||||||
response_type |
Erforderlich
Bei JavaScript-Anwendungen muss der Wert des Parameters auf |
||||||||||||||||
scope |
Erforderlich
Eine durch Leerzeichen getrennte Liste von Bereichen, die die Ressourcen identifizieren, auf die Ihre Anwendung im Namen des Nutzers zugreifen kann. Diese Werte werden auf dem Zustimmungsbildschirm angezeigt, den Google dem Nutzer präsentiert. Mithilfe von Bereichen wird ermöglicht, dass eine Anwendung nur für benötigte Ressourcen den Zugriff anfordern kann, während Nutzer wiederum steuern können, wie viel Zugriff sie der Anwendung gewähren. Daher besteht ein umgekehrtes Verhältnis zwischen der Anzahl der angeforderten Bereiche und der Wahrscheinlichkeit, dass Nutzer ihre Einwilligung erteilen. Die YouTube Data API v3 verwendet die folgenden Bereiche:
Das Dokument OAuth 2.0-API-Bereiche enthält eine vollständige Liste der Bereiche, die Sie für den Zugriff auf Google-APIs verwenden können. Wir empfehlen, dass Ihre Anwendung nach Möglichkeit kontextbezogenen Zugriff auf Autorisierungsbereiche anfordert. Wenn Sie über die schrittweise Autorisierung im Kontext auf Nutzerdaten zugreifen, können Nutzer leichter nachvollziehen, warum Ihre Anwendung den angeforderten Zugriff benötigt. |
||||||||||||||||
state |
Empfohlen
Gibt einen beliebigen Stringwert an, den Ihre Anwendung verwendet, um den Status zwischen Ihrer Autorisierungsanfrage und der Antwort des Autorisierungsservers beizubehalten.
Der Server gibt den genauen Wert zurück, den Sie als Sie können diesen Parameter für verschiedene Zwecke verwenden, z. B. um den Nutzer zur richtigen Ressource in Ihrer Anwendung weiterzuleiten, Nounces zu senden und Cross-Site-Request-Forgery zu verhindern. Da Ihr |
||||||||||||||||
include_granted_scopes |
Optional
Ermöglicht Anwendungen, die schrittweise Autorisierung zu verwenden, um im Kontext Zugriff auf zusätzliche Bereiche anzufordern. Wenn Sie den Wert dieses Parameters auf |
||||||||||||||||
enable_granular_consent |
Optional
Die Standardeinstellung ist Wenn Google detaillierte Berechtigungen für eine Anwendung aktiviert, hat dieser Parameter keine Auswirkungen mehr. |
||||||||||||||||
login_hint |
Optional
Wenn Ihre Anwendung weiß, welcher Nutzer sich authentifizieren möchte, kann sie diesen Parameter verwenden, um dem Google-Authentifizierungsserver einen Hinweis zu geben. Der Server verwendet den Hinweis, um den Anmeldevorgang zu vereinfachen, indem er entweder das E-Mail-Feld im Anmeldeformular vorab ausfüllt oder die entsprechende Multi-Login-Sitzung auswählt. Legen Sie den Parameterwert auf eine E-Mail-Adresse oder eine |
||||||||||||||||
prompt |
Optional
Eine durch Leerzeichen getrennte Liste von Aufforderungen, die dem Nutzer präsentiert werden sollen. Bei den Aufforderungen wird zwischen Groß- und Kleinschreibung unterschieden. Wenn Sie diesen Parameter nicht angeben, wird der Nutzer nur beim ersten Zugriff auf Ihr Projekt aufgefordert, die Berechtigung zu erteilen. Weitere Informationen finden Sie unter Erneute Einwilligung einholen. Folgende Werte sind möglich:
|
Beispiel für eine Weiterleitung an den Google-Autorisierungsserver
In der Beispiel-URL unten wird der Offlinezugriff (access_type=offline
) auf einen Bereich angefordert, der den Zugriff auf das YouTube-Konto des Nutzers ermöglicht. Dabei wird die inkrementelle Autorisierung verwendet, um sicherzustellen, dass das neue Zugriffstoken alle Bereiche abdeckt, auf die der Nutzer der Anwendung zuvor Zugriff gewährt hat. In der URL werden auch Werte für die erforderlichen Parameter redirect_uri
, response_type
und client_id
sowie für den Parameter state
festgelegt. Die URL enthält Zeilenumbrüche und Leerzeichen für eine bessere Lesbarkeit.
https://accounts.google.com/o/oauth2/v2/auth?
scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly&
include_granted_scopes=true&
state=state_parameter_passthrough_value&
redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback&
response_type=token&
client_id=client_id
Nachdem Sie die Anfrage-URL erstellt haben, leiten Sie den Nutzer dorthin weiter.
JavaScript-Beispielcode
Im folgenden JavaScript-Snippet wird gezeigt, wie der Autorisierungsablauf in JavaScript initiiert wird, ohne die Google API-Clientbibliothek für JavaScript zu verwenden. Da dieser OAuth 2.0-Endpunkt kein Cross-Origin Resource Sharing (CORS) unterstützt, wird im Snippet ein Formular erstellt, mit dem die Anfrage an diesen Endpunkt geöffnet wird.
/* * Create form to request access token from Google's OAuth 2.0 server. */ function oauthSignIn() { // Google's OAuth 2.0 endpoint for requesting an access token var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth'; // Create <form> element to submit parameters to OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'GET'); // Send as a GET request. form.setAttribute('action', oauth2Endpoint); // Parameters to pass to OAuth 2.0 endpoint. var params = {'client_id': 'YOUR_CLIENT_ID', 'redirect_uri': 'YOUR_REDIRECT_URI', 'response_type': 'token', 'scope': 'https://www.googleapis.com/auth/youtube.force-ssl', 'include_granted_scopes': 'true', 'state': 'pass-through value'}; // Add form parameters as hidden input values. for (var p in params) { var input = document.createElement('input'); input.setAttribute('type', 'hidden'); input.setAttribute('name', p); input.setAttribute('value', params[p]); form.appendChild(input); } // Add form to page and submit it to open the OAuth 2.0 endpoint. document.body.appendChild(form); form.submit(); }
Schritt 2: Google fordert Nutzer zur Einwilligung auf
In diesem Schritt entscheidet der Nutzer, ob er Ihrer Anwendung den angeforderten Zugriff gewähren möchte. In dieser Phase zeigt Google ein Zustimmungsfenster an, in dem der Name Ihrer Anwendung und die Google API-Dienste angezeigt werden, für die mit den Autorisierungsanmeldedaten des Nutzers eine Berechtigung angefordert wird, sowie eine Zusammenfassung der zu erteilenden Zugriffsbereiche. Der Nutzer kann dann zustimmen, den Zugriff auf einen oder mehrere von Ihrer Anwendung angeforderte Bereiche zu gewähren, oder die Anfrage ablehnen.
Ihre Anwendung muss in dieser Phase nichts tun, da sie auf die Antwort des OAuth 2.0-Servers von Google wartet, in der angegeben wird, ob Zugriff gewährt wurde. Diese Antwort wird im nächsten Schritt erläutert.
Fehler
Bei Anfragen an den OAuth 2.0-Autorisierungsendpunkt von Google werden möglicherweise für Nutzer sichtbare Fehlermeldungen anstelle der erwarteten Authentifizierungs- und Autorisierungsabläufe angezeigt. Häufige Fehlercodes und empfohlene Lösungen sind unten aufgeführt.
admin_policy_enforced
Das Google-Konto kann aufgrund der Richtlinien des Google Workspace-Administrators einen oder mehrere angeforderte Bereiche nicht autorisieren. Weitere Informationen dazu, wie ein Administrator den Zugriff auf alle Bereiche oder auf vertrauliche und eingeschränkte Bereiche einschränken kann, bis der Zugriff explizit für Ihre OAuth-Client-ID gewährt wird, finden Sie im Google Workspace-Hilfeartikel Zugriff externer und interner Apps auf Google Workspace-Daten verwalten.
disallowed_useragent
Der Autorisierungsendpunkt wird in einem eingebetteten User-Agent angezeigt, der gemäß den OAuth 2.0-Richtlinien von Google nicht zulässig ist.
Android
Android-Entwickler sehen diese Fehlermeldung möglicherweise, wenn sie Autorisierungsanfragen in android.webkit.WebView
öffnen.
Entwickler sollten stattdessen Android-Bibliotheken wie Google Sign-In for Android oder AppAuth for Android von der OpenID Foundation verwenden.
Webentwickler können auf diesen Fehler stoßen, wenn eine Android-App einen allgemeinen Weblink in einem eingebetteten User-Agent öffnet und ein Nutzer von Ihrer Website aus zum OAuth 2.0-Autorisierungsendpunkt von Google navigiert. Entwickler sollten zulassen, dass allgemeine Links im Standard-Link-Handler des Betriebssystems geöffnet werden. Dazu gehören sowohl Android App Links-Handler als auch die Standardbrowser-App. Die Android Custom Tabs-Bibliothek ist ebenfalls eine unterstützte Option.
iOS
iOS- und macOS-Entwickler können diesen Fehler erhalten, wenn sie Autorisierungsanfragen in WKWebView
öffnen.
Entwickler sollten stattdessen iOS-Bibliotheken wie Google Sign-In for iOS oder AppAuth for iOS von der OpenID Foundation verwenden.
Webentwickler können auf diesen Fehler stoßen, wenn eine iOS- oder macOS-App einen allgemeinen Weblink in einem eingebetteten User-Agent öffnet und ein Nutzer von Ihrer Website aus zum OAuth 2.0-Autorisierungsendpunkt von Google navigiert. Entwickler sollten zulassen, dass allgemeine Links im Standard-Link-Handler des Betriebssystems geöffnet werden. Dazu gehören sowohl Universal Links-Handler als auch die Standardbrowser-App. Die SFSafariViewController
-Bibliothek ist ebenfalls eine unterstützte Option.
org_internal
Die OAuth-Client-ID in der Anfrage gehört zu einem Projekt, das den Zugriff auf Google-Konten in einer bestimmten Google Cloud-Organisation einschränkt. Weitere Informationen zu dieser Konfigurationsoption finden Sie im Hilfeartikel OAuth-Zustimmungsbildschirm einrichten im Abschnitt Nutzertyp.
invalid_client
Der Ursprung, von dem die Anfrage gesendet wurde, ist für diesen Client nicht autorisiert. Weitere Informationen finden Sie unter origin_mismatch
.
deleted_client
Der OAuth-Client, der für die Anfrage verwendet wird, wurde gelöscht. Das Löschen kann manuell oder automatisch erfolgen, z. B. bei nicht verwendeten Clients . Gelöschte Mandanten können innerhalb von 30 Tagen nach dem Löschen wiederhergestellt werden. Weitere Informationen
invalid_grant
Bei Verwendung der inkrementellen Autorisierung ist das Token möglicherweise abgelaufen oder wurde ungültig gemacht. Authentifizieren Sie den Nutzer noch einmal und bitten Sie ihn um die Einwilligung, neue Tokens zu erhalten. Wenn dieser Fehler weiterhin auftritt, prüfen Sie, ob Ihre Anwendung richtig konfiguriert ist und ob Sie die richtigen Tokens und Parameter in Ihrer Anfrage verwenden. Andernfalls wurde das Nutzerkonto möglicherweise gelöscht oder deaktiviert.
origin_mismatch
Das Schema, die Domain und/oder der Port des JavaScript-Codes, aus dem die Autorisierungsanfrage stammt, stimmen möglicherweise nicht mit einem autorisierten JavaScript-Ursprungs-URI überein, der für die OAuth-Client-ID registriert ist. Überprüfen Sie die autorisierten JavaScript-Quellen in der .
redirect_uri_mismatch
Der in der Autorisierungsanfrage übergebene redirect_uri
stimmt nicht mit einem autorisierten Weiterleitungs-URI für die OAuth-Client-ID überein. Überprüfen Sie die autorisierten Weiterleitungs-URIs in der
.
Das Schema, die Domain und/oder der Port des JavaScript-Codes, aus dem die Autorisierungsanfrage stammt, stimmen möglicherweise nicht mit einem autorisierten JavaScript-Ursprungs-URI überein, der für die OAuth-Client-ID registriert ist. Überprüfen Sie die autorisierten JavaScript-Quellen in der .
Der Parameter redirect_uri
bezieht sich möglicherweise auf den OAuth-Out-of-Band-Ablauf (OOB), der eingestellt wurde und nicht mehr unterstützt wird. Weitere Informationen finden Sie in der Migrationsanleitung.
invalid_request
Bei Ihrer Anfrage ist ein Fehler aufgetreten. Das kann verschiedene Gründe haben:
- Die Anfrage war nicht richtig formatiert
- In der Anfrage fehlten erforderliche Parameter.
- Die Anfrage verwendet eine Autorisierungsmethode, die von Google nicht unterstützt wird. Prüfen, ob für Ihre OAuth-Integration eine empfohlene Integrationsmethode verwendet wird
Schritt 3: OAuth 2.0-Serverantwort verarbeiten
OAuth 2.0-Endpunkte
Der OAuth 2.0-Server sendet eine Antwort an den redirect_uri
, der in Ihrer Zugriffstokenanfrage angegeben ist.
Wenn der Nutzer die Anfrage genehmigt, enthält die Antwort ein Zugriffstoken. Wenn der Nutzer die Anfrage nicht genehmigt, enthält die Antwort eine Fehlermeldung. Das Zugriffstoken oder die Fehlermeldung wird im Hash-Fragment des Weiterleitungs-URI zurückgegeben, wie unten dargestellt:
Eine Antwort mit einem Zugriffstoken:
https://oauth2.example.com/callback#access_token=4/P7q7W91&token_type=Bearer&expires_in=3600
Zusätzlich zum Parameter
access_token
enthält der Fragment-String auch den Parametertoken_type
, der immer aufBearer
festgelegt ist, und den Parameterexpires_in
, der die Gültigkeitsdauer des Tokens in Sekunden angibt. Wenn der Parameterstate
in der Zugriffstokenanfrage angegeben wurde, ist sein Wert auch in der Antwort enthalten.- Eine Fehlerantwort:
https://oauth2.example.com/callback#error=access_denied
Beispiel für eine OAuth 2.0-Serverantwort
Sie können diesen Ablauf testen, indem Sie auf die folgende Beispiel-URL klicken, mit der schreibgeschützter Zugriff zum Anzeigen von Metadaten für Dateien in Ihrem Google Drive und schreibgeschützter Zugriff zum Anzeigen Ihrer Google Kalender-Termine angefordert wird:
https://accounts.google.com/o/oauth2/v2/auth? scope=https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fyoutube.readonly& include_granted_scopes=true& state=state_parameter_passthrough_value& redirect_uri=http%3A%2F%2Flocalhost%2Foauth2callback& response_type=token& client_id=client_id
Nach Abschluss des OAuth 2.0-Vorgangs werden Sie zu http://localhost/oauth2callback
weitergeleitet. Diese URL führt zu einem 404 NOT FOUND
-Fehler, sofern auf Ihrem lokalen Computer keine Datei unter dieser Adresse bereitgestellt wird. Im nächsten Schritt finden Sie weitere Informationen zu den Informationen, die im URI zurückgegeben werden, wenn der Nutzer zu Ihrer Anwendung zurückgeleitet wird.
Schritt 4: Prüfen, welche Bereiche Nutzer gewährt haben
Wenn Sie mehrere Berechtigungen (Bereich) anfordern, gewähren Nutzer Ihrer App möglicherweise nicht für alle Zugriff. Ihre App muss prüfen, welche Bereiche tatsächlich gewährt wurden, und Situationen, in denen einige Berechtigungen verweigert werden, angemessen behandeln. In der Regel werden die Funktionen deaktiviert, die auf diesen verweigerten Bereichen basieren.
Es gibt jedoch Ausnahmen. Google Workspace Enterprise-Apps mit domainweiter Übertragung von Befugnissen oder Apps, die als Vertrauenswürdig gekennzeichnet sind, umgehen den Zustimmungsbildschirm für detaillierte Berechtigungen. Nutzern dieser Apps wird der Zustimmungsbildschirm für detaillierte Berechtigungen nicht angezeigt. Stattdessen erhält Ihre App entweder alle angeforderten Bereiche oder keinen.
Weitere Informationen finden Sie unter Granulare Berechtigungen verwalten.
OAuth 2.0-Endpunkte
Wenn Sie prüfen möchten, ob der Nutzer Ihrer Anwendung Zugriff auf einen bestimmten Bereich gewährt hat, sehen Sie sich das Feld scope
in der Antwort des Zugriffstokens an. Die Zugriffsbereiche, die durch das access_token gewährt werden, ausgedrückt als Liste von durch Leerzeichen getrennten, case-sensitiven Strings.
Die folgende Beispielantwort für ein Zugriffstoken gibt beispielsweise an, dass der Nutzer Ihrer Anwendung die Berechtigung erteilt hat, die YouTube-Videos, ‑Bewertungen, ‑Kommentare und ‑Untertitel des Nutzers anzusehen, zu bearbeiten und dauerhaft zu löschen:
{ "access_token": "1/fFAGRNJru1FTz70BzhT3Zg", "expires_in": 3920, "token_type": "Bearer", "scope": "https://www.googleapis.com/auth/youtube.force-ssl", "refresh_token": "1//xEoDL4iW3cxlI7yDbSRFYNG01kVKM2C-259HOF2aQbI" }
Google APIs aufrufen
OAuth 2.0-Endpunkte
Nachdem Ihre Anwendung ein Zugriffstoken erhalten hat, können Sie das Token verwenden, um im Namen eines bestimmten Nutzerkontos Aufrufe an eine Google API zu senden, sofern die von der API erforderlichen Zugriffsbereiche gewährt wurden. Dazu müssen Sie das Zugriffstoken in eine Anfrage an die API einfügen. Verwenden Sie dazu entweder den Abfrageparameter access_token
oder den HTTP-Header Authorization
mit dem Wert Bearer
. Wenn möglich, ist der HTTP-Header vorzuziehen, da Abfragestrings in der Regel in Serverlogs sichtbar sind. In den meisten Fällen können Sie eine Clientbibliothek verwenden, um Ihre Aufrufe von Google APIs einzurichten, z. B. beim Aufrufen der YouTube Data API.
Hinweis: Die YouTube Data API unterstützt Dienstkonten nur für YouTube-Rechteinhaber, die mehrere YouTube-Kanäle besitzen und verwalten, z. B. Musiklabels und Filmstudios.
Sie können alle Google APIs ausprobieren und ihre Bereiche im OAuth 2.0 Playground ansehen.
Beispiele für HTTP GET
Ein Aufruf des Endpunkts
youtube.channels
(YouTube Data API) mit dem HTTP-Header Authorization: Bearer
könnte so aussehen: Sie müssen Ihr eigenes Zugriffstoken angeben:
GET /youtube/v3/channels?part=snippet&mine=true HTTP/1.1 Host: www.googleapis.com Authorization: Bearer access_token
Hier ist ein Aufruf derselben API für den authentifizierten Nutzer mit dem Query-String-Parameter access_token
:
GET https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true
Beispiele für curl
Sie können diese Befehle mit der curl
-Befehlszeilenanwendung testen. Hier ein Beispiel mit der HTTP-Header-Option (bevorzugt):
curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true
Alternativ können Sie auch die Option für den Abfragestringparameter verwenden:
curl https://www.googleapis.com/youtube/v3/channels?access_token=access_token&part=snippet&mine=true
JavaScript-Beispielcode
Das folgende Code-Snippet zeigt, wie Sie CORS (Cross-Origin Resource Sharing) verwenden, um eine Anfrage an eine Google API zu senden. In diesem Beispiel wird die Google APIs-Clientbibliothek für JavaScript nicht verwendet. Auch wenn Sie die Clientbibliothek nicht verwenden, kann Ihnen der Leitfaden zur CORS-Unterstützung in der Dokumentation der Bibliothek helfen, diese Anfragen besser zu verstehen.
In diesem Code-Snippet steht die Variable access_token
für das Token, das Sie erhalten haben, um API-Anfragen im Namen des autorisierten Nutzers zu stellen. Im vollständigen Beispiel wird gezeigt, wie Sie dieses Token im lokalen Speicher des Browsers speichern und beim Senden einer API-Anfrage abrufen.
var xhr = new XMLHttpRequest(); xhr.open('GET', 'https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true&' + 'access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { console.log(xhr.response); }; xhr.send(null);
Vollständiges Beispiel
OAuth 2.0-Endpunkte
In diesem Codebeispiel wird gezeigt, wie Sie den OAuth 2.0-Ablauf in JavaScript abschließen, ohne die Google APIs-Clientbibliothek für JavaScript zu verwenden. Der Code ist für eine HTML-Seite, auf der eine Schaltfläche zum Ausführen einer API-Anfrage angezeigt wird. Wenn Sie auf die Schaltfläche klicken, wird geprüft, ob auf der Seite ein API-Zugriffstoken im lokalen Speicher Ihres Browsers gespeichert ist. Wenn ja, wird die API-Anfrage ausgeführt. Andernfalls wird der OAuth 2.0-Vorgang gestartet.
Für den OAuth 2.0-Vorgang werden auf der Seite die folgenden Schritte ausgeführt:
- Der Nutzer wird zum OAuth 2.0-Server von Google weitergeleitet, auf dem Zugriff auf den Bereich
https://www.googleapis.com/auth/youtube.force-ssl
angefordert wird. - Nachdem der Nutzer den Zugriff auf einen oder mehrere angeforderte Bereiche gewährt (oder verweigert) hat, wird er zur ursprünglichen Seite weitergeleitet, die das Zugriffstoken aus dem Fragment-ID-String parst.
- Auf der Seite wird geprüft, auf welche Bereiche der Nutzer der Anwendung Zugriff gewährt hat.
Wenn der Nutzer den Zugriff auf die angeforderten Bereiche gewährt hat, verwendet die Seite das Zugriffstoken, um die Beispiel-API-Anfrage zu stellen.
Mit dieser API-Anfrage wird die Methode
channels.list
der YouTube Data API aufgerufen, um Daten zum YouTube-Kanal des autorisierten Nutzers abzurufen.- Wenn die Anfrage erfolgreich ausgeführt wird, wird die API-Antwort in der Debugging-Konsole des Browsers protokolliert.
Sie können den Zugriff auf die App über die Seite Berechtigungen Ihres Google-Kontos widerrufen. Die App wird als OAuth 2.0-Demo für Google API-Dokumente aufgeführt.
Wenn Sie diesen Code lokal ausführen möchten, müssen Sie Werte für die Variablen YOUR_CLIENT_ID
und YOUR_REDIRECT_URI
festlegen, die Ihren Autorisierungsanmeldedaten entsprechen. Die Variable YOUR_REDIRECT_URI
sollte auf dieselbe URL festgelegt werden, über die die Seite bereitgestellt wird. Der Wert muss genau mit einem der autorisierten Weiterleitungs-URIs für den OAuth 2.0-Client übereinstimmen, den Sie in der
konfiguriert haben. Wenn dieser Wert nicht mit einem autorisierten URI übereinstimmt, erhalten Sie einen redirect_uri_mismatch
-Fehler. In Ihrem Projekt muss auch die entsprechende API für diese Anfrage aktiviert sein.
<html><head></head><body> <script> var YOUR_CLIENT_ID = 'REPLACE_THIS_VALUE'; var YOUR_REDIRECT_URI = 'REPLACE_THIS_VALUE'; // Parse query string to see if page request is coming from OAuth 2.0 server. var fragmentString = location.hash.substring(1); var params = {}; var regex = /([^&=]+)=([^&]*)/g, m; while (m = regex.exec(fragmentString)) { params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]); } if (Object.keys(params).length > 0 && params['state']) { if (params['state'] == localStorage.getItem('state')) { localStorage.setItem('oauth2-test-params', JSON.stringify(params) ); trySampleRequest(); } else { console.log('State mismatch. Possible CSRF attack'); } } // Function to generate a random state value function generateCryptoRandomState() { const randomValues = new Uint32Array(2); window.crypto.getRandomValues(randomValues); // Encode as UTF-8 const utf8Encoder = new TextEncoder(); const utf8Array = utf8Encoder.encode( String.fromCharCode.apply(null, randomValues) ); // Base64 encode the UTF-8 data return btoa(String.fromCharCode.apply(null, utf8Array)) .replace(/\+/g, '-') .replace(/\//g, '_') .replace(/=+$/, ''); } // If there's an access token, try an API request. // Otherwise, start OAuth 2.0 flow. function trySampleRequest() { var params = JSON.parse(localStorage.getItem('oauth2-test-params')); if (params && params['access_token']) { var xhr = new XMLHttpRequest(); xhr.open('GET', 'https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true&' + 'access_token=' + params['access_token']); xhr.onreadystatechange = function (e) { if (xhr.readyState === 4 && xhr.status === 200) { console.log(xhr.response); } else if (xhr.readyState === 4 && xhr.status === 401) { // Token invalid, so prompt for user permission. oauth2SignIn(); } }; xhr.send(null); } else { oauth2SignIn(); } } /* * Create form to request access token from Google's OAuth 2.0 server. */ function oauth2SignIn() { // create random state value and store in local storage var state = generateCryptoRandomState(); localStorage.setItem('state', state); // Google's OAuth 2.0 endpoint for requesting an access token var oauth2Endpoint = 'https://accounts.google.com/o/oauth2/v2/auth'; // Create element to open OAuth 2.0 endpoint in new window. var form = document.createElement('form'); form.setAttribute('method', 'GET'); // Send as a GET request. form.setAttribute('action', oauth2Endpoint); // Parameters to pass to OAuth 2.0 endpoint. var params = {'client_id': YOUR_CLIENT_ID, 'redirect_uri': YOUR_REDIRECT_URI, 'scope': 'https://www.googleapis.com/auth/youtube.force-ssl', 'state': state, 'include_granted_scopes': 'true', 'response_type': 'token'}; // Add form parameters as hidden input values. for (var p in params) { var input = document.createElement('input'); input.setAttribute('type', 'hidden'); input.setAttribute('name', p); input.setAttribute('value', params[p]); form.appendChild(input); } // Add form to page and submit it to open the OAuth 2.0 endpoint. document.body.appendChild(form); form.submit(); } </script> <button onclick="trySampleRequest();">Try sample request</button> </body></html>
Validierungsregeln für JavaScript-Quellen
Google wendet die folgenden Validierungsregeln auf JavaScript-Quellen an, um Entwicklern dabei zu helfen, ihre Anwendungen zu schützen. Ihre JavaScript-Ursprünge müssen diesen Regeln entsprechen. Die Definitionen der unten erwähnten Begriffe „Domain“, „Host“ und „Schema“ finden Sie in RFC 3986, Abschnitt 3.
Validierungsregeln | |
---|---|
Schema |
JavaScript-Ursprünge müssen das HTTPS-Schema und nicht HTTP verwenden. Localhost-URIs (einschließlich Localhost-IP-Adress-URIs) sind von dieser Regel ausgenommen. |
Moderator:in |
Hosts dürfen keine reinen IP-Adressen sein. Localhost-IP-Adressen sind von dieser Regel ausgenommen. |
Domain |
“googleusercontent.com” sein.goo.gl ) enthalten, es sei denn, die App ist Eigentümer der Domain. |
Userinfo |
JavaScript-Ursprünge dürfen die Unterkomponente „userinfo“ nicht enthalten. |
Pfad |
JavaScript-Ursprünge dürfen die Pfadkomponente nicht enthalten. |
Abfrage |
JavaScript-Ursprünge dürfen die Abfragekomponente nicht enthalten. |
Fragment |
JavaScript-Ursprünge dürfen die Fragmentkomponente nicht enthalten. |
Zeichen |
JavaScript-Quellen dürfen bestimmte Zeichen nicht enthalten, darunter:
|
Inkrementelle Autorisierung
Im OAuth 2.0-Protokoll fordert Ihre App die Autorisierung für den Zugriff auf Ressourcen an, die durch Bereiche identifiziert werden. Es gilt als Best Practice für die Nutzerfreundlichkeit, die Autorisierung für Ressourcen zum Zeitpunkt des Bedarfs anzufordern. Um dies zu ermöglichen, unterstützt der Autorisierungsserver von Google die inkrementelle Autorisierung. Mit dieser Funktion können Sie Bereichsanfragen stellen, wenn sie benötigt werden. Wenn der Nutzer die Berechtigung für den neuen Bereich erteilt, wird ein Autorisierungscode zurückgegeben, der gegen ein Token mit allen Bereichen eingetauscht werden kann, die der Nutzer dem Projekt gewährt hat.
Angenommen, eine App hilft Nutzern, interessante lokale Veranstaltungen zu finden. In der App können Nutzer Videos zu den Events ansehen, bewerten und zu Playlists hinzufügen. Nutzer können mit der App auch Termine in ihren Google-Kalendern hinzufügen.
In diesem Fall benötigt die App bei der Anmeldung möglicherweise keinen Zugriff auf Bereiche und fordert ihn auch nicht an. Wenn der Nutzer jedoch versucht, ein Video zu bewerten, ein Video einer Playlist hinzuzufügen oder eine andere YouTube-Aktion auszuführen, kann die App Zugriff auf den https://www.googleapis.com/auth/youtube.force-ssl
-Bereich anfordern.
Ebenso könnte die App Zugriff auf den Bereich https://www.googleapis.com/auth/calendar
anfordern, wenn der Nutzer versucht hat, einen Kalendertermin hinzuzufügen.
Für ein Zugriffstoken, das durch eine inkrementelle Autorisierung abgerufen wurde, gelten die folgenden Regeln:
- Mit dem Token kann auf Ressourcen zugegriffen werden, die einem der Bereiche entsprechen, die in der neuen, kombinierten Autorisierung enthalten sind.
- Wenn Sie das Aktualisierungstoken für die kombinierte Autorisierung verwenden, um ein Zugriffstoken zu erhalten, repräsentiert das Zugriffstoken die kombinierte Autorisierung und kann für alle
scope
-Werte verwendet werden, die in der Antwort enthalten sind. - Die kombinierte Autorisierung umfasst alle Bereiche, die der Nutzer dem API-Projekt gewährt hat, auch wenn die Berechtigungen von verschiedenen Clients angefordert wurden. Wenn ein Nutzer beispielsweise über den Desktopclient einer Anwendung Zugriff auf einen Bereich gewährt und dann über einen mobilen Client derselben Anwendung Zugriff auf einen anderen Bereich gewährt, umfasst die kombinierte Autorisierung beide Bereiche.
- Wenn Sie ein Token widerrufen, das eine kombinierte Autorisierung darstellt, wird der Zugriff auf alle Bereiche dieser Autorisierung im Namen des zugehörigen Nutzers gleichzeitig widerrufen.
Die folgenden Codebeispiele zeigen, wie Sie einem vorhandenen Zugriffstoken Bereiche hinzufügen. So muss Ihre App nicht mehrere Zugriffstokens verwalten.
OAuth 2.0-Endpunkte
In diesem Beispiel fordert die aufrufende Anwendung Zugriff an, um die YouTube Analytics-Daten des Nutzers abzurufen. Dies gilt zusätzlich zu allen anderen Zugriffsberechtigungen, die der Nutzer der Anwendung bereits erteilt hat.
Wenn Sie einem vorhandenen Zugriffstoken Bereiche hinzufügen möchten, fügen Sie den Parameter include_granted_scopes
in Ihre Anfrage an den OAuth 2.0-Server von Google ein.
Das folgende Code-Snippet zeigt, wie das geht. Im Snippet wird davon ausgegangen, dass Sie die Bereiche, für die Ihr Zugriffstoken gültig ist, im lokalen Speicher des Browsers gespeichert haben. Im vollständigen Beispielcode wird eine Liste der Zugriffsbereiche gespeichert, für die das Zugriffstoken gültig ist. Dazu wird die Eigenschaft oauth2-test-params.scope
im lokalen Speicher des Browsers festgelegt.
Im Snippet werden die Bereiche, für die das Zugriffstoken gültig ist, mit dem Bereich verglichen, den Sie für eine bestimmte Anfrage verwenden möchten. Wenn das Zugriffstoken diesen Bereich nicht abdeckt, wird der OAuth 2.0-Ablauf gestartet.
Die Funktion oauth2SignIn
ist dieselbe wie in Schritt 2 (und später im vollständigen Beispiel).
var SCOPE = 'https://www.googleapis.com/auth/youtube.force-ssl'; var params = JSON.parse(localStorage.getItem('oauth2-test-params')); var current_scope_granted = false; if (params.hasOwnProperty('scope')) { var scopes = params['scope'].split(' '); for (var s = 0; s < scopes.length; s++) { if (SCOPE == scopes[s]) { current_scope_granted = true; } } } if (!current_scope_granted) { oauth2SignIn(); // This function is defined elsewhere in this document. } else { // Since you already have access, you can proceed with the API request. }
Token widerrufen
In einigen Fällen möchten Nutzer den Zugriff auf eine Anwendung widerrufen. Ein Nutzer kann den Zugriff in den Kontoeinstellungen widerrufen. Weitere Informationen finden Sie im Hilfeartikel Websites und Apps von Drittanbietern mit Zugriff auf Ihr Konto im Abschnitt Zugriff auf Websites oder Apps entfernen.
Eine Anwendung kann den ihr gewährten Zugriff auch programmatisch widerrufen. Der programmatische Widerruf ist wichtig, wenn ein Nutzer ein Abo kündigt, eine Anwendung entfernt oder sich die von einer App benötigten API-Ressourcen erheblich geändert haben. Mit anderen Worten: Ein Teil des Entfernungsprozesses kann eine API-Anfrage umfassen, um sicherzustellen, dass die zuvor der Anwendung gewährten Berechtigungen entfernt werden.
OAuth 2.0-Endpunkte
Wenn Sie ein Token programmatisch widerrufen möchten, sendet Ihre Anwendung eine Anfrage an https://oauth2.googleapis.com/revoke
und fügt das Token als Parameter ein:
curl -d -X -POST --header "Content-type:application/x-www-form-urlencoded" \ https://oauth2.googleapis.com/revoke?token={token}
Das Token kann ein Zugriffs- oder ein Aktualisierungstoken sein. Wenn es sich bei dem Token um ein Zugriffstoken handelt und es ein entsprechendes Aktualisierungstoken gibt, wird auch das Aktualisierungstoken widerrufen.
Wenn der Widerruf erfolgreich verarbeitet wurde, ist der HTTP-Statuscode der Antwort 200
. Bei Fehlerbedingungen wird zusammen mit einem Fehlercode ein HTTP-Statuscode 400
zurückgegeben.
Das folgende JavaScript-Snippet zeigt, wie ein Token in JavaScript widerrufen wird, ohne die Google APIs Client Library for JavaScript zu verwenden. Da der OAuth 2.0-Endpunkt von Google zum Widerrufen von Tokens kein Cross-Origin Resource Sharing (CORS) unterstützt, wird im Code ein Formular erstellt und an den Endpunkt gesendet, anstatt die XMLHttpRequest()
-Methode zum Senden der Anfrage zu verwenden.
function revokeAccess(accessToken) { // Google's OAuth 2.0 endpoint for revoking access tokens. var revokeTokenEndpoint = 'https://oauth2.googleapis.com/revoke'; // Create <form> element to use to POST data to the OAuth 2.0 endpoint. var form = document.createElement('form'); form.setAttribute('method', 'post'); form.setAttribute('action', revokeTokenEndpoint); // Add access token to the form so it is set as value of 'token' parameter. // This corresponds to the sample curl request, where the URL is: // https://oauth2.googleapis.com/revoke?token={token} var tokenField = document.createElement('input'); tokenField.setAttribute('type', 'hidden'); tokenField.setAttribute('name', 'token'); tokenField.setAttribute('value', accessToken); form.appendChild(tokenField); // Add form to page and submit it to actually revoke the token. document.body.appendChild(form); form.submit(); }
Produktübergreifenden Kontoschutz implementieren
Ein zusätzlicher Schritt, den Sie unternehmen sollten, um die Konten Ihrer Nutzer zu schützen, ist die Implementierung von Cross-Account Protection mithilfe des Cross-Account Protection Service von Google. Mit diesem Dienst können Sie Benachrichtigungen zu Sicherheitsereignissen abonnieren, die Ihre Anwendung über wichtige Änderungen am Nutzerkonto informieren. Anhand dieser Informationen können Sie dann Maßnahmen ergreifen, je nachdem, wie Sie auf Ereignisse reagieren möchten.
Hier einige Beispiele für die Ereignistypen, die vom Google Cross-Account Protection Service an Ihre App gesendet werden:
-
https://schemas.openid.net/secevent/risc/event-type/sessions-revoked
-
https://schemas.openid.net/secevent/oauth/event-type/token-revoked
-
https://schemas.openid.net/secevent/risc/event-type/account-disabled
Weitere Informationen zur Implementierung des produktübergreifenden Kontoschutzes und die vollständige Liste der verfügbaren Ereignisse finden Sie auf der Seite Nutzerkonten mit dem produktübergreifenden Kontoschutz schützen .