Udostępnij za pośrednictwem

Logowanie internetowe za pomocą narzędzia OpenID Connect w usłudze Azure Active Directory B2C

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.

OpenID Connect to protokół uwierzytelniania oparty na protokole OAuth 2.0, który może służyć do bezpiecznego logowania użytkowników do aplikacji internetowych. Korzystając z implementacji protokołu OpenID Connect w usłudze Azure Active Directory B2C (Azure AD B2C), możesz zlecić rejestrację, logowanie i inne środowiska zarządzania tożsamościami w aplikacjach internetowych do usługi Microsoft Entra ID. W tym przewodniku pokazano, jak to zrobić w sposób niezależny od języka. W tym artykule opisano sposób wysyłania i odbierania komunikatów HTTP bez używania żadnej z naszych bibliotek typu open source.

Uwaga

Większość bibliotek uwierzytelniania typu open source uzyskuje i weryfikuje JWTs dla aplikacji. Zalecamy eksplorowanie tych opcji zamiast implementowania własnego kodu. Aby uzyskać więcej informacji, zobacz Omówienie biblioteki Microsoft Authentication Library (MSAL) i biblioteki uwierzytelniania sieci Web tożsamości firmy Microsoft.

OpenID Connect rozszerza protokół autoryzacji OAuth 2.0 do użycia jako protokół uwierzytelniania . Ten protokół uwierzytelniania umożliwia logowanie jednokrotne. Wprowadza ona koncepcję tokenu identyfikatora, który umożliwia klientowi zweryfikowanie tożsamości użytkownika i uzyskanie podstawowych informacji o profilu użytkownika.

OpenID Connect umożliwia również aplikacjom bezpieczne uzyskiwanie tokenów dostępu. Tokeny dostępu umożliwiają uzyskiwanie dostępu do zasobów zabezpieczonych przez serwer autoryzacji . Zalecamy program OpenID Connect, jeśli tworzysz aplikację internetową hostowaną na serwerze i uzyskujesz dostęp za pośrednictwem przeglądarki. Aby uzyskać więcej informacji na temat tokenów, zobacz Omówienie tokenów w usłudze Azure Active Directory B2C

Usługa Azure AD B2C rozszerza standardowy protokół OpenID Connect, aby wykonywać więcej niż proste uwierzytelnianie i autoryzację. Wprowadza parametr przepływu użytkownika, który umożliwia korzystanie z OpenID Connect do integrowania doświadczeń użytkownika z aplikacją, takich jak rejestracja, logowanie i zarządzanie profilami.

Wysyłanie żądań uwierzytelniania

Gdy aplikacja internetowa musi uwierzytelnić użytkownika i uruchomić przepływ użytkownika, może kierować użytkownika do punktu końcowego /authorize . Użytkownik podejmuje działania w zależności od ścieżki użytkownika.

W tym żądaniu klient wskazuje uprawnienia, które musi uzyskać od użytkownika w parametrze scope i określa przepływ użytkownika do uruchomienia. Aby dowiedzieć się, jak działa żądanie, wklej żądanie w przeglądarce i uruchom je. Zastąp:

  • {tenant} z nazwą twojego najemcy.
  • 00001111-aaaa-2222-bbbb-3333cccc4444 z identyfikatorem aplikacji, którą zarejestrowałeś w swoim dzierżawcy.
  • {application-id-uri}/{scope-name} za pomocą URI identyfikatora aplikacji i zakresu aplikacji, którą zarejestrowałeś w swojej dzierżawie.
  • {policy} z nazwą zasad, które masz w dzierżawie, na przykład b2c_1_sign_in.
GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
Parametr Wymagane Opis
{najemca} Tak Nazwa dzierżawy usługi Azure AD B2C. Jeśli używasz domeny niestandardowej, zastąp ciąg tenant.b2clogin.com domeną, taką jak fabrikam.com.
{polityka} Tak Przepływ użytkownika lub zasady stosowane przez aplikację. Określ nazwę przepływu użytkownika, który tworzysz w dzierżawie usługi Azure AD B2C. Na przykład: b2c_1_sign_in, b2c_1_sign_uplub b2c_1_edit_profile.
identyfikator_klienta Tak Identyfikator aplikacji przypisany przez portal Azure do twojej aplikacji.
nonce Zalecane Wartość zawarta w żądaniu (wygenerowanym przez aplikację), która znajduje się w wynikowym tokenie ID jako oświadczenie. Następnie aplikacja może zweryfikować tę wartość, aby wyeliminować ataki ponownego odtwarzania tokenu. Wartość jest zazwyczaj losowym unikatowym ciągiem, który może służyć do identyfikowania źródła żądania.
typ_odpowiedzi Tak Musi zawierać token identyfikatora dla programu OpenID Connect. Jeśli aplikacja internetowa wymaga również tokenów do wywoływania internetowego interfejsu API, możesz użyć polecenia code+id_token.
zakres Tak Rozdzielona spacjami lista zakresów. Zakres openid wskazuje uprawnienie do logowania użytkownika i uzyskiwania danych o użytkowniku w postaci tokenów identyfikatorów. Zakres offline_access jest opcjonalny dla aplikacji internetowych. Wskazuje ona, że aplikacja potrzebuje tokenu odświeżania w celu uzyskania rozszerzonego dostępu do zasobów. Element https://{tenant-name}/{app-id-uri}/{scope} wskazuje uprawnienie do chronionych zasobów, takich jak internetowy interfejs API. Aby uzyskać więcej informacji, zobacz Żądanie tokenu dostępu.
zachęta Nie. Wymagany typ interakcji użytkownika. Jedyną prawidłową wartością w tej chwili jest login, która wymusza na użytkowniku wprowadzanie poświadczeń w tym żądaniu.
adres_przekierowania Tak redirect_uri Parametr aplikacji, w którym serwer wysyła odpowiedzi uwierzytelniania do aplikacji. Musi dokładnie odpowiadać jednemu z redirect_uri parametrów zarejestrowanych w witrynie Azure Portal, z tą różnicą, że musi być zakodowana pod adresem URL.
Tryb_odpowiedzi Nie. Metoda używana do wysyłania wynikowego kodu autoryzacji z powrotem do aplikacji. Może to być wartość query, form_postlub fragment. Zalecamy użycie form_post trybu odpowiedzi w celu uzyskania najlepszych zabezpieczeń.
stan Nie. Wartość, którą można uwzględnić w żądaniu, a serwer autoryzacji zwraca ją w odpowiedzi z tokenem. Może to być ciąg dowolnej zawartości. Losowo wygenerowana unikatowa wartość jest zwykle używana do zapobiegania atakom fałszerzowanym żądań między witrynami. Stan jest również używany do kodowania informacji o stanie użytkownika w aplikacji przed wystąpieniem żądania uwierzytelnienia, na przykład strony, na której się znajdowały. Jeśli nie chcesz rejestrować wielu adresów URL przekierowania w portalu Azure, możesz użyć parametru state, aby odróżnić odpowiedzi w aplikacji od usługi Azure AD B2C w odpowiedzi na różne żądania.
podpowiedź do logowania Nie. Może służyć do wstępnego wypełniania pola nazwy logowania na stronie logowania. Aby uzyskać więcej informacji, zobacz Wstępne wypełnianie nazwy logowania.
wskazówka dotycząca domeny Nie. Zawiera wskazówkę dotyczącą dostawcy tożsamości społecznościowych usługi Azure AD B2C, który powinien być używany do logowania. Jeśli zostanie uwzględniona prawidłowa wartość, użytkownik przejdzie bezpośrednio do strony logowania dostawcy tożsamości. Aby uzyskać więcej informacji, zobacz Przekierowanie logowania do dostawcy społecznościowego.
Parametry niestandardowe Nie. Parametry niestandardowe, których można używać z zasadami niestandardowymi. Na przykład dynamiczne identyfikatory URI zawartości strony niestandardowej lub metody rozpoznawania oświadczeń klucz-wartość.

