Na tej stronie znajdziesz ogólne sprawdzone metody integracji z OAuth 2.0. Oprócz konkretnych wskazówek dotyczących Twojego typu aplikacji i platformy deweloperskiej weź pod uwagę te sprawdzone metody. Zapoznaj się też z wskazówkami dotyczącymi przygotowania aplikacji do publikacji i zasadami Google dotyczącymi OAuth 2.0.
Bezpieczne zarządzanie danymi logowania klienta
Dane logowania klienta OAuth identyfikują Twoją aplikację i należy się z nimi ostrożnie obchodzić. Przechowuj te dane logowania tylko w bezpiecznym miejscu, np. w menedżerze obiektów tajnych, takim jak Google Cloud Secret Manager. Nie koduj na stałe danych logowania, nie zapisuj ich w repozytorium kodu ani nie publikuj ich publicznie.
Bezpieczne postępowanie z tokenami użytkowników
Tokeny użytkownika obejmują zarówno tokeny odświeżania, jak i tokeny dostępu używane przez Twoją aplikację. Bezpiecznie przechowuj tokeny w spoczynku i nigdy nie przesyłaj ich w postaci zwykłego tekstu. Używaj bezpiecznego systemu przechowywania odpowiedniego dla Twojej platformy, np. Keystore na Androidzie, Keychain Services na iOS i macOS lub Credential Locker na Windowsie.
Cofaj tokeny, gdy tylko przestaną być potrzebne, i trwale usuwaj je ze swoich systemów.
Weź też pod uwagę te sprawdzone metody dotyczące Twojej platformy:
- W przypadku aplikacji po stronie serwera, które przechowują tokeny wielu użytkowników, szyfruj je w stanie spoczynku i dopilnuj, aby Twój magazyn danych nie był publicznie dostępny w internecie.
- W przypadku natywnych aplikacji na komputery zalecamy używanie protokołu PKCE (Proof Key for Code Exchange) do uzyskiwania kodów autoryzacji, które można wymieniać na tokeny dostępu.
Używanie parametru stanu
Przed przetworzeniem odpowiedzi OAuth 2.0 sprawdź, czy state otrzymany od Google jest zgodny z state wysłanym w prośbie o autoryzację. Parametr state powinien być niepowtarzalną, trudną do odgadnięcia wartością wygenerowaną przez Twoją aplikację.
Użycie parametru state pomaga upewnić się, że żądanie pochodzi od użytkownika, a nie od złośliwego skryptu, i zmniejsza ryzyko ataków polegających na fałszowaniu żądań z innej witryny (CSRF).
Obsługa unieważnienia i wygasania tokena odświeżania
Jeśli aplikacja poprosiła o token odświeżania do dostępu offline, musisz też obsługiwać jego unieważnienie lub wygaśnięcie. Tokeny mogą zostać unieważnione z różnych powodów, na przykład mogą wygasnąć lub dostęp aplikacji mógł zostać cofnięty przez użytkownika albo w ramach procesu automatycznego. W takim przypadku dokładnie rozważ, jak powinna zareagować Twoja aplikacja, w tym czy przy następnym logowaniu użytkownik powinien otrzymać odpowiedni komunikat lub czy należy usunąć jego dane. Aby otrzymywać powiadomienia o unieważnieniu tokena, zintegruj usługę Ochrona wszystkich kont.
Korzystanie z autoryzacji przyrostowej
Używaj autoryzacji przyrostowej, aby prosić o odpowiednie zakresy OAuth, gdy Twoja aplikacja potrzebuje danej funkcji.
Nie należy prosić o dostęp do danych podczas pierwszej autoryzacji użytkownika, chyba że jest to niezbędne do działania głównej funkcjonalności aplikacji. Zamiast tego proś tylko o zakresy potrzebne do wykonania zadania, zgodnie z zasadą wybierania najmniejszych i najbardziej ograniczonych zakresów.
Zawsze proś o zakresy w odpowiednim kontekście, aby użytkownicy wiedzieli, dlaczego aplikacja prosi o dostęp i jak będą wykorzystywane dane.
Aplikacja może na przykład działać w ten sposób:
- Użytkownik uwierzytelnia się w aplikacji.
- Nie są wymagane żadne dodatkowe zakresy. Aplikacja zapewnia podstawowe funkcje, które umożliwiają użytkownikowi poznawanie i korzystanie z funkcji niewymagających dodatkowych danych ani dostępu.
- Użytkownik wybiera funkcję, która wymaga dostępu do dodatkowych danych.
- Aplikacja wysyła żądanie autoryzacji dla tego konkretnego zakresu OAuth, który jest wymagany w przypadku tej funkcji. Jeśli ta funkcja wymaga wielu zakresów, postępuj zgodnie ze sprawdzonymi metodami opisanymi poniżej.
- Jeśli użytkownik odrzuci prośbę, aplikacja wyłączy tę funkcję i wyświetli dodatkowe informacje, aby użytkownik mógł ponownie poprosić o dostęp.
Obsługa zgody w przypadku wielu zakresów
Gdy użytkownicy proszą o wiele zakresów jednocześnie, mogą nie przyznać wszystkich zakresów protokołu OAuth, o które prosisz. Aplikacja powinna obsługiwać odmowę przyznania zakresów przez wyłączanie odpowiednich funkcji.
Jeśli podstawowe funkcje aplikacji wymagają wielu zakresów, wyjaśnij to użytkownikowi przed wyświetleniem prośby o zgodę.
Możesz ponownie poprosić użytkownika o zgodę dopiero wtedy, gdy wyraźnie wskaże, że chce użyć konkretnej funkcji, która wymaga zakresu. Zanim poprosisz użytkownika o zakresy OAuth, aplikacja powinna podać odpowiedni kontekst i uzasadnienie.
Zminimalizuj liczbę zakresów, o które aplikacja prosi jednocześnie. Zamiast tego używaj uwierzytelniania stopniowego, aby prosić o zakresy w kontekście funkcji.
Korzystanie z bezpiecznych przeglądarek
W internecie żądania autoryzacji OAuth 2.0 muszą być wysyłane tylko z pełnoprawnych przeglądarek internetowych. Na innych platformach wybierz odpowiedni typ klienta OAuth i zintegruj OAuth w sposób odpowiedni dla Twojej platformy. Nie przekierowuj żądania przez osadzone środowiska przeglądania, w tym komponenty WebView na platformach mobilnych, takie jak WebView na Androidzie czy WKWebView na iOS. Zamiast tego używaj natywnych bibliotek OAuth lub Logowania przez Google na swojej platformie.
Ręczne tworzenie i konfigurowanie klientów OAuth
Aby zapobiec nadużyciom, nie można tworzyć ani modyfikować klientów OAuth programowo. Aby wyraźnie zaakceptować warunki usługi, skonfigurować klienta OAuth i przygotować się do weryfikacji OAuth, musisz użyć konsoli Google Developers.
W przypadku zautomatyzowanych przepływów pracy rozważ użycie kont usługi.
Usuwanie nieużywanych klientów OAuth
Regularnie sprawdzaj klientów OAuth 2.0 i proaktywnie usuwaj tych, którzy nie są już potrzebni w Twojej aplikacji lub stali się przestarzali. Pozostawienie skonfigurowanych, ale nieużywanych klientów stanowi potencjalne zagrożenie dla bezpieczeństwa, ponieważ w razie naruszenia bezpieczeństwa Twoich danych logowania klienta może on zostać wykorzystany w nieuprawniony sposób.
Aby jeszcze bardziej ograniczyć ryzyko związane z nieużywanymi klientami, klienci OAuth 2.0, którzy są nieaktywni przez 6 miesięcy, są automatycznie usuwani.
Zalecamy, aby nie czekać na automatyczne usunięcie, ale proaktywnie usuwać nieużywane konta klientów. Dzięki temu zmniejszysz obszar narażony na atak i zapewnisz odpowiedni poziom bezpieczeństwa.