Podczas tworzenia i wdrażania aplikacji korzystających z protokołu Google OAuth 2.0 ważne jest, aby znać różne stany, w jakich może znajdować się aplikacja, oraz sposób, w jaki te stany współdziałają z ustawieniami administratora Google Workspace. Na tej stronie znajdziesz ogólne omówienie stanów publikacji aplikacji OAuth, typów użytkowników i wymagań dotyczących weryfikacji.
Określanie typu aplikacji
Aby dowiedzieć się, które zasady i mechanizmy kontroli mają zastosowanie do Twojego projektu, najpierw określ docelowych odbiorców:
- Aplikacje do użytku w dowolnym miejscu: te aplikacje są przeznaczone dla jak najszerszego grona odbiorców, w tym dla posiadaczy indywidualnych kont Google i użytkowników zewnętrznych organizacji Google Workspace. Są one konfigurowane jako typy użytkowników zewnętrznych w konsoli Google Cloud. Więcej informacji znajdziesz w artykule Typ użytkownika: zewnętrzny.
- Aplikacje do użytku tylko w organizacji Google Workspace: te aplikacje są prywatne i dostępne tylko dla użytkowników w Twojej domenie Google Workspace. Nie są one dostępne dla użytkowników spoza Twojej organizacji. Są one skonfigurowane jako typy użytkowników Wewnętrzni. Twoja aplikacja i jej użytkownicy podlegają zasadom administracyjnym na poziomie organizacji, które mogą zastępować standardowe działanie OAuth. Więcej informacji znajdziesz w sekcji Typ użytkownika: wewnętrzny.
Porównanie działania platformy Google OAuth
W tabeli poniżej znajdziesz informacje o tym, jak różne konfiguracje stanu publikacji, typu użytkownika i stanu weryfikacji wpływają na działanie aplikacji i dostęp do niej. Te działania podlegają zasadom weryfikacji OAuth i regułom wygasania tokenów.
| Stan publikacji | Typ użytkownika | Czy dotyczy użytkowników testowych? | Status weryfikacji | Uwagi |
|---|---|---|---|---|
| Nie dotyczy | Wewnętrzne | Nie | Nie dotyczy | Dostęp mają wszyscy użytkownicy w organizacji. Weryfikacja nie jest wymagana. Ekran zgody może nie zawierać zakresów. Przydatne w przypadku aplikacji przeznaczonych tylko do użytku wewnętrznego. |
| Testowanie | Zewnętrzna | Tak | Nie dotyczy | Dostęp do aplikacji mają tylko użytkownicy, którzy zostali wyraźnie dodani do listy dozwolonych użytkowników testowych (maksymalnie 100 użytkowników testowych). Wyjątek: jeśli aplikacja żąda tylko podstawowych zakresów tożsamości (openid, email, profile), każdy użytkownik może uzyskać do niej dostęp bez dodawania go do listy dozwolonych. Użytkownicy widzą interfejs ostrzegawczy informujący, że aplikacja jest w trakcie testów, a nie standardowy ekran niezweryfikowanej aplikacji. Uwaga: użytkownicy organizacji nie są zwolnieni z tych wymagań dotyczących testowania, chyba że typ użytkownika aplikacji jest ustawiony na wewnętrzny. Przydatne przy programowaniu i testowaniu. |
| Opublikowano | Zewnętrzna | Nie | Niezweryfikowany | Każdy użytkownik Google ma dostęp. Zdecydowanie odradzamy. Ponieważ aplikacja nie przeszła weryfikacji marki, jej nazwa i logo nie są wyświetlane na ekranie zgody. Dodatkowo w przypadku aplikacji, które żądają zakresów wrażliwych lub zakresów z ograniczeniami, użytkownikom będą wyświetlane ostrzeżenia o niezweryfikowanej aplikacji (interfejs użytkownika z ostrzeżeniem), a łączna liczba użytkowników będzie ograniczona do 100. |
| Opublikowano | Zewnętrzna | Nie | Zweryfikowano | Każdy użytkownik Google ma dostęp. Wymagane w przypadku aplikacji publicznych, które proszą o zakresy wrażliwe i zakresy z ograniczeniami. Nazwa aplikacji, logo i zakresy są wyświetlane na ekranie zgody bez ostrzeżeń (po zweryfikowaniu marki i zakresów). |
Zastąpienia administracyjne w środowiskach Google Workspace
Administratorzy Google Workspace mają znaczną kontrolę nad tym, jak aplikacje OAuth uzyskują dostęp do danych organizacji, niezależnie od ustawień aplikacji w konsoli Google Cloud. Tymi ustawieniami zarządza się w konsoli administracyjnej Google Workspace w sekcji Dostęp do interfejsów API.
- Kontrola uniwersalna: administratorzy Google Workspace mogą zawsze blokować dowolną aplikację OAuth, niezależnie od tego, czy jest to aplikacja wewnętrzna czy zewnętrzna, testowa czy opublikowana, zweryfikowana czy niezweryfikowana, uniemożliwiając użytkownikom jej autoryzację.
- Aplikacje wewnętrzne: są one często domyślnie traktowane jako zaufane w organizacji Google Workspace, zwłaszcza jeśli administrator włączy opcję „Oznacz aplikacje wewnętrzne (należące do domeny) jako zaufane”. Administratorzy mogą jednak nadal stosować etykiety takie jak Zaufane, Ograniczony dostęp lub Zablokowane, aby precyzyjnie dostosować dostęp. Delegowanie w całej domenie (DWD) można też skonfigurować tak, aby pomijać zgodę użytkownika w przypadku określonych zakresów.
- Aplikacje zewnętrzne:
- Niezweryfikowane: administratorzy prawdopodobnie nie będą im ufać i mogą być zablokowane lub ograniczone. Administrator może oznaczyć niezweryfikowaną aplikację zewnętrzną jako „Zaufaną” w swojej domenie, ale generalnie nie jest to zalecane.
- Zweryfikowane: weryfikacja przez Google zwiększa zaufanie, ale administratorzy Google Workspace nadal mają pełną kontrolę. Stan „Zweryfikowano” nie zastępuje ustawień administratora Google Workspace. Administratorzy mogą oznaczyć aplikację jako zaufaną (z pominięciem niektórych ograniczeń zakresu ustawionych przez administratora), z ograniczonym dostępem (podlegającą ograniczeniom usługi) lub zablokowaną.
Zastąpienie stanu „Zaufana”: gdy administrator Google Workspace oznaczy aplikację jako zaufaną, będzie ona traktowana jako aplikacja wewnętrzna w tej organizacji. Ten stan zastępuje niektóre standardowe ograniczenia OAuth dotyczące użytkowników organizacji, takie jak limit 100 użytkowników testowych i 7-dniowy limit wygaśnięcia tokena odświeżania w przypadku aplikacji w stanie Testowanie.
Proces weryfikacji Google jest w zasadzie sygnałem ogólnej zgodności z zasadami, ale administrator Google Workspace ma ostateczną władzę w zakresie tego, czy aplikacja może uzyskać dostęp do danych organizacji.
Dalsze kroki
Szczegółowe informacje o przygotowywaniu aplikacji do wdrożenia i kwestiach związanych z Google Workspace znajdziesz w tych materiałach: