In diesem Leitfaden erfahren Sie, ob Sie die Google Identity Services-Bibliothek für die Nutzerautorisierung verwenden oder Ihre eigene JavaScript-Bibliothek implementieren sollten. Außerdem wird erläutert, welcher OAuth 2.0-Autorisierungsablauf für Ihre Webanwendung am besten geeignet ist.
Bevor Sie diesen Leitfaden lesen, sollten Sie mit den Begriffen und Konzepten vertraut sein, die in der Übersicht und im Leitfaden zur Nutzerautorisierung beschrieben werden.
Die GIS-Bibliothek wird in diesen unterstützten Browsern auf dem Gerät des Nutzers ausgeführt. Sie ist nicht für die Verwendung mit serverseitigen JavaScript-Frameworks wie Node.js vorgesehen. Verwenden Sie stattdessen die Node.js Clientbibliothek von Google.
In diesem Leitfaden werden nur die Themen Autorisierung und Datenfreigabe behandelt. Die Nutzerauthentifizierung wird nicht behandelt. Informationen zur Nutzerregistrierung und ‑anmeldung finden Sie unter Über Google anmelden und Migration von Google Log-in.
Entscheiden, ob die GIS-Bibliothek für Sie geeignet ist
Sie müssen entscheiden, ob die Verwendung der Google-Bibliothek oder die Erstellung einer eigenen Bibliothek Ihren Anforderungen am besten entspricht. Übersicht über Funktionen:
- Die JavaScript-Bibliothek von Google Identity Services implementiert:
- Dialogbasierte Einwilligungsabläufe, um Weiterleitungen zu minimieren, damit Nutzer während des gesamten Autorisierungsprozesses auf Ihrer Website bleiben können.
- Sicherheitsfunktionen wie Schutz vor websiteübergreifender Anfragefälschung (Cross-site Request Forgery, CSRF).
- Hilfsmethoden zum Anfordern einzelner Bereiche und zum Bestätigen der Nutzereinwilligung.
- Nutzerfreundliche Fehlerbehandlung und Dokumentationslinks für die Verwendung durch Entwickler während der Entwicklung und später für Besucher Ihrer Website.
- Wenn Sie die Implementierung ohne die Identity Services-Bibliothek vornehmen, sind Sie für Folgendes verantwortlich:
- Verwaltung von Anfragen und Antworten mit den OAuth 2.0-Endpunkten von Google, einschließlich Weiterleitungen.
- Optimierung der Nutzererfahrung.
- Implementierung von Sicherheitsfunktionen zur Validierung von Anfragen und Antworten und zur Verhinderung von CSRF.
- Methoden, um zu bestätigen, dass ein Nutzer die Einwilligung für alle angeforderten Bereiche erteilt hat.
- Verwaltung von OAuth 2.0-Fehlercodes, Erstellung von für Menschen lesbaren Nachrichten und Links zur Nutzerhilfe.
Zusammenfassend bietet Google die GIS-Bibliothek an, mit der Sie schnell und sicher einen OAuth 2.0-Client implementieren und die Autorisierungserfahrung des Nutzers optimieren können.
Autorisierungsablauf auswählen
Sie müssen einen von zwei OAuth 2.0-Autorisierungsabläufen auswählen: implizit oder Autorisierungscode. Das gilt unabhängig davon, ob Sie die JavaScript-Bibliothek von Google Identity Services verwenden oder Ihre eigene Bibliothek erstellen.
Beide Abläufe führen zu einem Zugriffstoken, mit dem Google APIs aufgerufen werden können.
Die Hauptunterschiede zwischen den beiden Abläufen sind:
- die Anzahl der Nutzeraktionen,
- ob Ihre App Google APIs ohne Anwesenheit des Nutzers aufrufen kann,
- ob eine Backend-Plattform erforderlich ist, um einen Endpunkt zu hosten und Aktualisierungstokens für einzelne Nutzerkonten zu speichern, und
- höhere oder niedrigere Stufen der Nutzersicherheit.
Beim Vergleich von Abläufen und der Bewertung Ihrer Sicherheitsanforderungen ist zu berücksichtigen, dass die Stufe der Nutzersicherheit je nach den von Ihnen ausgewählten Bereichen variiert. Das Anzeigen von Kalendereinladungen als schreibgeschützt ist beispielsweise weniger riskant als die Verwendung eines Lese- und Schreibbereichs zum Bearbeiten von Dateien in Drive.
Vergleich der OAuth 2.0-Abläufe
| Impliziter Ablauf | Autorisierungscode-Ablauf | |
| Nutzereinwilligung erforderlich | Für jede Tokenanfrage, einschließlich des Ersetzens abgelaufener Tokens. | Nur für die erste Tokenanfrage. |
| Nutzer muss anwesend sein | Ja | Nein, unterstützt die Offlinenutzung. |
| Nutzersicherheit | Seltenste | Höchste, mit Clientauthentifizierung und ohne Risiken bei der Tokenverwaltung im Browser. |
| Zugriffstoken ausgestellt | Ja | Ja |
| Aktualisierungstoken ausgestellt | Nein | Ja |
| Unterstützter Browser erforderlich | Ja | Ja |
| Zugriffstoken zum Aufrufen von Google APIs verwendet | nur über eine Webanwendung, die im Browser des Nutzers ausgeführt wird. | entweder von einem Server, der auf einer Backend-Plattform ausgeführt wird, oder von einer Webanwendung die im Browser des Nutzers ausgeführt wird. |
| Backend-Plattform erforderlich | Nein | Ja, für Endpunkthosting und ‑speicher. |
| Sicherer Speicher erforderlich | Nein | Ja, für die Speicherung von Aktualisierungstokens. |
| Hosting eines Autorisierungscode-Endpunkts erforderlich | Nein | Ja, um Autorisierungscodes von Google zu erhalten. |
| Verhalten beim Ablauf des Zugriffstokens | Eine Nutzergeste wie das Drücken einer Schaltfläche oder das Klicken auf einen Link ist erforderlich, um ein neues, gültiges Zugriffstoken anzufordern und zu erhalten. | Nach einer ersten Nutzeranfrage tauscht Ihre Plattform das gespeicherte Aktualisierungstoken aus, um ein neues, gültiges Zugriffstoken zu erhalten, das zum Aufrufen von Google APIs erforderlich ist. |