Z tego przewodnika dowiesz się, czy do autoryzacji użytkowników lepiej użyć biblioteki Google Identity Services, czy zaimplementować własną bibliotekę JavaScript. Pomoże Ci on zdecydować, który przepływ autoryzacji OAuth 2.0 jest najlepszy dla Twojej aplikacji internetowej.
Zakładamy, że przed przeczytaniem tego przewodnika znasz terminy i koncepcje opisane w przewodniku 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 jest przeznaczona do używania z frameworkami JavaScriptu po stronie serwera, takimi jak Node.js, zamiast tego użyj biblioteki klienta Google w Node.js.
Ten przewodnik obejmuje tylko autoryzację i udostępnianie danych. Nie omawia uwierzytelniania użytkowników. Informacje o rejestracji i logowaniu użytkowników znajdziesz w przewodnikach Zaloguj się przez Google i Migracja z Logowania przez Google.
Sprawdzanie, czy biblioteka GIS jest dla Ciebie odpowiednia
Musisz zdecydować, czy lepiej będzie użyć biblioteki Google, czy utworzyć własną. Omówienie funkcji i możliwości:
- Biblioteka JavaScriptu Google Identity Services implementuje:
- Przepływy zgody oparte na oknach, które minimalizują przekierowania i pozwalają użytkownikom pozostać w Twojej witrynie przez cały proces autoryzacji.
- Funkcje zabezpieczeń, takie jak ochrona przed fałszowaniem żądań z innych witryn (Cross-site Request Forgery, CSRF).
- Metody pomocnicze do żądania poszczególnych zakresów i potwierdzania zgody użytkownika.
- Przyjazną dla użytkownika obsługę błędów i linki do dokumentacji, które mogą być używane przez inżynierów podczas programowania, a później przez odwiedzających Twoją witrynę.
- Jeśli implementujesz bez biblioteki Identity Services, odpowiadasz za:
- Zarządzanie żądaniami i odpowiedziami za pomocą punktów końcowych OAuth 2.0 Google, w tym przekierowań.
- Optymalizowanie wrażeń użytkowników.
- Implementowanie funkcji zabezpieczeń do weryfikowania żądań i odpowiedzi oraz zapobiegania atakom CSRF.
- Metody potwierdzania, że użytkownik wyraził zgodę na wszystkie żądane zakresy.
- Zarządzanie kodami błędów OAuth 2.0, tworzenie czytelnych komunikatów i linków do pomocy dla użytkowników.
Podsumowując, Google udostępnia bibliotekę GIS, aby pomóc Ci szybko i bezpiecznie zaimplementować klienta OAuth 2.0 oraz zoptymalizować proces autoryzacji użytkownika.
Wybieranie przepływu autoryzacji
Musisz wybrać jeden z 2 przepływów autoryzacji OAuth 2.0: niejawny lub kodu autoryzacji. Nie ma znaczenia, czy zdecydujesz się użyć biblioteki JavaScriptu Google Identity Services, czy utworzyć własną bibliotekę.
Oba przepływy generują token dostępu, którego można używać do wywoływania interfejsów API Google.
Główne różnice między tymi 2 przepływami to:
- liczba działań użytkownika;
- czy Twoja aplikacja będzie wywoływać interfejsy API Google bez obecności użytkownika;
- czy do hostowania punktu końcowego i przechowywania tokenów odświeżania poszczególnych kont użytkowników potrzebna jest platforma backendowa;
- wyższy lub niższy poziom bezpieczeństwa użytkownika.
Porównując przepływy i oceniając wymagania dotyczące bezpieczeństwa, należy wziąć pod uwagę, że poziom bezpieczeństwa użytkownika różni się w zależności od wybranych zakresów. Na przykład wyświetlanie zaproszeń do kalendarza w trybie tylko do odczytu może być uważane za mniej ryzykowne niż używanie zakresu odczytu i zapisu do edytowania plików na Dysku.
Porównanie przepływów OAuth 2.0
| Przepływ niejawny | Przepływ kodu autoryzacji | |
| Wymagana zgoda użytkownika | W przypadku każdego żądania tokena, w tym zastępowania wygasłych tokenów. | Tylko w przypadku pierwszego żądania tokena. |
| Wymagana obecność użytkownika | Tak | Nie, obsługuje tryb offline. |
| Bezpieczeństwo użytkownika | Najrzadsze | Największe, obejmuje uwierzytelnianie klienta i pozwala uniknąć ryzyka związanego z obsługą tokenów w przeglądarce. |
| Wydawanie tokena dostępu | Tak | Tak |
| Wydawanie tokena 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 z aplikacji internetowej działającej w przeglądarce użytkownika. | Z serwera działającego na platformie backendowej lub z aplikacji internetowej działającej w przeglądarce użytkownika. |
| Wymagana platforma backendowa | Nie | Tak, do hostowania i przechowywania punktów końcowych. |
| Wymagane bezpieczne przechowywanie | Nie | Tak, do przechowywania tokenów odświeżania. |
| Wymaga hostowania punktu końcowego kodu autoryzacji | Nie | Tak, aby otrzymywać kody autoryzacji od Google. |
| Zachowanie po wygaśnięciu tokena dostępu | Aby poproszyć o nowy, prawidłowy token dostępu i go uzyskać, wymagany jest gest użytkownika, np. naciśnięcie przycisku lub kliknięcie linku. | Po początkowym żądaniu użytkownika Twoja platforma wymienia przechowywany token odświeżania na nowy, prawidłowy token dostępu niezbędny do wywoływania interfejsów API Google. |