Zgodność z zasadami OAuth 2.0

Gdy wszystko będzie gotowe do wdrożenia wdrożonego rozwiązania poza środowiskiem programistycznym, konieczne może być wykonanie dodatkowych czynności, aby zachować zgodność z zasadami OAuth 2.0 Google. Z tego przewodnika dowiesz się, jak zachować zgodność z najczęstszymi problemami dewelopera, które występują podczas przygotowywania aplikacji do produkcji. Dzięki temu możesz dotrzeć do największej liczby odbiorców z ograniczoną liczbą błędów.

Używaj osobnych projektów do testów i produkcji

Zasady OAuth Google wymagają osobnych projektów do testów i produkcji. Niektóre zasady i wymagania dotyczą tylko aplikacji produkcyjnych. Może być konieczne utworzenie i skonfigurowanie osobnego projektu obejmującego klienty OAuth, które odpowiadają wersji produkcyjnej aplikacji dostępnej na wszystkich kontach Google.

Klienty OAuth Google używane w środowisku produkcyjnym ułatwiają uzyskanie bardziej stabilnego, przewidywalnego i bezpiecznego środowiska danych niż podobne klienty OAuth, które testują lub debugują tę samą aplikację. Twój projekt produkcyjny może zostać przesłany do weryfikacji, więc podlega dodatkowym wymaganiom dotyczącym określonych zakresów interfejsu API, które mogą obejmować zewnętrzne testy bezpieczeństwa.

  1. Go to the Google API Console. Click Create project, enter a name, and click Create.
  2. Sprawdź klientów OAuth w tym projekcie, które mogą być powiązane z poziomem testowym. W razie potrzeby utwórz podobne klienty OAuth dla klientów produkcyjnych w projekcie produkcyjnym.
  3. Włącz dowolne interfejsy API używane przez Twoje klienty.
  4. Sprawdź konfigurację Ekran zgody OAuth w nowym projekcie.

Klienty OAuth Google używane w środowisku produkcyjnym nie mogą zawierać środowisk testowych, identyfikatorów URI przekierowań ani źródeł JavaScript, które są dostępne tylko dla Ciebie lub Twojego zespołu programistów. Oto kilka przykładów:

  • Serwery testowe poszczególnych deweloperów
  • Testowanie lub przedpremierowe wersje aplikacji

Utwórz listę kontaktów do projektu

W sprawie zmiany usług lub nowych konfiguracji wymaganych w projekcie i jego klientach być może trzeba będzie skontaktować się z Google i wybranymi przez Ciebie interfejsami API. Przejrzyj wizytówki uprawnień projektu, aby upewnić się, że odpowiednie osoby w Twoim zespole mają uprawnienia do edytowania lub wyświetlania konfiguracji Twojego projektu. Na te konta mogą być też wysyłane e-maile dotyczące wymaganych zmian w projekcie.

Rola zawiera zestaw uprawnień, które umożliwiają wykonywanie określonych działań na zasobach projektu. Edytorzy projektu mają uprawnienia do działań zmieniających stan, takich jak możliwość wprowadzania zmian na ekranie zgody OAuth w projekcie. Właściciele projektu, którzy mają wszystkie uprawnienia do edycji, mogą dodawać lub usuwać konta powiązane z projektem, a także usunąć projekt. Właściciele projektu mogą też podać kontekst, dla którego można ustawić informacje rozliczeniowe. Właściciele projektu mogą konfigurować informacje rozliczeniowe dla projektu korzystającego z płatnych interfejsów API.

Właściciele i edytorzy projektu muszą być na bieżąco uaktualniani. Możesz dodać do projektu wiele kont, aby zapewnić sobie stały dostęp do projektu i powiązaną z nim konserwację. Na te konta wysyłamy e-maile z powiadomieniami o projekcie lub aktualizacjach naszych usług. Administratorzy organizacji w Google Cloud muszą upewnić się, że z każdym projektem w organizacji jest powiązany osiągalny kontakt. Jeśli nie mamy aktualnych informacji kontaktowych dotyczących Twojego projektu, możesz przegapić ważne wiadomości, które wymagają podjęcia działania.

Dokładnie opisz swoją tożsamość

Podaj prawidłową nazwę aplikacji i opcjonalnie logo, które będzie się wyświetlać użytkownikom. Informacje o marce muszą dokładnie odzwierciedlać tożsamość aplikacji. Informacje o budowaniu marki aplikacji konfiguruje się za pomocą protokołu OAuth Consent Screen page.

W przypadku aplikacji w wersji produkcyjnej informacje o marce zdefiniowane na ekranie zgody OAuth muszą zostać zweryfikowane, zanim będą widoczne dla użytkowników. Zwiększa się prawdopodobieństwo, że użytkownicy przyznają dostęp do Twojej aplikacji po zakończeniu weryfikacji marki. Podstawowe informacje o aplikacji, w tym nazwa i strona główna aplikacji, warunki korzystania z usługi oraz polityka prywatności, są wyświetlane użytkownikom na ekranie przyznawania dostępu, gdy sprawdzają oni dotychczasowe przypisania lub administratorzy Google Workspace, którzy sprawdzają korzystanie z aplikacji przez organizację.

