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.
Zakładamy, że przed przeczytaniem tego przewodnika znasz już terminy i pojęcia opisane w przewodniku Omówienie i Jak działa autoryzacja użytkownika.
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. |