Weryfikacja zakresu wrażliwego

Jeśli aplikacja prosi o pozwolenie na używanie interfejsów API Google w celu uzyskania dostępu do danych, być może do ukończenia procesu weryfikacji przed udostępnieniem obecnie się znajdujesz.

To, czy to wymaganie dotyczy Twojej aplikacji, zależy głównie od 2 czynników:

1. Typ danych użytkownika, do których masz dostęp – informacje o profilu publicznym, wpisy w kalendarzu, pliki w Dysk, niektóre dane o zdrowiu i aktywności fizycznej itp.
2. Wymagany poziom dostępu – tylko do odczytu, odczyt i zapis itp.

Gdy używasz OAuth 2.0, aby uzyskać uprawnienia do dostępu do danych z konta Google, używasz ciągów znaków zwanych zakresami, aby określić typ danych, do których chcesz uzyskać dostęp w imieniu użytkownika. Jeśli zakresy żądań aplikacji sklasyfikowane jako o charakterze kontrowersyjnym lub ograniczone, prawdopodobnie musisz ukończyć proces weryfikacji, chyba że wykorzystanie aplikacji kwalifikuje się do wyjątku.

Przykłady zakresów poufnych to odczytywanie wydarzeń zapisanych w Kalendarzu Google, zapisywanie nowego kontaktu w Kontaktach Google lub usuwanie filmu z YouTube. Więcej informacji na temat: dostępne zakresy i ich klasyfikacje znajdziesz w dokumentacji API punkty końcowe wywoływane przez aplikację oraz wszelkie powiązane przewodniki dotyczące autoryzacji opublikowane dla interfejsu API.

Musisz poprosić o zakresy, które wymagają do minimalnego zakresu dostępu do danych użytkownika, który jest niezbędny do zapewnienia działania tej funkcji. Na przykład aplikacja, która tylko odczytuje dane, nie może prosić o dostęp do odczytu, zapisu i usuwania treści, gdy interfejs API i powiązane z nim punkty końcowe mają węższy zakres. Dane, które otrzymujesz z interfejsu API Google, możesz używać tylko zgodnie z zasadami tego interfejsu API oraz w sposób, który przedstawiasz użytkownikom w opisie działań aplikacji i w polityce prywatności.

Pamiętaj, aby uwzględnić czas potrzebny na przeprowadzenie weryfikacji w planie wprowadzania aplikacji na rynek lub nowych funkcji, które wymagają rozszerzenia zakresu. Proces weryfikacji zakresu wrażliwego Zajmuje to zwykle 3-5 dni roboczych. Pamiętaj, że Twoja aplikacja może kwalifikować się do ukończenia. marka weryfikacji jako podzbioru żądania weryfikacji zakresu wrażliwego.

Informacje o zakresach wrażliwych

Zakresy wrażliwe wymagają sprawdzenia przez Google, zanim jakiekolwiek konto Google będzie mogło przyznać dostęp. Google Administratorzy organizacji Workspace mogą ogranicz dostęp do zakresy wrażliwe, aby zablokować dostęp przy użyciu identyfikatorów klienta OAuth, których organizacja nie wyraźnie oznaczyć jako zaufane.

Informacje o użyciu zakresu

• Sprawdź zakresy, których używa Twoja aplikacja lub których chcesz używać. Aby znaleźć obecne wykorzystanie zakresu, sprawdzenie kodu źródłowego aplikacji pod kątem wszelkich zakresów wysłanych z żądaniami autoryzacji.
• Ustal, czy każdy żądany zakres jest niezbędny do realizacji zamierzonych działań funkcji aplikacji przy użyciu jak najmniejszych uprawnień wymaganych do świadczenia tej funkcji. Interfejs API Google zwykle ma dokumentacja na temat atrybutu produktu na stronie Google Developers sekcji punktów końcowych, które obejmują zakres wymagany do wywołania metody lub konkretnych właściwości w obrębie. Więcej informacji o wymaganych zakresach dostępu do punktów końcowych interfejsu API, które wywołuje aplikacja, znajdziesz w dokumentacji tych punktów końcowych.
• Danych otrzymywanych z interfejsu API Google można używać tylko zgodnie z zasadami w interfejsie API i w sposób, który przedstawiasz użytkownikom w działaniach aplikacji polityki prywatności.
• Zapoznaj się z dokumentacją interfejsu API, aby dowiedzieć się więcej o każdym zakresie i jego potencjale. sensitive or restricted .
• Zadeklaruj wszystkie zakresy używane przez aplikację w: Ekran zgody OAuth stronie zakresów konfiguracji. Określone zakresy są grupowane na wrażliwe lub z ograniczeniami kategorie, aby wyróżnić wszelkie dodatkowe czynności weryfikacyjne.
• znajdowanie najlepszego zakresu dopasowanego do danych używanych przez Twoją integrację, informacje o jego wykorzystaniu; ponownie upewnić się, że wszystko nadal działa w środowisku testowym, a następnie przygotować się do przesłania weryfikacji.

Przygotowanie do weryfikacji

