Aplikacja desktopowa, która wywołuje interfejsy sieciowe API: rejestracja aplikacji

Dotyczy: Dzierżawcy Workforce Zewnętrzni dzierżawcy (więcej informacji)

W tym artykule opisano szczegóły rejestracji aplikacji desktopowej.

Obsługiwane typy kont

Typy kont obsługiwane w aplikacji desktopowej zależą od funkcjonalności, które chcesz uruchomić. Ze względu na tę relację obsługiwane typy kont zależą od przepływów, których chcesz użyć.

Odbiorcy interaktywnego pozyskiwania tokenów

Jeśli aplikacja komputerowa używa uwierzytelniania interakcyjnego, możesz logować użytkowników z dowolnego typu konta.

Odbiorcy cichych przepływów aplikacji desktopowych

• Aby użyć zintegrowanego uwierzytelniania systemu Windows lub nazwy użytkownika i hasła, aplikacja musi zalogować użytkowników w swoim dzierżawcy, na przykład, jeśli jesteś deweloperem LOB. Lub w organizacjach Microsoft Entra twoja aplikacja musi logować użytkowników we własnej dzierżawie, jeśli jest to przypadek ISV. Te przepływy uwierzytelniania nie są obsługiwane w przypadku kont osobistych Microsoft.
• Jeśli logujesz użytkowników przy użyciu społecznościowych identyfikatorów, które przechodzą weryfikację przez instytucję i politykę business-to-commerce (B2C), możesz używać tylko uwierzytelniania interaktywnego i opartego na nazwie użytkownika i haśle.

Identyfikatory URI przekierowania

Identyfikatory URI przekierowania do użycia w aplikacji na komputer stacjonarny zależą od przepływu, którego chcesz użyć.

Określ identyfikator URI przekierowania dla aplikacji, konfigurując ustawienia platformy dla aplikacji w Rejestracje aplikacji w centrum administracyjnym firmy Microsoft Entra.

• W przypadku aplikacji korzystających z menedżera uwierzytelniania sieci Web (WAM), identyfikatory URI przekierowania nie muszą być skonfigurowane w MSAL, ale muszą być skonfigurowane w rejestracji aplikacji.

• W przypadku aplikacji korzystających z uwierzytelniania interakcyjnego:

  • Aplikacje korzystające z przeglądarek osadzonych: (Uwaga: https://login.microsoftonline.com/common/oauth2/nativeclient jeśli aplikacja będzie pojawiać się w oknie, które zwykle nie zawiera paska adresu, używa przeglądarki osadzonej).
  • Aplikacje korzystające z przeglądarek systemowych: (Uwaga: http://localhost jeśli aplikacja będzie używać domyślnej przeglądarki systemu (takiej jak Edge, Chrome, Firefox itd.), aby odwiedzić portal logowania firmy Microsoft, używa przeglądarki systemowej).

  Ważne

  Najlepszym rozwiązaniem w zakresie zabezpieczeń jest jawne ustawienie https://login.microsoftonline.com/common/oauth2/nativeclient lub http://localhost jako identyfikator URI przekierowania. Niektóre biblioteki uwierzytelniania, takie jak MSAL.NET używają wartości domyślnej urn:ietf:wg:oauth:2.0:oob , jeśli nie określono innego identyfikatora URI przekierowania, co nie jest zalecane. Ta wartość domyślna zostanie zaktualizowana jako zmiana powodująca niezgodność w następnej wersji głównej.

• Jeśli utworzysz natywną aplikację Objective-C lub Swift dla systemu macOS, zarejestruj identyfikator URI przekierowania na podstawie identyfikatora pakietu aplikacji w następującym formacie: msauth.<your.app.bundle.id>://auth. Zastąp ciąg <your.app.bundle.id> identyfikatorem pakietu aplikacji.

• Jeśli tworzysz aplikację Node.js Electron, użyj niestandardowego protokołu łańcuchowego zamiast zwykłego identyfikatora URI przekierowania sieci Web (https://), aby obsłużyć krok przekierowania w przepływie autoryzacji, na przykład msal{Your_Application/Client_Id}://auth (takiego jak msal00001111-aaaa-2222-bbbb-3333cccc4444://auth). Nazwa niestandardowego protokołu ciągów nie powinna być oczywista i powinna być zgodna z sugestiami w specyfikacji OAuth2.0 dla aplikacji natywnych.

• Jeśli aplikacja używa tylko zintegrowanego uwierzytelniania systemu Windows lub nazwy użytkownika i hasła, nie musisz rejestrować identyfikatora URI przekierowania dla aplikacji. Te przepływy wykonują rundę w obie strony do punktu końcowego platformy tożsamości Microsoft w wersji 2.0. Aplikacja nie zostanie wywołana ponownie dla żadnego konkretnego URI.

• Aby odróżnić przepływ kodu urządzenia, zintegrowane uwierzytelnianie Windows oraz nazwę użytkownika i hasło od poufnej aplikacji klienckiej, używając przepływu poświadczeń klienta stosowanego w aplikacjach demona, z których żadna nie wymaga identyfikatora URI przekierowania, skonfiguruj te aplikacje jako publiczne aplikacje klienckie. Aby osiągnąć tę konfigurację:

  1. W centrum administracyjnym firmy Microsoft Entra wybierz aplikację w Rejestracje aplikacji, a następnie wybierz pozycję Uwierzytelnianie.

  2. W Ustawieniach zaawansowanych>zezwól na przepływy klientów publicznych i włącz następujące przepływy>dla urządzeń przenośnych i stacjonarnych: wybierz Tak.

     

Uprawnienia interfejsu API

Aplikacje desktopowe wywołują API dla zalogowanego użytkownika. Muszą zażądać uprawnień delegowanych. Nie mogą żądać uprawnień aplikacji, które są obsługiwane tylko w aplikacjach demona.

Następne kroki

Przejdź do następnego artykułu w tym scenariuszu, konfiguracja kodu aplikacji.