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

Usługa Azure Active Directory B2C (Azure AD B2C) obsługuje uwierzytelnianie dla różnych nowoczesnych architektur aplikacji. Wszystkie one 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. Ułatwia on także zrozumienie ogólnych scenariuszy 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 przy użyciu Azure Portal. Proces rejestracji aplikacji zbiera i przypisuje wartości, takie jak:

• Identyfikator aplikacji, który jednoznacznie identyfikuje twoją aplikację.
• Adres URL odpowiedzi, który może służyć do kierowania odpowiedzi z powrotem do aplikacji.

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

Interakcja każdej aplikacji jest realizowana według następującego ogólnego schematu:

1. Aplikacja kieruje użytkownika do punktu końcowego w wersji 2.0 w celu wykonania zasad.
2. Użytkownik wypełnia zasady zgodnie z definicją zasad.
3. Aplikacja odbiera token zabezpieczający z punktu końcowego w wersji 2.0.
4. Aplikacja używa tokenu zabezpieczającego do uzyskiwania dostępu do chronionych informacji lub chronionego zasobu.
5. Serwer zasobów weryfikuje token zabezpieczający, aby sprawdzić możliwość przyznania dostępu.
6. Aplikacja okresowo odświeża token zabezpieczający.

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

Aplikacje internetowe

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, Azure AD B2C obsługuje program OpenID Connect dla wszystkich środowisk użytkownika. W implementacji Azure AD B2C programu OpenID Connect aplikacja internetowa inicjuje środowiska użytkownika, wysyłając żądania uwierzytelniania do identyfikatora Microsoft Entra. Wynikiem żądania jest token id_token. Ten token zabezpieczający reprezentuje tożsamość użytkownika. Zawiera także informacje o użytkowniku w formie oświadczeń:

// Partial raw id_token
eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6ImtyaU1QZG1Cd...

// Partial content of a decoded id_token
{
    "name": "John Smith",
    "email": "john.smith@gmail.com",
    "oid": "d9674823-dffc-4e3f-a6eb-62fe4bd48a58"
    ...
}

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

W aplikacji internetowej każde wykonanie zasad wykonuje następujące kroki wysokiego poziomu:

1. Użytkownik przechodzi do aplikacji internetowej.
2. Aplikacja internetowa przekierowuje użytkownika do Azure AD B2C wskazującą zasady do wykonania.
3. Użytkownik kończy zasady.
4. Azure AD B2C zwraca obiekt id_token do przeglądarki.
5. Element id_token jest publikowany w identyfikatorze URI przekierowania.
6. Plik id_token jest weryfikowany i ustawiany jest plik cookie sesji.
7. Bezpieczna strona jest zwracana do użytkownika.

Walidacja id_token przy użyciu publicznego klucza podpisywania otrzymanego z identyfikatora Microsoft Entra jest wystarczająca do zweryfikowania tożsamości użytkownika. Ten proces ustawia również plik cookie sesji, który może służyć do identyfikowania użytkownika na kolejnych żądaniach stron.

Aby zobaczyć ten scenariusz w działaniu, wypróbuj jeden z przykładów kodu logowania aplikacji internetowej w 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 wykonywać nieco inny przepływ OpenID Connect i uzyskiwać tokeny przy użyciu kodów autoryzacji i tokenów odświeżania. Ten scenariusz jest opisany w sekcji dotyczącej interfejsów API sieci Web poniżej.

Aplikacje jednostronicowe

Wiele nowoczesnych aplikacji internetowych jest tworzonych jako aplikacje jednostronicowe po stronie klienta ("SPAs"). Deweloperzy piszą je przy użyciu języka JavaScript lub struktury SPA, takiej 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.

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

