W tym przewodniku możesz wybrać, czy do autoryzacji użytkownika chcesz używać biblioteki usług tożsamości Google czy wdrożyć własną bibliotekę JavaScript. Pomaga określić, która metoda autoryzacji OAuth 2.0 jest najlepsza dla Twojej aplikacji internetowej.
Przed zapoznaniem się z tym przewodnikiem zakładamy, że znasz już terminy i zagadnienia opisane w podręcznikach Omówienie i Jak działa autoryzacja użytkowników.
Biblioteka GIS działa w tych obsługiwanych przeglądarkach na urządzeniu użytkownika. Nie powinien on być używany ze środowiskami JavaScript po stronie serwera, takimi jak Node.js, tylko korzystać z biblioteki klienta Node.js Google.
Ten przewodnik dotyczy wyłącznie tematów dotyczących autoryzacji i udostępniania danych. Nie obejmuje uwierzytelniania użytkowników. Zamiast tego zapoznaj się z artykułem Logowanie przez Google i przewodnikiem Rejestracja z logowania przez Google, gdzie znajdziesz instrukcje rejestracji i logowania użytkowników.
Określanie, czy biblioteka GIS jest dla Ciebie odpowiednia
Musisz wybrać, czy chcesz korzystać z biblioteki Google, czy utworzyć własne, które najlepiej odpowiadają Twoim potrzebom. Omówienie funkcji i ich funkcji:
- Biblioteka JavaScript usług tożsamości Google wdraża:
- Przepływy zgody na podstawie wyskakujących okienek minimalizują przekierowania, dzięki czemu użytkownicy mogą pozostać w witrynie przez cały proces autoryzacji.
- funkcji zabezpieczeń, takich jak fałszowanie żądań strony (CRSF);
- Metody pomocnicze, które umożliwiają żądanie pojedynczych zakresów i potwierdzenie zgody użytkownika.
- Prosta obsługa przez człowieka oraz linki do dokumentacji przeznaczone dla inżynierów do tworzenia stron i dla użytkowników.
- Podczas implementacji bez biblioteki usług tożsamości ponosisz odpowiedzialność za:
- Zarządzanie żądaniami i odpowiedziami za pomocą punktów końcowych OAuth 2.0 Google, w tym przekierowań.
- Optymalizacja wygody użytkowników
- Wdrażanie funkcji zabezpieczeń do weryfikowania żądań, odpowiedzi i zapobiegania CSRF.
- Metody potwierdzenia, że użytkownik udzielił zgody na każdy żądany zakres.
- Zarządzanie kodami błędów OAuth 2.0, tworzenie czytelnych dla ludzi wiadomości i linki do pomocy dla użytkowników.
Google udostępnia bibliotekę GIS, aby umożliwić szybkie i bezpieczne wdrożenie klienta OAuth 2.0 oraz optymalizację interfejsu użytkownika.
Wybieranie procesu autoryzacji
Musisz wybrać jeden z dwóch procesów autoryzacji OAuth 2.0: niejawny lub kod autoryzacji – niezależnie od tego, czy postanowisz użyć biblioteki JavaScript usług tożsamości Google, czy utworzyć własną bibliotekę.
W obu przypadkach powstaje token dostępu, którego można używać do wywoływania interfejsów API Google.
Główne różnice między tymi 2 metodami to:
- liczbę działań użytkownika;
- czy aplikacja będzie wywoływać interfejsy API Google bez konta użytkownika;
- jeśli potrzebna jest platforma backendu do hostowania punktu końcowego i przechowywania tokenów odświeżania dla poszczególnych użytkowników
- wyższego lub niższego poziomu bezpieczeństwa użytkownika.
Podczas porównywania przepływów pracy i oceniania wymagań związanych z bezpieczeństwem należy wziąć pod uwagę fakt, że poziom bezpieczeństwa użytkowników zależy od wybranych zakresów. Na przykład wyświetlanie zaproszeń z kalendarza w trybie tylko do odczytu może być mniej ryzykowne niż używanie zakresu odczytu/zapisu do edytowania plików na Dysku.
Porównanie przepływu OAuth 2.0
Przepływ domyślny | Przepływ kodu autoryzacji | |
Wymagana zgoda użytkownika | Dla każdego żądania tokena, w tym także wygasłych. | Tylko w przypadku pierwszego żądania tokena. |
Użytkownik musi być obecny | Tak | Nie, można używać offline. |
Bezpieczeństwo użytkowników | Najmniejszy | Większość ma uwierzytelnianie klienta i unika ryzyka związanego z obsługą tokenów w przeglądarce. |
Przyznany token dostępu | Tak | Tak |
Wykonano token odświeżania | Nie | Tak |
Wymagana obsługiwana przeglądarka | Tak | Tak |
Token dostępu używany do wywoływania interfejsów API Google | tylko w 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, to rozwiązanie służy do hostowania i przechowywania punktów końcowych. |
Wymagane miejsce na dane | Nie | Tak, aby móc przechowywać tokeny odświeżania. |
Wymaga hostowanego punktu końcowego kodu autoryzacji | Nie | Tak, aby otrzymywać kody autoryzacji od Google. |
Zachowanie ważności tokena dostępu | Aby poprosić o nowy i prawidłowy token dostępu, wymagany jest gest użytkownika, taki jak naciśnięcie przycisku lub kliknięcie linku. | Po otrzymaniu pierwszego żądania użytkownika platforma zapisuje zapisany token odświeżania w celu uzyskania nowego, prawidłowego tokena dostępu do interfejsów API Google. |