Na tym etapie użytkownik zostanie poproszony o ukończenie przepływu pracy. Użytkownik może musiał wprowadzić swoją nazwę użytkownika i hasło, zalogować się przy użyciu tożsamości społecznościowej lub zarejestrować się w katalogu. W zależności od sposobu definiowania przepływu użytkownika może istnieć dowolna inna liczba kroków.

Po zakończeniu przepływu użytkownika odpowiedź zostanie zwrócona do aplikacji na wskazany parametr redirect_uri, używając metody określonej w parametrze response_mode. Odpowiedź jest taka sama dla każdego z poprzednich przypadków niezależnie od przepływu użytkownika.

Pomyślna odpowiedź używająca polecenia response_mode=fragment wygląda następująco:

GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response
Parametr Opis
token identyfikacyjny Token identyfikatora, którego zażądała aplikacja. Możesz użyć tokenu identyfikatora, aby zweryfikować tożsamość użytkownika i rozpocząć sesję z użytkownikiem.
kod Kod autoryzacji żądany przez aplikację, jeśli użyto polecenia response_type=code+id_token. Aplikacja może użyć kodu autoryzacji, aby zażądać tokenu dostępu dla zasobu docelowego. Kody autoryzacji zwykle wygasają po około 10 minutach.
stan state Jeśli parametr jest uwzględniony w żądaniu, ta sama wartość powinna pojawić się w odpowiedzi. Aplikacja powinna sprawdzić, czy state wartości w żądaniu i odpowiedzi są identyczne.

Odpowiedzi na błędy można również wysłać do parametru redirect_uri , aby aplikacja mogła je odpowiednio obsłużyć:

GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response
Parametr Opis
błąd Kod, który może służyć do klasyfikowania typów błędów, które występują.
opis błędu Określony komunikat o błędzie, który może pomóc zidentyfikować główną przyczynę błędu uwierzytelniania.
stan state Jeśli parametr jest uwzględniony w żądaniu, ta sama wartość powinna pojawić się w odpowiedzi. Aplikacja powinna sprawdzić, czy state wartości w żądaniu i odpowiedzi są identyczne.

Weryfikowanie tokenu identyfikatora

Po prostu otrzymanie tokenu identyfikatora nie wystarczy do uwierzytelnienia użytkownika. Zweryfikuj podpis tokenu ID i sprawdź twierdzenia w tokenie zgodnie z wymaganiami aplikacji. Usługa Azure AD B2C używa tokenów sieci Web JSON (JWTs) i kryptografii klucza publicznego do podpisywania tokenów i sprawdzania, czy są one prawidłowe.

Uwaga

Większość bibliotek uwierzytelniania typu open source weryfikuje JWTs dla aplikacji. Zalecamy eksplorowanie tych opcji zamiast implementowania własnej logiki walidacji. Aby uzyskać więcej informacji, zobacz Omówienie biblioteki Microsoft Authentication Library (MSAL) i biblioteki uwierzytelniania sieci Web tożsamości firmy Microsoft.

Usługa Azure AD B2C ma punkt końcowy metadanych openID Connect, który umożliwia aplikacji uzyskanie informacji o usłudze Azure AD B2C w czasie wykonywania. Te informacje obejmują punkty końcowe, zawartość tokenu i klucze podpisywania tokenu. Istnieje dokument metadanych JSON dla każdego scenariusza użytkownika w tenantcie B2C. Na przykład dokument metadanych dla przepływu użytkownika b2c_1_sign_in w fabrikamb2c.onmicrosoft.com znajduje się pod adresem:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration

Jedną z właściwości tego dokumentu konfiguracji jest jwks_uri, którego wartość dla tego samego przepływu użytkownika to:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys

Aby określić, który przepływ użytkownika został użyty do podpisania tokenu identyfikatora, masz dwie opcje. Najpierw nazwa przepływu użytkownika jest zawarta w oświadczeniu acr w tokenie ID, zobacz oświadczenie reprezentujące przepływ użytkownika. Inną opcją jest kodowanie przepływu użytkownika w wartości state parametru podczas wystawiania żądania, a następnie dekodowanie go w celu określenia, który przepływ użytkownika został użyty. Każda z metod jest prawidłowa.

Po uzyskaniu dokumentu metadanych z punktu końcowego metadanych openID Connect można użyć kluczy publicznych RSA 256, aby zweryfikować podpis tokenu identyfikatora. W tym punkcie końcowym może znajdować się wiele kluczy, z których każdy jest identyfikowany przez kid roszczenie. Również nagłówek tokena identyfikacyjnego zawiera kid element wskazujący, który z tych kluczy został użyty do podpisania tokena identyfikacyjnego.

Aby sprawdzić tokeny z usługi Azure AD B2C, musisz wygenerować klucz publiczny przy użyciu wykładnika (e) i modulus(n). Aby to zrobić, musisz dowiedzieć się, jak wygenerować klucz publiczny w wybranym języku programowania. Oficjalna dokumentacja dotycząca generowania kluczy publicznych przy użyciu protokołu RSA można znaleźć tutaj: https://tools.ietf.org/html/rfc3447#section-3.1

Po zweryfikowaniu podpisu tokenu identyfikatora istnieją różne oświadczenia, które należy zweryfikować. Przykład:

  • Zweryfikuj nonce roszczenie, aby zapobiec atakom powtarzania tokenu. Jego wartość powinna być określona w żądaniu logowania.
  • Zweryfikuj aud oświadczenie, aby upewnić się, że token ID został wystawiony dla Twojej aplikacji. Jego wartość powinna być identyfikatorem aplikacji.
  • Zweryfikuj iat i exp roszczenia, aby upewnić się, że token identyfikatora nie wygasł.

Istnieje również kilka dodatkowych weryfikacji, które należy wykonać. Walidacje zostały szczegółowo opisane w specyfikacji OpenID Connect Core. W zależności od scenariusza możesz również zweryfikować więcej oświadczeń. Oto niektóre typowe walidacje:

  • Upewnij się, że użytkownik/organizacja zarejestrował się w aplikacji.
  • Upewnij się, że użytkownik ma odpowiednie uprawnienia/autoryzację.
  • Upewnij się, że wystąpiła pewna siła uwierzytelniania, taka jak uwierzytelnianie wieloskładnikowe firmy Microsoft.

Po zweryfikowaniu tokenu identyfikatora możesz rozpocząć sesję z użytkownikiem. Można użyć oświadczeń w identyfikacyjnym tokenie, aby uzyskać informacje o użytkowniku w aplikacji. Informacji tych używa się do wyświetlania, rejestrowania i autoryzacji.

Uzyskiwanie tokenu

Jeśli potrzebujesz aplikacji internetowej do uruchamiania tylko przepływów użytkowników, możesz pominąć kilka następnych sekcji. Te sekcje mają zastosowanie tylko do aplikacji internetowych, które muszą wykonywać uwierzytelnione wywołania do internetowego interfejsu API, który jest chroniony przez samą usługę Azure AD B2C.

Możesz zrealizować kod autoryzacji, który uzyskałeś (przy użyciu response_type=code+id_token), aby uzyskać token do żądanego zasobu, wysyłając żądanie POST do punktu końcowego /token. W usłudze Azure AD B2C możesz żądać tokenów dostępu dla innych interfejsów API w zwykły sposób, określając ich zakresy w żądaniu.

