Typy aplikacji, które mogą być używane w usłudze Active Directory B2C

2025-05-04

Ważne

Od 1 maja 2025 r. usługa Azure AD B2C nie będzie już dostępna do zakupu dla nowych klientów. Dowiedz się więcej w naszych często zadawanych pytaniach.

Azure Active Directory B2C (Azure AD B2C) obsługuje uwierzytelnianie dla różnych nowoczesnych architektur aplikacji. Wszystkie z nich 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ć, niezależnie od preferowanego języka lub platformy. Pomaga również zrozumieć scenariusze wysokiego poziomu przed rozpoczęciem tworzenia aplikacji.

Każda aplikacja korzystająca z usługi Azure AD B2C musi być zarejestrowana w dzierżawie usługi Azure AD B2C za pomocą portalu Azure. Proces rejestracji aplikacji zbiera i przypisuje wartości, takie jak:

Identyfikator aplikacji, który jednoznacznie identyfikuje aplikację.
Adres URL odpowiedzi, którego można użyć do kierowania odpowiedzi z powrotem do aplikacji.

Każde żądanie wysyłane do usługi Azure AD B2C określa przepływ użytkownika (wbudowane zasady) lub zasady niestandardowe , które kontrolują zachowanie usługi Azure AD B2C. Oba typy zasad umożliwiają tworzenie wysoce dostosowywalnego zestawu środowisk użytkownika.

Interakcja każdej aplikacji jest zgodna z podobnym wzorcem wysokiego poziomu:

Aplikacja kieruje użytkownika do punktu końcowego wersji 2.0, aby wykonać politykę.
Użytkownik uzupełnia politykę zgodnie z definicją polityki.
Aplikacja otrzymuje token zabezpieczający z punktu końcowego w wersji 2.0.
Aplikacja używa tokenu zabezpieczającego w celu uzyskania dostępu do chronionych informacji lub chronionego zasobu.
Serwer zasobów weryfikuje token zabezpieczający, aby sprawdzić, czy można udzielić dostępu.
Aplikacja okresowo odświeża token zabezpieczający.

Te kroki mogą się nieznacznie różnić w zależności od typu tworzonej aplikacji.

Aplikacje internetowe

pl-PL: W przypadku aplikacji internetowych (w tym .NET, PHP, Java, Ruby, Python i Node.js), które są hostowane na serwerze internetowym i dostępne za pośrednictwem przeglądarki, usługa Azure AD B2C obsługuje OpenID Connect dla wszystkich środowisk użytkownika. W implementacji OpenID Connect w usłudze Azure AD B2C aplikacja internetowa inicjuje środowiska użytkownika, wysyłając żądania uwierzytelniania do identyfikatora Microsoft Entra. Wynikiem żądania jest id_token. Ten token zabezpieczający reprezentuje tożsamość użytkownika. Udostępnia również informacje o użytkowniku w formie roszczeń:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb"
    ...
}

Dowiedz się więcej o typach tokenów i oświadczeń dostępnych dla aplikacji w dokumentacji tokenów usługi Azure AD B2C.

W aplikacji internetowej każde wykonanie zasad powoduje wykonanie następujących kroków wysokiego poziomu:

Użytkownik przechodzi do aplikacji internetowej.
Aplikacja internetowa przekierowuje użytkownika do usługi Azure AD B2C, wskazując zasady do wykonania.
Użytkownik wypełnia polisę.
Azure AD B2C zwraca id_token do przeglądarki.
id_token zostaje opublikowany w identyfikatorze URI przekierowania.
Plik id_token jest weryfikowany i ustawiany jest sesyjny plik cookie.
Bezpieczna strona zostanie zwrócona użytkownikowi.

Walidacja id_token przy użyciu publicznego klucza podpisywania, który jest odbierany z identyfikatora Microsoft Entra, jest wystarczająca do zweryfikowania tożsamości użytkownika. Proces ten ustawia również sesyjny plik cookie, który może być używany do identyfikacji użytkownika przy kolejnych żądaniach strony.

Aby zobaczyć ten scenariusz w działaniu, wypróbuj jeden z przykładów kodu logowania do aplikacji internetowej w naszej sekcji Wprowadzenie.

Oprócz ułatwienia prostego logowania aplikacja internetowa może również wymagać dostępu do usługi internetowej zaplecza. W takim przypadku aplikacja internetowa może wykonać nieco inny przepływ OpenID Connect i uzyskać tokeny za pomocą kodów autoryzacji i tokenów odświeżania. Ten scenariusz jest przedstawiony w następującej sekcji interfejsów API sieci Web.

Aplikacje jednostronicowe

Wiele nowoczesnych aplikacji internetowych jest tworzonych jako aplikacje jednostronicowe po stronie klienta ("SPAs"). Programiści piszą je przy użyciu JavaScript lub frameworka SPA, takiego jak Angular, Vue lub React. Te aplikacje działają w przeglądarce internetowej i mają różne cechy uwierzytelniania niż tradycyjne aplikacje internetowe po stronie serwera.

Usługa Azure AD B2C udostępnia dwie opcje umożliwiające logowanie użytkowników w aplikacjach jednostronicowych i uzyskiwanie tokenów do uzyskiwania dostępu do usług zaplecza lub do internetowych interfejsów API.

Przepływ kodu autoryzacji (z PKCE)

Przepływ kodu autoryzacji OAuth 2.0 (z protokołem PKCE) umożliwia aplikacji wymianę kodu autoryzacji tokenów identyfikatorów w celu reprezentowania uwierzytelnionego użytkownika i tokenów dostępu wymaganych do wywoływania chronionych interfejsów API. Ponadto zwraca tokeny odświeżania , które zapewniają długoterminowy dostęp do zasobów w imieniu użytkowników bez konieczności interakcji z tymi użytkownikami.

Zalecamy takie podejście. Posiadanie tokenów odświeżania o ograniczonym okresie istnienia pomaga aplikacji dostosować się do nowoczesnych ograniczeń prywatności plików cookie przeglądarki, takich jak Safari ITP.

Aby skorzystać z tego przepływu, aplikacja może użyć biblioteki uwierzytelniania, która go obsługuje, takiej jak MSAL.js 2.x.

Jednostronicowe uwierzytelnianie aplikacji

Niejawny przepływ udzielania

Niektóre biblioteki, takie jak MSAL.js 1.x, obsługują tylko niejawny przepływ udzielania lub aplikacja jest implementowana do korzystania z przepływu niejawnego. W takich przypadkach usługa Azure AD B2C obsługuje niejawny przepływ OAuth 2.0. Niejawny przepływ autoryzacji umożliwia aplikacji uzyskanie identyfikatora i tokenów dostępu. W przeciwieństwie do przepływu kodu autoryzacji, niejawny przepływ autoryzacji nie zwraca tokenu odświeżania.

Ten przepływ uwierzytelniania nie obejmuje scenariuszy aplikacji korzystających z międzyplatformowych struktur Języka JavaScript, takich jak Electron i React-Native. Scenariusze te wymagają dalszych możliwości interakcji z platformami natywnymi.

Ostrzeżenie

Firma Microsoft zaleca, aby nie używać niejawnego przepływu udzielania. Zalecanym sposobem wsparcia SPA jest przepływ kodu autoryzacji OAuth 2.0 (z PKCE). Niektóre konfiguracje tego przepływu wymagają bardzo wysokiego stopnia zaufania w aplikacji i niesie ze sobą ryzyko, które nie występują w innych przepływach. Tego przepływu należy używać tylko wtedy, gdy inne bezpieczniejsze przepływy nie są opłacalne. Aby uzyskać więcej informacji, zobacz obawy dotyczące zabezpieczeń dotyczące niejawnego przepływu udzielania.

Internetowe interfejsy API

Za pomocą usługi Azure AD B2C można zabezpieczyć usługi internetowe, takie jak internetowy interfejs API RESTful aplikacji. Internetowe interfejsy API mogą używać protokołu OAuth 2.0 do zabezpieczania swoich danych, uwierzytelniając przychodzące żądania HTTP przy użyciu tokenów. Obiekt wywołujący internetowy interfejs API dołącza token w nagłówku autoryzacji żądania HTTP:

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

Internetowy interfejs API może następnie użyć tokenu do zweryfikowania tożsamości obiektu wywołującego interfejs API i wyodrębnienia informacji o obiekcie wywołującym z oświadczeń zakodowanych w tokenie. Dowiedz się więcej o typach tokenów i oświadczeń dostępnych dla aplikacji w dokumentacji tokenów usługi Azure AD B2C.

Internetowy interfejs API może odbierać tokeny od wielu typów klientów, w tym aplikacji internetowych, aplikacji klasycznych i mobilnych, aplikacji jednostronicowych, demonów po stronie serwera i innych internetowych interfejsów API. Oto przykład pełnego procesu aplikacji internetowej, która wywołuje interfejs API.

