Logowanie internetowe przy użyciu Połączenie OpenID w usłudze Azure Active Directory B2C

OpenID Połączenie 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 interfejsu OpenID usługi Azure Active Directory B2C (Azure AD B2C) Połączenie, 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 tokeny JWT 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 Połączenie 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 Połączenie 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 Połączenie OpenID, 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 Połączenie, aby wykonać więcej niż proste uwierzytelnianie i autoryzację. Wprowadza on parametr przepływu użytkownika, który umożliwia używanie Połączenie OpenID w celu dodawania środowisk użytkownika do aplikacji, 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 przepływu 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. Wymiana:

• {tenant} z nazwą dzierżawy.
• 90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 przy użyciu identyfikatora aplikacji zarejestrowanej w dzierżawie.
• {application-id-uri}/{scope-name} za pomocą identyfikatora URI identyfikatora aplikacji i zakresu aplikacji zarejestrowanej w 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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&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	Wymagania	opis
{tenant}	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.
{policy}	Tak	Przepływ użytkownika lub zasady uruchamiane przez aplikację. Określ nazwę przepływu użytkownika utworzonego w dzierżawie usługi Azure AD B2C. Na przykład: b2c_1_sign_in, b2c_1_sign_uplub b2c_1_edit_profile.
client_id	Tak	Identyfikator aplikacji przypisany do aplikacji w witrynie Azure Portal .
nonce	Tak	Wartość uwzględniona w żądaniu (wygenerowanym przez aplikację), która jest uwzględniona w wynikowym tokenie identyfikatora 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.
response_type	Tak	Musi zawierać token identyfikatora dla Połączenie OpenID. 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.
Wierszu	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.
redirect_uri	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.
response_mode	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 zwracanym przez serwer autoryzacji w odpowiedzi tokenu. 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 witrynie Azure Portal, możesz użyć parametru state , aby odróżnić odpowiedzi w aplikacji od usługi Azure AD B2C z powodu różnych żądań.
login_hint	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.
domain_hint	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 Przekierowywanie 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 zostanie zwrócona odpowiedź do aplikacji przy wskazanym redirect_uri parametrze przy użyciu 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
id_token	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.
code	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
error	Kod, który może służyć do klasyfikowania typów błędów, które występują.
error_description	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 identyfikatora i sprawdź oświadczenia 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 tokeny JWT 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 Połączenie, 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 przepływu użytkownika w dzierżawie usługi B2C. Na przykład dokument metadanych dla b2c_1_sign_in przepływu użytkownika w fabrikamb2c.onmicrosoft.com programie 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 uwzględniona w oświadczeniu acr w tokenie identyfikatora, 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 Połączenie 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żda jest identyfikowana przez kid oświadczenie. Nagłówek tokenu identyfikatora zawiera kid również oświadczenie wskazujące, które z tych kluczy zostało użyte do podpisania tokenu identyfikatora.

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 oświadczenie, nonce aby zapobiec atakom powtarzania tokenu. Jego wartość powinna być określona w żądaniu logowania.
• Zweryfikuj aud oświadczenie, aby upewnić się, że token identyfikatora został wystawiony dla aplikacji. Jego wartość powinna być identyfikatorem aplikacji.
• Zweryfikuj iat oświadczenia i exp , 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 Połączenie 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żesz użyć oświadczeń w tokenie identyfikatora, aby uzyskać informacje o użytkowniku w aplikacji. Do tych informacji należą wyświetlanie, rekordy i autoryzacja.

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ć uzyskany kod autoryzacji (przy użyciu polecenia response_type=code+id_token) dla tokenu do żądanego zasobu, wysyłając POST żądanie 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 własnego internetowego interfejsu API zaplecza aplikacji. W takim przypadku użyjesz identyfikatora klienta aplikacji jako żądanego zakresu, co skutkuje tokenem dostępu z tym identyfikatorem klienta jako "odbiorcą":

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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Parametr	Wymagania	opis
{tenant}	Tak	Nazwa dzierżawy usługi Azure AD B2C
{policy}	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.
client_id	Tak	Identyfikator aplikacji przypisany do aplikacji w witrynie Azure Portal .
client_secret	Tak, w usłudze Web Apps	Wpis tajny aplikacji wygenerowany w witrynie Azure Portal. Wpisy tajne klienta są używane w tym przepływie w scenariuszach aplikacji internetowej, w których klient może bezpiecznie przechowywać klucz tajny klienta. W przypadku scenariuszy aplikacji natywnej (klienta publicznego) wpisy tajne klienta nie mogą być bezpiecznie przechowywane, dlatego nie są używane w tym przepływie. Jeśli używasz wpisu tajnego klienta, zmień go okresowo.
code	Tak	Kod autoryzacji uzyskany na początku przepływu użytkownika.
grant_type	Tak	Typ udzielenia, który musi być authorization_code przeznaczony dla przepływu kodu autoryzacji.
redirect_uri	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 własnego internetowego interfejsu API zaplecza 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": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "expires_on": "1644254945",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

