OAuth 2.0 für clientseitige Webanwendungen

In diesem Dokument wird erläutert, wie die OAuth 2.0-Autorisierung implementiert wird, um über eine JavaScript-Webanwendung auf Google APIs 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. Beispielsweise kann eine Anwendung mithilfe von OAuth 2.0 die Berechtigung von Nutzern zum Speichern von Dateien in ihren Google Drive-Ablagen einholen.

Dieser OAuth 2.0-Vorgang wird als impliziter Gewährungsvorgang bezeichnet. Sie ist für Anwendungen gedacht, die nur auf APIs zugreifen, während der Nutzer an der Anwendung ist. Diese Anwendungen können keine vertraulichen Informationen speichern.

In diesem Ablauf öffnet Ihre Anwendung eine Google-URL, die Suchparameter verwendet, um Ihre Anwendung und den Typ des API-Zugriffs zu identifizieren, den die Anwendung benötigt. 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 erteilen. Google leitet den Nutzer dann zurück zu Ihrer Anwendung zurück. Die Weiterleitung enthält ein Zugriffstoken, das Ihre Anwendung bestätigt und dann für API-Anfragen verwendet.

Google API-Clientbibliothek und Google Identity Services

Wenn Sie autorisierte Aufrufe an Google über die Google API-Clientbibliothek für JavaScript ausführen, sollten Sie die JavaScript-Bibliothek der Google Identity Services verwenden, um den OAuth 2.0-Vorgang zu verarbeiten. Weitere Informationen findest du im Tokenmodell der Google Identity Services, das auf dem impliziten OAuth 2.0-Zustimmungsvorgang basiert.

Voraussetzungen

Die APIs für Ihr Projekt aktivieren

Jede Anwendung, die Google APIs aufruft, muss diese APIs in API Consoleaktivieren.

So aktivieren Sie eine API für Ihr Projekt:

  1. Open the API Library in Google API Console.
  2. If prompted, select a project, or create a new one.
  3. Unter API Library werden alle verfügbaren APIs nach Produktfamilie und Beliebtheit gruppiert aufgeführt. Wenn die gewünschte API nicht in der Liste angezeigt wird, verwenden Sie die Suche oder klicken Sie in der zugehörigen Produktfamilie auf Alle ansehen.
  4. Wählen Sie die gewünschte API aus und klicken Sie auf die Schaltfläche Aktivieren.
  5. If prompted, enable billing.
  6. If prompted, read and accept the API's Terms of Service.

Anmeldedaten für die Autorisierung erstellen

Jede Anwendung, die über OAuth 2.0 auf Google APIs zugreift, muss über Anmeldedaten für die Autorisierung verfügen, die die Anwendung beim OAuth 2.0-Server von Google identifizieren. 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 das Projekt aktiviert haben.

  1. Go to the Credentials page.
  2. Klicken Sie auf Anmeldedaten erstellen > OAuth-Client-ID.
  3. Wählen Sie den Anwendungstyp Webanwendung aus.
  4. Füllen Sie es aus. Für Anwendungen, die autorisierte Google API-Anfragen über JavaScript senden, müssen autorisierte JavaScript-Quellen angegeben werden. Die Quellen geben die Domains an, von denen deine Anwendung Anfragen an den OAuth 2.0-Server senden kann. Diese müssen den Validierungsregeln von Google entsprechen.

Zugriffsbereiche identifizieren

Mithilfe von Bereichen kann Ihre Anwendung nur Zugriff auf die Ressourcen anfordern, die sie benötigt. Gleichzeitig ermöglichen sie Nutzern, den Umfang des Zugriffs auf Ihre Anwendung zu steuern. Daher kann es eine umgekehrte Beziehung zwischen der Anzahl der angeforderten Bereiche und der Wahrscheinlichkeit der Einholung der Nutzereinwilligung geben.

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

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 haben, bevor sie eine Google API-Anfrage ausführen kann, die eine Nutzerautorisierung erfordert.

Schritt 1: Zum OAuth 2.0-Server von Google weiterleiten

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

Generiere eine URL, um Zugriff vom OAuth 2.0-Endpunkt von Google unter https://accounts.google.com/o/oauth2/v2/auth anzufordern. Auf diesen Endpunkt kann über HTTPS zugegriffen werden. 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 API Console Credentials page.

redirect_uri Erforderlich

