Aplikacja klasyczna, która wywołuje internetowe interfejsy API: rejestracja aplikacji

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

Obsługiwane typy kont

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

Odbiorcy pozyskiwania tokenu interakcyjnego

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

Odbiorcy przepływów dyskretnych aplikacji klasycznych

  • Aby użyć zintegrowanego uwierzytelniania systemu Windows lub nazwy użytkownika i hasła, aplikacja musi zalogować użytkowników w swojej dzierżawie, na przykład jeśli jesteś deweloperem biznesowym (LOB). Lub w organizacjach firmy Microsoft Entra twoja aplikacja musi logować użytkowników we własnej dzierżawie, jeśli jest to scenariusz niezależnego dostawcy oprogramowania. Te przepływy uwierzytelniania nie są obsługiwane w przypadku kont osobistych Microsoft.
  • Jeśli logujesz użytkowników przy użyciu tożsamości społecznościowych, które przekazują urząd i zasady biznesowe do handlu (B2C), możesz używać tylko uwierzytelniania interakcyjnego i hasła użytkownika.

Identyfikatory URI przekierowania

Identyfikatory URI przekierowania do użycia w aplikacji klasycznej 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 usłudze 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 itp.), 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 ciągów zamiast zwykłego identyfikatora URI przekierowania internetowego (https://), aby obsłużyć krok przekierowania przepływu autoryzacji, na przykład msal{Your_Application/Client_Id}://auth (np. 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ę do punktu końcowego Platforma tożsamości Microsoft w wersji 2.0. Aplikacja nie zostanie wywołana ponownie dla żadnego określonego identyfikatora URI.

  • Aby odróżnić przepływ kodu urządzenia, zintegrowane uwierzytelnianie systemu Windows oraz nazwę użytkownika i hasło z poufnej aplikacji klienckiej przy użyciu przepływu poświadczeń klienta używanego w aplikacjach demona, z których żaden nie wymaga identyfikatora URI przekierowania, skonfiguruj go jako publiczną aplikację kliencką. 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 obszarze Ustawienia>zaawansowane Zezwalaj na przepływy klientów publicznych Włącz następujące przepływy>dla urządzeń przenośnych i klasycznych: wybierz pozycję Tak.

      Włączanie ustawienia klienta publicznego w okienku Uwierzytelnianie w witrynie Azure Portal

Uprawnienia aplikacji

Aplikacje klasyczne wywołają interfejsy 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.