Możesz również zażądać tokenu dostępu dla interfejsu API zaplecza internetowego Twojej aplikacji. W takim przypadku używasz identyfikatora klienta aplikacji jako żądanego obszaru, co skutkuje tokenem dostępu z tym identyfikatorem klienta jako „audytorium”:

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parametr Wymagane Opis
{najemca} Tak Nazwa dzierżawy usługi Azure AD B2C
{polityka} Tak Przepływ użytkownika, który został użyty do uzyskania kodu autoryzacji. Nie można użyć innego przepływu użytkownika w tym żądaniu. Dodaj ten parametr do ciągu zapytania, a nie do treści POST.
identyfikator_klienta Tak Identyfikator aplikacji przypisany przez portal Azure do twojej aplikacji.
tajemnica klienta Tak, w usłudze Web Apps Tajny klucz aplikacji, który został wygenerowany w portalu Azure. Tajne dane klienta są używane w tym przepływie w scenariuszach aplikacji webowych, w których klient może bezpiecznie przechowywać swoje tajne dane. W przypadku scenariuszy aplikacji natywnej (klienta publicznego) hasła klienta nie mogą być bezpiecznie przechowywane, dlatego nie używa się ich w tym przepływie. Jeśli używasz tajnego klucza klienta, zmieniaj go okresowo.
kod Tak Kod autoryzacji uzyskany na początku przepływu użytkownika.
typ_grantu Tak Typ udzielenia, który musi być authorization_code przeznaczony dla przepływu kodu autoryzacji.
adres_przekierowania Nie. redirect_uri Parametr aplikacji, w której otrzymano kod autoryzacji.
zakres Nie. Rozdzielona spacjami lista zakresów. Zakres openid wskazuje uprawnienia do logowania użytkownika i pobierania danych o użytkowniku w postaci parametrów id_token. Może służyć do pobierania tokenów do webowego API backendowego swojej aplikacji, który jest reprezentowany przez ten sam identyfikator aplikacji co klient. Zakres offline_access wskazuje, że aplikacja potrzebuje tokenu odświeżania na potrzeby rozszerzonego dostępu do zasobów.

Pomyślna odpowiedź tokenu wygląda następująco:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "expires_on": "1644254945",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}
Parametr Opis
nie wcześniej niż Czas epoki, w którym token staje się prawidłowy.
typ tokena Wartość typu tokenu. Bearer jest jedynym obsługiwanym typem.
token dostępu Podpisany token JWT, o który proszono.
zakres Prawidłowe zakresy tokenu.
wygasa_za Czas ważności tokenu dostępu (w sekundach).
wygasa_ Czas epoki, kiedy token dostępu staje się nieprawidłowy.
token odświeżania Token odświeżania OAuth 2.0. Aplikacja może użyć tego tokenu, aby uzyskać więcej tokenów po wygaśnięciu bieżącego tokenu. Tokeny odświeżania mogą służyć do zachowania dostępu do zasobów przez dłuższy czas. Zakres offline_access musi zostać użyty zarówno w żądaniach autoryzacji, jak i w żądaniach tokenu, aby otrzymać token odświeżania.

Odpowiedzi na błędy wyglądają następująco:

{
    "error": "invalid_grant",
    "error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}
Parametr Opis
błąd Kod, który może służyć do klasyfikowania typów błędów, które występują.
opis błędu Komunikat, który może pomóc zidentyfikować główną przyczynę błędu uwierzytelniania.

Korzystanie z tokenu

Po pomyślnym uzyskaniu tokenu dostępu możesz użyć tego tokenu w żądaniach do zaplecza webowego API, poprzez dołączenie go do nagłówka Authorization.

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

Odświeżanie tokenu

Tokeny dostępu i tokeny identyfikatorów są krótkotrwałe. Po wygaśnięciu należy je odświeżyć, aby nadal uzyskiwać dostęp do zasobów. Podczas odświeżania tokenu dostępu usługa Azure AD B2C zwraca nowy token. Odświeżony token dostępu będzie miał zaktualizowane wartości roszczeń: nbf (nie wcześniej), iat (wystawiony) i exp (wygaśnięcie). Wszystkie inne wartości oświadczeń są podobne do tych w poprzednim tokenie dostępu.

Odśwież token, przesyłając kolejne żądanie POST do punktu końcowego /token. Tym razem podaj refresh_token parametr zamiast parametru code :

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob
Parametr Wymagane Opis
{najemca} Tak Nazwa dzierżawy usługi Azure AD B2C
{polityka} Tak Przepływ użytkownika, który został użyty do uzyskania oryginalnego tokenu odświeżania. Nie można użyć innego przepływu użytkownika w tym żądaniu. Dodaj ten parametr do ciągu zapytania, a nie do treści POST.
identyfikator_klienta Tak Identyfikator aplikacji przypisany przez portal Azure do twojej aplikacji.
tajemnica klienta Tak, w usłudze Web Apps Tajny klucz aplikacji, który został wygenerowany w portalu Azure. Tajne dane klienta są używane w tym przepływie w scenariuszach aplikacji webowych, w których klient może bezpiecznie przechowywać swoje tajne dane. W przypadku scenariuszy aplikacji natywnej (klient publiczny) tajne dane klienta nie mogą być bezpiecznie przechowywane, dlatego nie są używane w tym wywołaniu. Jeśli używasz tajemnicy klienta, zmień ją okresowo.
typ_grantu Tak Rodzaj grantu, który musi być refresh_token dla tej części przepływu kodu autoryzacji.
token odświeżania Tak Oryginalny token odświeżający uzyskany w drugiej części przepływu. Zakres offline_access musi być używany zarówno w żądaniach autoryzacji, jak i żądaniach dotyczących tokenu, aby otrzymać token odświeżania.
adres_przekierowania Nie. redirect_uri Parametr aplikacji, w której otrzymano kod autoryzacji.
zakres Nie. Rozdzielona spacjami lista zakresów. Zakres openid wskazuje uprawnienie do logowania użytkownika i uzyskiwania danych o użytkowniku w postaci tokenów identyfikatorów. Może służyć do wysyłania tokenów do zaplecza API sieciowego aplikacji, które jest reprezentowane przez ten sam identyfikator aplikacji co aplikacja kliencka. Zakres offline_access wskazuje, że aplikacja potrzebuje tokenu odświeżania na potrzeby rozszerzonego dostępu do zasobów.

Pomyślna odpowiedź tokenu wygląda następująco:

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
    "refresh_token_expires_in": "1209600"
}
Parametr Opis
nie wcześniej niż Czas epoki, w którym token staje się prawidłowy.
typ tokena Wartość typu tokenu. Bearer jest jedynym obsługiwanym typem.
token dostępu Podpisany token JWT, o który poproszono.
zakres Prawidłowe zakresy tokenu.
wygasa_za Czas ważności tokenu dostępu (w sekundach).
token odświeżania Token odświeżania OAuth 2.0. Aplikacja może użyć tego tokenu, aby uzyskać dodatkowe tokeny po wygaśnięciu bieżącego tokenu. Tokeny odświeżania mogą służyć do zachowania dostępu do zasobów przez dłuższy czas.
czas_wygasania_refresh_token Czas ważności tokenu odświeżania (w sekundach).

Odpowiedzi na błędy wyglądają następująco:

{
    "error": "invalid_grant",
    "error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}
Parametr Opis
błąd Kod, który może służyć do klasyfikowania typów błędów, które występują.
opis błędu Komunikat, który może pomóc zidentyfikować główną przyczynę błędu uwierzytelniania.

Wysyłanie żądania wylogowania

Jeśli chcesz wylogować użytkownika z aplikacji, nie wystarczy wyczyścić pliki cookie aplikacji lub zakończyć sesję z użytkownikiem. Przekieruj użytkownika do usługi Azure AD B2C, aby się wylogować. Jeśli tego nie zrobisz, użytkownik może być w stanie ponownie uwierzytelnić aplikację bez konieczności ponownego wprowadzania poświadczeń. Aby uzyskać więcej informacji, zobacz Zachowanie sesji usługi Azure AD B2C.

Aby wylogować użytkownika, przekieruj użytkownika do end_session_endpoint obiektu wymienionego w dokumencie metadanych OpenID Connect opisanym wcześniej:

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F
Parametr Wymagane Opis
{najemca} Tak Nazwa Twojego dzierżawcy Azure AD B2C. Jeśli używasz domeny niestandardowej, zastąp ciąg tenant.b2clogin.com domeną, taką jak fabrikam.com.
{polityka} Tak Przepływ użytkownika, który określasz w żądaniu autoryzacji. Jeśli na przykład użytkownik zalogował się z użyciem b2c_1_sign_in przepływu użytkownika, określ w żądaniu wylogowania b2c_1_sign_in.
id_token_hint (wskazówka identyfikacyjna tokenu) Nie. Wcześniej wystawiony token identyfikacyjny do przekazania do punktu końcowego wylogowania jako wskazówka dotycząca autoryzowanej sesji bieżącej użytkownika końcowego z klientem. Element id_token_hint zapewnia, że adres URL odpowiedzi post_logout_redirect_uri jest zarejestrowany w ustawieniach aplikacji Azure AD B2C. Aby uzyskać więcej informacji, zobacz Zabezpiecz swoje przekierowanie wylogowania.
identyfikator_klienta Nie* Identyfikator aplikacji przypisany przez portal Azure do twojej aplikacji.

* Jest to wymagane w przypadku korzystania z Application izolowanej konfiguracji SSO i Wymagaj tokenu ID w żądaniu wylogowania jest ustawione na No.
adnotacja_przekierowania_po_wylogowaniu_uri Nie. Adres URL, do którego użytkownik powinien zostać przekierowany po pomyślnym wylogowaniu. Jeśli nie zostanie ona dołączona, usługa Azure AD B2C wyświetli użytkownikowi ogólny komunikat. Jeśli nie podasz elementu id_token_hint, nie rejestruj owego adresu URL jako adresu URL odpowiedzi w ustawieniach aplikacji usługi Azure AD B2C.
stan Nie. Jeśli dołączysz state parametr do żądania autoryzacji, serwer autoryzacji zwróci tę samą wartość w odpowiedzi na post_logout_redirect_uri. Aplikacja powinna sprawdzić, czy state wartość żądania i odpowiedzi są identyczne.

Po żądaniu wylogowania usługa Azure AD B2C unieważnia sesję opartą na plikach cookie usługi Azure AD B2C i próbuje wylogować się z federacyjnych dostawców tożsamości. Aby uzyskać więcej informacji, zobacz Logowanie jednokrotne.

Zabezpiecz przekierowanie wylogowania

Po wylogowaniu użytkownik jest przekierowywany do identyfikatora URI określonego w parametrze post_logout_redirect_uri , niezależnie od adresów URL odpowiedzi określonych dla aplikacji. Jeśli jednak przekazano prawidłowy id_token_hint, a opcja Wymagaj tokenu identyfikatora w żądaniach wylogowania jest włączona, usługa Azure AD B2C sprawdza, czy wartość post_logout_redirect_uri pasuje do jednego ze skonfigurowanych URI przekierowań aplikacji przed wykonaniem przekierowania. Jeśli dla aplikacji nie skonfigurowano pasującego adresu URL odpowiedzi, zostanie wyświetlony komunikat o błędzie i użytkownik nie zostanie przekierowany.

Aby ustawić wymagany token identyfikatora w żądaniach wylogowywania, zobacz Konfigurowanie zachowania sesji w usłudze Azure Active Directory B2C.

Powiązana zawartość