OAuth 2.0 für clientseitige Webanwendungen

In diesem Dokument wird erläutert, wie die OAuth 2.0-Autorisierung für den Zugriff implementiert wird. Google APIs über eine JavaScript-Webanwendung erstellen und verwalten. Mit OAuth 2.0 können Nutzer bestimmte Daten für eine Anwendung freigeben und gleichzeitig ihre Nutzernamen, Passwörter und andere Daten dass die Daten privat bleiben. Eine Anwendung kann beispielsweise OAuth 2.0 verwenden, um die Berechtigung von Nutzern erlauben, Dateien in ihren Google Drive-Ablagen zu speichern.

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

Bei diesem Ablauf öffnet Ihre App eine Google-URL, die Ihre App mithilfe von Suchparametern identifiziert. und die Art des API-Zugriffs, den die App benötigt. Du kannst die URL im aktuellen Browser öffnen oder ein 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 App. Die Weiterleitung enthält ein Zugriffstoken, die Ihre Anwendung verifiziert und verwendet, um API-Anfragen zu senden.

Google APIs-Clientbibliothek und Google Identity Services

Sie verwenden die Google API-Clientbibliothek für JavaScript. verwenden, um autorisierte Anrufe an Google zu tätigen, sollten Sie JavaScript-Bibliothek von Google Identity Services zur Verarbeitung des OAuth 2.0-Vorgangs. Bitte wenden Sie sich an Google Identity Services Tokenmodell, das basierend auf dem impliziten OAuth 2.0-Grant-Vorgang.

Vorbereitung

Die APIs für Ihr Projekt aktivieren

Jede Anwendung, die Google APIs aufruft, muss diese APIs im API Console

So aktivieren Sie eine API für Ihr Projekt:

  1. Open the API Library in der Google API Console.
  2. If prompted, select a project, or create a new one.
  3. Unter API Library sind alle verfügbaren APIs nach Produkt gruppiert aufgeführt. Familie und Beliebtheit. Wenn die gewünschte API nicht in der Liste angezeigt wird, verwenden Sie die Suche, um suchen oder in der zugehörigen Produktfamilie auf Alle ansehen klicken.
  4. Wählen Sie die gewünschte API aus und klicken Sie dann 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 OAuth 2.0 für den Zugriff auf Google APIs verwendet, muss über Anmeldedaten zur Autorisierung verfügen. über die 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 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. Anwendungen, die JavaScript für autorisierte Google API-Anfragen verwenden muss autorisierte JavaScript-Quellen angeben. Die Ursprünge geben die Domains aus über den Ihre Anwendung Anfragen an den OAuth 2.0-Server senden kann. Diese Quellen müssen den den Validierungsregeln von Google entsprechen.

Zugriffsbereiche identifizieren

Mithilfe von Bereichen kann Ihre Anwendung nur Zugriff auf die benötigten Ressourcen anfordern. So können Nutzer den Umfang des Zugriffs, den sie auf Ihre Anwendung gewähren, steuern. Das heißt, es gibt kann eine inverse Beziehung zwischen der Anzahl der angeforderten Zugriffsbereiche und der Wahrscheinlichkeit Einholen der Nutzereinwilligung

Bevor Sie mit der Implementierung der OAuth 2.0-Autorisierung beginnen, sollten Sie die Bereiche identifizieren auf die deine App eine Zugriffsberechtigung benötigt.

Das Dokument OAuth 2.0 API-Bereiche enthält eine vollständige eine Liste der Bereiche, die Sie für den Zugriff auf Google APIs verwenden können.

OAuth 2.0-Zugriffstokens abrufen

Die folgenden Schritte zeigen, wie Ihre Anwendung mit dem OAuth 2.0-Server von Google interagiert, um Zustimmung des Nutzers, eine API-Anfrage im Namen des Nutzers auszuführen. Ihre App muss über Folgendes verfügen: Einwilligung erteilen, bevor eine Google API-Anfrage ausgeführt werden kann, die eine Nutzerautorisierung erfordert.

Schritt 1: Weiterleitung zum OAuth 2.0-Server von Google

Um die Berechtigung für den Zugriff auf die Daten eines Nutzers anzufordern, leiten Sie den Nutzer an OAuth 2.0 von Google weiter Server.

OAuth 2.0-Endpunkte

