Zgodność z zasadami OAuth 2.0

Gdy będziesz gotowy do wdrożenia zaimplementowanego rozwiązania poza środowiskiem programistycznym dla użytkowników aplikacji, może być konieczne podjęcie dodatkowych działań w celu zapewnienia zgodności z zasadami Google dotyczącymi OAuth 2.0. W tym przewodniku wyjaśniamy, jak uzyskać zgodność z najczęstszymi problemami deweloperów, które pojawiają się podczas przygotowywania aplikacji do wdrożenia w środowisku produkcyjnym. Dzięki temu możesz docierać do jak największej liczby odbiorców z minimalną liczbą błędów.

Używanie oddzielnych projektów na potrzeby testowania i produkcji

Zasady Google dotyczące protokołu OAuth wymagają osobnych projektów do testowania i do celów produkcyjnych. 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.

Klienty Google OAuth używane w wersji produkcyjnej zapewniają stabilniejsze, bardziej przewidywalne i bezpieczne środowisko gromadzenia i przechowywania danych niż podobne klienty OAuth, które testują lub debugują tę samą aplikację. Twój projekt produkcyjny może zostać przesłany do weryfikacji i w związku z tym podlegać dodatkowym wymaganiom dotyczącym konkretnych zakresów API, które mogą obejmować zewnętrzne oceny bezpieczeństwa.

  2. Sprawdź klienty OAuth w tym projekcie, które mogą być powiązane z poziomem testowym. W razie potrzeby utwórz podobne 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 w nowym projekcie.

Klienci Google OAuth używani w wersji produkcyjnej nie mogą zawierać środowisk testowych, identyfikatorów URI przekierowania ani źródeł JavaScriptu dostępnych tylko dla Ciebie lub Twojego zespołu programistów. Oto kilka przykładów:

  • serwery testowe poszczególnych programistów;
  • Testowanie wersji aplikacji lub wersji przedpremierowych

sporządzić listę odpowiednich kontaktów w przypadku projektu;

Google i poszczególne interfejsy API, które włączysz, mogą się z Tobą skontaktować w sprawie zmian w usługach lub nowych konfiguracji wymaganych przez Twój projekt i jego klientów. Sprawdź listy uprawnień w danym projekcie, aby mieć pewność, że odpowiednie osoby w Twoim zespole mają dostęp do edycji lub wyświetlania konfiguracji projektu. Te konta mogą też otrzymywać e-maile o wymaganych zmianach w Twoim projekcie.

Rola zawiera zestaw uprawnień, które umożliwiają wykonywanie określonych działań na zasobach projektu. Edytorzy projektu mają uprawnienia do działań, które zmieniają stan, np. możliwość wprowadzania zmian w ekranie zgody OAuth projektu. Właściciele projektu, którzy mają wszystkie uprawnienia edytującego, mogą dodawać i usuwać konta powiązane z projektem, a także usunąć projekt. Właściciele projektów mogą też podać kontekst, w jakim mogą być ustawione informacje rozliczeniowe. 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. Możesz dodać do projektu wiele odpowiednich kont, aby zapewnić nieprzerwany dostęp do projektu i związaną z nim konserwację. Wysyłamy na te konta e-maile, gdy pojawiają się powiadomienia dotyczące Twojego projektu lub aktualizacje naszych usług. Administratorzy organizacji Google Cloud muszą sprawdzić, czy z każdym projektem w organizacji powiązana jest dostępna osoba kontaktowa. Jeśli nie mamy aktualnych informacji kontaktowych dotyczących Twojego projektu, możesz nie otrzymywać ważnych wiadomości, które wymagają Twojej interwencji.

Dokładnie przedstawiać Twoją tożsamość

Podaj prawidłową nazwę aplikacji i opcjonalnie logo, które będzie widoczne dla użytkowników. Informacje o marce muszą dokładnie odzwierciedlać tożsamość aplikacji. Informacje o brandingu aplikacji są konfigurowane w ustawieniach OAuth .

