Dieser Leitfaden hilft Ihnen dabei, zwischen der Verwendung der Google Identity Services-Bibliothek für die Nutzerautorisierung und der Implementierung Ihrer eigenen JavaScript-Bibliothek zu wählen. Er hilft Ihnen bei der Entscheidung, welcher OAuth 2.0-Autorisierungsvorgang für Ihre Webanwendung am besten geeignet ist.
Es wird vorausgesetzt, dass Sie mit den Begriffen und Konzepten vertraut sind, die in der Anleitung Übersicht und Funktionsweise der Nutzerautorisierung beschrieben werden.
Die GIS-Bibliothek wird auf dem Gerät des Nutzers in diesen unterstützten Browsern ausgeführt. Es ist nicht für die Verwendung mit serverseitigen JavaScript-Frameworks wie Node.js vorgesehen. Nutzen Sie stattdessen die Node.js von Google.
In diesem Leitfaden werden nur die Themen Autorisierung und Datenfreigabe behandelt. Die Nutzerauthentifizierung wird nicht geprüft. Weitere Informationen zur Nutzerregistrierung und -anmeldung finden Sie unter Über Google anmelden und im Leitfaden Migration von Google Log-in.
Entscheiden, ob die GIS-Bibliothek das Richtige für Sie ist
Sie müssen entscheiden, ob Sie die Google-Bibliothek verwenden oder Ihre eigene Bibliothek am besten erstellen möchten. Übersicht über die Funktionen:
- Mit der JavaScript-Bibliothek „Identity Services“ von Google wird Folgendes implementiert:
- Pop-up-basierte Einwilligungsabläufe minimieren Weiterleitungen, sodass Nutzer während des gesamten Autorisierungsprozesses auf Ihrer Website bleiben können.
- Sicherheitsfunktionen wie Cross-Site Request Forgery (CRSF)
- Hilfsmethoden zum Anfordern einzelner Bereiche und zum Bestätigen der Nutzereinwilligung.
- Nutzerfreundliche Fehlerbehandlung und Dokumentationslinks, die von Entwicklern während der Entwicklung und später für Besucher Ihrer Website verwendet werden können.
- Bei der Implementierung ohne die Identity Services-Bibliothek sind Sie für Folgendes verantwortlich:
- Anfragen und Antworten mit den OAuth 2.0-Endpunkten von Google verwalten, einschließlich Weiterleitungen.
- Nutzererfahrung optimieren
- Implementierung von Sicherheitsfunktionen, um Anfragen und Antworten zu validieren und CSRF zu verhindern
- Methoden, um zu prüfen, ob ein Nutzer seine Einwilligung für alle angeforderten Bereiche erteilt hat.
- OAuth 2.0-Fehlercodes verwalten, für Menschen lesbare Meldungen und Links zur Nutzerhilfe erstellen
Zusammenfassend lässt sich sagen, dass Google die GIS-Bibliothek bietet, damit Sie schnell und sicher einen OAuth 2.0-Client implementieren und die Autorisierung für Nutzer optimieren können.
Autorisierungsablauf auswählen
Du musst einen von zwei OAuth 2.0-Autorisierungsabläufen auswählen: impliziten Autorisierungscode oder Autorisierungscode. Das gilt unabhängig davon, ob du die JavaScript-Bibliothek von Google Identity Services verwenden oder eine eigene Bibliothek erstellen möchtest.
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 den Nutzer aufruft,
- Ob zum Hosten eines Endpunkts und zum Speichern nutzerbezogener Aktualisierungstokens für einzelne Nutzerkonten eine Back-End-Plattform erforderlich ist und
- eine höhere oder niedrigere Sicherheitsstufe zu erreichen.
Wenn Sie Abläufe vergleichen und Ihre Sicherheitsanforderungen bewerten, sollten Sie berücksichtigen, dass das Sicherheitsniveau der Nutzer abhängig von den ausgewählten Bereichen variiert. Wenn Sie beispielsweise Kalendereinladungen schreibgeschützt ansehen, ist dies weniger riskant als die Verwendung eines Lese-/Schreibbereichs zum Bearbeiten von Dateien in Drive.
OAuth 2.0-Vorgang im Vergleich
| Impliziter Fluss | Vorgang mit Autorisierungscode | |
| Nutzereinwilligung erforderlich | Für jede Token-Anfrage, einschließlich des Ersetzens abgelaufener Tokens | Nur für die erste Tokenanfrage. |
| Nutzer muss anwesend sein | Ja | Nein, die Offlinenutzung wird unterstützt. |
| Nutzersicherheit | Am wenigsten | Die meisten bieten eine Clientauthentifizierung und vermeidet Risiken bei der Verarbeitung von Tokens im Browser. |
| Zugriffstoken ausgestellt | Ja | Ja |
| Aktualisierungstoken ausgestellt | Nein | Ja |
| Unterstützter Browser erforderlich | Ja | Ja |
| Zugriffstoken zum Aufrufen von Google APIs | nur über eine Webanwendung, die im Browser des Nutzers ausgeführt wird. | entweder von einem Server, der auf einer Back-End-Plattform ausgeführt wird, oder von einer Webanwendung, die im Browser des Nutzers ausgeführt wird. |
| Back-End-Plattform erforderlich | Nein | Ja, für das Hosting und die Speicherung von Endpunkten. |
| Sicherer Speicher erforderlich | Nein | Ja, für die Speicherung von Aktualisierungstokens. |
| Erfordert das Hosting eines Autorisierungscode-Endpunkts | Nein | Ja, um Autorisierungscodes von Google zu erhalten. |
| Verhalten bei Ablauf von Zugriffstokens | Eine Nutzergeste wie das Drücken oder Klicken auf einen Link ist erforderlich, um ein neues, gültiges Zugriffstoken anzufordern und abzurufen. | Nach einer ersten Nutzeranfrage tauscht die Plattform das gespeicherte Aktualisierungstoken gegen ein neues, gültiges Zugriffstoken aus, das zum Aufrufen von Google APIs erforderlich ist. |