Generiere eine URL, um den Zugriff vom OAuth 2.0-Endpunkt von Google unter https://accounts.google.com/o/oauth2/v2/auth Auf diesen Endpunkt kann über HTTPS zugegriffen werden. Einfache HTTP-Verbindungen werden abgelehnt.

Der Google-Autorisierungsserver unterstützt die folgenden Abfragestringparameter für das Web Serveranwendungen:

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 der Nutzer das Autorisierungsablauf. Der Wert muss genau mit einem der autorisierten Weiterleitungs-URIs für den OAuth 2.0-Client, den Sie im Client API Console Credentials page. Stimmt dieser Wert nicht mit einem autorisierten Weiterleitungs-URI für die angegebene client_id erhalten Sie eine redirect_uri_mismatch Fehler.

Beachten Sie, dass das Schema http oder https, die Groß-/Kleinschreibung und der nachgestellte Schrägstrich ('/') müssen übereinstimmen.

response_type Erforderlich

In JavaScript-Anwendungen muss der Wert des Parameters auf token gesetzt werden. Dieses weist den Google-Autorisierungsserver an, das Zugriffstoken als name=value-Paar in der Fragment-ID des URI (#), zu dem Der Nutzer wird nach Abschluss des Autorisierungsvorgangs weitergeleitet.

scope Erforderlich

A durch Leerzeichen getrennt Liste mit Bereichen zur Identifizierung der Ressourcen, auf die Ihre Anwendung im im Namen des Nutzers. Diese Werte bilden die Grundlage für den Zustimmungsbildschirm, den Google den Nutzern anzeigt. Nutzer.

Mit Bereichen kann Ihre Anwendung nur Zugriff auf die benötigten Ressourcen anfordern Gleichzeitig können die Nutzer steuern, wie viel Zugriff sie auf Ihre . Daher besteht eine inverse Beziehung zwischen der Anzahl der angeforderten Bereiche und wie wahrscheinlich es ist, Nutzereinwilligungen einzuholen.

Wir empfehlen, dass Ihre Anwendung Zugriff auf Autorisierungsbereiche im Kontext anfordert wenn möglich. Indem der Zugriff auf Nutzerdaten im Kontext angefordert wird, über inkrementelle Autorisierung können Sie den Nutzern warum Ihre Anwendung den angeforderten Zugriff benötigt.

state Empfohlen

Gibt einen String-Wert an, mit dem Ihre Anwendung den Status zwischen Ihren Autorisierungsanfrage und die Antwort des Autorisierungsservers. Der Server gibt genau den Wert zurück, den Sie als name=value-Paar im URL-Fragment-ID (#) der redirect_uri, nachdem der Nutzer den Nutzungsbedingungen Ihrer Anwendung zugestimmt oder abgelehnt hat Zugriffsanforderung.

Sie können diesen Parameter für verschiedene Zwecke verwenden, z. B. um den Nutzer zum richtige Ressource in Ihrer Anwendung zu finden, Nonces zu senden und websiteübergreifende Anfragen zu reduzieren Fälschung. Da Ihr redirect_uri erraten werden kann, verwenden Sie einen state können Sie sicher sein, dass eine eingehende Verbindung das Ergebnis eines Authentifizierungsanfrage an. Wenn Sie einen zufälligen String generieren oder den Hash eines Cookies oder einen anderen Wert, der den Status des Clients erfasst, können Sie die Antwort auf Außerdem muss sichergestellt werden, dass Anfrage und Antwort aus demselben Browser stammen. und bietet Schutz vor Angriffen wie websiteübergreifende Anfrage Fälschung. Weitere Informationen finden Sie in der OpenID Connect Dokumentation mit einem Beispiel zum Erstellen und Bestätigen eines state-Tokens.

<ph type="x-smartling-placeholder">
include_granted_scopes Optional

Ermöglicht es Anwendungen, die inkrementelle Autorisierung zu nutzen, um Zugriff auf zusätzliche Bereiche im Kontext. Wenn Sie den Wert dieses Parameters auf true setzen und das Attribut Autorisierungsanfrage gewährt wurde, deckt das neue Zugriffstoken auch alle Bereiche ab, die der Nutzer der Anwendung zuvor Zugriff gewährt hat. Weitere Informationen finden Sie in der inkrementelle Autorisierung.

login_hint Optional

Wenn Ihre Anwendung weiß, welcher Nutzer sich authentifizieren möchte, kann sie diesen Parameter verwenden ein, um dem Google-Authentifizierungsserver einen Hinweis zu geben. Der Server verwendet den Hinweis, den Anmeldevorgang zu vereinfachen, indem Sie entweder das E-Mail-Feld im Anmeldeformular vorab ausfüllen oder die entsprechende Mehrfachanmeldung aus.

Legen Sie als Parameterwert eine E-Mail-Adresse oder sub-Kennung fest. mit der Google-ID des Nutzers übereinstimmen.

prompt Optional

Eine durch Leerzeichen getrennte Liste von Eingabeaufforderungen, die dem Nutzer angezeigt werden. Beachten Sie dabei die Groß- und Kleinschreibung. Wenn Sie keine Wenn Sie diesen Parameter angeben, wird der Nutzer nur beim ersten Mal zur Ausführung Ihres Projekts aufgefordert. fordert Zugriff an. Weitere Informationen finden Sie unter . Bitte um die erneute Einwilligung.

Folgende Werte sind möglich:

none Keine Authentifizierungs- oder Zustimmungsbildschirme anzeigen. Darf nicht angegeben werden mit andere Werte.
consent Den Nutzer um seine Einwilligung bitten.
select_account Nutzer auffordern, ein Konto auszuwählen

Beispiel für eine Weiterleitung zum Autorisierungsserver von Google

Im Folgenden 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 dorthin weiter.

JavaScript-Beispielcode

Das folgende JavaScript-Snippet zeigt, wie der Autorisierungsvorgang in JavaScript verwenden, ohne die Google APIs-Clientbibliothek für JavaScript zu verwenden. Da dieser OAuth 2.0-Endpunkt unterstützt Cross-Origin Resource Sharing (CORS) nicht, das Snippet erstellt ein 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ähren möchte. In dieser angezeigt wird, zeigt Google ein Einwilligungsfenster an, in dem der Name Ihrer Anwendung und die Google API für die er die Berechtigung anfordert, mit den Anmeldedaten des Nutzers und Eine Zusammenfassung der Zugriffsbereiche, die gewährt werden sollen. Die kann der Nutzer zustimmen, um Zugriff auf einen oder mehrere Bereiche zu gewähren, die von Ihrer Anwendung angefordert oder die Anfrage ablehnen.

Ihre Anwendung muss in dieser Phase nichts weiter tun, da sie auf die Antwort von OAuth 2.0-Server von Google gibt an, ob Zugriff gewährt wurde. Diese Antwort wird in folgenden Schritt ausführen.

Fehler

Bei Anfragen an den OAuth 2.0-Autorisierungsendpunkt von Google können nutzerseitige Fehlermeldungen angezeigt werden statt der erwarteten Authentifizierungs- und Autorisierungsabläufe. Häufige Fehlercodes und Vorschläge Lösungen finden Sie unten.

admin_policy_enforced

Das Google-Konto kann einen oder mehrere Bereiche, die aufgrund der Richtlinien von angefordert werden, nicht autorisieren. Ihrem Google Workspace-Administrator. Google Workspace-Admin-Hilfeartikel lesen <ph type="x-smartling-placeholder"></ph> Festlegen, welche Drittanbieter- und Interne Apps greifen auf Google Workspace-Daten zu. finden Sie weitere Informationen dazu, wie ein Administrator den Zugriff auf alle Bereiche oder vertrauliche und eingeschränkten Bereichen, bis ausdrücklich Zugriff auf Ihre OAuth-Client-ID gewährt wird.

disallowed_useragent

Der Autorisierungsendpunkt wird in einem eingebetteten User-Agent angezeigt, der vom OAuth 2.0-Richtlinien

Android

Android-Entwicklern kann diese Fehlermeldung angezeigt werden, wenn sie Autorisierungsanfragen in android.webkit.WebView Entwickler sollten stattdessen Android-Bibliotheken wie Google Log-in für Android oder OpenID Foundation AppAuth für Android

Bei Webentwicklern kann dieser Fehler auftreten, wenn eine Android-App einen allgemeinen Weblink in einem eingebetteter User-Agent und ein Nutzer navigiert von Googles OAuth 2.0-Autorisierungsendpunkt für Ihre Website. Entwickler sollten das Öffnen allgemeiner Links im Standard-Link-Handler der Betriebssystem, das sowohl Android-App-Links oder der Standard-Browser-App. Die Benutzerdefinierte Tabs für Android ist ebenfalls eine unterstützte Option.

iOS

Bei iOS- und macOS-Entwicklern kann dieser Fehler auftreten, wenn Autorisierungsanfragen in WKWebView Entwickler sollten stattdessen iOS-Bibliotheken wie Google Log-in für iOS oder OpenID Foundation AppAuth für iOS

Bei Webentwicklern kann dieser Fehler auftreten, wenn eine iOS- oder macOS-App einen allgemeinen Weblink in einem eingebetteten User-Agent und ein Nutzer navigiert von Googles OAuth 2.0-Autorisierungsendpunkt für Ihre Website. Entwickler sollten das Öffnen allgemeiner Links im Standard-Link-Handler der Betriebssystem, das sowohl Universelle Links oder der Standard-Browser-App. Die SFSafariViewController 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 einem spezifisch <ph type="x-smartling-placeholder"></ph> Google Cloud-Organisation. Weitere Informationen zu dieser Konfigurationsoption finden Sie in der Nutzertyp im Hilfeartikel OAuth-Zustimmungsbildschirm einrichten.

invalid_client

Der Ursprung, von dem die Anfrage gesendet wurde, 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 für ungültig erklärt wurden. Authentifizieren Sie den Nutzer noch einmal und bitten Sie um seine Einwilligung, um neue Tokens zu erhalten. Wenn Sie fortfahren um diesen Fehler anzuzeigen, vergewissern Sie sich, dass Ihre Anwendung richtig konfiguriert ist und Verwenden Sie in Ihrer Anfrage die richtigen Tokens und Parameter. Andernfalls hat das Nutzerkonto möglicherweise gelöscht oder deaktiviert wurden.

origin_mismatch

Das Schema, die Domain und/oder der Port des JavaScript-Codes, von dem die Autorisierungsanfrage stammt, Sie entsprechen einem autorisierten JavaScript-Ursprungs-URI, der für die OAuth-Client-ID registriert ist. Überprüfung autorisiert JavaScript-Quellen in Google API Console Credentials page.

redirect_uri_mismatch

Die in der Autorisierungsanfrage übergebene redirect_uri stimmt mit keinem autorisierten Weiterleitungs-URI für die OAuth-Client-ID. Überprüfen Sie die autorisierten Weiterleitungs-URIs in der Google API Console Credentials page

Das Schema, die Domain und/oder der Port des JavaScript-Codes, von dem die Autorisierungsanfrage stammt, Sie entsprechen einem autorisierten JavaScript-Ursprungs-URI, der für die OAuth-Client-ID registriert ist. Überprüfen autorisierte JavaScript-Quellen in der Google API Console Credentials page

Der Parameter redirect_uri kann sich auf den OAuth-Out-of-Band-Vorgang (OOB) beziehen, der eine und wird nicht mehr unterstützt. Weitere Informationen finden Sie im Migrationsanleitung, um Ihre

invalid_request

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

  • Die Anfrage war nicht richtig formatiert
  • In der Anfrage fehlen erforderliche Parameter
  • In der Anfrage wird eine Autorisierungsmethode verwendet, die von Google nicht unterstützt wird. OAuth bestätigen Für die Integration wird eine empfohlene Integrationsmethode verwendet.

Schritt 3: Die Antwort des OAuth 2.0-Servers verarbeiten

OAuth 2.0-Endpunkte

Der OAuth 2.0-Server sendet eine Antwort an die redirect_uri, die in deinem Zugriffs-Token-Anforderung

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 wird im Hash-Fragment des Weiterleitungs-URI wie unten dargestellt 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 enthält den Parameter token_type, der immer auf Bearer und dem Parameter expires_in, der die Lebensdauer des Tokens in Sekunden. Wenn der Parameter state angegeben wurde in der Zugriffstokenanfrage enthält, 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 Vorgang testen, indem Sie auf die folgende Beispiel-URL klicken, die Anfragen Lesezugriff auf Metadaten für Dateien in Google Drive:

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 weitergeleitet zu http://localhost/oauth2callback Diese URL liefert ein 404 NOT FOUND-Fehler, es sei denn, Ihr lokaler Computer stellt zufällig eine Datei bereit diese Adresse. Im nächsten Schritt erhalten Sie weitere Details zu den im URI, wenn der Nutzer zu Ihrer Anwendung zurückgeleitet wird.

Google APIs aufrufen

OAuth 2.0-Endpunkte

Nachdem Ihre Anwendung ein Zugriffstoken erhalten hat, können Sie mit diesem Token Aufrufe an eine Google API für eine bestimmte Nutzerkonto, wenn die von der API erforderlichen Zugriffsbereiche gewährt wurden. Fügen Sie dazu Das Zugriffstoken in einer Anfrage an die API durch Einfügen einer access_token-Abfrage oder einen Bearer-Wert für den Authorization-HTTP-Header. Wenn möglich, der HTTP-Header ist zu bevorzugen, da Abfragezeichenfolgen in Serverprotokollen in der Regel sichtbar sind. In den meisten können Sie Aufrufe von Google APIs mithilfe einer Clientbibliothek einrichten (z. B. Drive Files API aufrufen.

Sie können alle Google APIs ausprobieren und ihre Bereiche auf der OAuth 2.0 Playground.

Beispiele für HTTP GET

Ein Aufruf an die <ph type="x-smartling-placeholder"></ph> drive.files. (die Drive Files API) über Authorization: Bearer-HTTP könnte wie folgt aussehen. Beachten Sie, dass Sie Ihr eigenes Zugriffstoken angeben müssen:

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 mithilfe der access_token Abfragestringparameter:

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 mit HTTP-Header-Option (bevorzugt):

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

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

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

JavaScript-Beispielcode

Das Code-Snippet unten zeigt, wie CORS (Cross-Origin Resource Sharing) zum Senden eines an eine Google API senden. In diesem Beispiel wird nicht die Google APIs-Clientbibliothek für JavaScript verwendet. Aber auch wenn Sie die Clientbibliothek nicht verwenden, CORS-Supportleitfaden in der Dokumentation der Bibliothek ist wahrscheinlich hilfreich. um diese Anfragen besser zu verstehen.

In diesem Code-Snippet steht die Variable access_token für das Token, Zugriff erhalten, um im Namen des autorisierten Nutzers API-Anfragen zu stellen. Das vollständige Beispiel zeigt, wie Sie dieses Token im lokalen Speicher des Browsers speichern und abrufen. wenn Sie eine API-Anfrage stellen.

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 den Google APIs-Clientbibliothek für JavaScript Der Code ist für eine HTML-Seite bestimmt, die eine Schaltfläche versuchen Sie es mit einer API-Anfrage. Wenn Sie auf die Schaltfläche klicken, prüft der Code, ob auf der Seite ein API-Zugriffstoken im lokalen Speicher Ihres Browsers. Falls ja, wird die API-Anfrage ausgeführt. Andernfalls wird der OAuth 2.0-Vorgang initiiert.

Für den OAuth 2.0-Vorgang sind auf der Seite die folgenden Schritte auszuführen:

  1. Sie leitet den Nutzer zum OAuth 2.0-Server von Google weiter, der Zugriff auf den https://www.googleapis.com/auth/drive.metadata.readonly Bereich.
  2. Nachdem der Nutzer Zugriff auf einen oder mehrere angeforderte Bereiche gewährt (oder verweigert) hat, wird er an folgende URL weitergeleitet: Die Originalseite, die das Zugriffstoken aus dem String der Fragment-ID analysiert.
  3. Auf der Seite wird das Zugriffstoken verwendet, um die Beispiel-API-Anfrage zu erstellen.

    In der API-Anfrage wird die about.get-Methode der Drive API aufgerufen, um Informationen zum Google Drive-Konto des autorisierten Nutzers.

  4. Wenn die Anfrage erfolgreich ausgeführt wird, wird die API-Antwort im Debugging-Tool des Browsers protokolliert. .

Du kannst den Zugriff auf die App über die Berechtigungen für Ihr Google-Konto. Die Anwendung 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 YOUR_CLIENT_ID und YOUR_REDIRECT_URI Variablen, die Ihrem Anmeldedaten für die Autorisierung Variable YOUR_REDIRECT_URI sollte dieselbe URL haben, unter der die Seite bereitgestellt wird. Der Wert muss genau einem der folgenden Werte entsprechen: Die autorisierten Weiterleitungs-URIs für den OAuth 2.0-Client, die Sie im API Console Credentials pageWenn stimmt dieser Wert mit keinem autorisierten URI überein, erhalten Sie den Fehler redirect_uri_mismatch. Fehler. Ihr Projekt muss außerdem die entsprechende API für diese Anfrage aktiviert haben.

<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/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() {
    // 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/drive.metadata.readonly',
                  '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>

Regeln für die Validierung der JavaScript-Ursprung

Google wendet die folgenden Validierungsregeln auf JavaScript-Quellen an, um für die Sicherheit ihrer Anwendungen. Ihre JavaScript-Quellen müssen diesen Regeln entsprechen. Siehe RFC 3986, Abschnitt 3 für die Definition von Domain, Host und Schema.

Validierungsregeln
Schema

JavaScript-Quellen müssen das HTTPS-Schema und nicht einfaches HTTP verwenden. 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) muss zur öffentlichen Suffixliste gehören.
  • Hostdomains dürfen nicht “googleusercontent.com” sein.
  • JavaScript-Quellen dürfen keine URL Shortener-Domains enthalten (z.B. goo.gl) sofern die Domain nicht der App gehört.
  • Nutzerinformationen

    JavaScript-Quellen dürfen die Unterkomponente „Nutzerinformationen“ 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 Fragmentkomponente nicht enthalten.

    Zeichen JavaScript-Quellen dürfen bestimmte Zeichen nicht enthalten, darunter: <ph type="x-smartling-placeholder">
      </ph>
    • Platzhalterzeichen ('*')
    • Nicht druckbare ASCII-Zeichen
    • Ungültige Prozentcodierung (Prozentcodierung, die nicht der URL-Codierung entspricht) Form eines Prozentzeichens gefolgt von zwei Hexadezimalziffern)
    • Nullzeichen (codiertes NULL-Zeichen, z.B. %00, %C0%80)

    Inkrementelle Autorisierung

    Im OAuth 2.0-Protokoll fordert Ihre Anwendung eine Autorisierung für den Zugriff auf Ressourcen an. Diese sind die durch den Umfang identifiziert werden. Es hat sich bewährt, die Autorisierung anzufordern. genau dann, wenn Sie sie brauchen. Dafür gibt der Autorisierungsserver von Google unterstützt inkrementelle Autorisierung. Mit dieser Funktion können Sie Bereiche bei Bedarf anfordern. Erteilt der Nutzer die Berechtigung für den neuen Bereich, wird ein Autorisierungscode zurückgegeben, der möglicherweise gegen ein Token ausgetauscht werden, das alle Bereiche enthält, die der Nutzer dem Projekt gewährt hat.

    Eine App, mit der Nutzer Musiktitel sampeln und Mixe erstellen können, benötigt Ressourcen bei der Anmeldung, möglicherweise nicht mehr als der Name der Person, die sich anmeldet. Sie können jedoch benötigen zum Speichern eines fertigen Mix Zugriff auf Google Drive. Die meisten Leute würden es finden selbst wenn sie nur zum Zeitpunkt der eigentlichen App-Nutzung um Zugriff auf ihr Google Drive gebeten werden. dass sie es brauchten.

    In diesem Fall kann die App bei der Anmeldung die openid und profile Bereichen für eine einfache Anmeldung verwenden und später die https://www.googleapis.com/auth/drive.file bei der ersten Anfrage zum Speichern eines

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

    • Das Token kann für den Zugriff auf Ressourcen verwendet werden, die einem der Bereiche entsprechen, die in den neue kombinierte Autorisierung.
    • Wenn Sie das Aktualisierungstoken für die kombinierte Autorisierung zum Abrufen eines Zugriffstokens verwenden, wird der steht für die kombinierte Autorisierung und kann für alle scope-Werte in der Antwort enthalten.
    • Die kombinierte Autorisierung umfasst alle Bereiche, die der Nutzer dem API-Projekt gewährt hat, auch wenn die Erteilungen von verschiedenen Kunden angefordert wurden. Wenn ein Nutzer z. B. Zugriff auf einem Bereich über den Desktop-Client einer Anwendung und einem anderen App über einen mobilen Client senden würde, würde die kombinierte Autorisierung beide Bereiche umfassen.
    • Wenn Sie ein Token widerrufen, das eine kombinierte Autorisierung darstellt, kann auf all diese Die Zugriffsbereiche der Autorisierung für den zugeordneten Nutzer werden gleichzeitig widerrufen.

    Die folgenden Codebeispiele zeigen, wie Sie einem vorhandenen Zugriffstoken Bereiche hinzufügen. Dieser Ansatz ermöglicht es, um nicht mehrere Zugriffstokens verwalten zu müssen.

    OAuth 2.0-Endpunkte

    Fügen Sie einen include_granted_scopes ein, um einem vorhandenen Zugriffstoken Bereiche hinzuzufügen. in Ihrer Anfrage an den OAuth 2.0-Server von Google.

    Das folgende Code-Snippet zeigt, wie dies funktioniert. Das Snippet geht davon aus, dass Sie Die Bereiche, für die Ihr Zugriffstoken im lokalen Speicher des Browsers gültig ist. Der Parameter vollständiger Beispielcode speichert eine Liste von Bereichen, für die das Zugriffstoken ist gültig, indem die Eigenschaft oauth2-test-params.scope im lokalen Browser storage.)

    Mit dem Snippet werden die Bereiche, für die das Zugriffstoken gültig ist, mit dem Bereich verglichen, den Sie verwenden möchten für eine bestimmte Suchanfrage. Wenn das Zugriffstoken diesen Bereich nicht abdeckt, wird der OAuth 2.0-Vorgang gestartet. Hier ist die Funktion oauth2SignIn die gleiche wie die in Schritt 2 (und dieser wird später im vollständigen Beispiel)

    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

    In einigen Fällen möchte ein Nutzer den Zugriff auf eine Anwendung widerrufen. Ein Nutzer kann den Zugriff widerrufen. unter Kontoeinstellungen. Weitere Informationen finden Sie in der Entfernen Website- oder App-Zugriff auf der Seite „Websites und Apps von Drittanbietern“ Apps mit Zugriff auf Ihr Konto finden Sie weitere Informationen.

    Es ist auch möglich, den Zugriff einer Anwendung programmatisch zu widerrufen. Der programmatische Widerruf ist wichtig, wenn ein Nutzer ein Abonnement beendet, oder die für eine App erforderlichen API-Ressourcen haben sich wesentlich geändert. Mit anderen Worten: Ein Teil des Entfernungsprozesses kann eine API-Anfrage umfassen, um sicherzustellen, dass die zuvor werden entfernt.

    OAuth 2.0-Endpunkte

    Zum programmatischen Widerrufen eines Tokens sendet Ihre Anwendung eine Anfrage an https://oauth2.googleapis.com/revoke und enthält das Token als Parameter:

    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. Handelt es sich bei dem Token um ein Zugriffstoken mit einem entsprechendes Aktualisierungstoken, wird auch das Aktualisierungstoken widerrufen.

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

    Das folgende JavaScript-Snippet zeigt, wie ein Token in JavaScript widerrufen wird, ohne die Methode Google APIs-Clientbibliothek für JavaScript Da der OAuth 2.0-Endpunkt von Google zum Widerrufen der wird Cross-Origin Resource Sharing (CORS) nicht unterstützt, mit dem Code wird ein Formular erstellt und an den Endpunkt zu senden, anstatt die Methode XMLHttpRequest() 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();
    }

    Den produktübergreifenden Kontoschutz implementieren

    Zusätzlicher Schritt zum Schutz der Nutzerdaten für Google-Konten wird die kontoübergreifende Schutz durch den produktübergreifenden Kontoschutz von Google Mit diesem Dienst können Sie Benachrichtigungen zu Sicherheitsereignissen abonnieren, die Ihrer Anwendung Informationen über größere Änderungen am Nutzerkonto vorgenommen hat. Anhand dieser Informationen können Sie dann wie Sie auf Ereignisse reagieren.

    Der produktübergreifende Kontoschutz von Google sendet beispielsweise folgende Ereignistypen an Ihre App:

    • 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 finden Sie in der <ph type="x-smartling-placeholder"></ph> Nutzerkonten mit der Seite zum produktübergreifenden Kontoschutz schützen finden Sie weitere Informationen zur Implementierung des produktübergreifenden Kontoschutzes und eine vollständige Liste der verfügbaren Ereignisse.