OAuth 2.0 für JavaScript-Webanwendungen verwenden

In diesem Dokument wird erläutert, wie du die OAuth 2.0-Autorisierung implementierst, um über eine JavaScript-Webanwendung auf die YouTube Data API zuzugreifen. OAuth 2.0 ermöglicht Nutzern, bestimmte Daten für eine Anwendung freizugeben, 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 Berechtigungsvorgang bezeichnet. Sie ist für Anwendungen gedacht, die nur dann auf APIs zugreifen, wenn der Nutzer in der Anwendung aktiv ist. Diese Anwendungen können keine vertraulichen Informationen speichern.

In diesem Ablauf öffnet Ihre App eine Google-URL, die Suchparameter verwendet, um Ihre App und den Typ des API-Zugriffs zu identifizieren, den die App benötigt. Sie können die URL im aktuellen Browserfenster oder in einem Dialogfeld öffnen. Der Nutzer kann sich bei Google authentifizieren und die angeforderten Berechtigungen gewähren. Anschließend leitet Google den Nutzer zurück zu Ihrer App. Die Weiterleitung enthält ein Zugriffstoken, das von Ihrer App überprüft und dann für API-Anfragen verwendet wird.

Google APIs-Clientbibliothek und Google Identity Services

Wenn Sie die Google APIs-Clientbibliothek für JavaScript verwenden, um autorisierte Aufrufe an Google zu senden, sollten Sie die JavaScript-Bibliothek der Google Identity Services verwenden, um den Autorisierungsablauf zu verarbeiten. Wir empfehlen dringend, das Codemodell der Google Identity Services zu verwenden, das auf dem sichereren Autorisierungscode-Vorgang mit PKCE basiert.

Vorbereitung

Die APIs für Ihr Projekt aktivieren

Für jede Anwendung, die Google APIs aufruft, müssen diese APIs in der API Console aktiviert werden.

So aktivieren Sie eine API für Ihr Projekt:

  1. Öffnen Sie die API-Bibliothek in der Google API Console.
  2. Wählen Sie ein Projekt aus oder erstellen Sie ein neues, wenn Sie dazu aufgefordert werden.
  3. Suchen Sie auf der Seite Bibliothek nach der YouTube Data API und aktivieren Sie sie. Suchen Sie nach anderen APIs, die Ihre Anwendung verwendet, und aktivieren Sie diese ebenfalls.

Anmeldedaten für die Autorisierung erstellen

Jede Anwendung, die OAuth 2.0 für den Zugriff auf Google APIs verwendet, muss über Autorisierungsdaten verfügen, mit denen sie sich gegenüber dem OAuth 2.0-Server von Google identifiziert. In den folgenden Schritten wird beschrieben, 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.

  1. Rufen Sie die Seite „Clients“ auf.
  2. Klicken Sie auf Client erstellen.
  3. Wählen Sie den Anwendungstyp Webanwendung aus.
  4. Füllen Sie es aus. Anwendungen, die JavaScript verwenden, um autorisierte Google API-Anfragen zu stellen, müssen autorisierte JavaScript-Quellen angeben. 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 identifizieren

Mit Bereichen kann Ihre Anwendung nur Zugriff auf die Ressourcen anfordern, die sie benötigt. Außerdem können Nutzer so den Umfang des Zugriffs steuern, den sie Ihrer Anwendung gewähren. Es kann also eine umgekehrte Beziehung zwischen der Anzahl der angeforderten Bereiche und der Wahrscheinlichkeit geben, dass die Nutzereinwilligung erteilt wird.

Bevor Sie mit der Implementierung der OAuth 2.0-Autorisierung beginnen, sollten Sie die Bereiche ermitteln, für die Ihre App Zugriffsberechtigungen benötigt.

Die YouTube Data API v3 verwendet die folgenden Bereiche:

Umfang Beschreibung
https://www.googleapis.com/auth/youtube YouTube-Konto verwalten
https://www.googleapis.com/auth/youtube.channel-memberships.creator Hiermit wird eine Liste der aktuell aktiven Mitglieder des Kanals, ihre Stufe und das jeweilige Abonnementdatum abgerufen
https://www.googleapis.com/auth/youtube.force-ssl Ihre YouTube-Videos, -Bewertungen, -Kommentare und -Untertitel ansehen, bearbeiten oder dauerhaft löschen
https://www.googleapis.com/auth/youtube.readonly YouTube-Konto abrufen
https://www.googleapis.com/auth/youtube.upload YouTube-Videos verwalten
https://www.googleapis.com/auth/youtubepartner Ihre Inhalte und zugehörigen Content bei YouTube abrufen und verwalten
https://www.googleapis.com/auth/youtubepartner-channel-audit 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 gezeigt, wie Ihre Anwendung mit dem OAuth 2.0-Server von Google interagiert, um die Einwilligung eines Nutzers einzuholen, eine API-Anfrage im Namen des Nutzers auszuführen. Ihre Anwendung muss diese Einwilligung einholen, 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 an den 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 Abfragestring-Parameter für Webserveranwendungen:

Parameter
client_id Erforderlich

Die Client-ID für Ihre Anwendung. Sie finden diesen Wert in der Cloud Console auf der Seite „Clients“.

redirect_uri Erforderlich

Bestimmt, wohin der API-Server den Nutzer weiterleitet, nachdem er den Autorisierungsablauf abgeschlossen hat. Der Wert muss genau mit einem der autorisierten Weiterleitungs-URIs für den OAuth 2.0-Client übereinstimmen, den Sie in der Cloud Console auf der Seite „Clients“ Ihres Clients konfiguriert haben. Wenn dieser Wert nicht mit einem autorisierten Weiterleitungs-URI für die angegebene client_id übereinstimmt, wird der Fehler redirect_uri_mismatch angezeigt.

Das Schema http oder https, die Groß-/Kleinschreibung und der abschließende Schrägstrich (/) müssen übereinstimmen.

response_type Erforderlich

