Azure AD B2C: protokoły uwierzytelniania
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ż Azure AD B2C, możesz przejść prosto 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 Azure Portal. Proces rejestracji aplikacji polega na zgromadzeniu kilku wartości i przypisaniu ich do aplikacji:
Identyfikator aplikacji który w sposób unikatowy identyfikuje 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 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ę:
Serwer autoryzacji jest punktem końcowym 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 przepływie. Jest on odpowiedzialny za weryfikowanie tożsamości użytkownika, udzielanie i odwołowanie dostępu do zasobów oraz wystawianie tokenów. Jest on również znany 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 zezwolić osobom trzecim na dostęp do tych danych lub zasobów.
Klient OAuth to Twoja aplikacja. Jest identyfikowany przez jego identyfikator aplikacji. Zazwyczaj jest to strona, z którą użytkownicy końcowi korzystają. Żą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 serwerowi autoryzacji w celu bezpiecznego uwierzytelniania i autoryzacji klienta OAuth. Używa również tokenów dostępu elementu nośnego, aby zapewnić, że można udzielić dostępu do zasobu.
Zasady i przepływy użytkowników
Azure AD B2C rozszerza standardowe protokoły OAuth 2.0 i OpenID Connect, wprowadzając zasady. Umożliwiają one 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 Azure AD B2C zawiera wstępnie zdefiniowane, konfigurowalne zasady nazywane przepływami użytkowników. Przepływy użytkowników w pełni opisują środowiska tożsamości użytkowników, w tym rejestrację, logowanie i edytowanie profilu. Przepływy użytkownika można zdefiniować w interfejsie użytkownika administracyjnego. Można je wykonać 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 Azure AD B2C umożliwia szerokie wykorzystanie tokenów elementu nośnego, w tym tokenów elementu nośnego reprezentowanych jako tokeny internetowe JSON (JWTs). Token elementu nośnego jest uproszczonym tokenem zabezpieczającym, który udziela dostępu "elementu nośnego" do chronionego zasobu.
Element nośny to każda strona, która może przedstawić token. Azure AD B2C musi najpierw uwierzytelnić stronę, zanim będzie mogła otrzymać token elementu nośnego. Jeśli jednak wymagane kroki nie zostaną podjęte w celu zabezpieczenia tokenu w transmisji i magazynie, może zostać przechwycony i użyty 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ą one być transportowane w bezpiecznym kanale, takim jak zabezpieczenia warstwy transportu (HTTPS).
Jeśli token elementu nośnego jest przesyłany poza bezpiecznym kanałem, złośliwa osoba może użyć ataku typu man-in-the-middle w celu uzyskania tokenu 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 elementu nośnego, zobacz RFC 6750 Sekcja 5.
Więcej informacji o różnych typach tokenów używanych w usłudze Azure AD B2C są dostępne w dokumentacji tokenu B2C Azure AD B2C.
Protokoły
Gdy wszystko będzie gotowe do przejrzenia 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żna tworzyć przy użyciu usługi Azure AD B2C.