Wprowadziliśmy ustawienia kontroli dostępu do aplikacji, aby ułatwić administratorom Google Workspace for Education określanie, w jaki sposób aplikacje innych firm uzyskują dostęp do danych Google ich organizacji, gdy użytkownicy logują się za pomocą kont Google Workspace for Education. Deweloperzy aplikacji innych firm nie muszą podejmować żadnych działań, ale poniżej znajdziesz sprawdzone metody, które mogą być dla nich przydatne.
Korzystanie z przyrostowego protokołu 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 określa następnie powód prośby skierowanej do użytkownika.
Podczas logowania aplikacja prosi o podstawowe zakresy, takie jak zakres logowania profile i inne początkowe zakresy, których aplikacja potrzebuje do działania. Później, gdy użytkownik będzie chciał wykonać działanie wymagające dodatkowych zakresów, Twoja aplikacja poprosi o te zakresy, a użytkownik na ekranie zgody autoryzuje tylko nowe zakresy.
Podczas tworzenia dodatku do Google Classroom należy postępować zgodnie z wytycznymi Google Workspace Marketplace, które wymagają podania pełnej listy zakresów OAuth potrzebnych aplikacji. Jest to konieczne, aby administrator wiedział, o jakie zakresy użytkownik domeny jest proszony o zgodę.
Sprawdź, czy wszystkie aplikacje są zweryfikowane za pomocą protokołu OAuth
Wszystkie aplikacje, które korzystają z interfejsów API Google, muszą potwierdzić, że dokładnie odzwierciedlają swoją tożsamość i zamiary zgodnie z Zasadami usług interfejsu API Google dotyczącymi danych użytkownika. Jeśli masz kilka aplikacji korzystających z interfejsów API Google, upewnij się, że każda z nich została zweryfikowana. Administratorzy mogą wyświetlać wszystkie identyfikatory klientów 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 usuwaj wszystkie nieużywane identyfikatory klienta OAuth.
Weryfikacja interfejsu API OAuth to proces, który Google Cloud Platform wykorzystuje, aby zapewnić bezpieczeństwo i zgodność aplikacji, które wymagają podania poufnych lub zastrzeżonych zakresów. Proces weryfikacji pomaga chronić użytkowników i dane Google Cloud przed nieautoryzowanym dostępem.
Aplikacje, które żądają zakresów wrażliwych lub z ograniczeniem, muszą być zgodne z zasadami dotyczącymi danych użytkownika w usługach interfejsu API Google. Zgodnie z tymi zasadami aplikacje muszą chronić dane użytkowników i wykorzystywać je wyłącznie w celach, 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 OAuth API może potrwać kilka tygodni. Po zweryfikowaniu aplikacji możesz poprosić o potrzebne zakresy wrażliwe lub zakresy 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.
Sprawdzanie poprawności identyfikatorów klienta OAuth
Skontaktuj się z zespołem programistó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 na potrzeby testowania i produkcji, aby pomóc administratorom w określeniu, które identyfikatory klientów OAuth należy skonfigurować. Usuń z projektów produkcyjnych wszystkie wycofane lub nieaktualne identyfikatory klientów.
Przesyłanie pliku CSV
Jeśli masz wiele identyfikatorów klienta, zalecamy skorzystanie z opcji przesyłania zbiorczego pliku CSV, aby administratorzy mogli szybko skonfigurować wszystkie Twoje aplikacje.
Pola 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 | Jedna z tych wartości: web application, 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 odpowiedni wiersz dla każdej z nich, powtarzając nazwę, typ i identyfikator aplikacji. (np. „/org_unit_1/sub_unit_1”). |
| Dostęp | Tak | Jedna z wartości: zaufany, zablokowany lub ograniczony. |
Błędy OAuth
Wraz z tymi nowymi ustawieniami kontroli administratora wprowadziliśmy 2 komunikaty o błędach.
- Błąd 400: access_not_configured – występuje, gdy połączenie OAuth jest odrzucane, ponieważ aplikacja nie została skonfigurowana.
- Błąd 400: admin_policy_enforced – występuje, gdy połączenie OAuth jest odrzucane, ponieważ administrator zablokował Twoją aplikację.
Użytkownicy oznaczeni jako niepełnoletni
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 pojawi się błąd „Dostęp zablokowany: administrator Twojej instytucji musi sprawdzić aplikację [nazwa aplikacji]”, użytkownik musi poprosić o dostęp z poziomu komunikatu o błędzie. Pozwoli to administratorowi sprawdzić aplikację innej firmy. Administratorzy mogą zezwolić na używanie aplikacji innych firm lub je zablokować.