Wszystkie aplikacje, które używają interfejsów API Google do żądania dostępu do danych, muszą wykonać te czynności, aby przejść weryfikację marki:

1. Upewnij się, że Twoja aplikacja nie pasuje do żadnego z przypadków użycia opisanych Wyjątki od wymagań weryfikacji.
2. Upewnij się, że aplikacja spełnia wymagania dotyczące marki powiązane z powiązanymi interfejsami API lub usługi. Zobacz np. wskazówki dotyczące promowania marki. dla zakresów Logowania przez Google.
3. Potwierdź własność projektu autoryzowanych domen w ramach Google Search Console. Użyj konta Google Konto powiązane z Twoim projektem jako Właściciel lub Edytujący.
4. Sprawdź, czy na ekranie zgody OAuth są wszystkie informacje o marce, takie jak nazwa aplikacji, pomoc adres e-mail, identyfikator URI strony głównej, identyfikator URI polityki prywatności itp., dokładnie odzwierciedlają tożsamość aplikacji.

Wymagania dotyczące strony głównej aplikacji

Upewnij się, że strona główna spełnia te wymagania:

• Strona główna musi być dostępna publicznie, a nie tylko dla zalogowanych użytkowników użytkowników.
• Strona główna musi być związana z aplikacją, która jest sprawdzana.
• Linki do informacji o aplikacji w Sklepie Google Play i na Facebooku nie są brane pod uwagę. prawidłowe strony główne aplikacji.

Wymagania dotyczące linku do polityki prywatności aplikacji

Upewnij się, że polityka prywatności aplikacji spełnia te wymagania:

• Polityka prywatności musi być widoczna dla użytkowników, hostowana w tej samej domenie co strona główna aplikacji i powiązana z ekranem zgody OAuth w aplikacji . Pamiętaj, że strona główna musi zawierać link opis funkcji aplikacji, a także linki do polityki prywatności opcjonalnych warunkach korzystania z usługi.
• Polityka prywatności musi określać, w jaki sposób aplikacja uzyskuje dostęp do przechowuje ani udostępnia dane użytkowników Google. Musisz ograniczyć korzystanie z danych użytkownika Google wyłącznie zgodnie z zasadami opisanymi przez Ciebie o ochronie prywatności.

Jak przesłać aplikację do weryfikacji

Projekt pozwala uporządkować wszystkie zasobów. Projekt składa się ze zbioru powiązanych kont Google, które mają uprawnienia do wykonywania operacji w projekcie, zestaw włączonych interfejsów API oraz płatności, uwierzytelniania i monitorowania dla tych interfejsów API. Projekt może na przykład zawierać co najmniej jednego klienta OAuth, skonfigurować interfejsy API do używania przez te klienty oraz skonfigurować Ekran zgody OAuth wyświetlany użytkownikom przed autoryzowaniem dostępu do Twojej aplikacji.

Jeśli klient OAuth nie jest gotowy do wdrożenia w wersji produkcyjnej, zalecamy usunięcie go z projekt, który prosi o weryfikację. Możesz to zrobić w

Aby przesłać dokumenty do weryfikacji:

1. Upewnij się, że aplikacja jest zgodna z Warunkami korzystania z interfejsów API Google oraz Zasady dotyczące danych użytkownika w usługach interfejsów API Google
2. Zadbaj o aktualność ról właściciela i edytującego konta powiązanych z projektem. Adres e-mail pomocy technicznej dla użytkowników ekranu zgody OAuth oraz informacje kontaktowe dewelopera do Dzięki temu właściwi członkowie zostaną powiadomieni o nowych wymaganiach.
3. Otwórz OAuth.
4. Kliknij przycisk Selektor projektów.

5. W wyświetlonym oknie Wybierz wybierz projekt. Jeśli nie możesz znaleźć projektu, ale znasz swój identyfikator projektu, możesz utworzyć adres URL w przeglądarce w tym format:

   ?project=[PROJECT_ID]

   Zastąp [PROJECT_ID] identyfikatorem projektu, którego chcesz użyć.

6. Kliknij przycisk Edit App (Edytuj aplikację).
7. Wpisz niezbędne informacje na stronie ekranu zgody OAuth i kliknij przycisk Zapisz i kontynuuj.
8. Aby zadeklarować wszystkie zakresy wymagane przez Twoją aplikację, użyj przycisku Dodaj lub usuń zakresy. W sekcji Zakresy niekrytyczne znajdziesz wstępny zestaw zakresów wymaganych do Logowania przez Google. Dodane zakresy są klasyfikowane jako niewrażliwe. sensitive, or restricted
9. Podaj maksymalnie 3 linki do odpowiedniej dokumentacji dotyczącej powiązanych funkcji aplikacji.

