Omówienie rejestracji aplikacji internetowej
Rejestracja aplikacji dostarcza tożsamość i konfigurację używaną przez aplikację internetową Java podczas komunikowania się z Microsoft Entra ID. W tej lekcji przeanalizujesz ustawienia rejestracji dla przykładowego portalu firmowego, zamiast tworzyć rejestrację.
Note
Grupa odbiorców logowania aplikacji jednotenantowej obejmuje zarówno konta użytkowników, jak i konta gości w tej dzierżawie. Dostęp tylko do pracowników wymaga dodatkowej autoryzacji dla wyselekcjonowanych zestawów użytkowników lub grup pracowników; scenariusz nie implementuje tych zasad. Członkostwo w organizacji, domena adresu e-mail i klasyfikacja jako członek lub gość nie stanowią dowodu zatrudnienia. Aby uzyskać więcej informacji, zobacz Single and multitenant apps (Aplikacje jednodostępne i wielodostępne).
Interpretowanie ustawień rejestracji
W poniższej tabeli opisano ustawienia związane z portalem. Identyfikatory i przykładowy identyfikator URI to symbole zastępcze objaśniające, a nie wartości, które należy skonfigurować przez ucznia.
| Setting | Rola w przykładzie |
|---|---|
| Name | Czytelna dla człowieka etykieta dla aplikacji. Nie jest to identyfikator protokołu aplikacji. |
| Identyfikator aplikacji (klienta) | Identyfikuje aplikację. Przykłady kodu odnoszą się do tej wartości jako CLIENT_ID. |
| Identyfikator katalogu (klienta) | Identyfikuje tenant pracowniczy. Urząd specyficzny dla dzierżawy kieruje żądania uwierzytelniania do tej dzierżawy. |
| Obsługiwane typy kont | Odbiorcy jednej dzierżawy umożliwiają dostęp kontom użytkowników i gości w wybranym katalogu, z zastrzeżeniem obowiązujących zasad dostępu. |
| Adres URI przekierowania w sieci Web | Identyfikuje punkt końcowy serwera, który odbiera odpowiedź autoryzacji. Ilustracyjna wartość to https://app.example.com/auth/callback. |
| Poświadczenia aplikacji | Umożliwia poufnej aplikacji internetowej uwierzytelnienie się podczas wymiany kodu autoryzacyjnego na tokeny. |
Na poniższej ilustracji przedstawiono sposób wyświetlania identyfikatorów klienta i dzierżawy w przeglądzie rejestracji aplikacji. Jest to materiał referencyjny, a nie ekran, który należy otworzyć, aby ukończyć moduł.
Powiąż adres URI przekierowania z przepływem logowania
W przepływie kodu autoryzacji aplikacja wysyła przeglądarkę do punktu końcowego autoryzacji Microsoft Entra. Po otrzymaniu pomyślnej odpowiedzi autoryzacyjnej przeglądarka wraca do zarejestrowanego URI przekierowania z kodem autoryzacyjnym.
Adres URI wywołania zwrotnego musi być zgodny z internetowym adresem URI przekierowania podanym podczas rejestracji oraz z adresem URI użytym w żądaniu autoryzacji. Następnie serwer wymienia kod w punkcie końcowym tokenu. Funkcja wywołania zwrotnego przeglądarki nie otrzymuje tokenu dostępu Microsoft Graph w tym przepływie.
W kolejnych przykładach Config.REDIRECT_URI reprezentuje ten adres wywołania zwrotnego. Jest to wartość konfiguracji aplikacji, a nie metoda dostarczana przez bibliotekę MSAL4J.
Rozróżnianie identyfikatorów od poświadczeń
Identyfikator klienta identyfikuje aplikację, ale nie potwierdza jej tożsamości. Poufne aplikacje internetowe przedstawiają również poświadczenia podczas pozyskiwania tokenu.
Klucz tajny klienta jest jednym z możliwych poświadczeń. Jego Wartość to tajny materiał; jego Identyfikator wpisu tajnego jest identyfikatorem, a nie wartością używaną do uwierzytelnienia klienta. Portal Azure wyświetla wartość nowo utworzonego klucza tajnego tylko raz. Te różnice wyjaśniają symbol zastępczy CLIENT_SECRET w następnej lekcji; w tym module nie jest potrzebny żaden sekret.
Ważna
Przykłady kodu wykorzystujące wpisy tajne ilustrują strukturę interfejsu API, a nie produkcyjny projekt przechowywania poświadczeń. Wpisy tajne i wypełnione pliki konfiguracji muszą pozostawać poza kontrolą źródła, zrzutami ekranu i dziennikami. Poufne aplikacje internetowe używane w środowisku produkcyjnym powinny korzystać z certyfikatu lub odpowiednio skonfigurowanego poświadczenia federacyjnego, z bezpiecznym przechowywaniem materiałów uwierzytelniających. Tożsamość zarządzana nie jest bezpośrednim zamiennikiem dla tego przepływu logowania użytkownika. Zobacz Wskazówki dotyczące poświadczeń aplikacji.
Zarządzanie rejestracją i dostęp do interfejsu API są oddzielnymi problemami
Możliwość zarządzania rejestracjami zależy od uprawnień dzierżawy. Użytkownicy będący członkami zwykle mogą rejestrować aplikacje, ale zasady dzierżawy mogą to ograniczyć. Odpowiedni dostęp, taki jak rola dewelopera aplikacji lub pomoc administratora, może być konieczny w rzeczywistej implementacji. Jest to kwestia administracyjna, a nie wymaganie wstępne ucznia.
Rejestracja również nie przyznaje wszystkich uprawnień interfejsu API, o które aplikacja może zażądać. Dostęp portalu do Microsoft Graph zależy od żądanych przez niego zakresów i mających zastosowanie udzielonych zgód, które omówiono w dalszej części modułu.
Informacje na ten temat zawiera artykuł Rejestrowanie aplikacji, w którym opisano ustawienia rejestracji i sposób zarządzania nimi.