Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Ten przewodnik pomoże Ci wybrać, czy chcesz używać biblioteki Google Identity Services do autoryzacji użytkowników czy implementowania własnej biblioteki JavaScript. Ułatwia on wybór sposobu autoryzacji OAuth 2.0, który najlepiej sprawdzi się w przypadku Twojej aplikacji internetowej.
Biblioteka GIS działa na urządzeniu użytkownika w obsługiwanych przeglądarkach. Nie należy korzystać z platform JavaScript po stronie serwera, takich jak Node.js. Zamiast tego należy używać biblioteki klienta Node.js firmy Google.
Ten przewodnik obejmuje tylko tematy związane z autoryzacją i udostępnianiem danych. Nie sprawdza uwierzytelniania użytkowników. Zamiast tego zapoznaj się z sekcją Zaloguj się przez Google oraz przewodnikiem Migracja z logowania przez Google na temat rejestracji i logowania użytkowników.
Zastanów się, czy biblioteka GIS jest dla Ciebie odpowiednia
Musisz wybrać, czy chcesz korzystać z biblioteki Google, czy utworzyć własną. Omówienie funkcji:
Biblioteka JavaScript usług tożsamości Google implementuje:
Proces uzyskiwania zgody oparty na wyskakujących okienkach pozwala zminimalizować przekierowania i pozostawać w witrynie przez cały proces autoryzacji.
funkcje zabezpieczeń, takie jak fałszowanie żądań z innych witryn (CRSF);
Metody pomocnicze dotyczące żądania poszczególnych zakresów i potwierdzania zgody użytkownika.
Obsługiwana w sposób zrozumiały dla człowieka sposób obsługi błędów i linki do dokumentacji przeznaczone dla inżynierów podczas programowania i w późniejszym czasie dla użytkowników witryny.
Implementując bez biblioteki usług tożsamości, odpowiadasz za:
zarządzanie żądaniami i odpowiedziami za pomocą punktów końcowych OAuth 2.0 Google, w tym przekierowań;
Optymalizacja wygody użytkowników.
Wdrożenie funkcji zabezpieczeń do weryfikowania żądań i odpowiedzi oraz zapobiegania im.
Metody potwierdzania, że użytkownik wyraził zgodę na żądane zakresy.
Zarządzanie kodami błędów OAuth 2.0, tworzenie wiadomości czytelnych dla człowieka i linki do pomocy dla użytkowników.
Podsumowując, Google udostępnia bibliotekę GIS, aby pomóc Ci szybko i bezpiecznie wdrożyć klienta OAuth 2.0 oraz zoptymalizować proces autoryzacji dla użytkowników.
Wybieranie procesu autoryzacji
Musisz wybrać jeden z dwóch procesów autoryzacji OAuth 2.0: kod niejawny lub kod autoryzacji – niezależnie od tego, czy użyjesz biblioteki JavaScript usług tożsamości Google czy utworzysz własną bibliotekę.
Oba przepływy skutkują tokenem dostępu, którego można używać do wywoływania interfejsów API Google.
Główne różnice między tymi dwoma przepływami:
liczbę działań użytkownika,
czy aplikacja będzie wywoływać interfejsy API Google bez obecności użytkownika,
czy platforma backendu jest potrzebna do hostowania punktu końcowego i przechowywania tokenów odświeżania dla poszczególnych kont użytkowników oraz
wyższy lub niższy poziom bezpieczeństwa użytkowników.
Podczas porównywania przepływów i oceny wymagań dotyczących bezpieczeństwa warto wziąć pod uwagę, że poziom bezpieczeństwa użytkowników różni się w zależności od wybranych zakresów. Na przykład wyświetlanie zaproszeń z kalendarza w trybie tylko do odczytu może być mniej ryzykowne niż edytowanie plików na Dysku za pomocą zakresu do odczytu i zapisu.
Porównanie przepływu OAuth 2.0
Przepływ niejawny
Przepływ kodu autoryzacji
Wymagana zgoda użytkownika
Dla każdego żądania tokena, w tym do wymiany wygasłych tokenów.
Tylko w przypadku pierwszego żądania tokena.
Użytkownik musi być obecny
Tak
Nie, działa w trybie offline.
Bezpieczeństwo użytkowników
Najmniej
Większość z nich opiera się na uwierzytelnianiu klienta i pozwala uniknąć ryzyka związanego z obsługą tokenów w przeglądarce.
Wydany token dostępu
Tak
Tak
Wydany token odświeżania
Nie
Tak
Wymagana jest obsługiwana przeglądarka
Tak
Tak
Token dostępu używany do wywoływania interfejsów API Google
tylko z aplikacji internetowej uruchomionej w przeglądarce użytkownika.
z serwera działającego na platformie backendu lub z aplikacji internetowej uruchomionej w przeglądarce użytkownika.
Wymaga platformy backendu
Nie
Tak – do hostowania i przechowywania punktów końcowych.
Wymagane bezpieczne miejsce na dane
Nie
Tak, aby przechowywać tokeny odświeżania.
Wymaga hostowania punktu końcowego kodu autoryzacji
Nie
Tak, żeby otrzymywać od Google kody autoryzacji.
Zachowanie ważności tokena dostępu
Aby poprosić o nowy, prawidłowy token dostępu, wymagany jest gest użytkownika, taki jak naciśnięcie przycisku lub kliknięcie linku.
Po pierwszym żądaniu użytkownika platforma wymienia zapisany token odświeżania, aby uzyskać nowy, prawidłowy token dostępu niezbędny do wywoływania interfejsów API Google.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 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. |"]]