10. Podaj w kolejnym kroków.

    1. Prepare a detailed justification for each requested sensitive scope, as well as an explanation for why a narrower scope isn't sufficient. For example: "My app will use https://www.googleapis.com/auth/calendar to show a user's Google calendar data on the scheduling screen of my app. This lets users manage their schedules through my app and sync the changes with their Google calendar."

    2. Prepare a video that fully demonstrates how a user initiates and grants access to the requested scopes and shows, in detail, the usage of the granted sensitive and restricted scopes in the app. Upload the video to YouTube Studio and set its Visibility as Unlisted. You need to provide a link to the demonstration video in the YouTube link field.

       1. Show the OAuth grant process that users will experience, in English. This includes the consent flow and, if you use Google Sign-In, the sign-in flow.
       2. Show that the OAuth consent screen correctly displays the App Name.
       3. Show that the browser address bar of the OAuth consent screen correctly includes your app's OAuth client ID.
       4. To show how the data will be used, demonstrate the functionality that's enabled by each sensitive scope that you request.
11. Jeśli podana przez Ciebie konfiguracja aplikacji wymaga weryfikacji, możesz przesłać aplikacji do weryfikacji. Wypełnij wymagane pola i kliknij Prześlij, aby rozpocząć proces weryfikacji.

Gdy prześlesz aplikację, Google Trust & Zespół ds. bezpieczeństwa przesyła e-mailem dodatkowych informacji lub czynności, które musisz wykonać. Sprawdź swoje adresy e-mail w sekcji Informacje kontaktowe dewelopera i e-mailu pomocy na ekranie zgody OAuth, aby dowiedzieć się, o jakie informacje dodatkowe chodzi. Możesz też wyświetlić zgodę OAuth projektu sprawdzić bieżący stan projektu, m.in. sprawdzić, czy proces weryfikacji Adres jest wstrzymany na czas oczekiwania na Twoją odpowiedź.

Wyjątki od wymagań weryfikacji

Jeśli Twoja aplikacja będzie używana w którymkolwiek ze scenariuszy opisanych w poniższych sekcjach, nie muszą przesyłać go do sprawdzenia.

Do użytku osobistego

Jednym z takich przypadków jest sytuacja, w której jesteś jedynym użytkownikiem aplikacji lub aplikacja jest używana przez niewielką liczbę użytkowników, których znasz osobiście. Dla Ciebie i ograniczonej liczby użytkowników może to być wygodne, wraz z przejściem niezweryfikowana aplikacja ekranu i przyznając kontom osobistym dostęp do aplikacji.

projekty używane na poziomach rozwoju, testowania lub testów pośrednich.

Aby zgodność z zasadami Google OAuth 2.0, zalecamy korzystanie z różnych projektów środowiska testowego i produkcyjnego. Zalecamy przesyłanie aplikacji tylko do weryfikacji. , jeśli chcesz udostępnić aplikację wszystkim użytkownikom mającym konto Google. Dlatego, jeśli Twoja aplikacja jest w fazie rozwoju, testów lub testowania, weryfikacja nie jest wymagana.

Jeśli aplikacja jest w fazie tworzenia lub testowania, możesz opuścić Stan publikacji w domyślnym ustawieniu Testowanie. To ustawienie oznacza, że aplikacja jest nadal w fazie rozwoju i jest dostępna tylko dla użytkowników, których dodasz do listy użytkowników testowych. Musisz zarządzać listą kont Google osoby uczestniczące w tworzeniu lub testowaniu aplikacji.

Tylko dane należące do usługi

Jeśli Twoja aplikacja używa konta usługi tylko do uzyskiwania dostępu do własnych danych i nie ma dostępu do żadnych użytkowników (powiązanych z kontem Google), nie musisz przesyłać danych do weryfikacji.

Więcej informacji o kontach usługi znajdziesz w dokumentacji Google Cloud na temat kont usługi. Instrukcje dotyczące korzystania z konta usługi znajdziesz w artykule Używanie protokołu OAuth 2.0 w aplikacjach międzyserwerowych.

Jest przeznaczony tylko do użytku wewnętrznego

Oznacza to, że z aplikacji mogą korzystać tylko osoby korzystające z Twojego konta Google Workspace lub Cloud Identity. organizacji. Projekt musi należeć do organizacji i znajdować się w niej ekran zgody OAuth należy skonfigurować dla Użytkownik wewnętrzny . W takim przypadku aplikacja może wymagać zatwierdzenia przez administratora organizacji. Dla: więcej informacji znajdziesz w Dodatkowe uwagi na temat Google Workspace.

• Dowiedz się więcej o publicznych i wewnętrznych aplikacjach.
• Więcej informacji o oznaczaniu aplikacji jako wewnętrznej znajdziesz w najczęstszych pytaniach Jak oznaczyć aplikację jako tylko do użytku wewnętrznego?

Instalacja w całej domenie

Jeśli planujesz, aby Twoja aplikacja była kierowana tylko na użytkowników Google Workspace lub Cloud Identity i zawsze używaj całej domeny instalacji, aplikacja nie będzie wymagać jej weryfikacji. Dzieje się tak, ponieważ w całej domenie pozwala administratorowi domeny na przyznawanie dostępu aplikacjom zewnętrznym i wewnętrznym do użytkowników i skalowalnych danych. Administratorzy organizacji są jedynymi kontami, którzy mogą dodać aplikację do do użytku w swoich domenach.

Najczęstsze pytania o to, jak ustawić aplikację w całej domenie Moja aplikacja ma użytkowników z kont firmowych z innej domeny Google Workspace