Firma Google wprowadziła ustawienia kontroli dostępu aplikacji, aby ułatwić administratorom Google Workspace for Education kontrolowanie sposobu dostępu aplikacji innych firm do danych Google organizacji, gdy użytkownicy logują się na swoje konta Google Workspace for Education. Deweloperzy aplikacji innych firm nie muszą nic robić, ale poniżej przedstawiamy sprawdzone metody, które inni deweloperzy uznali za przydatne.
Korzystanie z incremental OAuth
Możesz użyć autoryzacji przyrostowej, aby początkowo żądać tylko zakresów wymaganych do uruchomienia aplikacji, a potem poprosić o dodatkowe zakresy w miarę potrzeb. Kontekst aplikacji określa powód wysłania prośby do użytkownika.
Podczas logowania aplikacja prosi o podstawowe zakresy, takie jak profil zakresu logowania i inne początkowe zakresy, których potrzebuje do działania. Później, gdy użytkownik chce wykonać działanie, które wymaga dodatkowych zakresów, aplikacja żąda ich, a użytkownik autoryzuje na ekranie zgody tylko nowe zakresy.
Tworząc dodatek do Google Classroom, postępuj zgodnie ze wskazówkami dotyczącymi Google Workspace Marketplace, które dotyczą podania pełnej listy zakresów OAuth wymaganych przez Twoją aplikację. Jest to konieczne, aby administrator wiedział, na jakie zakresy użytkownik domeny ma wyrazić zgodę.
Upewnij się, że wszystkie aplikacje są zweryfikowane przez OAuth
Wszystkie aplikacje, które uzyskują dostęp do interfejsów API Google, muszą potwierdzać, że prawidłowo przedstawiają swoją tożsamość i zamiary zgodnie z zasadami Google dotyczącymi danych użytkownika w usługach interfejsu API. Jeśli masz kilka aplikacji, które korzystają z interfejsów API Google, sprawdź, czy każda z nich została zweryfikowana. Administratorzy mogą wyświetlać wszystkie identyfikatory klienta OAuth powiązane z weryfikowaną marką. Aby pomóc administratorom uniknąć konfigurowania nieprawidłowych identyfikatorów klienta OAuth, użyj oddzielnych projektów Google Cloud na potrzeby testów i produkcji oraz usuń wszystkie identyfikatory klienta OAuth, których nie używasz.
Weryfikacja OAuth API to proces, przy użyciu którego Google Cloud Platform ma pewność, że aplikacje żądające zakresów wrażliwych lub zakresów z ograniczeniami są bezpieczne i zgodne z wymaganiami. Proces weryfikacji pomaga chronić użytkowników i dane Google Cloud przed nieautoryzowanym dostępem.
Aplikacje, które żądają zakresów wrażliwych lub ograniczonych, muszą być zgodne z zasadami dotyczącymi danych użytkownika usług interfejsu API Google. Ta zasada wymaga, aby aplikacje chroniły dane użytkownika i używały ich wyłącznie w celach autoryzowanych przez użytkownika. Aplikacje mogą też wymagać niezależnej oceny bezpieczeństwa, aby można było sprawdzić, czy spełniają wymagania Google Cloud dotyczące zabezpieczeń.
Pamiętaj, że weryfikacja interfejsu API OAuth może potrwać do kilku tygodni. Po zweryfikowaniu aplikacji możesz poprosić o wyznaczenie zakresów wrażliwych lub ograniczonych, których potrzebujesz.
Więcej informacji znajdziesz w najczęstszych pytaniach dotyczących weryfikacji interfejsu OAuth API.
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 skonfigurowania Twojego dostępu kilka razy.
Sprawdzanie poprawności identyfikatorów klienta OAuth
Skontaktuj się ze swoim zespołem programistów, by dowiedzieć się, które identyfikatory klienta OAuth są używane do integracji z Google OAuth. Użyj 2 różnych projektów Google Cloud na potrzeby testów i produkcji, aby ułatwić administratorom konfigurowanie identyfikatorów klienta OAuth. 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 przesyłania zbiorczego pliku CSV, aby pomóc administratorom szybko skonfigurować wszystkie aplikacje.
Pola te to:
| Pole | Wymagane | Uwagi |
|---|---|---|
| Nazwa aplikacji | Nie | Wpisz nazwę aplikacji. Zmiany nazwy aplikacji wprowadzone w pliku CSV nie są aktualizowane w konsoli administracyjnej. |
| Typ | Tak | 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 App Store. |
| Jednostka organizacyjna | Tak | Do wypełnienia przez klienta. Wpisz ukośnik („/”), aby zastosować ustawienie dostępu aplikacji w całej domenie. Aby zastosować ustawienia dostępu do określonych jednostek organizacyjnych, dodaj do arkusza odpowiedni wiersz dla każdej z nich, powtarzając nazwę, typ i identyfikator aplikacji. (np. '/org_unit_1/sub_unit_1'). |
| Dostęp | Tak | Zaufane, Zablokowane lub Ograniczony dostęp. |
Błędy OAuth
Dzięki tym nowym opcjom administratora pojawiły się 2 komunikaty o błędach.
- Błąd 400: access_not_configured – pojawia się, gdy połączenie OAuth jest odrzucane, ponieważ aplikacja nie jest skonfigurowana.
- Błąd 400: admin_policy_enforced – wysyłany, gdy połączenie OAuth jest odrzucane, 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 napotka błąd „Dostęp zablokowany: administrator Twojej instytucji musi sprawdzić nazwę 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 używanie aplikacji innych firm lub je zablokować.