Sprawdzone metody

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. za pomocą menedżera obiektów tajnych, takiego 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 stanie 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.

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ły wygasnąć lub dostęp do 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 zgłaszać żądania odpowiednich zakresów OAuth, gdy Twoja aplikacja potrzebuje danej funkcji.

Nie proś o dostęp do danych podczas pierwszej autoryzacji użytkownika, chyba że jest to niezbędne do działania podstawowych funkcji 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:

1. Użytkownik uwierzytelnia się w aplikacji.
   1. 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.
2. Użytkownik wybiera funkcję, która wymaga dostępu do dodatkowych danych.
   1. Aplikacja wysyła żądanie autoryzacji dla tego konkretnego zakresu protokołu 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.
   2. 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 przyznanie dostępu 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 korzystaj z uwierzytelniania stopniowego, aby prosić o zakresy w kontekście funkcji i działania.

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 lub 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 Twojej aplikacji lub stali się przestarzali. Pozostawienie skonfigurowanych, ale nieużywanych klientów stanowi potencjalne zagrożenie dla bezpieczeństwa, ponieważ klient może zostać wykorzystany w nieodpowiedni sposób, jeśli Twoje dane logowania klienta zostaną kiedykolwiek naruszone.

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 aktywnie usuwać nieużywanych klientów. Dzięki temu zmniejszysz obszar narażony na atak i zapewnisz odpowiedni poziom bezpieczeństwa.