Zgodność z zasadami OAuth 2.0

Gdy wszystko będzie gotowe do wdrożenia u użytkowników aplikacji zaimplementowanego rozwiązania spoza środowiska programistycznego, może być konieczne wykonanie dodatkowych czynności, aby zapewnić zgodność z zasadami Google dotyczącymi protokołu OAuth 2.0. W tym przewodniku pokazujemy, jak zapewnić zgodność z najczęstszymi problemami deweloperów, jakie pojawiają się podczas przygotowywania aplikacji do produkcji. Pomoże Ci to dotrzeć do największej możliwej grupy odbiorców z ograniczoną liczbą błędów.

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

Zasady Google dotyczące protokołu OAuth wymagają oddzielnych projektów na potrzeby testowania i produkcji. Niektóre zasady i wymagania dotyczą tylko aplikacji produkcyjnych. Może być konieczne utworzenie i skonfigurowanie osobnego projektu obejmującego klienty OAuth odpowiadające wersji produkcyjnej aplikacji dostępnej dla wszystkich kont Google.

Klienty Google OAuth używane w środowisku produkcyjnym pomagają zapewnić bardziej stabilne, przewidywalne i bezpieczne środowisko zbierania 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, dlatego podlega dodatkowym wymaganiom dotyczącym określonych zakresów interfejsów API, które mogą obejmować oceny zabezpieczeń przygotowane przez inne firmy.

  1. Go to the Google API Console. Click Create project, enter a name, and click Create.
  2. Sprawdź w tym projekcie klienty OAuth, 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 wszystkie interfejsy API używane przez klientów.
  4. Sprawdź konfigurację ekranu akceptacji OAuth w nowym projekcie.

Klienty Google OAuth używane w środowisku produkcyjnym nie mogą zawierać środowisk testowych, identyfikatorów URI przekierowań 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

Utwórz listę osób kontaktowych związanych z projektem.

Możliwe, że zarówno firma Google, jak i poszczególne interfejsy API, które włączasz, będą musiały kontaktować się z Tobą w sprawie zmian w usługach lub nowych konfiguracji wymaganych w przypadku Twojego projektu i jego klientów. Sprawdź Uprawnienia projektu, aby upewnić się, że odpowiednie osoby w Twoim zespole mogą edytować lub wyświetlać konfigurację projektu. Te konta mogą też otrzymywać e-maile z informacjami o wymaganych zmianach w projekcie.

Rola obejmuje zbiór uprawnień, które pozwalają wykonywać określone działania na zasobach projektu. Edytujący projekt mają uprawnienia do działań, które zmieniają stan, np. do wprowadzania zmian na ekranie zgody OAuth w projekcie. Właściciele projektu, którzy mają wszystkie uprawnienia do edycji, mogą dodawać i usuwać konta powiązane z projektem, a także usunąć projekt. Właściciele projektów mogą też podać kontekst, dla którego warto ustawić informacje rozliczeniowe. Właściciele projektów mogą skonfigurować informacje rozliczeniowe w projekcie, w którym używane są płatne interfejsy API.

Właściciele i edytujący projekt muszą być na bieżąco. Możesz dodać do projektu wiele odpowiednich kont, by zapewnić sobie stały dostęp do projektu i powiązanej z nim konserwacji. Gdy pojawią się powiadomienia dotyczące Twojego projektu lub aktualizacji w naszych usługach, wysyłamy na te konta e-maile. Administratorzy organizacji Google Cloud muszą dopilnować, aby z każdym projektem w organizacji powiązany jest osiągalny kontakt. Jeśli nie będziemy mieć aktualnych informacji kontaktowych dotyczących Twojego projektu, możesz przegapić ważne wiadomości wymagające Twojego działania.

Przedstaw swoją tożsamość w sposób precyzyjny

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ść Twojej aplikacji. Informacje o marce aplikacji są konfigurowane przez OAuth Consent Screen page.

W przypadku aplikacji produkcyjnych informacje o marce zdefiniowane na ekranie zgody OAuth muszą zostać zweryfikowane, zanim będą wyświetlane użytkownikom. Gdy tylko aplikacja przejdzie weryfikację marki, może być bardziej prawdopodobne, że użytkownicy przyznają jej dostęp. Podstawowe informacje o aplikacji, w tym nazwa aplikacji, jej strona główna, warunki korzystania z usługi i polityka prywatności, są wyświetlane użytkownikom na ekranie przyznawania uprawnień, podczas sprawdzania już przyznanych uprawnień, lub administratorom Google Workspace, którzy sprawdzają użycie aplikacji przez ich organizację.

