Wprowadziliśmy ustawienia kontroli dostępu aplikacji, aby ułatwić administratorom Google Workspace for Education kontrolowanie, jak aplikacje innych firm uzyskują dostęp do danych Google w ich organizacjach , gdy użytkownicy logują się za pomocą swoich kont Google Workspace for Education. Deweloperzy aplikacji innych firm nie muszą podejmować żadnych działań, ale poniżej znajdą sprawdzone metody, które okazały się przydatne dla innych deweloperów.
Korzystanie z przyrostowego OAuth
Możesz użyć autoryzacji przyrostowej, aby początkowo poprosić tylko o zakresy wymagane do uruchomienia aplikacji, a następnie poprosić o dodatkowe zakresy, gdy będą potrzebne nowe uprawnienia. Kontekst aplikacji informuje użytkownika o przyczynie żądania.
Podczas logowania aplikacja prosi o podstawowe zakresy, takie jak zakres logowania profile, oraz inne początkowe zakresy wymagane do działania aplikacji. Później, gdy użytkownik będzie chciał wykonać działanie wymagające dodatkowych zakresów, aplikacja poprosi o te zakresy, a użytkownik autoryzuje tylko nowe zakresy na ekranie zgody.
Podczas tworzenia dodatku do Google Classroom należy postępować zgodnie z wytycznymi Google Workspace Marketplace i podać pełną listę zakresów OAuth wymaganych przez aplikację. Jest to konieczne, aby administrator wiedział, o jakie zakresy użytkownik domeny jest proszony o zgodę.
Upewnij się, że wszystkie aplikacje są zweryfikowane przez OAuth
Wszystkie aplikacje, które uzyskują dostęp do interfejsów API Google, muszą potwierdzić, że dokładnie przedstawiają swoją tożsamość i intencje zgodnie z zasadami dotyczącymi danych użytkowników w usługach API Google. Jeśli masz kilka aplikacji korzystających z interfejsów API Google, upewnij się, że każda z nich została zweryfikowana. Administratorzy mogą zobaczyć wszystkie identyfikatory klienta OAuth powiązane z Twoją zweryfikowaną marką. Aby pomóc administratorom uniknąć konfigurowania nieprawidłowych identyfikatorów klienta OAuth, używaj oddzielnych projektów Google Cloud do testowania i produkcji oraz usuń wszystkie nieużywane identyfikatory klienta OAuth.
Weryfikacja interfejsu API OAuth to proces, który Google Cloud Platform stosuje, aby zapewnić bezpieczeństwo i zgodność aplikacji, które proszą o zakresy wrażliwe lub z ograniczeniami. Proces weryfikacji pomaga chronić użytkowników i dane Google Cloud przed nieautoryzowanym dostępem.
Aplikacje, które proszą o zakresy wrażliwe lub z ograniczeniami, muszą być zgodne z zasadami dotyczącymi danych użytkowników w usługach API Google. Te zasady wymagają, aby aplikacje chroniły dane użytkowników i używały ich tylko do celów, na które użytkownik wyraził zgodę. Aplikacje mogą też wymagać niezależnej oceny bezpieczeństwa, aby potwierdzić, że spełniają wymagania Google Cloud dotyczące bezpieczeństwa.
Pamiętaj, że proces weryfikacji interfejsu API OAuth może potrwać kilka tygodni. Gdy aplikacja zostanie zweryfikowana, możesz poprosić o potrzebne zakresy wrażliwe lub z ograniczeniami.
Więcej informacji znajdziesz w najczęstszych pytaniach dotyczących weryfikacji interfejsu API OAuth.
Obsługa wielu identyfikatorów klienta OAuth
Projekt Google Cloud może mieć wiele identyfikatorów klienta OAuth, co może wymagać od administratora domeny kilkukrotnego skonfigurowania dostępu.
Zapewnij dokładność identyfikatorów klienta OAuth
Skontaktuj się z zespołem deweloperów, aby dowiedzieć się, które identyfikatory klienta OAuth są używane do integracji z Google OAuth. Używaj 2 różnych projektów Google Cloud do testowania i produkcji, aby pomóc administratorom zrozumieć, które identyfikatory klienta OAuth należy skonfigurować. Usuń z projektów produkcyjnych wszystkie wycofane lub nieaktualne identyfikatory klienta.
Przesyłanie pliku CSV
Jeśli masz wiele identyfikatorów klienta, zalecamy skorzystanie z opcji zbiorczego przesyłania pliku CSV , aby pomóc administratorom w szybkim skonfigurowaniu wszystkich aplikacji.
Pola:
| Pole | Wymagane | Uwagi |
|---|---|---|
| Nazwa aplikacji | Nie | Wpisz nazwę aplikacji. Zmiany nazwy aplikacji wprowadzone w pliku CSV nie są aktualizowane w konsoli administracyjnej. |
| Typ | Tak | Jedna z tych opcji: aplikacja internetowa, Android lub iOS. |
| Identyfikator | Tak | W przypadku aplikacji internetowych wpisz identyfikator klienta OAuth wydany dla aplikacji. W przypadku aplikacji na Androida i iOS wpisz identyfikator klienta OAuth albo identyfikator pakietu, którego aplikacja używa w Google Play lub Apple App Store. |
| Jednostka organizacyjna | Tak | Do wypełnienia przez klienta. Aby zastosować ustawienie dostępu do aplikacji w całej domenie, wpisz ukośnik („/”). Aby zastosować ustawienia dostępu do określonych jednostek organizacyjnych, dodaj do arkusza kalkulacyjnego odpowiedni wiersz dla każdej z nich, powtarzając nazwę, typ i identyfikator aplikacji. (na przykład „/jednostka_organizacyjna_1/podjednostka_1”). |
| Dostęp | Tak | Jedna z tych opcji: zaufany, zablokowany lub ograniczony. |
Błędy OAuth
Wraz z tymi nowymi kontrolkami administratora wprowadziliśmy 2 komunikaty o błędach.
- Błąd 400: access_not_configured – występuje, gdy połączenie OAuth zostanie odrzucone, ponieważ aplikacja nie została skonfigurowana.
- Błąd 400: admin_policy_enforced – występuje, gdy połączenie OAuth zostanie odrzucone, ponieważ administrator zablokował Twoją aplikację.
Użytkownicy oznaczeni jako osoby poniżej 18 roku życia
Administratorzy mogą zarządzać dostępem do nieskonfigurowanych aplikacji innych firm dla użytkowników oznaczonych jako osoby poniżej 18 roku życia. Jeśli użytkownik zobaczy błąd „Dostęp zablokowany: administrator Twojej instytucji musi sprawdzić aplikację [nazwa aplikacji]”, musi poprosić o dostęp z poziomu komunikatu o błędzie. Dzięki temu administrator może sprawdzić aplikację innej firmy. Administratorzy mogą zezwolić na korzystanie z aplikacji innych firm lub je zablokować.