Przepływ kodu autoryzacji (z kluczem 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łania chronionych interfejsów API. Ponadto zwraca tokeny Odświeżanie , które zapewniają długoterminowy dostęp do zasobów w imieniu użytkowników bez konieczności interakcji z tymi użytkownikami.

Zalecamy to 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żywać biblioteki uwierzytelniania, która ją obsługuje, na przykład MSAL.js 2.x.

Niejawny przepływ udzielania

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

Nie zalecamy tego podejścia.

Ten przepływ uwierzytelniania nie obejmuje scenariuszy aplikacji korzystających z wieloplatformowych struktur Języka JavaScript, takich jak Elektron i React Native. Te scenariusze wymagają dalszych możliwości interakcji z platformami natywnymi.

Interfejsy API sieci Web

Za pomocą usługi Azure AD B2C można zabezpieczyć usługi internetowe, takie jak internetowy interfejs API RESTful aplikacji. Interfejsy API sieci Web mogą zabezpieczać swoje dane za pomocą protokołu OAuth 2.0, uwierzytelniając żądania przychodzące HTTP przy użyciu tokenów. Element wywołujący interfejs API sieci Web 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
...

Interfejs API sieci Web może następnie użyć tego tokenu do zweryfikowania tożsamości elementu wywołującego interfejs API oraz do wyodrębnienia informacji o elemencie wywołującym z oświadczeń zakodowanych w tokenie. Aby uzyskać więcej informacji o typach tokenów i oświadczeń dostępnych dla aplikacji, zobacz informacje o tokenach 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 przepływu dla aplikacji internetowej, która wywołuje internetowy interfejs API:

1. Aplikacja internetowa wykonuje zasady, a użytkownik ukończy środowisko użytkownika.
2. Azure AD B2C zwraca (OpenID Connect) id_token i kod autoryzacji do przeglądarki.
3. Przeglądarka publikuje id_token kod autoryzacji i do identyfikatora URI przekierowania.
4. Serwer internetowy weryfikuje id_token plik i ustawia plik cookie sesji.
5. Serwer internetowy prosi Azure AD B2C o podanie access_token kodu autoryzacji, identyfikatora klienta aplikacji i poświadczeń klienta.
6. Element access_token i refresh_token są zwracane do serwera internetowego.
7. Internetowy interfejs API jest wywoływany z access_token nagłówkiem w nagłówku autoryzacji.
8. Internetowy interfejs API weryfikuje token.
9. Bezpieczne dane są zwracane do aplikacji internetowej.

Aby dowiedzieć się więcej o kodach autoryzacji, tokenach odświeżania i krokach uzyskiwania tokenów, zapoznaj się z informacjami na temat protokołu OAuth 2.0.

Aby dowiedzieć się, jak zabezpieczyć interfejs API sieci Web przy użyciu usługi Azure AD B2C, zapoznaj się z samouczkami dotyczącymi interfejsu API sieci Web w sekcji Wprowadzenie.

Aplikacje mobilne i natywne

Aplikacje instalowane na urządzeniach, takich 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. Niestandardowe środowiska zarządzania tożsamościami można dodać do aplikacji natywnych i bezpiecznie wywoływać usługi 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 odbiera identyfikator authorization_code z Microsoft Entra po ukończeniu zasad przez użytkownika. Reprezentuje authorization_code uprawnienie aplikacji do wywoływania usług zaplecza w imieniu użytkownika, który jest obecnie zalogowany. Następnie aplikacja może wymienić element authorization_code w tle dla elementu access_token i .refresh_token Aplikacja może używać elementu access_token do uwierzytelniania w internetowym interfejsie API zaplecza w żądaniach HTTP. Może również użyć tokenu refresh_token do pobrania nowego tokenu access_token, gdy wygaśnie stary.

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ć i pobierać tokeny przy użyciu tożsamości (zamiast tożsamości delegowanej użytkownika) i przy użyciu przepływu poświadczeń klienta OAuth 2.0. Przepływ poświadczeń klienta nie jest taki sam jak przepływ w imieniu, a przepływ w imieniu nie powinien być używany do uwierzytelniania serwer-serwer.

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

Nieobsługiwane typy aplikacji

Łańcuchy interfejsu API sieci Web (przepływ „w imieniu”)

Wiele architektur obejmuje interfejs API sieci Web, który musi wywołać inny podrzędny interfejs API sieci Web, przy czym oba interfejsy są zabezpieczane przez usługę Azure AD B2C. Ten scenariusz jest typowy w przypadku klientów natywnych, którzy mają zaplecze internetowego interfejsu API i wywołuje usługę online firmy Microsoft, taką jak microsoft interfejs Graph API.

Ten scenariusz obejmujący łańcuch interfejsów API sieci Web może być obsługiwany przy użyciu przyznania poświadczeń elementu nośnego OAuth 2.0 JWT, określanego również jako przepływ „w imieniu”. Jednak przepływ w imieniu użytkownika nie jest obecnie implementowany w Azure AD B2C.

Następne kroki

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