Aplikacja internetowa wykonuje politykę, dzięki czemu użytkownik kończy doświadczenie użytkownika.
Azure AD B2C zwraca token (OpenID Connect) id_token oraz kod autoryzacji do przeglądarki.
Przeglądarka przesyła id_token i kod autoryzacji do identyfikatora URI przekierowania.
Serwer WWW weryfikuje id_token i ustawia sesyjny plik cookie.
Serwer internetowy prosi Azure AD B2C o access_token, dostarczając kod autoryzacji, identyfikator klienta aplikacji oraz poświadczenia klienta.
Elementy access_token i refresh_token są zwracane do serwera WWW.
Internetowy interfejs API jest wywoływany z access_token w nagłówku autoryzacji.
Internetowy interfejs API weryfikuje token.
Bezpieczne dane są zwracane do aplikacji internetowej.

Aby dowiedzieć się więcej o kodach autoryzacji, tokenach odświeżania i krokach uzyskiwania tokenów, przeczytaj o protokole OAuth 2.0.

Aby dowiedzieć się, jak zabezpieczyć internetowy interfejs API przy użyciu usługi Azure AD B2C, zapoznaj się z samouczkami internetowego interfejsu API w naszej sekcji Wprowadzenie.

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 w imieniu użytkowników. Możesz dodać dostosowane środowiska zarządzania tożsamościami do aplikacji natywnych i bezpiecznie komunikować się z usługami zaplecza przy użyciu usługi Azure AD B2C i przepływu kodu autoryzacji OAuth 2.0.

W tym przepływie aplikacja wykonuje zasady i otrzymuje authorization_code od Microsoft Entra ID po zakończeniu zasad przez użytkownika. Reprezentuje authorization_code uprawnienie aplikacji do wywoływania usług zaplecza w imieniu użytkownika, który jest aktualnie zalogowany. Aplikacja może następnie zamienić authorization_code w tle na access_token i refresh_token. Aplikacja może używać access_token do uwierzytelniania się w zapleczu webowego API w żądaniach HTTP. Może również użyć , refresh_token aby uzyskać nowy access_token , gdy starszy wygaśnie.

Demony/aplikacje po stronie serwera

Aplikacje, które zawierają długotrwałe procesy lub działają bez obecności użytkownika, również potrzebują sposobu uzyskiwania dostępu do zabezpieczonych zasobów, takich jak internetowe interfejsy API. Te aplikacje mogą uwierzytelniać się i uzyskiwać tokeny przy użyciu swoich tożsamości (a nie delegowanej tożsamości użytkownika) oraz przy użyciu przepływu poświadczeń klienta OAuth 2.0. Przepływ poświadczeń klienta nie jest taki sam jak przepływ w trybie działania w imieniu i ten ostatni nie powinien być używany do uwierzytelniania serwer-do-serwera.

W przypadku usługi Azure AD B2C przepływ poświadczeń klienta OAuth 2.0 jest obecnie dostępny w publicznej wersji zapoznawczej. Można jednak skonfigurować przepływ poświadczeń klienta przy użyciu identyfikatora Microsoft Entra i punktu końcowego platformy /token tożsamości firmy Microsoft (https://login.microsoftonline.com/your-tenant-name.onmicrosoft.com/oauth2/v2.0/token) dla aplikacji Microsoft Graph lub własnej aplikacji. Aby uzyskać więcej informacji, zapoznaj się z artykułem Microsoft Entra token reference.

Nieobsługiwane typy aplikacji

Łańcuchy internetowego interfejsu API (w imieniu przepływu)

Wiele architektur zawiera API, które musi wykonać wywołanie do innego podrzędnego API, przy czym oba są zabezpieczone przez Azure AD B2C. Ten scenariusz jest typowy dla klientów natywnych, którzy mają zaplecze internetowego interfejsu API i wywołują usługę online firmy Microsoft, taką jak interfejs API programu Microsoft Graph.

Ten scenariusz połączonego internetowego interfejsu API może być obsługiwany przy użyciu udzielenia poświadczeń okaziciela JWT OAuth 2.0, znanego również jako przepływ w imieniu. Jednak przepływ z upoważnienia nie jest obecnie zaimplementowany w usłudze Azure AD B2C.

Dalsze kroki

Dowiedz się więcej o zasadach wbudowanych w przepływy użytkownika w usłudze Azure Active Directory B2C.