Platforma tożsamości Microsoft typy aplikacji i przepływy uwierzytelniania

Platforma tożsamości Microsoft obsługuje uwierzytelnianie dla różnych rodzajów nowoczesnych architektur aplikacji. Wszystkie architektury są oparte na standardowych protokołach OAuth 2.0 i OpenID Połączenie. Korzystając z bibliotek uwierzytelniania dla Platforma tożsamości Microsoft, aplikacje uwierzytelniają tożsamości i uzyskują tokeny w celu uzyskania dostępu do chronionych interfejsów API.

W tym artykule opisano przepływy uwierzytelniania i scenariusze aplikacji, w których są używane.

Kategorie aplikacji

Tokeny zabezpieczające można uzyskać z kilku typów aplikacji, w tym:

• Aplikacje internetowe
• Aplikacji mobilnych
• Aplikacje klasyczne
• Interfejsy API sieci Web

Tokeny mogą być również uzyskiwane przez aplikacje działające na urządzeniach, które nie mają przeglądarki lub działają w Internecie rzeczy (IoT).

W poniższych sekcjach opisano kategorie aplikacji.

Chronione zasoby a aplikacje klienckie

Scenariusze uwierzytelniania obejmują dwa działania:

• Uzyskiwanie tokenów zabezpieczających dla chronionego internetowego interfejsu API: zalecamy korzystanie z biblioteki Microsoft Authentication Library (MSAL) opracowanej i obsługiwanej przez firmę Microsoft.
• Ochrona internetowego interfejsu API lub aplikacji internetowej: Jednym z wyzwań dotyczących ochrony tych zasobów jest weryfikowanie tokenu zabezpieczającego. Na niektórych platformach firma Microsoft oferuje biblioteki oprogramowania pośredniczącego.

Użytkownicy lub bez użytkowników

Większość scenariuszy uwierzytelniania uzyskuje tokeny w imieniu zalogowanych użytkowników.

Istnieją jednak również aplikacje demona. W tych scenariuszach aplikacje uzyskują tokeny w imieniu siebie bez użytkownika.

Jednostronicowe, publiczne i poufne aplikacje klienckie

Tokeny zabezpieczające mogą być uzyskiwane przez wiele typów aplikacji. Te aplikacje są zwykle oddzielone od następujących trzech kategorii. Każda z nich jest używana z różnymi bibliotekami i obiektami.

• Aplikacje jednostronicowe: nazywane również dostawcami usług, są to aplikacje internetowe, w których tokeny są uzyskiwane przez aplikację JavaScript lub TypeScript działającą w przeglądarce. Wiele nowoczesnych aplikacji ma jednostronicową aplikację na frontonie, która jest napisana głównie w języku JavaScript. Aplikacja często używa platformy, takiej jak Angular, React lub Vue. MSAL.js jest jedyną biblioteką uwierzytelniania firmy Microsoft, która obsługuje aplikacje jednostronicowe.

• Publiczne aplikacje klienckie: aplikacje w tej kategorii, takie jak następujące typy, zawsze loguj użytkowników:

  • Aplikacje klasyczne wywołujące internetowe interfejsy API w imieniu zalogowanych użytkowników
  • Aplikacje mobilne
  • Aplikacje uruchomione na urządzeniach, które nie mają przeglądarki, takie jak aplikacje uruchomione w usłudze IoT

• Poufne aplikacje klienckie: aplikacje w tej kategorii obejmują:

  • Aplikacje internetowe wywołujące internetowy interfejs API
  • Internetowe interfejsy API wywołujące internetowy interfejs API
  • Aplikacje demona, nawet w przypadku implementacji jako usługi konsolowej, takiej jak demon systemu Linux lub usługa systemu Windows

Logowanie odbiorców

Dostępne przepływy uwierzytelniania różnią się w zależności od odbiorców logowania. Niektóre przepływy są dostępne tylko dla kont służbowych. Inne są dostępne zarówno dla kont służbowych, jak i osobistych kont Microsoft.

Aby uzyskać więcej informacji, zobacz Obsługiwane typy kont.

Typy aplikacji

Platforma tożsamości Microsoft obsługuje uwierzytelnianie dla tych architektur aplikacji:

• Aplikacje jednostronicowe
• Aplikacje internetowe
• Interfejsy API sieci Web
• Aplikacje mobilne
• Aplikacje natywne
• Aplikacje demona
• Aplikacje po stronie serwera

Aplikacje używają różnych przepływów uwierzytelniania do logowania użytkowników i uzyskiwania tokenów w celu wywoływania chronionych interfejsów API.

Aplikacja jednostronicowa

Wiele nowoczesnych aplikacji internetowych jest tworzonych jako aplikacje jednostronicowe po stronie klienta. Te aplikacje używają języka JavaScript lub platformy, takiej jak Angular, Vue i React. Te aplikacje działają w przeglądarce internetowej.

Aplikacje jednostronicowe różnią się od tradycyjnych aplikacji internetowych po stronie serwera pod względem właściwości uwierzytelniania. Korzystając z Platforma tożsamości Microsoft, aplikacje jednostronicowe mogą logować użytkowników i uzyskiwać tokeny w celu uzyskania dostępu do usług zaplecza lub internetowych interfejsów API. Platforma tożsamości Microsoft oferuje dwa typy dotacji dla aplikacji JavaScript:

MSAL.js (2.x)	MSAL.js (1.x)

Aplikacja internetowa, która loguje się użytkownika

Aby ułatwić ochronę aplikacji internetowej, która loguje się użytkownika:

• Jeśli programujesz na platformie .NET, używasz ASP.NET lub ASP.NET Core z oprogramowaniem pośredniczącym ASP.NET OpenID Połączenie. Ochrona zasobu obejmuje weryfikowanie tokenu zabezpieczającego, który jest wykonywany przez rozszerzenia IdentityModel dla platformy .NET , a nie bibliotek BIBLIOTEK MSAL.

• Jeśli programujesz w Node.js, należy użyć biblioteki MSAL Node.

Aby uzyskać więcej informacji, zobacz Aplikacja internetowa, która loguje użytkowników.

Aplikacja internetowa, która loguje użytkownika i wywołuje internetowy interfejs API w imieniu użytkownika

Aby wywołać internetowy interfejs API z aplikacji internetowej w imieniu użytkownika, użyj przepływu kodu autoryzacji i zapisz uzyskane tokeny w pamięci podręcznej tokenów. W razie potrzeby biblioteka MSAL odświeża tokeny i kontroler w trybie dyskretnym uzyskuje tokeny z pamięci podręcznej.

Aby uzyskać więcej informacji, zobacz Aplikacja internetowa, która wywołuje internetowe interfejsy API.

Aplikacja klasyczna, która wywołuje internetowy interfejs API w imieniu zalogowanego użytkownika

Aby aplikacja klasyczna wywoływać internetowy interfejs API, który loguje użytkowników, należy użyć interaktywnych metod pozyskiwania tokenów biblioteki MSAL. Za pomocą tych metod interaktywnych możesz kontrolować środowisko interfejsu użytkownika logowania. Biblioteka MSAL używa przeglądarki internetowej na potrzeby tej interakcji.

Istnieje inna możliwość dla aplikacji hostowanych w systemie Windows na komputerach dołączonych do domeny systemu Windows lub przez microsoft Entra ID. Te aplikacje mogą dyskretnie uzyskiwać token przy użyciu zintegrowanego uwierzytelniania systemu Windows.

Aplikacje działające na urządzeniu bez przeglądarki nadal mogą wywoływać interfejs API w imieniu użytkownika. Aby się uwierzytelnić, użytkownik musi zalogować się na innym urządzeniu z przeglądarką internetową. Ten scenariusz wymaga użycia przepływu kodu urządzenia.

Chociaż nie zalecamy używania go, przepływ nazwy użytkownika/hasła jest dostępny w publicznych aplikacjach klienckich. Ten przepływ jest nadal potrzebny w niektórych scenariuszach, takich jak DevOps.

Użycie przepływu nazwy użytkownika/hasła ogranicza aplikacje. Na przykład aplikacje nie mogą zalogować się do użytkownika, który musi używać uwierzytelniania wieloskładnikowego ani narzędzia dostępu warunkowego w usłudze Microsoft Entra ID. Aplikacje nie korzystają również z logowania jednokrotnego. Uwierzytelnianie przy użyciu przepływu nazwy użytkownika/hasła jest sprzeczne z zasadami nowoczesnego uwierzytelniania i jest udostępniane tylko ze starszych powodów.

Jeśli w aplikacjach klasycznych pamięć podręczna tokenów ma być utrwalana, możesz dostosować serializacji pamięci podręcznej tokenu. Implementując serializacji podwójnej pamięci podręcznej tokenów, można użyć pamięci podręcznych tokenów zgodnych z poprzednimi wersjami i zgodnych z przekazywaniem.

Aby uzyskać więcej informacji, zobacz Aplikacja klasyczna, która wywołuje internetowe interfejsy API.

Aplikacja mobilna, która wywołuje internetowy interfejs API w imieniu interakcyjnego użytkownika

Podobnie jak w przypadku aplikacji klasycznej aplikacja mobilna wywołuje metody pozyskiwania tokenów interakcyjnych biblioteki MSAL w celu uzyskania tokenu do wywoływania internetowego interfejsu API.

Biblioteki MSAL iOS i MSAL Android domyślnie używają systemowej przeglądarki internetowej. Można jednak zamiast tego kierować je do korzystania z osadzonego widoku internetowego. Istnieją specyficzne elementy, które zależą od platformy mobilnej: platforma uniwersalna systemu Windows (UWP), iOS lub Android.

Niektóre scenariusze, takie jak te, które obejmują dostęp warunkowy związany z identyfikatorem urządzenia lub rejestracją urządzenia, wymagają zainstalowania brokera na urządzeniu. Przykłady brokerów to microsoft Portal firmy w systemach Android i Microsoft Authenticator w systemach Android i iOS. Biblioteka MSAL może teraz korzystać z brokerów. Aby uzyskać więcej informacji na temat brokerów, zobacz Korzystanie z brokerów w systemach Android i iOS.

Aby uzyskać więcej informacji, zobacz Aplikacja mobilna, która wywołuje internetowe interfejsy API.

Uwaga

Aplikacja mobilna korzystająca z biblioteki MSAL.iOS, MSAL. System Android lub MSAL.NET na platformie Xamarin mogą mieć zastosowane zasady ochrony aplikacji. Na przykład zasady mogą uniemożliwić użytkownikowi kopiowanie chronionego tekstu. Aplikacja mobilna jest zarządzana przez usługę Intune i jest rozpoznawana przez usługę Intune jako aplikację zarządzaną. Aby uzyskać więcej informacji, zobacz Omówienie zestawu SDK aplikacji usługi Microsoft Intune.

Zestaw SDK aplikacji usługi Intune jest oddzielony od bibliotek BIBLIOTEK MSAL i współdziała z własnym identyfikatorem Entra firmy Microsoft.

Chroniony internetowy interfejs API

Za pomocą punktu końcowego Platforma tożsamości Microsoft można zabezpieczyć usługi internetowe, takie jak interfejs API RESTful aplikacji. Chroniony internetowy interfejs API jest wywoływany za pośrednictwem tokenu dostępu. Token pomaga zabezpieczyć dane interfejsu API i uwierzytelniać żądania przychodzące. Obiekt wywołujący internetowego interfejsu API dołącza token dostępu w nagłówku autoryzacji żądania HTTP.

Jeśli chcesz chronić ASP.NET lub ASP.NET Core internetowego interfejsu API, zweryfikuj token dostępu. Na potrzeby tej weryfikacji należy użyć oprogramowania pośredniczącego JWT ASP.NET. Walidacja jest wykonywana przez rozszerzenia IdentityModel dla biblioteki .NET , a nie przez MSAL.NET.