Google może odebrać lub zawiesić dostęp do usług interfejsów API Google oraz innych usług Google w przypadku aplikacji, które wprowadzają użytkowników w błąd co do swojej tożsamości lub próbują oszukiwać użytkowników.

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

W trakcie tworzenia aplikacji możesz użyć przykładowego zakresu udostępnianego przez interfejs API, aby utworzyć model koncepcyjny w aplikacji, aby dowiedzieć się więcej o funkcjach i funkcjach interfejsu API. Te przykładowe zakresy często wymagają więcej informacji niż ostateczna implementacja aplikacji, ponieważ obejmują one wszystkie możliwe działania dla danego interfejsu API. Zakres przykładowy może na przykład żądać uprawnień do odczytu, zapisu i usuwania, a aplikacja wymaga tylko uprawnień do odczytu. Poproś o odpowiednie uprawnienia, które ograniczają się do najważniejszych informacji niezbędnych do zaimplementowania aplikacji.

Przejrzyj dokumentację referencyjną punktów końcowych interfejsu API wywoływanych przez Twoją aplikację i zanotuj zakresy, które są wymagane do uzyskania dostępu do odpowiednich danych, których potrzebuje Twoja aplikacja. Przejrzyj wszystkie przewodniki autoryzacji dostępne w interfejsie API i opisz ich zakresy bardziej szczegółowo, aby uwzględnić najczęstsze zastosowania. Wybierz jak najbardziej minimalny dostęp do danych, jakiego aplikacja potrzebuje do obsługi powiązanych funkcji.

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

Przesyłanie do weryfikacji aplikacji produkcyjnych, które używają zakresów wrażliwych lub zakresów z ograniczeniami

Niektóre zakresy są klasyfikowane jako „wrażliwe” lub „z ograniczonym dostępem” i nie można ich używać w aplikacjach produkcyjnych bez sprawdzenia. Wpisz wszystkie zakresy, których używa aplikacja w wersji produkcyjnej, w konfiguracji ekranu akceptacji OAuth. Jeśli Twoja aplikacja produkcyjna używa zakresów wrażliwych lub zakresów z ograniczeniami, przed uwzględnieniem zakresów w żądaniu autoryzacji musisz przesłać informacje o wykorzystaniu tych zakresów do weryfikacji.

Używaj tylko własnych domen

Opracowany przez Google proces weryfikacji ekranu zgody OAuth wymaga weryfikacji wszystkich domen powiązanych ze stroną główną Twojego 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 aplikację podsumowaną w sekcji Autoryzowane domeny w edytorze ekranu zgody OAuth i znajdź domeny, które do Ciebie nie należą i w związku z czym nie możesz ich zweryfikować. Własność autoryzowanych domen projektu możesz potwierdzić za pomocą Google Search Console. Użyj konta Google powiązanego z Twoim API Console projektem jako właściciela lub edytującego.

Jeśli Twój projekt korzysta z dostawcy usług ze wspólną, współdzieloną domeną, zalecamy włączenie konfiguracji, które zezwalają na korzystanie z Twojej domeny. Niektórzy dostawcy oferują mapowanie swoich usług na subdomenę domeny, którą już masz.

Hostowanie strony głównej aplikacji produkcyjnej

Każda aplikacja produkcyjna używająca protokołu OAuth 2.0 musi mieć publicznie dostępną stronę główną. Potencjalni użytkownicy Twojej aplikacji mogą odwiedzić stronę główną, by dowiedzieć się więcej o jej funkcjach i funkcjach. Istniejący już użytkownicy mogą przejrzeć swoje listy obecnych grantów i wejść na 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 istnieć w zweryfikowanej domenie należącej do Ciebie.

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

Klienty OAuth 2.0 na potrzeby aplikacji internetowych muszą zabezpieczyć swoje dane za pomocą identyfikatorów URI przekierowań 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 lub nie są rozwiązywane w ramach bezpiecznego kontekstu.

Zastanów się, które aplikacje i skrypty innych firm mogą mieć dostęp do tokenów i innych danych logowania użytkownika powracających na Twoją stronę. Ogranicz dostęp do danych wrażliwych za pomocą identyfikatorów URI przekierowania, które są ograniczone do weryfikowania i przechowywania danych tokenów.

Dalsze kroki

Gdy upewnisz się, że aplikacja jest zgodna z zasadami OAuth 2.0 opisanymi na tej stronie, szczegółowe informacje o procesie weryfikacji znajdziesz w sekcji Przesyłanie do weryfikacji marki.