Typy aplikacji dla Platforma tożsamości Microsoft

Platforma tożsamości Microsoft obsługuje uwierzytelnianie dla różnych nowoczesnych architektur aplikacji, z których wszystkie są oparte na standardowych protokołach branżowych OAuth 2.0 lub OpenID Connect. W tym artykule opisano typy aplikacji, które można tworzyć przy użyciu Platforma tożsamości Microsoft, niezależnie od preferowanego języka lub platformy. Te informacje ułatwiają zrozumienie scenariuszy wysokiego poziomu przed rozpoczęciem pracy z kodem w scenariuszach aplikacji.

Podstawy

Należy zarejestrować każdą aplikację korzystającą z Platforma tożsamości Microsoft w centrum administracyjnym firmy Microsoft Entra Rejestracje aplikacji. Proces rejestracji aplikacji zbiera i przypisuje następujące wartości dla aplikacji:

• Identyfikator aplikacji (klienta), który jednoznacznie identyfikuje twoją aplikację
• Identyfikator URI przekierowania, którego można użyć do kierowania odpowiedzi z powrotem do aplikacji
• Kilka innych wartości specyficznych dla scenariusza, takich jak obsługiwane typy kont

Aby uzyskać szczegółowe informacje, dowiedz się, jak zarejestrować aplikację.

Po zarejestrowaniu aplikacji aplikacja komunikuje się z Platforma tożsamości Microsoft, wysyłając żądania do punktu końcowego. Udostępniamy struktury i biblioteki typu open source, które obsługują szczegóły tych żądań. Istnieje również możliwość samodzielnego zaimplementowania logiki uwierzytelniania przez utworzenie żądań do tych punktów końcowych:

https://login.microsoftonline.com/common/oauth2/v2.0/authorize
https://login.microsoftonline.com/common/oauth2/v2.0/token

Typy aplikacji obsługiwane przez Platforma tożsamości Microsoft to;

• Aplikacja jednostronicowa (SPA)
• Aplikacja internetowa
• Internetowy interfejs API
• Aplikacje mobilne i natywne
• Usługa, demon, skrypt

Aplikacje jednostronicowe

Wiele nowoczesnych aplikacji ma fronton jednostronicowy napisany głównie w języku JavaScript, często ze strukturą, na przykład Angular, React lub Vue. Platforma tożsamości Microsoft obsługuje te aplikacje przy użyciu protokołu OpenID Connect na potrzeby uwierzytelniania i jednego z dwóch typów dotacji autoryzacji zdefiniowanych przez protokół OAuth 2.0. Podczas opracowywania umów SPA należy użyć przepływu kodu autoryzacji z kluczem PKCE. Ten przepływ jest bezpieczniejszy niż przepływ niejawny, który nie jest już zalecany. Aby uzyskać więcej informacji, zobacz preferuj przepływ kodu uwierzytelniania.

Diagram przepływu przedstawia przepływ udzielania kodu autoryzacji OAuth 2.0 (ze szczegółami dotyczącymi pomijania PKCE), w którym aplikacja odbiera kod z punktu końcowego Platforma tożsamości Microsoft authorize i wykonuje go na potrzeby tokenu dostępu i tokenu odświeżania przy użyciu żądań sieci Web obejmujących wiele witryn. W przypadku umów SPA token dostępu jest ważny przez 1 godzinę, a raz wygasł, musi zażądać innego kodu przy użyciu tokenu odświeżania. Oprócz tokenu dostępu, token id_token reprezentujący zalogowanego użytkownika do aplikacji klienckiej jest zwykle również żądany za pośrednictwem tego samego przepływu i/lub oddzielnego żądania OpenID Connect (nie pokazano tutaj).

Aby zobaczyć to w akcji, zapoznaj się z przewodnikiem Szybki start: logowanie użytkowników w jednostronicowej aplikacji (SPA) i wywoływanie interfejsu API programu Microsoft Graph przy użyciu języka JavaScript.