Google może cofnąć lub zawiesić dostęp do interfejsów API Google oraz innych produktów i usług Google w przypadku aplikacji, które podają nieprawdziwe informacje o swojej tożsamości lub próbują oszukać użytkowników.

Żądaj tylko zakresów, których potrzebujesz

W trakcie tworzenia aplikacji możesz użyć przykładowego zakresu podanego przez interfejs API, aby utworzyć model koncepcyjny w aplikacji, aby dowiedzieć się więcej o funkcjach i funkcjach tego interfejsu. Te przykładowe zakresy często wymagają więcej informacji niż końcowa implementacja aplikacji, ponieważ zawierają wszystkie możliwe działania dotyczące określonego interfejsu API. Przykładowy zakres może wymagać uprawnień do odczytu, zapisu i usuwania, podczas gdy aplikacja wymaga tylko uprawnień do odczytu. Poproś o przyznanie odpowiednich uprawnień, które są ograniczone do najważniejszych informacji niezbędnych do wdrożenia aplikacji.

Przejrzyj dokumentację referencyjną dotyczącą punktów końcowych interfejsu API, które wywołuje Twoja aplikacja, i zanotuj zakresy wymagane do uzyskania dostępu do odpowiednich danych aplikacji. Przejrzyj przewodniki autoryzacji oferowane przez interfejs API i szczegółowo opisz ich zakresy, aby uwzględnić najczęstsze wykorzystanie. Wybierz minimalny poziom dostępu do danych, którego aplikacja potrzebuje do obsługi powiązanych funkcji.

Więcej informacji o tym wymaganiu znajdziesz w sekcji Prośby o odpowiednie zakresy w zasadach OAuth 2.0 oraz w sekcji Żądanie odpowiednich uprawnień w zasadach dotyczących danych użytkownika usług Google API.

Prześlij aplikacje produkcyjne, które do weryfikacji używają wrażliwych lub ograniczonych zakresów

Niektóre zakresy są sklasyfikowane jako "wrażliwy" i "restricted" nie można ich używać w aplikacjach produkcyjnych bez sprawdzenia. Podaj wszystkie zakresy używane przez aplikację produkcyjną w konfiguracji ekranu zgody OAuth. Jeśli Twoja aplikacja produkcyjna używa zakresów wrażliwych lub zakresów z ograniczeniami, musisz przesłać te zakresy do weryfikacji, zanim uwzględnisz te zakresy w żądaniu autoryzacji.

Używaj tylko własnych domen

Proces weryfikacji ekranu zgody OAuth w Google wymaga weryfikacji wszystkich domen powiązanych z Twoją stroną główną, polityką prywatności, warunkami korzystania z usługi lub autoryzowanymi źródłami JavaScript. Przejrzyj listę domen używanych przez Twoją aplikację, podsumowanie w sekcji Autoryzowane domeny edytora ekranu zgody OAuth i znajdź domeny, które nie należą do Ciebie i nie możesz ich zweryfikować. Aby potwierdzić własność autoryzowanych domen projektu, użyj Google Search Console. Użyj konta Google powiązanego z Twoim projektem API Console jako właściciel lub edytujący.

Jeśli Twój projekt korzysta z usług dostawcy ze wspólnej domeny, zalecamy włączenie konfiguracji, które pozwolą na używanie własnej domeny. Niektórzy dostawcy mapują swoje usługi na subdomenę, którą już masz.

Hostowanie strony głównej aplikacji produkcyjnych

Każda aplikacja produkcyjna korzystająca z protokołu OAuth 2.0 musi mieć publicznie dostępną stronę główną. Potencjalni użytkownicy Twojej aplikacji mogą odwiedzić jej stronę główną, aby dowiedzieć się więcej o dostępnych w niej funkcjach. Obecni użytkownicy mogą przejrzeć listę dotychczasowych grantów i odwiedzić stronę główną aplikacji, aby przypomnieć o dalszym korzystaniu z Twojej oferty.

Strona główna aplikacji musi zawierać opis jej funkcji, a także linki do polityki prywatności i opcjonalnych warunków korzystania z usługi. Strona główna musi istnieć w zweryfikowanej domenie będącej Twoją własnością.

Użyj identyfikatorów URI bezpiecznych przekierowań i źródeł JavaScript

Klienty OAuth 2.0 na potrzeby aplikacji internetowych muszą zabezpieczać swoje dane za pomocą identyfikatorów URI przekierowań HTTPS i źródeł JavaScript, a nie zwykłego protokołu HTTP. Google może odrzucać żądania OAuth, które nie pochodzą z bezpiecznego kontekstu ani nie są z nich usuwane.

Zastanów się, które aplikacje i skrypty innych firm mogą mieć dostęp do tokenów i innych danych logowania użytkownika, które wracają na Twoją stronę. Ogranicz dostęp do danych wrażliwych za pomocą lokalizacji URI przekierowania, które ograniczają weryfikację i przechowywanie danych tokena.

Dalsze kroki

Gdy upewnisz się, że Twoja aplikacja jest zgodna z zasadami OAuth 2.0 na tej stronie, przeczytaj artykuł Przesyłanie do weryfikacji marki, by dowiedzieć się więcej o procesie weryfikacji.