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 opisujemy, jak rozwiązać najczęstsze problemy deweloperów występujące podczas przygotowywania aplikacji do wdrożenia. Dzięki temu możesz docierać do jak największej liczby odbiorców z minimalną liczbą błędów.
- Używanie oddzielnych projektów do testowania i produkcji
- Utrzymywanie listy odpowiednich kontaktów w przypadku projektu
- Dokładnie przedstawiaj swoją tożsamość
- Proś o zakresy, których potrzebujesz
- Przesyłanie do weryfikacji produkcyjnych wersji aplikacji, które używają zakresów wrażliwych lub z ograniczeniem
- Używaj tylko domen, które Ci przysługują
- Hostowanie strony głównej aplikacji w wersji produkcyjnej
- Używanie bezpiecznych identyfikatorów URI przekierowania i źródeł JavaScript
Używanie osobnych projektów na potrzeby testowania i produkcji
Zasady Google dotyczące OAuth wymagają tworzenia oddzielnych projektów na potrzeby testów i produkcji. Niektóre zasady i wymagania dotyczą tylko aplikacji w wersji produkcyjnej. 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.
- Sprawdź w tym projekcie klientów OAuth, którzy mogą być powiązani z poziomem testowania. W razie potrzeby utwórz podobne klientów OAuth dla klientów produkcyjnych w projekcie produkcyjnym.
- Włącz interfejsy API używane przez Twoich klientów.
- Sprawdź konfigurację ekranu zgody OAuth w nowym projekcie w .
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 deweloperó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ą skontaktować się z Tobą w sprawie zmian w usługach lub nowych konfiguracji wymaganych przez Twój projekt i jego klientów. Sprawdź listy IAM 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 projektów, którzy mają wszystkie uprawnienia edytujące, mogą dodawać i usuwać konta powiązane z projektem oraz usuwać projekt. Właściciele projektów mogą też podać kontekst, w jakim mogą być ustawione informacje rozliczeniowe. Właściciele projektów mogą konfigurować informacje rozliczeniowe w przypadku projektów korzystających z płatnych interfejsów API.
Właściciele i edytujący projekt muszą być na bieżąco. Do projektu możesz dodać wiele odpowiednich kont, aby zapewnić ciągły dostęp do projektu i powiązanej konserwacji. 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ą zadbać o to, aby z każdym projektem w ich organizacji powiązana była osoba kontaktowa, z którą można się skontaktować. Jeśli nie mamy aktualnych informacji kontaktowych dotyczących Twojego projektu, możesz nie otrzymywać ważnych wiadomości wymagających podjęcia przez Ciebie działań.
Dokładnie przedstawiać Twoją tożsamość
Podaj prawidłową nazwę aplikacji i opcjonalnie logo, które będzie widoczne dla użytkowników. Te informacje o marce muszą 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 cofnąć lub zawiesić dostęp do usług interfejsu API Google i innych usług Google w przypadku aplikacji, które podają się za kogoś innego 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, podczas gdy 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 uprawnień, których potrzebują te punkty końcowe, aby uzyskać dostęp do danych, których potrzebuje aplikacja. Zapoznaj się ze wszystkimi przewodnikami autoryzacji oferowanymi przez interfejs API i bardziej szczegółowo opisz zakresy, uwzględniając najczęściej występujące 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 Wymagaj tylko tych zakresów, których potrzebujesz zasad OAuth 2.0 oraz w sekcji Wymagaj odpowiednich uprawnień zasad dotyczących danych użytkownika w usługach interfejsu API Google.
Przesyłanie do weryfikacji produkcyjnych wersji aplikacji, które korzystają z zakresów wrażliwych lub z ograniczeniem
Niektóre zakresy są klasyfikowane jako „wrażliwe” lub „ograniczone” i nie można ich używać w aplikacji produkcyjnych bez sprawdzenia. Wpisz wszystkie zakresy, których używa produkcyjna wersja aplikacji w konfiguracji ekranu zgody 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 domen, które należą do Ciebie.
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 przekierowań lub autoryzowanymi źródłami JavaScript. Sprawdź listę domen używanych przez Twoją aplikację, która jest podsumowana w sekcji Domeny autoryzowane w edytorze ekranu akceptacji OAuth. Odszukaj domeny, których nie posiadasz i których nie możesz więc 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 usług dostawcy w ramach wspólnej, współdzielonej domeny, 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órą już masz.
Hostowanie strony głównej aplikacji w wersji produkcyjnej
Każda produkcyjna aplikacja korzystająca z protokołu OAuth 2.0 musi mieć publicznie dostępną stronę główną. Potencjalni użytkownicy aplikacji mogą odwiedzać 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 oraz linki do polityki prywatności i opcjonalnie do 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
Klienci OAuth 2.0 w przypadku aplikacji internetowych muszą chronić swoje dane za pomocą identyfikatorów URI przekierowań HTTPS i źródeł JavaScriptu, a nie zwykłego HTTP. Google może odrzucać żądania OAuth, które nie pochodzą z bezpiecznego kontekstu ani do niego nie pasują.
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 artykułem Przesyłanie aplikacji do weryfikacji marki, aby dowiedzieć się więcej o procesie weryfikacji.