Parametr	Opis
not_before	Czas, w którym token staje się prawidłowy.
token_type	Wartość typu tokenu. Bearer jest jedynym obsługiwanym typem.
access_token	Podpisany token JWT, którego zażądano.
zakres	Prawidłowe zakresy tokenu.
expires_in	Czas ważności tokenu dostępu (w sekundach).
expires_on	Czas epoki, kiedy token dostępu staje się nieprawidłowy.
refresh_token	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 być używany zarówno w żądaniach autoryzacji, jak i tokenu w celu odebrania tokenu 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
error	Kod, który może służyć do klasyfikowania typów błędów, które występują.
error_description	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ć tokenu w żądaniach do interfejsów API sieci Web zaplecza, dołączając 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 zostanie zaktualizowany nbf (nie wcześniej), iat (wystawiony pod adresem) i exp (wygaśnięcie) wartości oświadczeń. Wszystkie inne wartości oświadczeń są podobne do tych w poprzednim tokenie dostępu.

Odśwież token, przesyłając kolejne POST żądanie 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=90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Parametr	Wymagania	opis
{tenant}	Tak	Nazwa dzierżawy usługi Azure AD B2C
{policy}	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.
client_id	Tak	Identyfikator aplikacji przypisany do aplikacji w witrynie Azure Portal .
client_secret	Tak, w usłudze Web Apps	Wpis tajny aplikacji wygenerowany w witrynie Azure Portal. Wpisy tajne klienta są używane w tym przepływie w scenariuszach aplikacji internetowej, w których klient może bezpiecznie przechowywać klucz tajny klienta. W przypadku scenariuszy aplikacji natywnej (klienta publicznego) wpisy tajne klienta nie mogą być bezpiecznie przechowywane, dlatego nie są używane w tym wywołaniu. Jeśli używasz wpisu tajnego klienta, zmień go okresowo.
grant_type	Tak	Typ udzielenia, który musi być refresh_token dla tej części przepływu kodu autoryzacji.
refresh_token	Tak	Oryginalny token odświeżania uzyskany w drugiej części przepływu. Zakres offline_access musi być używany zarówno w żądaniach autoryzacji, jak i tokenu w celu odebrania tokenu odświeżania.
redirect_uri	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 własnego internetowego interfejsu API zaplecza 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": "90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
    "refresh_token_expires_in": "1209600"
}

Parametr	Opis
not_before	Czas, w którym token staje się prawidłowy.
token_type	Wartość typu tokenu. Bearer jest jedynym obsługiwanym typem.
access_token	Podpisany token JWT, którego zażądano.
zakres	Prawidłowe zakresy tokenu.
expires_in	Czas ważności tokenu dostępu (w sekundach).
refresh_token	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.
refresh_token_expires_in	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
error	Kod, który może służyć do klasyfikowania typów błędów, które występują.
error_description	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 Połączenie 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	Wymagania	opis
{tenant}	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.
{policy}	Tak	Przepływ użytkownika określony w żądaniu autoryzacji. Jeśli na przykład użytkownik zalogował się przy użyciu b2c_1_sign_in przepływu użytkownika, określ b2c_1_sign_in żądanie wylogowania.
id_token_hint	Nie.	Wcześniej wystawiony token identyfikatora do przekazania do punktu końcowego wylogowania jako wskazówka dotycząca bieżącej sesji uwierzytelnionej użytkownika końcowego z klientem. Dzięki id_token_hint temu adres post_logout_redirect_uri URL odpowiedzi jest zarejestrowany w ustawieniach aplikacji usługi Azure AD B2C. Aby uzyskać więcej informacji, zobacz Zabezpieczanie przekierowania wylogowywanie.
client_id	Nr*	Identyfikator aplikacji przypisany do aplikacji w witrynie Azure Portal . *Jest to wymagane w przypadku korzystania z Application konfiguracji logowania jednokrotnego izolacji i wymagaj tokenu identyfikatora w żądaniu wylogowywanie jest ustawiona na Nowartość .
post_logout_redirect_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 id_token_hintelementu , nie należy rejestrować tego 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.

Zabezpieczanie przekierowania wylogowywanie

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 token, a żądań wylogowania wymagaj tokenu identyfikatora jest włączony, usługa Azure AD B2C sprawdza, czy wartość post_logout_redirect_uri jest zgodna z jednym ze skonfigurowanych identyfikatorów URI przekierowania 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 wylogowywanie, zobacz Konfigurowanie zachowania sesji w usłudze Azure Active Directory B2C.

Następne kroki

• Dowiedz się więcej o sesji usługi Azure AD B2C.