W przypadku aplikacji produkcyjnych informacje o marces, zdefiniowane na ekranie akceptacji OAuth, muszą zostać zweryfikowane, zanim będą wyświetlane użytkownikom. Użytkownicy chętniej udzielą dostępu do aplikacji, gdy ta przejdzie weryfikację 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 grantu, gdy sprawdzają oni swoje dotychczasowe granty, lub administratorom Google Workspace, którzy sprawdzają korzystanie z aplikacji przez ich organizację.

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

Proś o wybrane zakresy uprawnień

Podczas tworzenia aplikacji możesz użyć przykładowego zakresu interfejsu API, aby stworzyć w niej prototyp, który pozwoli Ci dowiedzieć się więcej o jego funkcjach i możliwościach. Te przykładowe zakresy często wymagają więcej informacji niż potrzebuje ich ostateczne wdrożenie aplikacji, ponieważ obejmują wszystkie możliwe działania w ramach danego interfejsu API. Na przykład zakres może wymagać uprawnień do odczytu, zapisu i usuwania, a Twoja aplikacja wymaga tylko uprawnień do odczytu. Poproś o odpowiednie uprawnienia, które są ograniczone do kluczowych informacji niezbędnych do wdrożenia aplikacji.

Zapoznaj się z dokumentacją referencyjną punktów końcowych interfejsu API, do których odwołuje się Twoja aplikacja, i zapisz zakresy, których potrzebują one do uzyskania dostępu do danych, których potrzebuje aplikacja. Przejrzyj wszystkie przewodniki dotyczące autoryzacji oferowane przez interfejs API i bardziej szczegółowo opisz ich zakresy z uwzględnieniem najczęstszych zastosowań. Wybierz minimalny dostęp do danych, którego Twoja aplikacja potrzebuje do obsługi powiązanych funkcji.

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

Przesyłanie do weryfikacji aplikacji produkcyjnych korzystających z zakresów wrażliwych lub zakresów z ograniczeniami

Niektóre zakresy są klasyfikowane jako „wrażliwe” lub „ograniczone” i nie można ich używać w aplikacji produkcyjnych bez sprawdzenia. Podaj wszystkie zakresy używane przez aplikację w wersji produkcyjnej w jej konfiguracji ekranu akceptacji OAuth. Jeśli aplikacja w wersji produkcyjnej korzysta z zakresów wrażliwych lub z ograniczeniem, przed uwzględnieniem tych zakresów w prośbie o autoryzację musisz przesłać do weryfikacji sposób ich użycia.

Używaj tylko własnych domen

Przeprowadzany przez Google proces weryfikacji ekranu zgody OAuth 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. Przejrzyj listę domen używanych przez Twoją aplikację widoczną w sekcji Autoryzowane domeny w edytorze ekranu zgody OAuth i zidentyfikuj domeny, które nie należą do Ciebie, w związku z czym 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 jako właściciela lub edytującego.

Jeśli Twój projekt korzysta z dostawcy usług z częstą, współdzieloną domeną, zalecamy włączenie konfiguracji, która umożliwi korzystanie z własnej domeny. Niektórzy dostawcy oferują mapowanie swoich usług na subdomenę domeny, która należy już do Ciebie.

Hostowanie strony głównej aplikacji w wersji produkcyjnej

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ć jej stronę główną, aby dowiedzieć się więcej o jej funkcjach. Dotychczasowi użytkownicy mogą przejrzeć listę dostępnych grantów i odwiedzić stronę główną Twojej 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óra należy do Ciebie.

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

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

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 są zwracane 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 tokenów.

Dalsze kroki

Gdy upewnisz się, że Twoja aplikacja jest zgodna z zasadami OAuth 2.0 opisanymi na tej stronie, zapoznaj się z informacjami o procesie weryfikacji w sekcji Przesłanie aplikacji na potrzeby weryfikacji marki.