Zgodność z zasadami OAuth 2.0

Z tego przewodnika dowiesz się, jak rozwiązać najczęstsze problemy, które deweloperzy napotykają podczas przygotowywania aplikacji do wdrożenia w wersji produkcyjnej.

Przegląd

Gdy zechcesz wdrożyć zaimplementowane rozwiązanie poza środowiskiem programistycznym i udostępnić je użytkownikom aplikacji, konieczne może być wykonanie dodatkowych czynności, aby zachować zgodność z zasadami Google dotyczącymi protokołu OAuth 2.0. W tym przewodniku opisujemy, jak rozwiązać najczęstsze problemy deweloperów, które pojawiają się podczas przygotowywania aplikacji do wersji produkcyjnej. Dzięki temu dotrzesz do jak największej liczby odbiorców przy minimalnej liczbie błędów.

Używanie osobnych projektów do testowania i produkcji

Zasady Google dotyczące protokołu OAuth wymagają osobnych projektów do testowania i produkcji. Niektóre zasady i wymagania dotyczą tylko aplikacji produkcyjnych. Może być konieczne utworzenie i skonfigurowanie osobnego projektu, który zawiera klientów OAuth odpowiadających wersji produkcyjnej aplikacji dostępnej dla wszystkich kont Google.

Klienci Google OAuth używani w środowisku produkcyjnym pomagają zapewnić bardziej stabilne, przewidywalne i bezpieczne środowisko zbierania danych i przechowywania danych niż podobni klienci OAuth, którzy testują lub debugują tę samą aplikację. Projekt produkcyjny można przesłać do weryfikacji, dlatego podlega on dodatkowym wymaganiom dotyczącym określonych zakresów interfejsu API, które mogą obejmować oceny bezpieczeństwa przeprowadzane przez firmy zewnętrzne.

  1. Otwórz konsolę interfejsów API Google. Kliknij Utwórz projekt, wpisz nazwę i kliknij Utwórz.
  2. Sprawdź klientów OAuth w tym projekcie, którzy mogą być powiązani z Twoim poziomem testowania. W razie potrzeby utwórz podobnych klientów OAuth dla klientów produkcyjnych w projekcie produkcyjnym.
  3. Włącz wszystkie interfejsy API używane przez klientów.
  4. Sprawdź konfigurację ekranu zgody OAuth dla nowego projektu na stronie Marka w konsoli Cloud.

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

  • serwery testowe poszczególnych deweloperów;
  • wersje testowe lub przedpremierowe aplikacji;

prowadzić listę odpowiednich osób kontaktowych w projekcie;

Google i poszczególne włączone przez Ciebie interfejsy API mogą potrzebować kontaktu z Tobą w sprawie zmian w usługach lub nowych konfiguracji wymaganych w Twoim projekcie i jego klientach. Przejrzyj listy uprawnień projektu, aby upewnić się, że odpowiednie osoby w Twoim zespole mają dostęp do edytowania lub wyświetlania konfiguracji projektu. Na te konta mogą też przychodzić e-maile o wymaganych zmianach w projekcie.

Rola obejmuje zestaw uprawnień, które umożliwiają wykonywanie określonych działań na zasobach projektu. Edytujący projekt mają uprawnienia do wykonywania działań, które zmieniają stan, takich jak wprowadzanie zmian na ekranie zgody OAuth projektu. Właściciele projektu, którzy mają wszystkie uprawnienia edytującego, mogą dodawać i usuwać konta powiązane z projektem oraz usuwać projekt. Właściciele projektów mogą też podać kontekst, w którym informacje rozliczeniowe mogą być ustawione. Właściciele projektów mogą skonfigurować informacje rozliczeniowe dla projektu, który korzysta z płatnych interfejsów API.

Właściciele projektu i edytujący muszą być na bieżąco aktualizowani. Do projektu możesz dodać wiele odpowiednich kont, aby zapewnić stały dostęp do projektu i powiązanych z nim czynności konserwacyjnych. Na te konta wysyłamy e-maile z powiadomieniami o Twoim projekcie lub aktualizacjami naszych usług. Administratorzy organizacji Google Cloud muszą zadbać o to, aby z każdym projektem w organizacji była powiązana osoba kontaktowa, z którą można się skontaktować. Jeśli nie będziemy mieć aktualnych danych kontaktowych Twojego projektu, możesz przegapić ważne wiadomości, które wymagają podjęcia działań.

Dokładne określenie swojej tożsamości

Podaj prawidłową nazwę aplikacji i opcjonalnie logo, które będzie wyświetlane użytkownikom. Te informacje o marce muszą dokładnie odzwierciedlać tożsamość aplikacji. Informacje o marce aplikacji są konfigurowane na stronie marki OAuth.

