Zgodność z zasadami OAuth 2.0

Z tego przewodnika dowiesz się, jak dostosować aplikację do wymagań, aby rozwiązać najczęstsze problemy deweloperów podczas przygotowywania aplikacji do wersji produkcyjnej.

Przegląd

Gdy będziesz gotowy(-a) do wdrożenia zaimplementowanego rozwiązania poza środowiskiem programistycznym, aby udostępnić je użytkownikom aplikacji, być może będziesz musiał(-a) wykonać dodatkowe czynności, aby zapewnić zgodność z zasadami Google dotyczącymi protokołu OAuth 2.0. Z tego przewodnika dowiesz się, jak dostosować aplikację do wymagań, aby rozwiązać najczęstsze problemy deweloperów podczas przygotowywania aplikacji do wersji produkcyjnej. Dzięki temu możesz dotrzeć do jak największej liczby odbiorców przy minimalnej liczbie błędów.

Używanie osobnych projektów do testowania i wersji produkcyjnej

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

Klienci Google OAuth używani w wersji produkcyjnej zapewniają 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, a tym samym może on podlegać 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ź klienty OAuth w tym projekcie, które mogą być powiązane 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 Twoich klientów.
  4. Sprawdź konfigurację ekranu akceptacji OAuth w nowym projekcie na stronie marki w konsoli Google Cloud.

Klienci Google OAuth używani w wersji produkcyjnej 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;
  • testowe lub przedpremierowe wersje aplikacji.

Prowadzenie listy osób kontaktowych w kwestiach związanych z projektem

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

Rola zawiera zestaw uprawnień, które pozwalają wykonywać określone działania na zasobach projektu. Edytujący projekt mają uprawnienia do działań, które modyfikują stan, np. do wprowadzania zmian na ekranie akceptacji OAuth w projekcie. 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 projektu mogą też podać kontekst, dlaczego informacje rozliczeniowe mogą być ustawione. Właściciele projektu mogą skonfigurować informacje rozliczeniowe dla projektu, który korzysta z płatnych interfejsów API.

Właściciele i edytujący projekt muszą być na bieżąco informowani o zmianach. Aby zapewnić ciągły dostęp do projektu i związaną z nim konserwację, możesz dodać do projektu kilka odpowiednich kont. Gdy pojawią się powiadomienia dotyczące Twojego projektu lub aktualizacje naszych usług, wysyłamy e-maile na te konta. Administratorzy organizacji Google Cloud muszą dopilnować, aby z każdym projektem w organizacji było powiązane konto, z którym można się skontaktować. Jeśli nie będziemy mieć aktualnych informacji kontaktowych dotyczących Twojego projektu, możesz przegapić ważne wiadomości, które wymagają Twojej reakcji.

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

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

W przypadku aplikacji produkcyjnych informacje o marce zdefiniowane na ekranie zgody OAuth muszą zostać zweryfikowane zanim będą wyświetlane użytkownikom. Użytkownicy mogą chętniej przyznawać dostęp do Twojej aplikacji po zakończeniu weryfikacji marki. Podstawowe informacje o aplikacji, w tym 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 cofnąć lub zawiesić dostęp do usług interfejsów API Google oraz innych usług i produktów Google w przypadku aplikacji, które fałszywie przedstawiają swoją tożsamość lub próbują wprowadzić użytkowników w błąd.

Żądanie tylko potrzebnych zakresów

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

Zapoznaj się z 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 potrzebnych aplikacji. Zapoznaj się z wszelkimi przewodnikami autoryzacji, które oferuje interfejs API, i opisz ich zakresy bardziej szczegółowo, aby uwzględnić najczęstsze zastosowania. Wybierz minimalny dostęp do danych, którego potrzebuje Twoja aplikacja, aby obsługiwać powiązane funkcje.

Więcej informacji o tym wymaganiu znajdziesz w sekcji Żądanie tylko potrzebnych zakresów w zasadach dotyczących protokołu OAuth 2.0 oraz w sekcji Prośba o odpowiednie uprawnienia w zasadach dotyczących danych użytkowników w usługach interfejsów API Google.

Przesyłanie do weryfikacji aplikacji produkcyjnych, które używają zakresów niewrażliwych lub nieobjętych ograniczeniami

Podczas uwierzytelniania użytkownika funkcja Zaloguj się przez Google nie wymaga podania zakresów wrażliwych i objętych ograniczeniami. Jeśli Twoja aplikacja używa funkcji Zaloguj się przez Google tylko do uwierzytelniania, musisz przesłać ją do weryfikacji marki. Możesz przesłać aplikację do weryfikacji w konsoli Google Cloud na stronie marki. Ta weryfikacja jest niezbędna do wyświetlania elementów marki aplikacji – w tym nazwy, logo, polityki prywatności, warunków korzystania z usługi i zakresów – na ekranie akceptacji.

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

Używanie tylko domen, których jesteś właścicielem(-ką)

Proces weryfikacji ekranu akceptacji OAuth w Google wymaga weryfikacji wszystkich domen powiązanych ze stroną główną projektu, polityką prywatności, warunkami korzystania z usługi, autoryzowanymi identyfikatorami URI przekierowania lub autoryzowanymi źródłami JavaScript. Sprawdź listę domen używanych przez Twoją aplikację, podsumowaną w sekcji Autoryzowane domeny w edytorze ekranu zgody OAuth, i zidentyfikuj domeny, których nie jesteś właścicielem(-ką) 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 wspólną, 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órej już jesteś właścicielem(-ką).

Hostowanie strony głównej 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 Twojej aplikacji mogą odwiedzić stronę główną, aby dowiedzieć się więcej o funkcjach i możliwościach aplikacji. Dotychczasowi użytkownicy mogą sprawdzić listę dotychczasowych uprawnień i odwiedzić stronę główną Twojej aplikacji, aby przypomnieć sobie o dalszym korzystaniu z Twojej oferty.

Strona główna Twojej aplikacji musi zawierać opis funkcji aplikacji oraz 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(-ką).

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

Klienci OAuth 2.0 w przypadku aplikacji internetowych muszą zabezpieczać swoje 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 za pomocą lokalizacji identyfikatorów URI przekierowania, które są ograniczone do weryfikowania i przechowywania danych tokena.

Dalsze kroki

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