Aby uzyskać więcej informacji, zobacz Chroniony internetowy interfejs API.

Internetowy interfejs API, który wywołuje inny internetowy interfejs API w imieniu użytkownika

Aby chroniony internetowy interfejs API wywoływać inny internetowy interfejs API w imieniu użytkownika, aplikacja musi uzyskać token dla podrzędnego internetowego interfejsu API. Takie wywołania są czasami nazywane wywołaniami typu service-to-service . Internetowe interfejsy API wywołujące inne internetowe interfejsy API muszą zapewnić niestandardową serializacji pamięci podręcznej.

Aby uzyskać więcej informacji, zobacz Internetowy interfejs API, który wywołuje internetowe interfejsy API.

Aplikacja demona, która wywołuje internetowy interfejs API w nazwie demona

Aplikacje, które mają długotrwałe procesy lub działają bez interakcji użytkownika, również potrzebują sposobu uzyskiwania dostępu do bezpiecznych internetowych interfejsów API. Taka aplikacja może uwierzytelniać się i pobierać tokeny przy użyciu tożsamości aplikacji. Aplikacja potwierdza swoją tożsamość przy użyciu klucza tajnego klienta lub certyfikatu.

Możesz napisać takie aplikacje demona, które uzyskują token dla aplikacji wywołującej przy użyciu metod pozyskiwania poświadczeń klienta w usłudze MSAL. Te metody wymagają wpisu tajnego klienta dodanego do rejestracji aplikacji w identyfikatorze Entra firmy Microsoft. Następnie aplikacja udostępnia wpis tajny z wywołaną demonem. Przykłady takich wpisów tajnych obejmują hasła aplikacji, asercji certyfikatu i asercji klienta.

Aby uzyskać więcej informacji, zobacz Aplikacja demona, która wywołuje internetowe interfejsy API.

Scenariusze i obsługiwane przepływy uwierzytelniania

Przepływy uwierzytelniania służą do implementowania scenariuszy aplikacji, które żądają tokenów. Nie istnieje mapowanie jeden do jednego między scenariuszami aplikacji i przepływami uwierzytelniania.

Scenariusze obejmujące uzyskiwanie tokenów są również mapowanie na przepływy uwierzytelniania OAuth 2.0. Aby uzyskać więcej informacji, zobacz Protokoły OAuth 2.0 i OpenID Połączenie w Platforma tożsamości Microsoft.

Scenariusz	Szczegółowy przewodnik po scenariuszu	Przepływ i udzielanie protokołu OAuth 2.0	Odbiorcy
	Aplikacje z jedną stroną	Kod autoryzacji za pomocą protokołu PKCE	Konta służbowe, konta osobiste i usługa Azure Active Directory B2C (Azure AD B2C)
	Aplikacje z jedną stroną	Niejawne	Konta służbowe, konta osobiste i usługa Azure Active Directory B2C (Azure AD B2C)
	Aplikacja internetowa, która loguje użytkowników	Kod autoryzacji	Konta służbowe, konta osobiste i usługa Azure AD B2C
	Aplikacja internetowa, która wywołuje internetowe interfejsy API	Kod autoryzacji	Konta służbowe, konta osobiste i usługa Azure AD B2C
	Aplikacja klasyczna wywołująca internetowe interfejsy API	Interakcyjne przy użyciu kodu autoryzacji z protokołem PKCE	Konta służbowe, konta osobiste i usługa Azure AD B2C
		Zintegrowane uwierzytelnianie systemu Windows	Konta służbowe
		Hasło właściciela zasobu	Konta służbowe i usługa Azure AD B2C
	Kod urządzenia	Konta służbowe, konta osobiste, ale nie usługa Azure AD B2C
	Aplikacja mobilna, która wywołuje internetowe interfejsy API	Interakcyjne przy użyciu kodu autoryzacji z protokołem PKCE	Konta służbowe, konta osobiste i usługa Azure AD B2C
		Hasło właściciela zasobu	Konta służbowe i usługa Azure AD B2C
	Aplikacja demona, która wywołuje internetowe interfejsy API	Poświadczenia klienta	Uprawnienia tylko do aplikacji, które nie mają użytkownika i są używane tylko w organizacjach firmy Microsoft Entra
	Internetowy interfejs API wywołujący internetowe interfejsy API	W imieniu	Konta służbowe i konta osobiste

