Na tej stronie znajdziesz ogólne sprawdzone metody integracji z OAuth 2.0. Oprócz konkretnych wskazówek dotyczących typu aplikacji i platformy programistycznej weź pod uwagę te sprawdzone metody. Zapoznaj się też ze wskazówkami dotyczącymi przygotowywania aplikacji do wersji produkcyjnej i zasadami Google dotyczącymi protokołu OAuth 2.0.
Bezpieczne postępowanie z danymi logowania klienta
Dane logowania klienta OAuth identyfikują Twoją aplikację i należy się z nimi obchodzić ostrożnie. Przechowuj te dane logowania tylko w bezpiecznym miejscu, na przykład za pomocą menedżera obiektów tajnych, takiego jak Google Cloud Secret Manager. Nie koduj danych logowania na stałe, nie zapisuj ich w repozytorium kodu ani nie publikuj ich publicznie.
Bezpieczne zarządzanie tokenami użytkowników
Tokeny użytkownika obejmują zarówno tokeny odświeżania, jak i tokeny dostępu używane przez aplikację. Przechowuj tokeny bezpiecznie w stanie spoczynku i nigdy nie przesyłaj ich w postaci zwykłego tekstu. Użyj bezpiecznego systemu pamięci masowej odpowiedniego dla Twojej platformy, takiego jak Keystore na Androidzie, Keychain Services na iOS i macOS lub Credential Locker na Windowsie.
Unieważniaj tokeny, gdy tylko przestaną być potrzebne, i trwale usuwaj je ze swoich systemów.
Oprócz tego weź pod uwagę te sprawdzone metody dotyczące Twojej platformy:
- W przypadku aplikacji po stronie serwera, które przechowują tokeny wielu użytkowników, zaszyfruj je w spoczynku i upewnij się, że Twój magazyn danych nie jest publicznie dostępny w internecie.
- W przypadku aplikacji komputerowych zdecydowanie 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.
Tokeny z ograniczeniami nadawcy z DPoP
Aby chronić aplikację przed kradzieżą tokenów i atakami typu replay, rozważ ograniczenie tokenów do nadawcy za pomocą DPoP (Demonstrating Proof-of-Possession). Standardowe tokeny okaziciela mogą być używane przez dowolną stronę, która je przechwyci, natomiast tokeny DPoP są kryptograficznie powiązane z unikalną parą kluczy wygenerowaną i przechowywaną przez klienta.
W przypadku korzystania z DPoP klient przedstawia dowód (podpisany token internetowy JSON) punktowi końcowemu tokena podczas żądania lub odświeżania tokenów odświeżania. To potwierdzenie dowodzi, że klient posiada klucz prywatny odpowiadający kluczowi publicznemu powiązanemu z tokenem. Jeśli token odświeżania powiązany z DPoP wycieknie, atakujący nie będzie mógł go odtworzyć bez tego klucza prywatnego.
DPoP działa razem z PKCE, zapewniając kompleksową ochronę:
- PKCE chroni kod autoryzacji podczas początkowego procesu przekierowania.
- DPoP chroni długotrwały token odświeżania, zapobiegając atakom typu replay w przypadku jego przejęcia.
Zdecydowanie zalecamy stosowanie DPoP, jeśli Twoja aplikacja:
- Działa jako zainstalowana aplikacja lub aplikacja komputerowa (albo aplikacja jednostronicowa połączona z serwerem Backend-for-Frontend), w której tokeny odświeżania mogą być bardziej podatne na eksfiltrację.
- uzyskuje dostęp do wysoce wrażliwych danych lub interfejsów API o wysokiej wartości, gdzie wyciek tokena ma znaczący wpływ;
- Musisz spełniać rygorystyczne standardy zgodności lub bezpieczeństwa, które wymagają tokenów ograniczonych przez nadawcę.
Szczegółowe instrukcje tworzenia dowodów DPoP i żądania tokenów powiązanych z DPoP znajdziesz w przewodniku po wdrażaniu DPoP.
Używanie parametru stanu
Przed przetworzeniem odpowiedzi OAuth 2.0 sprawdź, czy parametr state otrzymany od Google jest zgodny z parametrem state wysłanym w żądaniu autoryzacji. Parametr state powinien być unikalną, niemożliwą do odgadnięcia wartością wygenerowaną przez aplikację.
Użycie parametru state pomaga upewnić się, że żądanie wysyła użytkownik, a nie złośliwy skrypt, i zmniejsza ryzyko ataków polegających na fałszowaniu żądań z innej witryny (CSRF).
Obsługa unieważnienia i wygaśnięcia tokena odświeżania
Jeśli Twoja aplikacja poprosiła o token odświeżania na potrzeby dostępu offline, musisz też obsłużyć jego unieważnienie lub wygaśnięcie. Tokeny mogą zostać unieważnione z różnych powodów, na przykład gdy wygasną lub gdy dostęp aplikacji zostanie cofnięty przez użytkownika lub proces automatyczny. W takim przypadku zastanów się, jak powinna zareagować aplikacja, np. czy powinna wyświetlić użytkownikowi prośbę przy następnym logowaniu lub usunąć jego dane. Aby otrzymywać powiadomienia o unieważnieniu tokena, zintegruj aplikację z usługą Ochrona wszystkich kont.
Używanie autoryzacji przyrostowej
Użyj autoryzacji przyrostowej, aby poprosić o odpowiednie zakresy OAuth, gdy aplikacja potrzebuje danej funkcji.
Nie proś o dostęp do danych, gdy użytkownik po raz pierwszy przechodzi uwierzytelnianie, chyba że jest to niezbędne do działania głównej funkcji aplikacji. Zamiast tego poproś tylko o określone zakresy, które są potrzebne do wykonania zadania, zgodnie z zasadą wybierania najmniejszych, najbardziej ograniczonych zakresów.
Zawsze proś o zakresy w odpowiednim kontekście, aby użytkownicy rozumieli, dlaczego aplikacja prosi o dostęp i jak dane będą wykorzystywane.
Aplikacja może na przykład działać według tego modelu:
- Użytkownik uwierzytelnia się w aplikacji.
- Nie są wymagane żadne dodatkowe zakresy. Aplikacja zapewnia podstawowe funkcje, które umożliwiają użytkownikowi przeglądanie 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 wymaganego przez tę funkcję. Jeśli ta funkcja wymaga wielu zakresów, postępuj zgodnie ze sprawdzonymi metodami dotyczącymi wielu zakresów.
- Jeśli użytkownik odrzuci prośbę, aplikacja wyłączy funkcję i poda użytkownikowi dodatkowe informacje, aby ponownie poprosić o dostęp.
Obsługa zgody na dostęp do wielu zakresów
Jeśli poprosisz o kilka zakresów naraz, użytkownicy mogą nie przyznać wszystkich zakresów protokołu OAuth, o które prosisz. Aplikacja powinna obsłużyć odmowę dostępu do zakresów, wyłączając odpowiednie funkcje.
Jeśli podstawowe funkcje aplikacji wymagają wielu zakresów, wyjaśnij to użytkownikowi, zanim poprosisz go o zgodę.
Możesz ponownie poprosić użytkownika o zgodę tylko wtedy, gdy wyraźnie wskaże on, że chce użyć konkretnej funkcji, która wymaga danego zakresu. Zanim aplikacja poprosi o zakresy OAuth, powinna podać użytkownikowi odpowiedni kontekst i uzasadnienie.
Należy zminimalizować liczbę zakresów, o które aplikacja prosi jednocześnie. Zamiast tego użyj autoryzacji przyrostowej, aby poprosić o zakresy w kontekście funkcji.
Korzystanie z bezpiecznych przeglądarek
W internecie żądania autoryzacji OAuth 2.0 można wysyłać tylko z pełnych przeglądarek internetowych. Na innych platformach wybierz odpowiedni typ klienta OAuth i zintegruj protokół OAuth w sposób odpowiedni dla danej platformy. Nie przekierowuj żądania przez wbudowane środowiska przeglądania, w tym komponenty WebView na platformach mobilnych, takie jak WebView na Androidzie czy WKWebView na iOS. Zamiast tego użyj zalecanych bibliotek OAuth lub Logowania przez Google na swojej platformie.
Ręczne tworzenie i konfigurowanie klientów OAuth
Aby zapobiec nadużyciom, klientów OAuth nie można tworzyć ani modyfikować automatycznie. Musisz użyć konsoli Google Cloud, aby wyraźnie zaakceptować warunki korzystania z usługi, skonfigurować klienta OAuth i przygotować się do weryfikacji OAuth.
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 aplikacji lub stali się nieaktualni. Pozostawienie skonfigurowanych nieużywanych klientów stanowi potencjalne zagrożenie bezpieczeństwa, ponieważ klient może zostać niewłaściwie wykorzystany, jeśli dane logowania klienta zostaną przejęte.
Aby jeszcze bardziej ograniczyć ryzyko związane z nieużywanymi klientami, klienty OAuth 2.0, które były nieaktywne przez 6 miesięcy, są automatycznie usuwane.
Zalecamy, aby nie czekać na automatyczne usunięcie, ale aktywnie usuwać nieużywanych klientów. Ta praktyka minimalizuje powierzchnię ataku na aplikację i zapewnia dobrą higienę bezpieczeństwa.