W przypadku aplikacji produkcyjnych informacje o marce zdefiniowane na ekranie zgody OAuth muszą zostać zweryfikowane, zanim zostaną wyświetlone użytkownikom. Użytkownicy mogą być bardziej skłonni do przyznania dostępu do aplikacji po zakończeniu weryfikacji marki. Podstawowe informacje o aplikacji, takie jak jej nazwa, strona główna, warunki korzystania z usługi i polityka prywatności, są wyświetlane użytkownikom na ekranie przyznawania uprawnień, gdy sprawdzają oni swoje dotychczasowe uprawnienia, lub administratorom Google Workspace, którzy sprawdzają, jak aplikacja jest używana w ich organizacji.

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

Proś tylko o potrzebne zakresy

Podczas tworzenia aplikacji możesz użyć przykładowego zakresu udostępnionego przez interfejs API, aby utworzyć w aplikacji wersję testową i dowiedzieć się więcej o funkcjach i możliwościach interfejsu API. Te przykładowe zakresy często żądają więcej informacji, niż wymaga ostateczna implementacja aplikacji, ponieważ zapewniają kompleksową obsługę wszystkich możliwych działań w przypadku danego interfejsu API. Na przykład przykładowy zakres może żądać uprawnień do odczytu, zapisu i usuwania, podczas gdy aplikacja wymaga tylko uprawnień do odczytu. Poproś o odpowiednie uprawnienia, które są ograniczone do najważniejszych informacji niezbędnych do wdrożenia aplikacji.

Przejrzyj dokumentację referencyjną punktów końcowych interfejsu API, które wywołuje Twoja aplikacja, i zwróć uwagę na zakresy, których wymagają, aby uzyskać dostęp do odpowiednich danych potrzebnych aplikacji. Zapoznaj się z przewodnikami po autoryzacji dostępnymi w interfejsie API i opisz zakresy bardziej szczegółowo, uwzględniając najczęstsze przypadki użycia. Wybierz minimalny dostęp do danych, którego aplikacja potrzebuje do obsługi powiązanych funkcji.

Więcej informacji o tym wymaganiu znajdziesz w sekcji Proś tylko o te zakresy, których potrzebujesz w zasadach dotyczących protokołu OAuth 2.0 oraz w sekcji Proś o odpowiednie uprawnienia w zasadach dotyczących danych użytkownika w usługach interfejsów API Google.

Przesyłanie do weryfikacji aplikacji produkcyjnych, które używają zakresów niewrażliwych lub bez ograniczeń

Funkcja Zaloguj się przez Google nie żąda zakresów wrażliwych ani zakresów z ograniczeniami podczas uwierzytelniania użytkownika. Jeśli aplikacja korzysta z funkcji Zaloguj się przez Google tylko do uwierzytelniania, musisz przesłać ją do weryfikacji marki. Możesz przesłać aplikację do weryfikacji na stronie Marka w konsoli Google Cloud. Weryfikacja jest konieczna, aby na ekranie zgody wyświetlać elementy marki aplikacji, w tym nazwę, logo, politykę prywatności, warunki korzystania z usługi i zakresy.

Zdecydowanie zalecamy, aby Twoja aplikacja była zgodna z oficjalnymi wytycznymi dotyczącymi marki w zakresie umieszczania przycisku logowania.

Używaj tylko domen, które należą do Ciebie.

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

Jeśli Twój projekt korzysta z usług dostawcy z powszechną, współdzieloną domeną, zalecamy włączenie konfiguracji, które umożliwią korzystanie z własnej domeny. Niektórzy dostawcy oferują mapowanie swoich usług na subdomenę domeny, którą już posiadasz.

hostować stronę główną aplikacji produkcyjnych;

Każda aplikacja produkcyjna, która korzysta z protokołu OAuth 2.0, musi mieć publicznie dostępną stronę główną. Potencjalni użytkownicy aplikacji mogą odwiedzić stronę główną, aby dowiedzieć się więcej o funkcjach i możliwościach, które oferuje aplikacja. Dotychczasowi użytkownicy mogą przejrzeć listę przyznanych uprawnień i odwiedzić stronę główną aplikacji, aby przypomnieć sobie, że nadal korzystają 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 znajdować się w zweryfikowanej domenie, której jesteś właścicielem.

Używanie bezpiecznych identyfikatorów URI przekierowania i źródeł JavaScript

Klienty OAuth 2.0 dla aplikacji internetowych muszą zabezpieczać dane za pomocą identyfikatorów URI przekierowania 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 lub nie są do niego kierowane.

Zastanów się, które aplikacje i skrypty innych firm mogą mieć dostęp do tokenów i innych danych logowania użytkowników, które wracają na Twoją stronę. Ogranicz dostęp do danych wrażliwych, używając lokalizacji identyfikatorów URI przekierowania, które są ograniczone do weryfikowania i przechowywania danych tokenów.

Dalsze kroki

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