Scenariusze i obsługiwane platformy i języki

Biblioteki uwierzytelniania firmy Microsoft obsługują wiele platform:

• .NET
• .NET Framework
• Java
• JavaScript
• macOS
• Natywny system Android
• Aplikacja natywna systemu iOS
• Node.js
• Python
• Windows 10/UWP
• Xamarin.iOS
• Xamarin.Android

Możesz również użyć różnych języków do kompilowania aplikacji.

W kolumnie Windows w poniższej tabeli za każdym razem, gdy platforma .NET jest wymieniona, program .NET Framework jest również możliwy. Ten ostatni zostanie pominięty, aby uniknąć zaśmiecania tabeli.

Scenariusz	Windows	Linux	Mac	iOS	Android
Aplikacje z jedną stroną	MSAL.js	MSAL.js	MSAL.js	MSAL.js	MSAL.js
Aplikacje z jedną stroną	MSAL.js	MSAL.js	MSAL.js	MSAL.js	MSAL.js
Aplikacja internetowa, która loguje użytkowników	ASP.NET Core Węzeł BIBLIOTEKI MSAL	ASP.NET Core Węzeł BIBLIOTEKI MSAL	ASP.NET Core Węzeł BIBLIOTEKI MSAL
Aplikacja internetowa, która wywołuje internetowe interfejsy API	ASP.NET Core + MSAL.NET MSAL Java Flask + MSAL Python Węzeł BIBLIOTEKI MSAL	ASP.NET Core + MSAL.NET MSAL Java Flask + MSAL Python Węzeł BIBLIOTEKI MSAL	ASP.NET Core + MSAL.NET MSAL Java Flask + MSAL Python Węzeł BIBLIOTEKI MSAL
Aplikacja klasyczna wywołująca internetowe interfejsy API	MSAL.NET MSAL Java MSAL Python Węzeł BIBLIOTEKI MSAL	MSAL.NET MSAL Java MSAL Python Węzeł BIBLIOTEKI MSAL	MSAL.NET MSAL Java MSAL Python Węzeł BIBLIOTEKI MSAL MSAL.objc
Aplikacja mobilna, która wywołuje internetowe interfejsy API	MSAL.NET MSAL.NET			MSAL.objc	BIBLIOTEKA MSAL. Android
Aplikacja demona	MSAL.NET MSAL Java MSAL Python Węzeł BIBLIOTEKI MSAL	MSAL.NET MSAL Java MSAL Python Węzeł BIBLIOTEKI MSAL	MSAL.NET MSAL Java MSAL Python Węzeł BIBLIOTEKI MSAL
Internetowy interfejs API wywołujący internetowe interfejsy API	ASP.NET Core + MSAL.NET MSAL Java MSAL Python Węzeł BIBLIOTEKI MSAL	ASP.NET Core + MSAL.NET MSAL Java MSAL Python Węzeł BIBLIOTEKI MSAL	ASP.NET Core + MSAL.NET MSAL Java MSAL Python Węzeł BIBLIOTEKI MSAL

Aby uzyskać więcej informacji, zobacz Platforma tożsamości Microsoft biblioteki uwierzytelniania.

Następne kroki

Aby uzyskać więcej informacji na temat uwierzytelniania, zobacz:

• Uwierzytelnianie a autoryzacja.
• Platforma tożsamości Microsoft tokeny dostępu.
• Zabezpieczanie dostępu do aplikacji IoT.