In JavaScript-Anwendungen muss der Wert des Parameters auf token festgelegt werden. Dieser Wert weist den Google-Autorisierungsserver an, das Zugriffstoken als name=value-Paar im Fragmentbezeichner der URI (#) zurückzugeben, zu der der Nutzer nach Abschluss des Autorisierungsvorgangs weitergeleitet wird.

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.

Mit Bereichen kann Ihre Anwendung nur Zugriff auf die Ressourcen anfordern, die sie benötigt. Außerdem können Nutzer so den Umfang des Zugriffs steuern, den sie Ihrer Anwendung gewähren. Es besteht also eine umgekehrte Beziehung zwischen der Anzahl der angeforderten Bereiche und der Wahrscheinlichkeit, dass die Nutzereinwilligung erteilt wird.

Die YouTube Data API v3 verwendet die folgenden Bereiche:

Umfang Beschreibung
https://www.googleapis.com/auth/youtube YouTube-Konto verwalten
https://www.googleapis.com/auth/youtube.channel-memberships.creator Hiermit wird eine Liste der aktuell aktiven Mitglieder des Kanals, ihre Stufe und das jeweilige Abonnementdatum abgerufen
https://www.googleapis.com/auth/youtube.force-ssl Ihre YouTube-Videos, -Bewertungen, -Kommentare und -Untertitel ansehen, bearbeiten oder dauerhaft löschen
https://www.googleapis.com/auth/youtube.readonly YouTube-Konto abrufen
https://www.googleapis.com/auth/youtube.upload YouTube-Videos verwalten
https://www.googleapis.com/auth/youtubepartner Ihre Inhalte und zugehörigen Content bei YouTube abrufen und verwalten
https://www.googleapis.com/auth/youtubepartner-channel-audit 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.

Wir empfehlen, dass Ihre Anwendung nach Möglichkeit im Kontext Zugriff auf Autorisierungsbereiche anfordert. Wenn Sie den Zugriff auf Nutzerdaten im Kontext über die inkrementelle Autorisierung anfordern, können Nutzer besser 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 name=value-Paar im URL-Fragmentbezeichner (#) der redirect_uri senden, nachdem der Nutzer die Zugriffsanfrage Ihrer Anwendung genehmigt oder abgelehnt hat.

Sie können diesen Parameter für verschiedene Zwecke verwenden, z. B. um den Nutzer zur richtigen Ressource in Ihrer Anwendung weiterzuleiten, Nonces zu senden und websiteübergreifende Anfragen zu verhindern. Da Ihre redirect_uri erraten werden kann, können Sie mit einem state-Wert die Wahrscheinlichkeit erhöhen, dass eine eingehende Verbindung das Ergebnis einer Authentifizierungsanfrage ist. Wenn Sie einen zufälligen String generieren oder den Hash eines Cookies oder eines anderen Werts codieren, der den Status des Clients erfasst, können Sie die Antwort validieren, um zusätzlich sicherzustellen, dass die Anfrage und die Antwort vom selben Browser stammen. So können Sie sich vor Angriffen wie websiteübergreifende Anfragefälschung schützen. Ein Beispiel für das Erstellen und Bestätigen eines state-Tokens finden Sie in der Dokumentation zu OpenID Connect.

include_granted_scopes Optional

Ermöglicht Anwendungen, die inkrementelle Autorisierung zu verwenden, um Zugriff auf zusätzliche Bereiche im Kontext anzufordern. Wenn Sie den Wert dieses Parameters auf true setzen und die Autorisierungsanfrage genehmigt wird, deckt das neue Zugriffstoken auch alle Bereiche ab, für die der Nutzer der Anwendung zuvor Zugriff gewährt hat. Beispiele finden Sie im Abschnitt Inkrementelle Autorisierung.

login_hint Optional

Wenn Ihre Anwendung weiß, welcher Nutzer versucht, sich zu authentifizieren, 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 vorausfüllt oder die entsprechende Multi-Login-Sitzung auswählt.

Legen Sie den Parameterwert auf eine E-Mail-Adresse oder eine sub-Kennung fest, die der Google-ID des Nutzers entspricht.

prompt Optional

Eine durch Leerzeichen getrennte Liste von Aufforderungen, die dem Nutzer angezeigt werden sollen. Bei der Liste wird zwischen Groß- und Kleinschreibung unterschieden. Wenn Sie diesen Parameter nicht angeben, wird der Nutzer nur beim ersten Mal aufgefordert, wenn Ihr Projekt Zugriff anfordert. Weitere Informationen finden Sie unter Erneute Einwilligung einholen.

Folgende Werte sind möglich:

none Keine Authentifizierungs- oder Zustimmungsbildschirme anzeigen. Darf nicht mit anderen Werten angegeben werden.
consent Den Nutzer auffordern, seine Einwilligung zu geben.
select_account Fordern Sie den Nutzer auf, ein Konto auszuwählen.

Beispiel für eine Weiterleitung zum Autorisierungsserver von Google

In der Beispiel-URL unten wird Offlinezugriff (access_type=offline) auf einen Bereich angefordert, der Zugriff auf das YouTube-Konto des Nutzers gewährt. Dabei wird die inkrementelle Autorisierung verwendet, um sicherzustellen, dass das neue Zugriffstoken alle Bereiche abdeckt, für 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, um die Lesbarkeit zu verbessern.

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

Das folgende JavaScript-Snippet zeigt, wie der Autorisierungsablauf in JavaScript ohne die Google APIs-Clientbibliothek für JavaScript initiiert wird. Da dieser OAuth 2.0-Endpunkt kein Cross-Origin Resource Sharing (CORS) unterstützt, wird mit dem Snippet ein Formular erstellt, das die Anfrage an diesen Endpunkt öffnet.

/*
 * 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 den Nutzer auf, seine Einwilligung zu erteilen

In diesem Schritt entscheidet der Nutzer, ob er Ihrer Anwendung den angeforderten Zugriff gewährt. In dieser Phase zeigt Google ein Zustimmungsfenster an, in dem der Name Ihrer Anwendung und die Google API-Dienste, für die sie mit den Autorisierungsdaten des Nutzers Zugriff anfordert, sowie eine Zusammenfassung der zu gewährenden Zugriffsbereiche aufgeführt sind. 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, während sie auf die Antwort des OAuth 2.0-Servers von Google wartet, die angibt, ob Zugriff gewährt wurde. Diese Antwort wird im folgenden Schritt erläutert.

Fehler

Bei Anfragen an den OAuth 2.0-Autorisierungsendpunkt von Google werden möglicherweise Fehlermeldungen für Nutzer angezeigt, anstatt der erwarteten Authentifizierungs- und Autorisierungsabläufe. Häufige Fehlercodes und Lösungsvorschläge:

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 sensible und eingeschränkte Bereiche einschränken kann, bis der Zugriff explizit für Ihre OAuth-Client-ID gewährt wird, finden Sie im Hilfeartikel für Google Workspace-Administratoren Festlegen, welche Apps auf Google Workspace-Daten zugreifen können.

disallowed_useragent

Der Autorisierungsendpunkt wird in einem eingebetteten User-Agent angezeigt, der gemäß den OAuth 2.0-Richtlinien von Google nicht zulässig ist.

iOS- und macOS-Entwickler können diesen Fehler beim Öffnen von Autorisierungsanfragen in WKWebView erhalten. Entwickler sollten stattdessen iOS-Bibliotheken wie Google Log-in für iOS oder AppAuth für iOS 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 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 ist Teil eines Projekts, 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 gestellt wurde, ist für diesen Client nicht autorisiert. Siehe origin_mismatch.

deleted_client

Der OAuth-Client, der zum Senden der Anfrage verwendet wird, wurde gelöscht. Das Löschen kann manuell oder im Fall von nicht verwendeten Clients automatisch erfolgen. Gelöschte Clients können innerhalb von 30 Tagen nach dem Löschen wiederhergestellt werden. Weitere Informationen

invalid_grant

Wenn Sie die inkrementelle Autorisierung verwenden, ist das Token möglicherweise abgelaufen oder wurde für ungültig erklärt. Authentifizieren Sie den Nutzer noch einmal und bitten Sie ihn um seine Einwilligung, um 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 JavaScripts, von dem die Autorisierungsanfrage stammt, stimmen möglicherweise nicht mit einem autorisierten JavaScript-Ursprungs-URI überein, der für die OAuth-Client-ID registriert ist. Prüfen Sie die autorisierten JavaScript-Quellen in der Google Cloud Console auf der Seite „Clients“.

redirect_uri_mismatch

Der in der Autorisierungsanfrage übergebene redirect_uri stimmt nicht mit einem autorisierten Weiterleitungs-URI für die OAuth-Client-ID überein. Prüfen Sie die autorisierten Weiterleitungs-URIs auf der Seite „Clients“ in der Google Cloud Console.

Das Schema, die Domain und/oder der Port des JavaScripts, von dem die Autorisierungsanfrage stammt, stimmen möglicherweise nicht mit einem autorisierten JavaScript-Ursprungs-URI überein, der für die OAuth-Client-ID registriert ist. Prüfen Sie die autorisierten JavaScript-Quellen in der Google Cloud Console auf der Seite „Clients“.

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. Informationen zum Aktualisieren Ihrer Integration 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.
  • Für die Anfrage wird eine Autorisierungsmethode verwendet, 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 die redirect_uri, die 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 in den folgenden Beispielen gezeigt:

  • Eine Zugriffstoken-Antwort:

    https://oauth2.example.com/callback#access_token=4/P7q7W91&token_type=Bearer&expires_in=3600

    Zusätzlich zum Parameter access_token enthält der Fragmentstring auch den Parameter token_type, der immer auf Bearer festgelegt ist, und den Parameter expires_in, der die Lebensdauer des Tokens in Sekunden angibt. Wenn der Parameter state in der Zugriffstokenanfrage angegeben wurde, ist sein Wert ebenfalls 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, die Lesezugriff auf Metadaten für Dateien in Ihrem Google Drive und Lesezugriff auf Ihre Google Kalender-Termine anfordert:

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 in Ihrem Browser zum OAuth 2.0 Playground weitergeleitet, einem Tool zum Testen von OAuth-Vorgängen. Sie werden sehen, dass der OAuth 2.0 Playground den Autorisierungscode automatisch erfasst hat.

Schritt 4: Prüfen, welche Bereiche Nutzer gewährt haben

Wenn Sie mehrere Berechtigungen (Bereiche) anfordern, gewähren Nutzer Ihrer App möglicherweise nicht Zugriff auf alle. In deiner App muss geprüft werden, welche Bereiche tatsächlich gewährt wurden. Außerdem müssen Situationen, in denen einige Berechtigungen verweigert werden, ordnungsgemäß behandelt werden. In der Regel werden dazu die Funktionen deaktiviert, die auf diesen verweigerten Bereichen basieren.

Es gibt allerdings Ausnahmen. Bei Google Workspace Enterprise-Apps mit domainweiter Übertragung von Befugnissen oder Apps, die als Vertrauenswürdig gekennzeichnet sind, wird der Zustimmungsbildschirm für detaillierte Berechtigungen umgangen. Für diese Apps wird Nutzern der Bildschirm für die Einwilligung in detaillierte Berechtigungen nicht angezeigt. Stattdessen erhält Ihre App entweder alle angeforderten Bereiche oder keine.

Weitere Informationen finden Sie unter Umgang mit detaillierten Berechtigungen.

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 Zugriffstoken gewährt werden, ausgedrückt als Liste von durch Leerzeichen getrennten Strings, bei denen die Groß-/Kleinschreibung beachtet wird.

Die folgende Beispielantwort für ein Zugriffstoken zeigt beispielsweise, dass der Nutzer Ihrer Anwendung die Berechtigung erteilt hat, seine YouTube-Videos, -Bewertungen, -Kommentare und -Untertitel 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 damit im Namen eines bestimmten Nutzerkontos Aufrufe an eine Google API senden, sofern die von der API erforderlichen Zugriffsbereiche gewährt wurden. Fügen Sie dazu das Zugriffstoken in eine Anfrage an die API ein, indem Sie entweder einen access_token-Suchparameter oder einen Authorization-HTTP-Header-Bearer-Wert angeben. Wenn möglich, ist der HTTP-Header vorzuziehen, da Abfragestrings in Server-Logs sichtbar sein können. In den meisten Fällen können Sie eine Clientbibliothek verwenden, um Ihre Aufrufe an Google APIs einzurichten (z. B. beim Aufrufen der YouTube Data API).

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.

HTTP-GET-Beispiele

Ein Aufruf des Endpunkts youtube.channels (YouTube Data API) mit dem HTTP-Header Authorization: Bearer könnte so aussehen: Beachten Sie, dass Sie Ihr eigenes Zugriffstoken angeben müssen:

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 Abfragestringparameter 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, in dem die HTTP-Header-Option (bevorzugt) verwendet wird:

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/youtube/v3/channels?part=snippet&mine=true

Oder alternativ die Option für den Abfragestringparameter:

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 mit CORS (Cross-Origin Resource Sharing) eine Anfrage an eine Google API senden. In diesem Beispiel wird die Google APIs-Clientbibliothek für JavaScript nicht verwendet. Auch wenn Sie die Clientbibliothek nicht verwenden, hilft Ihnen der Leitfaden zur CORS-Unterstützung in der Dokumentation dieser Bibliothek wahrscheinlich, 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 senden. Im vollständigen Beispiel wird gezeigt, wie Sie dieses Token im lokalen Speicher des Browsers speichern und bei 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-Vorgang in JavaScript ausführen, ohne die Google API-Clientbibliothek für JavaScript zu verwenden. Der Code ist für eine HTML-Seite, auf der eine Schaltfläche zum Ausprobieren einer API-Anfrage angezeigt wird. Wenn Sie auf die Schaltfläche klicken, wird geprüft, ob die Seite ein API-Zugriffstoken im lokalen Speicher Ihres Browsers gespeichert hat. Wenn ja, wird die API-Anfrage ausgeführt. Andernfalls wird der OAuth 2.0-Vorgang initiiert.

Für den OAuth 2.0-Vorgang werden auf der Seite die folgenden Schritte ausgeführt:

  1. Der Nutzer wird zum OAuth 2.0-Server von Google weitergeleitet, der Zugriff auf den Bereich https://www.googleapis.com/auth/youtube.force-ssl anfordert.
  2. 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 Fragmentbezeichnerstring parst.
  3. Auf der Seite wird geprüft, für welche Bereiche der Nutzer der Anwendung Zugriff gewährt hat.
  4. Wenn der Nutzer Zugriff auf die angeforderten Bereiche gewährt hat, wird auf der Seite das Zugriffstoken verwendet, um die Beispiel-API-Anfrage zu senden.

    Mit dieser API-Anfrage wird die Methode channels.list der YouTube Data API aufgerufen, um Daten zum YouTube-Kanal des autorisierten Nutzers abzurufen.

  5. Wenn die Anfrage erfolgreich ausgeführt wird, wird die API-Antwort in der Debugging-Konsole des Browsers protokolliert.

Du kannst den Zugriff auf die App auf der Seite Berechtigungen für dein Google-Konto widerrufen. Die App wird mit dem Namen aufgeführt, der auf der Branding-Seite im OAuth-Zustimmungsbildschirm bei der Erstellung der Client-ID angegeben wurde.

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 Anmeldedaten für die Autorisierung entsprechen. Die Variable YOUR_REDIRECT_URI sollte auf dieselbe URL festgelegt werden, unter der 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 Cloud Console auf der Seite „Clients“ konfiguriert haben. Wenn dieser Wert nicht mit einem autorisierten URI übereinstimmt, wird der Fehler redirect_uri_mismatch angezeigt. In Ihrem Projekt muss außerdem 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 von Domain, Host und Schema, die in diesen Regeln verwendet werden, finden Sie in RFC 3986, Abschnitt 3.

Validierungsregeln
Schema

JavaScript-Ursprünge müssen das HTTPS-Schema verwenden, nicht einfaches HTTP. Localhost-URIs (einschließlich Localhost-IP-Adress-URIs) sind von dieser Regel ausgenommen.

Moderator:in

Hosts dürfen keine unformatierten IP-Adressen sein. Localhost-IP-Adressen sind von dieser Regel ausgenommen.

Domain
  • Host-TLDs (Top-Level-Domains) müssen zur Public Suffix List gehören.
  • Hostdomains dürfen nicht “googleusercontent.com” sein.
  • JavaScript-Ursprünge dürfen keine URL-Kürzungsdomains (z.B. goo.gl) enthalten, es sei denn, die App ist Inhaber der Domain.
  • Userinfo

    JavaScript-Ursprünge dürfen die Unterkomponente „userinfo“ nicht enthalten.

    Pfad

    JavaScript-Ursprünge dürfen keine Pfadkomponente enthalten.

    Abfrage

    JavaScript-Ursprünge dürfen die Abfragekomponente nicht enthalten.

    Fragment

    JavaScript-Ursprünge dürfen keine Fragmentkomponente enthalten.

    Zeichen JavaScript-Quellen dürfen bestimmte Zeichen nicht enthalten, darunter:
    • Platzhalterzeichen ('*')
    • Nicht druckbare ASCII-Zeichen
    • Ungültige Prozentcodierungen (alle Prozentcodierungen, die nicht der URL-Codierungsform eines Prozentzeichens gefolgt von zwei Hexadezimalziffern entsprechen)
    • Nullzeichen (ein codiertes NULL-Zeichen, z.B. %00, %C0%80)

    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 erst dann anzufordern, wenn sie benötigt werden. Um diese Vorgehensweise zu ermöglichen, unterstützt der Autorisierungsserver von Google die inkrementelle Autorisierung. Mit dieser Funktion können Sie Bereiche nach Bedarf anfordern. Wenn der Nutzer die Berechtigung für den neuen Bereich erteilt, wird ein Autorisierungscode zurückgegeben, der gegen ein Token eingetauscht werden kann, das alle Bereiche enthält, 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 Veranstaltungen ansehen, die Videos bewerten und sie zu Playlists hinzufügen. Nutzer können die App auch verwenden, um Termine in ihren Google-Kalendern hinzuzufügen.

    In diesem Fall benötigt die App bei der Anmeldung möglicherweise keinen Zugriff auf Bereiche und fordert diesen auch nicht an. Wenn der Nutzer jedoch versucht, ein Video zu bewerten, ein Video zu einer Playlist hinzuzufügen oder eine andere YouTube-Aktion auszuführen, kann die App Zugriff auf den Bereich https://www.googleapis.com/auth/youtube.force-ssl anfordern. Ebenso könnte die App den Zugriff auf den Bereich https://www.googleapis.com/auth/calendar anfordern, wenn der Nutzer versucht, einen Kalendertermin hinzuzufügen.

    Für ein Zugriffstoken, das über eine inkrementelle Autorisierung abgerufen wird, gelten die folgenden Regeln:

    • Das Token kann verwendet werden, um auf Ressourcen zuzugreifen, die einem der Bereiche entsprechen, die in die neue, kombinierte Autorisierung einbezogen wurden.
    • Wenn Sie das Aktualisierungstoken für die kombinierte Autorisierung verwenden, um ein Zugriffstoken zu erhalten, steht das Zugriffstoken für die kombinierte Autorisierung und kann für alle in der Antwort enthaltenen scope-Werte verwendet werden.
    • Die kombinierte Autorisierung umfasst alle Bereiche, die der Nutzer dem API-Projekt gewährt hat, auch wenn die Gewährungen von verschiedenen Clients angefordert wurden. Wenn ein Nutzer beispielsweise über den Desktop-Client einer Anwendung Zugriff auf einen Bereich gewährt und dann über einen mobilen Client Zugriff auf einen anderen Bereich derselben Anwendung 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 auf die YouTube Analytics-Daten des Nutzers an, zusätzlich zu allen anderen Zugriffen, die der Nutzer der Anwendung bereits gewährt 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 Bereiche, für die das Zugriffstoken gültig ist, gespeichert. Dazu wird das Attribut oauth2-test-params.scope im lokalen Speicher des Browsers festgelegt.)

    Das Snippet vergleicht die Bereiche, für die das Zugriffstoken gültig ist, mit dem Bereich, den Sie für eine bestimmte Abfrage verwenden möchten. Wenn das Zugriffstoken diesen Bereich nicht abdeckt, wird der OAuth 2.0-Vorgang gestartet. Die Funktion oauth2SignIn ist hier dieselbe wie in Schritt 2 (und wird später im vollständigen Beispiel bereitgestellt).

    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-Widerruf

    In einigen Fällen möchte ein Nutzer möglicherweise den Zugriff einer Anwendung widerrufen. Nutzer können den Zugriff in den Kontoeinstellungen widerrufen. Weitere Informationen finden Sie im Supportdokument Drittanbieter-Websites und ‑Apps mit Zugriff auf Ihr Konto im Abschnitt „Zugriff von 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. Das bedeutet, dass ein Teil des Entfernungsprozesses eine API-Anfrage sein kann, um sicherzustellen, dass die der Anwendung zuvor gewährten Berechtigungen entfernt werden.

    OAuth 2.0-Endpunkte

    Wenn Sie ein Token programmatisch widerrufen möchten, stellt 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 Zugriffstoken oder ein Aktualisierungstoken sein. Wenn das Token ein Zugriffstoken ist und ein entsprechendes Aktualisierungstoken hat, wird das Aktualisierungstoken ebenfalls widerrufen.

    Wenn der Widerruf erfolgreich verarbeitet wurde, lautet der HTTP-Statuscode der Antwort 200. Bei Fehlerbedingungen wird ein HTTP-Statuscode 400 zusammen mit einem Fehlercode zurückgegeben.

    Das folgende JavaScript-Snippet zeigt, wie Sie ein Token in JavaScript widerrufen, ohne die Google APIs-Clientbibliothek für JavaScript zu verwenden. Da der OAuth 2.0-Endpunkt von Google zum Widerrufen von Tokens Cross-Origin Resource Sharing (CORS) nicht unterstützt, wird im Code ein Formular erstellt und an den Endpunkt gesendet, anstatt die Methode XMLHttpRequest() 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 weiterer Schritt, den Sie zum Schutz der Konten Ihrer Nutzer unternehmen sollten, ist die Implementierung des produktübergreifenden Kontoschutzes mithilfe des entsprechenden Google-Dienstes. Mit diesem Dienst können Sie Benachrichtigungen zu Sicherheitsereignissen abonnieren, die Ihre Anwendung über wichtige Änderungen am Nutzerkonto informieren. Anschließend können Sie die Informationen verwenden, um Maßnahmen zu ergreifen, je nachdem, wie Sie auf Ereignisse reagieren möchten.

    Hier einige Beispiele für Ereignistypen, die vom produktübergreifenden Kontoschutz von Google 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 eine vollständige Liste der verfügbaren Ereignisse finden Sie auf der Seite Nutzerkonten mit produktübergreifendem Kontoschutz schützen .