Aplikacje internetowe

W przypadku aplikacji internetowych (.NET, PHP, Java, Ruby, Python, Node), do których użytkownik uzyskuje dostęp za pośrednictwem przeglądarki, możesz użyć programu OpenID Connect do logowania użytkownika. W programie OpenID Connect aplikacja internetowa otrzymuje token identyfikatora. Token identyfikatora to token zabezpieczający, który weryfikuje tożsamość użytkownika i udostępnia informacje o użytkowniku w postaci oświadczeń:

// Partial raw ID token
abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...

// Partial content of a decoded ID token
{
    "name": "Casey Jensen",
    "email": "casey.jensen@onmicrosoft.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Dalsze szczegóły różnych typów tokenów używanych w Platforma tożsamości Microsoft są dostępne w dokumentacji tokenu dostępu i id_token dokumentacji.

W aplikacjach serwera internetowego przepływ uwierzytelniania logowania wykonuje następujące ogólne kroki:

Tożsamość użytkownika można zapewnić, sprawdzając token identyfikatora przy użyciu publicznego klucza podpisywania otrzymanego z Platforma tożsamości Microsoft. Ustawiono plik cookie sesji, który może służyć do identyfikowania użytkownika w kolejnych żądaniach strony.

Dowiedz się więcej, tworząc aplikację internetową platformy ASP.NET Core, która loguje użytkowników w poniższej serii samouczków wieloczęściowych

Oprócz prostego logowania aplikacja serwera internetowego może wymagać dostępu do innej usługi internetowej, takiej jak interfejs API REST (Representational State Transfer). W takim przypadku aplikacja serwera internetowego angażuje się w połączony przepływ OpenID Connect i OAuth 2.0 przy użyciu przepływu kodu autoryzacji OAuth 2.0. Aby uzyskać więcej informacji na temat tego scenariusza, zapoznaj się z naszym przykładem kodu.

Internetowe interfejsy API

Za pomocą Platforma tożsamości Microsoft można zabezpieczyć usługi internetowe, takie jak internetowy interfejs API RESTful aplikacji. Internetowe interfejsy API można zaimplementować na wielu platformach i językach. Można je również zaimplementować przy użyciu wyzwalaczy HTTP w usłudze Azure Functions. Zamiast tokenów identyfikatorów i plików cookie sesji internetowy interfejs API używa tokenu dostępu OAuth 2.0 w celu zabezpieczenia danych i uwierzytelniania żądań przychodzących.

Obiekt wywołujący internetowego interfejsu API dołącza token dostępu w nagłówku autoryzacji żądania HTTP, w następujący sposób:

GET /api/items HTTP/1.1
Host: www.mywebapi.com
Authorization: Bearer abC1dEf2Ghi3jkL4mNo5Pqr6stU7vWx8Yza9...
Accept: application/json
...

Internetowy interfejs API używa tokenu dostępu do weryfikowania tożsamości obiektu wywołującego interfejsu API i wyodrębniania informacji o obiekcie wywołującym z oświadczeń zakodowanych w tokenie dostępu. Dalsze szczegóły różnych typów tokenów używanych w Platforma tożsamości Microsoft są dostępne w dokumentacji tokenu dostępu i dokumentacji tokenu identyfikatora.

Internetowy interfejs API może dać użytkownikom możliwość rezygnacji z określonych funkcji lub danych, ujawniając uprawnienia, znane również jako zakresy. Aby aplikacja wywołująca uzyskała uprawnienia do zakresu, użytkownik musi wyrazić zgodę na zakres podczas przepływu. Platforma tożsamości Microsoft prosi użytkownika o uprawnienie, a następnie rejestruje uprawnienia we wszystkich tokenach dostępu odbieranych przez internetowy interfejs API. Internetowy interfejs API weryfikuje tokeny dostępu odbierane przy każdym wywołaniu i przeprowadza kontrole autoryzacji.

Internetowy interfejs API może odbierać tokeny dostępu ze wszystkich typów aplikacji, w tym aplikacji internetowych, aplikacji klasycznych i mobilnych, aplikacji jednostronicowych, demonów po stronie serwera, a nawet innych internetowych interfejsów API. Ogólny przepływ internetowego interfejsu API wygląda następująco:

Aby dowiedzieć się, jak zabezpieczyć internetowy interfejs API przy użyciu tokenów dostępu OAuth2, zapoznaj się z przykładami kodu internetowego interfejsu API w samouczku dotyczącym chronionego internetowego interfejsu API.

W wielu przypadkach internetowe interfejsy API muszą również wysyłać żądania wychodzące do innych podrzędnych internetowych interfejsów API zabezpieczonych przez Platforma tożsamości Microsoft. W tym celu internetowe interfejsy API mogą korzystać z przepływu On-Behalf-Of (OBO), który umożliwia internetowym interfejsowi API wymianę przychodzącego tokenu dostępu dla innego tokenu dostępu do użycia w żądaniach wychodzących. Aby uzyskać więcej informacji, zobacz przepływ Platforma tożsamości Microsoft i OAuth 2.0 On-Behalf-Of.

Aplikacje mobilne i natywne

Aplikacje zainstalowane na urządzeniach, takie jak aplikacje mobilne i klasyczne, często muszą uzyskiwać dostęp do usług zaplecza lub internetowych interfejsów API, które przechowują dane i wykonują funkcje w imieniu użytkownika. Te aplikacje mogą dodawać logowanie i autoryzację do usług zaplecza przy użyciu przepływu kodu autoryzacji OAuth 2.0.

W tym przepływie aplikacja otrzymuje kod autoryzacji z Platforma tożsamości Microsoft, gdy użytkownik się zaloguje. Kod autoryzacji reprezentuje uprawnienie aplikacji do wywoływania usług zaplecza w imieniu użytkownika, który jest zalogowany. Aplikacja może wymienić kod autoryzacji w tle dla tokenu dostępu OAuth 2.0 i token odświeżania. Aplikacja może używać tokenu dostępu do uwierzytelniania w internetowych interfejsach API w żądaniach HTTP i używać tokenu odświeżania, aby uzyskać nowe tokeny dostępu po wygaśnięciu starszych tokenów dostępu.

Nuta

Jeśli aplikacja używa domyślnego widoku internetowego systemu, sprawdź informacje na temat funkcji "Potwierdź moje logowanie" i kod AADSTS50199 błędu w kodach błędów uwierzytelniania i autoryzacji firmy Microsoft Entra.

Serwer, demony i skrypty

Aplikacje, które mają długotrwałe procesy lub działają bez interakcji z użytkownikiem, również potrzebują sposobu uzyskiwania dostępu do zabezpieczonych zasobów, takich jak internetowe interfejsy API. Te aplikacje mogą uwierzytelniać i pobierać tokeny przy użyciu tożsamości aplikacji, a nie tożsamości delegowanej użytkownika przy użyciu przepływu poświadczeń klienta OAuth 2.0. Tożsamość aplikacji można udowodnić przy użyciu klucza tajnego klienta lub certyfikatu. Aby uzyskać więcej informacji, zobacz aplikacja konsolowa demona platformy .NET używająca Platforma tożsamości Microsoft.

W tym przepływie aplikacja współdziała bezpośrednio z punktem końcowym w /token celu uzyskania dostępu:

Aby utworzyć aplikację demona, zobacz dokumentację poświadczeń klienta lub wypróbuj przykładową aplikację platformy .NET.

Zobacz też

Teraz, gdy znasz już typy aplikacji obsługiwanych przez Platforma tożsamości Microsoft, dowiedz się więcej o protokole OAuth 2.0 i OpenID Connect, aby poznać składniki protokołu używane przez różne scenariusze.