Bestimmt, wohin der API-Server den Nutzer weiterleitet, nachdem er den Autorisierungsvorgang abgeschlossen hat. Der Wert muss genau mit einem der autorisierten Weiterleitungs-URIs für den OAuth 2.0-Client übereinstimmen, den du in der API Console Credentials pagedeines Clients konfiguriert hast. Wenn dieser Wert keinem autorisierten Weiterleitungs-URI für die angegebene client_id entspricht, wird der Fehler redirect_uri_mismatch angezeigt.

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

response_type Erforderlich

JavaScript-Anwendungen müssen den Wert des Parameters auf token setzen. Dieser Wert weist den Google Authorization Server an, das Zugriffstoken als name=value-Paar in der Fragment-ID des URI (#) zurückzugeben, zu dem der Nutzer nach Abschluss der Autorisierung 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 beziehen sich auf den Zustimmungsbildschirm, den Google dem Nutzer anzeigt.

Mithilfe von Bereichen kann Ihre Anwendung nur Zugriff auf die Ressourcen anfordern, die sie benötigt. Gleichzeitig ermöglichen sie Nutzern, den Umfang des Zugriffs auf Ihre Anwendung zu steuern. Daher besteht eine umgekehrte Beziehung zwischen der Anzahl der angeforderten Bereiche und der Wahrscheinlichkeit, die Nutzereinwilligung einzuholen.

Wir empfehlen, dass Ihre Anwendung den Zugriff auf Autorisierungsbereiche nach Möglichkeit im Kontext anfordert. Wenn Sie den Zugriff auf Nutzerdaten im Kontext über eine 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 aufrechtzuerhalten. Nachdem der Nutzer der Zugriffsanfrage Ihrer Anwendung zugestimmt oder sie abgelehnt hat, gibt der Server genau den Wert zurück, den Sie als name=value-Paar in der URL-Fragment-ID (#) der redirect_uri senden.

Sie können diesen Parameter für verschiedene Zwecke verwenden, z. B. zum Weiterleiten des Nutzers zur richtigen Ressource in Ihrer Anwendung, zum Senden von Nonces und zur Vermeidung von websiteübergreifenden Anfragefälschungen. Da Ihr redirect_uri erraten werden kann, lässt sich mit einem state-Wert besser sicherstellen, 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 zu prüfen, ob die Anfrage und die Antwort vom selben Browser stammen. So sind Sie vor Angriffen wie websiteübergreifender Anfragefälschung geschützt. In der Dokumentation zu OpenID Connect finden Sie ein Beispiel zum Erstellen und Bestätigen eines state-Tokens.

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 gewährt wird, deckt das neue Zugriffstoken auch alle Bereiche ab, für die der Nutzer den Anwendungszugriff zuvor gewährt hat. Beispiele finden Sie im Abschnitt Inkrementelle Autorisierung.

login_hint Optional

Wenn Ihre Anwendung weiß, welcher Nutzer sich authentifizieren möchte, kann sie mit diesem Parameter einen Hinweis für den Google-Authentifizierungsserver bereitstellen. Der Server verwendet den Hinweis, um den Anmeldevorgang zu vereinfachen. Dazu füllt er das E-Mail-Feld im Anmeldeformular voraus oder wählt die entsprechende Mehrfachanmeldungssitzung aus.

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

prompt Optional

Eine Liste mit durch Leerzeichen voneinander getrennten Aufforderungen für den Nutzer. Beachten Sie dabei die Groß- und Kleinschreibung. Wenn Sie diesen Parameter nicht angeben, wird der Nutzer nur dann aufgefordert, wenn Ihr Projekt zum ersten Mal Zugriff anfordert. Weitere Informationen finden Sie unter Aufforderung zur erneuten Einwilligung.

Folgende Werte sind möglich:

none Zeigen Sie keine Authentifizierungs- oder Zustimmungsbildschirme an. Darf nicht mit anderen Werten angegeben werden.
consent Nutzer um Einwilligung bitten
select_account Fordern Sie den Nutzer auf, ein Konto auszuwählen.

Beispiel für Weiterleitung zum Autorisierungsserver von Google

Unten sehen Sie eine Beispiel-URL mit Zeilenumbrüchen und Leerzeichen zur besseren Lesbarkeit.

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly&
 include_granted_scopes=true&
 response_type=token&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

Nachdem Sie die Anfrage-URL erstellt haben, leiten Sie den Nutzer an diese URL weiter.

JavaScript-Beispielcode

Das folgende JavaScript-Snippet zeigt, wie du den Autorisierungsvorgang in JavaScript initiieren kannst, ohne die Google APIs-Clientbibliothek für JavaScript zu verwenden. Da dieser OAuth 2.0-Endpunkt Cross-Origin Resource Sharing (CORS) nicht unterstützt, erstellt das Snippet ein Formular, 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/drive.metadata.readonly',
                '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 zur Einwilligung auf

In diesem Schritt entscheidet der Nutzer, ob er Ihrer Anwendung den angeforderten Zugriff gewährt. In dieser Phase zeigt Google ein Einwilligungsfenster an, das den Namen Ihrer Anwendung und die Google API-Dienste enthält, für die die Berechtigung für den Zugriff mit den Autorisierungsanmeldedaten des Nutzers angefordert wird. Außerdem wird eine Zusammenfassung der Zugriffsbereiche angezeigt, die gewährt werden sollen. Der Nutzer kann dann zustimmen, Zugriff auf einen oder mehrere Bereiche zu gewähren, die von Ihrer Anwendung angefordert werden, oder die Anfrage ablehnen.

Deine Anwendung muss in dieser Phase nichts tun, da 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 den Nutzer anstelle der erwarteten Authentifizierungs- und Autorisierungsabläufe angezeigt. Häufige Fehlercodes und Lösungsvorschläge sind unten aufgeführt.

admin_policy_enforced

Mindestens ein angeforderter Bereich kann aufgrund der Richtlinien seines Google Workspace-Administrators nicht mit dem Google-Konto autorisiert werden. Im Hilfeartikel Zugriff externer und interner Apps auf Google Workspace-Daten verwalten finden Sie weitere Informationen dazu, wie ein Administrator den Zugriff auf alle oder vertrauliche und eingeschränkte Bereiche einschränken kann, bis der OAuth-Client-ID explizit Zugriff gewährt wird.

disallowed_useragent

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

Android

Diese Fehlermeldung kann beim Öffnen von Autorisierungsanfragen in android.webkit.WebView für Android-Entwickler angezeigt werden. Entwickler sollten stattdessen Android-Bibliotheken wie Google Log-in für Android oder AppAuth for Android 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 deiner Website zum OAuth 2.0-Autorisierungsendpunkt von Google navigiert. Entwickler sollten zulassen, dass allgemeine Links im standardmäßigen Link-Handler des Betriebssystems geöffnet werden, der sowohl Android-App-Links-Handler als auch die Standard-Browser-App umfasst. Die Bibliothek Benutzerdefinierte Android-Tabs wird ebenfalls unterstützt.

iOS

iOS- und macOS-Entwickler können auf diesen Fehler stoßen, wenn sie Autorisierungsanfragen in WKWebView öffnen. Entwickler sollten stattdessen iOS-Bibliotheken wie Google Log-in für iOS oder AppAuth for iOS von OpenID Foundation verwenden.

Bei Webentwicklern kann dieser Fehler auftreten, wenn eine iOS- oder macOS-App einen allgemeinen Weblink in einem eingebetteten User-Agent öffnet und ein Nutzer von deiner Website zum OAuth 2.0-Autorisierungsendpunkt von Google navigiert. Entwickler sollten zulassen, dass allgemeine Links im standardmäßigen Link-Handler des Betriebssystems geöffnet werden, der sowohl Universal-Links-Handler oder die Standard-Browser-App umfasst. 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 zum Einrichten des OAuth-Zustimmungsbildschirms im Abschnitt Nutzertyp.

invalid_client

Der Ursprung, von dem die Anfrage stammt, ist für diesen Client nicht autorisiert. Weitere Informationen finden Sie unter origin_mismatch.

invalid_grant

Bei Verwendung der inkrementellen Autorisierung ist das Token möglicherweise abgelaufen oder ungültig. Authentifizieren Sie den Nutzer noch einmal und bitten Sie ihn um seine Einwilligung, um neue Tokens zu erhalten. Wenn dieser Fehler weiterhin angezeigt wird, prüfen Sie, ob Ihre Anwendung richtig konfiguriert wurde und 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, 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üfe die autorisierten JavaScript-Quellen in Google API Console Credentials page.

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 in Google API Console Credentials page.

Das Schema, die Domain und/oder der Port des JavaScript-Codes, 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. Autorisierte JavaScript-Quellen findest du in der Google API Console Credentials page.

Der redirect_uri-Parameter kann sich auf den OAuth-Out-of-Band-Vorgang (OOB) beziehen, der eingestellt wurde und nicht mehr unterstützt wird. Informationen zum Aktualisieren der Integration findest du in der Migrationsanleitung.

invalid_request

Mit Ihrer Anfrage ist ein Fehler aufgetreten. Dafür kann es mehrere Gründe geben:

  • Die Anfrage war nicht richtig formatiert
  • In der Anfrage fehlten erforderliche Parameter
  • In der Anfrage wird eine Autorisierungsmethode verwendet, die nicht von Google unterstützt wird. Prüfen, ob für die 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 Zugriffstoken-Anfrage 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 wie unten dargestellt als Hash-Fragment des Weiterleitungs-URI zurückgegeben:

  • 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 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, die Lesezugriff zum Anzeigen von Metadaten für Dateien in Google Drive anfordert:

https://accounts.google.com/o/oauth2/v2/auth?
 scope=https%3A//www.googleapis.com/auth/drive.metadata.readonly&
 include_granted_scopes=true&
 response_type=token&
 state=state_parameter_passthrough_value&
 redirect_uri=https%3A//oauth2.example.com/code&
 client_id=client_id

Nach Abschluss des OAuth 2.0-Vorgangs werden Sie zu http://localhost/oauth2callback weitergeleitet. Diese URL gibt den Fehler 404 NOT FOUND zurück, es sei denn, Ihr lokaler Rechner stellt unter dieser Adresse eine Datei bereit. Der nächste Schritt enthält weitere Details zu den Informationen, die im URI zurückgegeben werden, wenn der Nutzer zu Ihrer Anwendung zurückgeleitet wird.

Google APIs aufrufen

OAuth 2.0-Endpunkte

Nachdem Ihre Anwendung ein Zugriffstoken abgerufen hat, können Sie mit dem Token im Namen eines bestimmten Nutzerkontos eine Google API aufrufen, sofern die für die API erforderlichen Zugriffsbereiche gewährt wurden. Fügen Sie dazu das Zugriffstoken in eine Anfrage an die API ein. Dazu verwenden Sie entweder den Abfrageparameter access_token oder den Bearer-Wert eines Authorization-HTTP-Headers. Wenn möglich, ist der HTTP-Header zu bevorzugen, da Abfragestrings in Serverlogs in der Regel sichtbar sind. In den meisten Fällen können Sie die Aufrufe von Google APIs mithilfe einer Clientbibliothek einrichten, z. B. beim Aufrufen der Drive Files API.

Sie können alle Google APIs testen und deren Bereiche im OAuth 2.0 Playground ansehen.

HTTP GET-Beispiele

Ein Aufruf des Endpunkts drive.files (die Drive Files API) mit dem HTTP-Header Authorization: Bearer könnte so aussehen. Sie müssen ein eigenes Zugriffstoken angeben:

GET /drive/v2/files 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/drive/v2/files?access_token=access_token

Beispiele für curl

Sie können diese Befehle mit der curl-Befehlszeilenanwendung testen. Hier ist ein Beispiel, in dem die HTTP-Header-Option (bevorzugt) verwendet wird:

curl -H "Authorization: Bearer access_token" https://www.googleapis.com/drive/v2/files

Alternativ können Sie folgende Parameteroption für den Abfragestring verwenden:

curl https://www.googleapis.com/drive/v2/files?access_token=access_token

JavaScript-Beispielcode

Das folgende Code-Snippet zeigt, wie mithilfe von CORS (Cross-Origin Resource Sharing) eine Anfrage an eine Google API gesendet wird. In diesem Beispiel wird die Google APIs-Clientbibliothek für JavaScript nicht verwendet. Selbst wenn Sie die Clientbibliothek nicht verwenden, wird Ihnen der CORS-Supportleitfaden in der Dokumentation dieser Bibliothek wahrscheinlich helfen, diese Anfragen besser zu verstehen.

In diesem Code-Snippet stellt die Variable access_token das Token dar, das Sie erhalten haben, um im Namen des autorisierten Nutzers API-Anfragen zu stellen. Das vollständige Beispiel zeigt, wie dieses Token im lokalen Speicher des Browsers gespeichert und bei einer API-Anfrage abgerufen wird.

var xhr = new XMLHttpRequest();
xhr.open('GET',
    'https://www.googleapis.com/drive/v3/about?fields=user&' +
    'access_token=' + params['access_token']);
xhr.onreadystatechange = function (e) {
  console.log(xhr.response);
};
xhr.send(null);

Vollständiges Beispiel

OAuth 2.0-Endpunkte

Dieses Codebeispiel zeigt, wie der OAuth 2.0-Vorgang in JavaScript ausgeführt wird, ohne die Google APIs-Clientbibliothek für JavaScript zu verwenden. Der Code bezieht sich auf eine HTML-Seite, auf der eine Schaltfläche zum Testen einer API-Anfrage angezeigt wird. Wenn du auf die Schaltfläche klickst, prüft der Code, ob die Seite ein API-Zugriffstoken im lokalen Speicher deines Browsers gespeichert hat. Ist dies der Fall, wird die API-Anfrage ausgeführt. Andernfalls wird der OAuth 2.0-Vorgang initiiert.

Für den OAuth 2.0-Vorgang werden auf dieser Seite folgende Schritte ausgeführt:

  1. Der Nutzer wird an den OAuth 2.0-Server von Google weitergeleitet, der Zugriff auf den Bereich https://www.googleapis.com/auth/drive.metadata.readonly 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 String der Fragment-ID parst.
  3. Die Seite verwendet das Zugriffstoken für die Beispiel-API-Anfrage.

    Die API-Anfrage ruft die Methode about.get der Drive API auf, um Informationen zum Google Drive-Konto des autorisierten Nutzers abzurufen.

  4. Wenn die Anfrage erfolgreich ausgeführt wird, wird die API-Antwort in der Fehlerbehebungskonsole des Browsers protokolliert.

Du kannst den Zugriff auf die App auf der Seite Berechtigungen für dein Google-Konto widerrufen. Die App wird als OAuth 2.0 Demo for Google API Docs 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 Autorisierungsdaten entsprechen. Für die Variable YOUR_REDIRECT_URI muss 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 du in der API Console Credentials pagekonfiguriert hast. Wenn dieser Wert mit keinem autorisierten URI übereinstimmt, wird der Fehler redirect_uri_mismatch angezeigt. Außerdem muss für Ihr Projekt 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';
  var fragmentString = location.hash.substring(1);

  // Parse query string to see if page request is coming from OAuth 2.0 server.
  var params = {};
  var regex = /([^&=]+)=([^&]*)/g, m;
  while (m = regex.exec(fragmentString)) {
    params[decodeURIComponent(m[1])] = decodeURIComponent(m[2]);
  }
  if (Object.keys(params).length > 0) {
    localStorage.setItem('oauth2-test-params', JSON.stringify(params) );
    if (params['state'] && params['state'] == 'try_sample_request') {
      trySampleRequest();
    }
  }

  // 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/drive/v3/about?fields=user&' +
          '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() {
    // 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/drive.metadata.readonly',
                  'state': 'try_sample_request',
                  '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-Ursprung

Google wendet die folgenden Validierungsregeln auf JavaScript-Quellen an, um Entwickler dabei zu unterstützen, ihre Anwendungen zu schützen. Ihre JavaScript-Quellen müssen diese Regeln einhalten. Die Definition von Domain, Host und Schema finden Sie unter RFC 3986, Abschnitt 3.

Validierungsregeln
Schema

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

Organisator

Hosts können keine unformatierten IP-Adressen sein. Localhost-IP-Adressen sind von dieser Regel ausgenommen.

Domain
  • Host-TLDs (Top-Level-Domains) müssen zur öffentlichen Suffixliste gehören.
  • Hostdomains dürfen nicht “googleusercontent.com” sein.
  • JavaScript-Quellen dürfen keine Domains mit Kurz-URL-Unterstützung (z.B. goo.gl) enthalten, sofern die Domain nicht der App gehört.
  • Nutzerinformationen

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

    Pfad

    JavaScript-Quellen dürfen die Pfadkomponente nicht enthalten.

    Abfrage

    JavaScript-Quellen dürfen die Abfragekomponente nicht enthalten.

    Fragment

    JavaScript-Quellen dürfen die Fragment-Komponente nicht enthalten.

    Zeichen JavaScript-Quellen dürfen folgende Zeichen nicht enthalten:
    • 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 Anwendung die Autorisierung für den Zugriff auf Ressourcen an, die durch Bereiche gekennzeichnet sind. Es gilt als Best Practice, für Ressourcen dann eine Autorisierung anzufordern, wenn Sie sie benötigen. Um diese Vorgehensweise zu ermöglichen, unterstützt der Autorisierungsserver von Google die inkrementelle Autorisierung. Mit diesem Feature können Sie Bereiche bei Bedarf anfordern. Wenn der Nutzer die Berechtigung für den neuen Bereich erteilt, wird ein Autorisierungscode zurückgegeben, der möglicherweise gegen ein Token ausgetauscht wird, das alle Bereiche enthält, die der Nutzer dem Projekt gewährt hat.

    Beispiel: Eine App, mit der Nutzer Musiktitel abspielen und Mixe erstellen können, benötigt bei der Anmeldung möglicherweise nur sehr wenige Ressourcen – unter Umständen nur den Namen der Person, die sich anmeldet. Um jedoch einen fertigen Mix zu speichern, wäre Zugriff auf Google Drive des Nutzers erforderlich. Die meisten Nutzer würden es ganz normal finden, wenn sie nur dann Zugriff auf ihr Google Drive-Konto anfordern würden, als die App diesen tatsächlich benötigt.

    In diesem Fall fordert die Anwendung bei der Anmeldung möglicherweise die Bereiche openid und profile an, um eine einfache Anmeldung durchzuführen. Später fordert die Anwendung dann bei der ersten Anfrage den Bereich https://www.googleapis.com/auth/drive.file an, um eine Kombination zu speichern.

    Die folgenden Regeln gelten für ein Zugriffstoken, das über eine inkrementelle Autorisierung abgerufen wurde:

    • Mit dem Token kann auf Ressourcen zugegriffen werden, die einem der Bereiche in der neuen kombinierten Autorisierung entsprechen.
    • Wenn Sie das Aktualisierungstoken für die kombinierte Autorisierung verwenden, um ein Zugriffstoken zu erhalten, stellt das Zugriffstoken die kombinierte Autorisierung dar und kann für jeden der scope-Werte in der Antwort verwendet werden.
    • Die kombinierte Autorisierung umfasst alle Bereiche, die der Nutzer dem API-Projekt gewährt hat, auch wenn die Erteilungen von verschiedenen Clients angefordert wurden. Wenn ein Nutzer beispielsweise über den Desktopclient einer Anwendung Zugriff auf einen Bereich gewährt und dann derselben Anwendung über einen mobilen Client einen anderen Bereich zuweist, 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 einem vorhandenen Zugriffstoken Bereiche hinzugefügt werden. So muss Ihre Anwendung nicht mehrere Zugriffstokens verwalten.

    OAuth 2.0-Endpunkte

    Wenn du einem vorhandenen Zugriffstoken Bereiche hinzufügen möchtest, füge den Parameter include_granted_scopes in deine Anfrage an den OAuth 2.0-Server von Google ein.

    Das folgende Code-Snippet zeigt, wie das funktioniert. Das Snippet geht davon aus, 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 gespeichert, für die das Zugriffstoken gültig ist. 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, beginnt der OAuth 2.0-Vorgang. Hier ist die Funktion oauth2SignIn dieselbe wie in Schritt 2 (und wird später im vollständigen Beispiel bereitgestellt).

    var SCOPE = 'https://www.googleapis.com/auth/drive.metadata.readonly';
    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

    Es kann vorkommen, dass ein Nutzer den Zugriff einer App widerrufen möchte. Ein Nutzer kann den Zugriff in den Kontoeinstellungen widerrufen. Weitere Informationen findest du im Supportdokument Website- oder App-Zugriff auf Websites und Apps von Drittanbietern mit Zugriff auf dein Konto entfernen.

    Eine Anwendung kann auch den ihr gewährten Zugriff programmatisch widerrufen. Ein programmatischer Widerruf ist wichtig, wenn ein Nutzer das Abo beendet, eine Anwendung entfernt oder sich die für eine Anwendung erforderlichen API-Ressourcen erheblich geändert haben. Mit anderen Worten: Ein Teil des Entfernungsprozesses kann eine API-Anfrage beinhalten, mit der sichergestellt wird, 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 Zugriffstoken oder ein Aktualisierungstoken sein. Wenn das Token ein Zugriffstoken ist und ein entsprechendes Aktualisierungstoken vorhanden ist, wird auch das Aktualisierungstoken widerrufen.

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

    Das folgende JavaScript-Snippet zeigt, wie ein Token in JavaScript widerrufen wird, 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 mit dem Code ein Formular erstellt und das Formular an den Endpunkt gesendet, anstatt die Anfrage mit der Methode XMLHttpRequest() zu senden.

    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();
    }