Udostępnij za pośrednictwem

Azure AD B2C: protokoły uwierzytelniania

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.

Usługa Azure Active Directory B2C (Azure AD B2C) zapewnia tożsamość jako usługę dla aplikacji, obsługując dwa standardowe protokoły branżowe: OpenID Connect i OAuth 2.0. Usługa jest zgodna ze standardami, ale wszystkie dwie implementacje tych protokołów mogą mieć subtelne różnice.

Informacje przedstawione w tym przewodniku są przydatne w przypadku pisania kodu przez bezpośrednie wysyłanie i obsługę żądań HTTP, a nie przy użyciu biblioteki open source. Zalecamy przeczytanie tej strony przed zapoznaniem się ze szczegółami poszczególnych protokołów. Jeśli jednak znasz już usługę Azure AD B2C, możesz przejść bezpośrednio do przewodników referencyjnych protokołu.

Podstawy

Każda aplikacja korzystająca z usługi Azure AD B2C musi być zarejestrowana w katalogu B2C w witrynie Azure Portal. Proces rejestracji aplikacji zbiera i przypisuje kilka wartości do aplikacji:

  • Identyfikator aplikacji, który jednoznacznie identyfikuje twoją aplikację.

  • Identyfikator URI przekierowania lub identyfikator pakietu , który może służyć do kierowania odpowiedzi z powrotem do aplikacji.

  • Kilka innych wartości specyficznych dla scenariusza. Aby uzyskać więcej informacji, dowiedz się, jak zarejestrować aplikację.

Po zarejestrowaniu aplikacji komunikuje się z usługą Azure AD B2C, wysyłając żądania do punktu końcowego:

https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/authorize
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/oauth2/v2.0/token

Jeśli używasz domeny niestandardowej, zastąp ciąg {tenant}.b2clogin.com domeną niestandardową, taką jak contoso.com, w punktach końcowych.

W prawie wszystkich przepływach OAuth i OpenID Connect cztery strony są zaangażowane w wymianę:

Diagram przedstawiający cztery role OAuth 2.0.

  • Serwer autoryzacji jest punktem końcowym usługi Azure AD B2C. Bezpiecznie obsługuje wszystkie elementy związane z informacjami o użytkowniku i dostępem. Obsługuje również relacje zaufania między stronami w procesie. Odpowiada za weryfikowanie tożsamości użytkownika, udzielanie i odwołowanie dostępu do zasobów oraz wystawianie tokenów. Jest to również znane jako dostawca tożsamości.

  • Właściciel zasobu jest zazwyczaj użytkownikiem końcowym. Jest to strona, która jest właścicielem danych, i ma prawo zezwalać osobom trzecim na dostęp do tych danych lub zasobów.

  • Klient OAuth to Twoja aplikacja. Jest identyfikowany przez swój identyfikator aplikacji. Zazwyczaj jest to podmiot, z którym użytkownicy końcowi wchodzą w interakcję. Żąda również tokenów z serwera autoryzacji. Właściciel zasobu musi udzielić klientowi uprawnień dostępu do zasobu.

  • Serwer zasobów to miejsce, w którym znajduje się zasób lub dane. Ufa on serwerowi autoryzacji w celu bezpiecznego uwierzytelniania i autoryzacji klienta OAuth. Używa również tokenów dostępu typu 'bearer', w celu umożliwienia udzielenia dostępu do zasobu.

Zasady i przepływy użytkowników

Usługa Azure AD B2C rozszerza standardowe protokoły OAuth 2.0 i OpenID Connect, wprowadzając zasady. Umożliwiają one usłudze Azure AD B2C wykonywanie znacznie więcej niż prostego uwierzytelniania i autoryzacji.

Aby ułatwić konfigurowanie najbardziej typowych zadań związanych z tożsamościami, portal usługi Azure AD B2C zawiera wstępnie zdefiniowane, konfigurowalne zasady nazywane przepływami użytkowników. Przepływy użytkowników w pełni opisują doświadczenia użytkowników związane z tożsamością, w tym rejestrację, logowanie i edytowanie profilu. Przepływy użytkownika można zdefiniować w interfejsie użytkownika administracyjnego. Można je wykonywać przy użyciu specjalnego parametru zapytania w żądaniach uwierzytelniania HTTP.

Zasady i przepływy użytkowników nie są standardowymi funkcjami protokołu OAuth 2.0 i openID Connect, dlatego należy zająć trochę czasu, aby je zrozumieć. Aby uzyskać więcej informacji, zobacz przewodnik po przepływie użytkownika usługi Azure AD B2C.

Tokeny

Implementacja protokołu OAuth 2.0 i OpenID Connect w usłudze Azure AD B2C umożliwia szerokie wykorzystanie tokenów elementu nośnego, w tym tokenów elementu nośnego, które są reprezentowane jako tokeny internetowe JSON (JWTs). Token użytkownika jest lekkim tokenem zabezpieczającym, który udziela posiadaczowi dostęp do chronionego zasobu.

Posiadacz to każda strona, która może przedstawić token. Usługa Azure AD B2C musi najpierw uwierzytelnić stronę, zanim będzie mogła otrzymać token nosiciela. Jeśli jednak wymagane kroki nie są podejmowane w celu zabezpieczenia tokenu w transmisji i magazynie, można go przechwycić i używać przez niezamierzoną stronę.

Niektóre tokeny zabezpieczające mają wbudowane mechanizmy, które uniemożliwiają nieautoryzowanym stronom korzystanie z nich, ale tokeny elementu nośnego nie mają tego mechanizmu. Muszą być transportowane w bezpiecznym kanale, takim jak warstwa zabezpieczeń transportu (HTTPS).

Jeśli token elementu nośnego jest przesyłany poza bezpiecznym kanałem, złośliwa strona może użyć ataku typu man-in-the-middle, aby uzyskać token i użyć go do uzyskania nieautoryzowanego dostępu do chronionego zasobu. Te same zasady zabezpieczeń mają zastosowanie, gdy tokeny elementu nośnego są przechowywane lub buforowane do późniejszego użycia. Zawsze upewnij się, że aplikacja przesyła i przechowuje tokeny elementu nośnego w bezpieczny sposób.

Aby uzyskać dodatkowe zagadnienia dotyczące zabezpieczeń tokenu nośnego, zobacz RFC 6750 Sekcja 5.

Więcej informacji o różnych typach tokenów używanych w usłudze Azure AD B2C jest dostępnych w dokumentacji tokenów usługi Azure AD B2C.

Protokoły

Kiedy będziesz gotowy do przeglądu przykładowych żądań, możesz zacząć od jednego z poniższych samouczków. Każdy z nich odpowiada konkretnemu scenariuszowi uwierzytelniania. Jeśli potrzebujesz pomocy przy określaniu, który przepływ jest odpowiedni dla Ciebie, zapoznaj się z typami aplikacji, które możesz utworzyć przy użyciu usługi Azure AD B2C.