Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
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.
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.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Benötigte Informationen nicht gefunden","missingTheInformationINeed","thumb-down"],["Zu umständlich/zu viele Schritte","tooComplicatedTooManySteps","thumb-down"],["Nicht mehr aktuell","outOfDate","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Problem mit Beispielen/Code","samplesCodeIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2023-12-01 (UTC)."],[[["\u003cp\u003eThis guide helps developers choose between Google Identity Services or a custom JavaScript library for OAuth 2.0 authorization in their web applications.\u003c/p\u003e\n"],["\u003cp\u003eGoogle Identity Services offers pre-built security features, optimized user experience, and easier implementation compared to building a custom solution.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers need to select between the Implicit or Authorization Code flow based on security, user presence requirements, and backend needs.\u003c/p\u003e\n"],["\u003cp\u003eAuthorization Code flow is recommended for enhanced security, offline access, and refresh token management through a backend server.\u003c/p\u003e\n"],["\u003cp\u003eThe guide assumes prior knowledge of OAuth 2.0 concepts and focuses solely on authorization and data sharing, not user authentication.\u003c/p\u003e\n"]]],[],null,["# Choose a user authorization model\n\nThis guide helps you to choose between using the Google Identity Services\nlibrary for user authorization or implementing your own JavaScript library. It\nhelps you decide which OAuth 2.0 authorization flow is best for your web\napplication.\n\nPrior to reading this guide it is assumed that you are familiar with the terms\nand concepts described in the [Overview](/identity/oauth2/web/guides/overview) and\n[How user authorization works](/identity/oauth2/web/guides/how-user-authz-works) guide.\n\nThe GIS library runs in these [supported browsers](/identity/gsi/web/guides/supported-browsers) on the user's device. It\nis not intended for use with server-side JavaScript frameworks such as Node.js,\ninstead use Google's [Node.js](https://github.com/googleapis/google-api-nodejs-client)\nclient library.\n\nThis guide only covers authorization and data sharing topics. It does not review\nuser authentication, instead see [Sign In With Google](/identity/gsi/web) and the [Migrating\nfrom Google Sign-In](/identity/gsi/web/guides/migration) guide for user sign-up and sign-in.\n\nDeciding if the GIS library is right for you\n--------------------------------------------\n\nYou must choose if using Google's library, or creating your own best fits your\nneeds. An overview of features and functionality:\n\n- Google's Identity Services JavaScript library implements:\n - Popup based consent flows to minimize redirects, thus enabling users to remain on your site throughout the authorization process.\n - Security features such as Cross-site Request Forgery (CRSF).\n - Helper methods to request individual scopes and confirm user consent.\n - Human friendly error handling and documentation links for use by engineers during development and later for visitors to your site.\n- When implementing without the Identity Services library you are responsible for:\n - Managing requests and responses with Google's OAuth 2.0 endpoints, including redirects.\n - Optimizing the user experience.\n - Implementation of security features to validate requests, responses, and to prevent CSRF.\n - Methods to confirm a user has granted consent for any requested scopes.\n - Managing OAuth 2.0 error codes, creating human readable messages, and links to user help.\n\nIn summary, Google offers the GIS library to help you to quickly, and securely\nimplement an OAuth 2.0 client and optimize the user's authorization experience.\n\nChoosing an authorization flow\n------------------------------\n\nYou will need to choose one of two OAuth 2.0 authorization flows: implicit or\nauthorization code -- regardless if you decide to use the Google Identity\nServices JavaScript library or to create your own library.\n\nBoth flows result in an access token which can be used to call Google APIs.\n\nThe primary differences between the two flows are:\n\n- the number of user actions,\n- whether your app will call Google APIs without the user present,\n- if a backend platform is needed to host an endpoint and to store per-user refresh tokens for individual user accounts, and\n- higher or lower levels of user security.\n\nWhen comparing flows and evaluating your security requirements, a factor to\nconsider is that the level of user security varies depending on the scopes you\nchoose. For example, viewing calendar invites as read-only might be considered\nless risky than using a read/write scope to edit files in Drive.\n| **Key Point:** Authorization code flow is recommended because it provides a more secure flow.\n\nOAuth 2.0 flow comparison\n-------------------------\n\n|--------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------|\n| | **Implicit flow** | **Authorization code flow** |\n| **User consent required** | For every token request, including replacing expired tokens. | Only for the first token request. |\n| **User must be present** | Yes | No, supports offline use. |\n| **User security** | Least | Most, has client authentication and avoids in-browser token handling risks. |\n| **Access token issued** | Yes | Yes |\n| **Refresh token issued** | No | Yes |\n| **Supported browser required** | Yes | Yes |\n| **Access token used to call Google APIs** | only from a web app running in the user's browser. | either from a server running on backend platform, or from a web app running in the user's browser. |\n| **Requires backend platform** | No | Yes, for endpoint hosting and storage. |\n| **Secure storage needed** | No | Yes, for refresh token storage. |\n| **Requires hosting of an authorization code endpoint** | No | Yes, to receive authorization codes from Google. |\n| **Access token expiration behavior** | A user gesture such as button press or clicking on a link is required to request and obtain a new, valid access token. | After an initial user request, your platform exchanges the stored refresh token to obtain a new, valid access token necessary to call Google APIs. |"]]
