Dokumentacja interfejsu API uwierzytelniania natywnego

Dotyczy: Dzierżawcy siły roboczej — dzierżawcy zewnętrzni (dowiedz się więcej)

Natywne uwierzytelnianie firmy Microsoft Entra umożliwia hostowanie interfejsu użytkownika aplikacji w aplikacji klienckiej zamiast delegowania uwierzytelniania do przeglądarek, co powoduje natywnie zintegrowane środowisko uwierzytelniania. Jako deweloper masz pełną kontrolę nad wyglądem i działaniem interfejsu logowania.

W tym artykule dokumentacji interfejsu API opisano szczegóły wymagane tylko w przypadku ręcznego wykonywania nieprzetworzonych żądań HTTP w celu wykonania przepływu. Nie zalecamy jednak tego podejścia. Dlatego, jeśli to możliwe, użyj zestawu SDK uwierzytelniania utworzonego przez firmę Microsoft i obsługiwanego przez firmę Microsoft. Aby uzyskać więcej informacji na temat korzystania z zestawu SDK, zobacz Samouczek: przygotowywanie aplikacji mobilnej systemu Android do uwierzytelniania natywnego i Samouczek: przygotowywanie aplikacji mobilnej dla systemu iOS/macOS na potrzeby uwierzytelniania natywnego.

Po pomyślnym wywołaniu punktów końcowych interfejsu API otrzymasz zarówno token identyfikatora do identyfikacji użytkownika, jak i token dostępu w celu wywołania chronionych interfejsów API. Wszystkie odpowiedzi z interfejsu API są w formacie JSON.

Natywny interfejs API uwierzytelniania firmy Microsoft Entra obsługuje rejestrację i logowanie na potrzeby dwóch metod uwierzytelniania:

• Wiadomość e-mail z hasłem, która obsługuje rejestrację i logowanie przy użyciu poczty e-mail i hasła oraz samoobsługowego resetowania hasła (SSPR).

• Jednorazowy kod dostępu poczty e-mail, który obsługuje rejestrację i logowanie przy użyciu jednorazowego kodu dostępu poczty e-mail.

Warunki wstępne

1. Dzierżawa zewnętrzna firmy Microsoft Entra. Jeśli jeszcze go nie masz, utwórz dzierżawę zewnętrzną.

2. Jeśli jeszcze tego nie zrobiono, zarejestruj aplikację w centrum administracyjnym firmy Microsoft Entra. Upewnij się, że udzielono delegowanych uprawnień i włączysz przepływy uwierzytelniania publicznego i natywnego klienta.

3. Jeśli jeszcze tego nie zrobiono, utwórz przepływ użytkownika w centrum administracyjnym firmy Microsoft Entra. Podczas tworzenia przepływu użytkownika zanotuj atrybuty użytkownika skonfigurowane zgodnie z wymaganiami, ponieważ te atrybuty są tymi, które firma Microsoft Entra oczekuje, że aplikacja zostanie przesłana.

4. Skojarz rejestrację aplikacji z przepływem użytkownika.

5. W przypadku przepływu logowania zarejestruj użytkownika klienta, którego używasz do testowania interfejsów API logowania. Alternatywnie możesz uzyskać tego użytkownika testowego po uruchomieniu przepływu rejestracji.

6. W przypadku przepływu samoobsługowego resetowania hasła włącz samoobsługowe resetowanie haseł dla użytkowników klientów w dzierżawie zewnętrznej. Samoobsługowe resetowanie hasła jest dostępne dla użytkowników klientów korzystających z poczty e-mail z metodą uwierzytelniania haseł.

Token kontynuacji

Za każdym razem, gdy wywołujesz punkt końcowy w dowolnych przepływach, logowaniu, rejestracji lub samoobsługowym resetowaniu hasła, punkt końcowy zawiera token kontynuacji w odpowiedzi. Token kontynuacji jest unikatowym identyfikatorem używanym przez firmę Microsoft Entra ID do zachowania stanu między wywołaniami do różnych punktów końcowych w ramach tego samego przepływu. Ten token należy uwzględnić w kolejnych żądaniach w tym samym przepływie.

Każdy token kontynuacji jest ważny przez określony okres i może być używany tylko dla kolejnych żądań w ramach tego samego przepływu.

Dokumentacja interfejsu API tworzenia konta

Aby ukończyć przepływ rejestracji użytkownika dla jednej z metod uwierzytelniania, aplikacja wchodzi w interakcję z czterema punktami końcowymi, /signup/v1.0/start, , /signup/v1.0/challenge/signup/v1.0/continuei /token.

Punkty końcowe interfejsu API tworzenia konta

Typy wyzwań rejestracji

Interfejs API umożliwia aplikacji klienckiej anonsowanie obsługiwanych przez nią metod uwierzytelniania, gdy wykonuje wywołanie do firmy Microsoft Entra. W tym celu aplikacja używa parametru challenge_type w żądaniu aplikacji. Ten parametr zawiera wstępnie zdefiniowane wartości, które reprezentują różne metody uwierzytelniania.

Dowiedz się więcej o typach wyzwań w typach wyzwań uwierzytelniania natywnego. W tym artykule wyjaśniono wartości typu wyzwania, które należy zastosować w przypadku metody uwierzytelniania.

Szczegóły protokołu przepływu rejestracji

Diagram sekwencji przedstawia przepływ procesu rejestracji.

Ten diagram wskazuje, że aplikacja zbiera nazwę użytkownika (wiadomość e-mail), hasło (w przypadku poczty e-mail z metodami uwierzytelniania haseł) i atrybuty od użytkownika w różnym czasie (i ewentualnie na oddzielnych ekranach). Możesz jednak zaprojektować aplikację, aby zebrać nazwę użytkownika (adres e-mail), hasło i wszystkie wymagane wartości atrybutów oraz opcjonalne wartości atrybutów na tym samym ekranie, a następnie przesłać wszystkie z nich za pośrednictwem punktu końcowego /signup/v1.0/start . W takim przypadku aplikacja nie musi wykonywać wywołań i obsługiwać odpowiedzi dla opcjonalnych kroków.

Krok 1. Żądanie uruchomienia przepływu rejestracji

Przepływ rejestracji rozpoczyna się od aplikacji wysyłającej żądanie POST do /signup/v1.0/start punktu końcowego w celu uruchomienia przepływu rejestracji.

Oto przykłady żądania (przedstawiamy przykładowe żądanie w wielu wierszach w celu zapewnienia czytelności):

Przykład 1:

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/signup/v1.0/start
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&challenge_type=oob password redirect
&username=contoso-consumer@contoso.com 

Przykład 2 (uwzględnij atrybuty użytkownika i hasło w żądaniu):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/signup/v1.0/start
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&challenge_type=oob password redirect
&password={secure_password}
&attributes={"displayName": "{given_name}", "extension_2588abcdwhtfeehjjeeqwertc_age": "{user_age}", "postalCode": "{user_postal_code}"}
&username=contoso-consumer@contoso.com 

Odpowiedź na powodzenie

Oto przykład pomyślnej odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "continuation_token": "AQABAAEAAA…",
} 

Jeśli aplikacja nie może obsługiwać wymaganej metody uwierzytelniania przez firmę Microsoft Entra, wymagany jest powrót do przepływu uwierzytelniania opartego na sieci Web. W tym scenariuszu firma Microsoft Entra informuje aplikację, zwracając typ wyzwania przekierowania w odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json

{     
   "challenge_type": "redirect" 
} 

Ta odpowiedź jest uznawana za pomyślną, ale aplikacja jest wymagana do przełączenia się do przepływu uwierzytelniania internetowego. W takim przypadku zalecamy użycie utworzonej i obsługiwanej przez firmę Microsoft biblioteki uwierzytelniania.

Odpowiedź na błąd

Przykład:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "error": "user_already_exists", 
    "error_description": "AADSTS1003037: It looks like you may already have an account.... .\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: yyyy-...", 
    "error_codes": [ 
        1003037 
    ],
    "timestamp": "yyyy-mm-dd 10:15:00Z",
    "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333", 
    "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
} 

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Jeśli parametr błędu ma wartość invalid_grant, firma Microsoft Entra zawiera suberror parametr w odpowiedzi. Poniżej przedstawiono możliwe wartości parametru suberror dla błędu invalid_grant :

Jeśli parametr błędu ma wartość invalid_client, firma Microsoft Entra zawiera suberror parametr w odpowiedzi. Poniżej przedstawiono możliwe wartości parametru suberror dla błędu invalid_client :

Krok 2. Wybieranie metody uwierzytelniania

Aplikacja żąda od firmy Microsoft Entra wybrania jednego z obsługiwanych typów wyzwań dla użytkownika do uwierzytelnienia. W tym celu aplikacja wykonuje wywołanie punktu końcowego /signup/v1.0/challenge . Aplikacja musi uwzględnić token kontynuacji uzyskany z punktu końcowego /signup/v1.0/start w żądaniu.

Oto przykład żądania (przedstawiamy przykładowe żądanie w wielu wierszach w celu zapewnienia czytelności).

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/signup/v1.0/challenge
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&challenge_type=oob password redirect
&continuation_token=AQABAAEAAA…

Odpowiedź na powodzenie

Firma Microsoft Entra wysyła jednorazowy kod dostępu do wiadomości e-mail użytkownika, a następnie odpowiada za pomocą typu wyzwania o wartości oob i dodatkowych informacji o jednorazowym kodzie dostępu:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "interval": 300,
    "continuation_token": "AQABAAEAAAYn...",
    "challenge_type": "oob",
    "binding_method": "prompt",
    "challenge_channel": "email",
    "challenge_target_label": "c***r@co**o**o.com",
    "code_length": 8
} 

Jeśli aplikacja nie może obsługiwać wymaganej metody uwierzytelniania przez firmę Microsoft Entra, wymagany jest powrót do przepływu uwierzytelniania opartego na sieci Web. W tym scenariuszu firma Microsoft Entra informuje aplikację, zwracając typ wyzwania przekierowania w odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json

{
   "challenge_type": "redirect"
}

Ta odpowiedź jest uznawana za pomyślną, ale aplikacja jest wymagana do przełączenia się do przepływu uwierzytelniania internetowego. W takim przypadku zalecamy użycie utworzonej i obsługiwanej przez firmę Microsoft biblioteki uwierzytelniania.

Odpowiedź na błąd

Przykład:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{ 
    "error": "invalid_request", 
    "error_description": "AADSTS901007: The challenge_type list parameter does not include the 'redirect' type.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: yyyy-...",
    "error_codes": [ 
        901007 
    ], 
    "timestamp": "yyyy-mm-dd 10:15:00Z",
    "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333", 
    "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
} 

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Krok 3. Przesyłanie jednorazowego kodu dostępu

Aplikacja przesyła jednorazowy kod dostępu wysyłany do wiadomości e-mail użytkownika. Ponieważ przesyłamy jednorazowy kod dostępu, oob wymagany jest parametr, a grant_type parametr musi mieć wartość oob.

Oto przykład żądania (przedstawiamy przykładowe żądanie w wielu wierszach na potrzeby czytelności):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/signup/v1.0/continue
Content-Type: application/x-www-form-urlencoded

continuation_token=uY29tL2F1dGhlbnRpY...
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444 
&grant_type=oob 
&oob={otp_code}

Po pomyślnym przesłaniu przez aplikację jednorazowego kodu dostępu przepływ rejestracji zależy od scenariuszy, jak pokazano w tabeli:

Odpowiedź

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "error": "credential_required",
    "error_description": "AADSTS55103: Credential required. Trace ID: d6966055-...-80500 Correlation ID: 3944-...-60d6 Timestamp: yy-mm-dd 02:37:33Z",
    "error_codes": [
        55103
    ],
    "timestamp": "yy-mm-dd 02:37:33Z",
    "trace_id": "d6966055-...-80500",
    "correlation_id": "3944-...-60d6",
    "continuation_token": "AQABEQEAAAA..."
} 

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Jeśli parametr błędu ma wartość invalid_grant, firma Microsoft Entra zawiera suberror parametr w odpowiedzi. Poniżej przedstawiono możliwe wartości parametru suberror dla błędu invalid_grant :

Aby poświadczenia hasła zostały zebrane od użytkownika, aplikacja musi wykonać wywołanie /signup/v1.0/challenge punktu końcowego w celu określenia poświadczeń, które użytkownik musi podać.

Oto przykład żądania (przedstawiamy przykładowe żądanie w wielu wierszach na potrzeby czytelności):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/signup/v1.0/challenge
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&challenge_type=oob password redirect
&continuation_token=AQABAAEAAA…

Odpowiedź na powodzenie

Jeśli hasło jest metodą uwierzytelniania skonfigurowaną dla użytkownika w centrum administracyjnym firmy Microsoft Entra, zostanie zwrócona odpowiedź powodzenia z tokenem kontynuacji do aplikacji.

HTTP/1.1 200 OK
Content-Type: application/json

{
    "challenge_type": "password",
    "continuation_token": " AQABAAEAAAAty..."
}

Jeśli aplikacja nie może obsługiwać wymaganej metody uwierzytelniania przez firmę Microsoft Entra, wymagany jest powrót do przepływu uwierzytelniania opartego na sieci Web. W tym scenariuszu firma Microsoft Entra informuje aplikację, zwracając typ wyzwania przekierowania w odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json

{     
    "challenge_type": "redirect" 
} 

Ta odpowiedź jest uznawana za pomyślną, ale aplikacja jest wymagana do przełączenia się do przepływu uwierzytelniania internetowego. W takim przypadku zalecamy użycie utworzonej i obsługiwanej przez firmę Microsoft biblioteki uwierzytelniania.

Krok 4. Uwierzytelnianie i uzyskiwanie tokenu w celu zarejestrowania się

Aplikacja musi przesłać poświadczenia użytkownika, w tym przypadku hasło, którego firma Microsoft zażądała w poprzednim kroku. Jeśli aplikacja nie zrobiła tego za pośrednictwem punktu końcowego /signup/v1.0/start , musi przesłać poświadczenie hasła. Aplikacja wysyła żądanie do punktu końcowego /signup/v1.0/continue w celu przesłania hasła. Ponieważ przesyłamy hasło, password wymagany jest parametr, a grant_type parametr musi mieć hasło wartości.

Oto przykład żądania (przedstawiamy przykładowe żądanie w wielu wierszach na potrzeby czytelności):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/signup/v1.0/continue
Content-Type: application/x-www-form-urlencoded

continuation_token=uY29tL2F1dGhlbnRpY...
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444 
&grant_type=password 
&password={secure_password}

Odpowiedź na powodzenie

Jeśli żądanie zakończy się pomyślnie, ale żadne atrybuty nie zostały skonfigurowane w centrum administracyjnym firmy Microsoft Entra lub wszystkie wymagane atrybuty zostały przesłane za pośrednictwem punktu końcowego /signup/v1.0/start , aplikacja otrzymuje token kontynuacji bez przesyłania żadnych atrybutów. Aplikacja może użyć tokenu kontynuacji, aby zażądać tokenów zabezpieczających, jak pokazano w kroku 5. W przeciwnym razie odpowiedź firmy Microsoft Entra wskazuje, że aplikacja musi przesłać wymagane atrybuty. Te atrybuty, wbudowane lub niestandardowe, zostały skonfigurowane w centrum administracyjnym firmy Microsoft Entra przez administratora dzierżawy.

Wymagane atrybuty użytkownika

Ta odpowiedź żąda od aplikacji przesłania wartości nazw, *wieku i atrybutów telefonu.

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "error": "attributes_required",
    "error_description": "User attributes required",
    "error_codes": [
            55106
        ],
    "timestamp": "yy-mm-dd 02:37:33Z",
    "trace_id": "d6966055-...-80500",
    "correlation_id": "3944-...-60d6",
    "continuation_token": "AQABAAEAAAAtn...",
    "required_attributes": [
        {
            "name": "displayName",
            "type": "string",
            "required": true,
            "options": {
              "regex": ".*@.**$"
            }
        },
        {
            "name": "extension_2588abcdwhtfeehjjeeqwertc_age",
            "type": "string",
            "required": true
        },
        {
            "name": "postalCode",
            "type": "string",
            "required": true,
            "options": {
              "regex":"^[1-9][0-9]*$"
            }
        }
    ],
}

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Jeśli aplikacja nie może obsługiwać wymaganej metody uwierzytelniania przez firmę Microsoft Entra, wymagany jest powrót do przepływu uwierzytelniania opartego na sieci Web. W tym scenariuszu firma Microsoft Entra informuje aplikację, zwracając typ wyzwania przekierowania w odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json

{     
   "challenge_type": "redirect" 
} 

Ta odpowiedź jest uznawana za pomyślną, ale aplikacja jest wymagana do przełączenia się do przepływu uwierzytelniania internetowego. W takim przypadku zalecamy użycie utworzonej i obsługiwanej przez firmę Microsoft biblioteki uwierzytelniania.

Odpowiedź na błąd

Przykład:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "error": "invalid_grant",
    "error_description": "New password is too weak",
    "error_codes": [
        399246
    ], 
    "timestamp": "yyyy-mm-dd 10:15:00Z",
    "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333", 
    "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd",
    "suberror": "password_too_weak"
}

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Jeśli parametr błędu ma wartość invalid_grant, firma Microsoft Entra zawiera suberror parametr w odpowiedzi. Poniżej przedstawiono możliwe wartości parametru suberror :

Przesyłanie atrybutów użytkownika

Aby kontynuować przepływ, aplikacja musi wykonać wywołanie punktu końcowego /signup/v1.0/continue , aby przesłać wymagane atrybuty użytkownika. Ponieważ przesyłamy atrybuty, attributes wymagany jest parametr, a grant_type parametr musi mieć wartość równą atrybutom.

Oto przykład żądania (przedstawiamy przykładowe żądanie w wielu wierszach na potrzeby czytelności):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/signup/v1.0/continue
Content-Type: application/x-www-form-urlencoded

&client_id=00001111-aaaa-2222-bbbb-3333cccc4444 
&grant_type=attributes 
&attributes={"displayName": "{given_name}", "extension_2588abcdwhtfeehjjeeqwertc_age": "{user_age}", "postaCode": "{postal_code}"}
&continuation_token=AQABAAEAAAAtn...

Odpowiedź na powodzenie

Jeśli żądanie zakończy się pomyślnie, firma Microsoft Entra wystawia token kontynuacji, którego aplikacja może użyć do żądania tokenów zabezpieczających.

HTTP/1.1 200 OK
Content-Type: application/json

{  
    "continuation_token": "AQABAAEAAAYn..."
} 

Jeśli aplikacja nie może obsługiwać wymaganej metody uwierzytelniania przez firmę Microsoft Entra, wymagany jest powrót do przepływu uwierzytelniania opartego na sieci Web. W tym scenariuszu firma Microsoft Entra informuje aplikację, zwracając typ wyzwania przekierowania w odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json

{     
   "challenge_type": "redirect" 
} 

Ta odpowiedź jest uznawana za pomyślną, ale aplikacja jest wymagana do przełączenia się do przepływu uwierzytelniania internetowego. W takim przypadku zalecamy użycie utworzonej i obsługiwanej przez firmę Microsoft biblioteki uwierzytelniania.

Odpowiedź na błąd

Przykład:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{
    "error": "expired_token",
    "error_description": "AADSTS901007: The continuation_token is expired.  .\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: yyyy-...", 
    "error_codes": [
        552003
    ], 
    "timestamp": "yyyy-mm-dd 10:15:00Z",
    "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333", 
    "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd" 
}

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Jeśli parametr błędu ma wartość invalid_grant, firma Microsoft Entra zawiera suberror parametr w odpowiedzi. Poniżej przedstawiono możliwe wartości parametru suberror dla błędu invalid_grant :

Krok 5. Żądanie tokenów zabezpieczających

Aplikacja wysyła żądanie POST do punktu końcowego /token i udostępnia token kontynuacji uzyskany z poprzedniego kroku w celu uzyskania tokenów zabezpieczających.

Oto przykład żądania (przedstawiamy przykładowe żądanie w wielu wierszach w celu zapewnienia czytelności):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded
 
continuation_token=ABAAEAAAAtyo... 
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444 
&username=contoso-consumer@contoso.com
&scope={scopes}
&grant_type=continuation_token 

Pomyślna odpowiedź

Oto przykład pomyślnej odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "token_type": "Bearer",
    "scope": "openid profile",
    "expires_in": 4141,
    "access_token": "eyJ0eXAiOiJKV1Qi...",
    "refresh_token": "AwABAAAA...",
    "id_token": "eyJ0eXAiOiJKV1Q..."
}

Odpowiedź na błąd

Przykład:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{ 
    "error": "invalid_request", 
    "error_description": "AADSTS901007: The client doesn't have consent for the requested scopes.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: yyyy-...",
    "error_codes": [ 
        50126 
    ], 
    "timestamp": "yyyy-mm-dd 10:15:00Z",
    "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333", 
    "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
} 

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Przesyłanie atrybutów użytkownika do punktów końcowych

W centrum administracyjnym firmy Microsoft Entra można skonfigurować atrybuty użytkownika zgodnie z wymaganiami lub opcjonalnie. Ta konfiguracja określa, jak firma Microsoft Entra reaguje podczas wykonywania wywołania do jego punktów końcowych. Opcjonalne atrybuty nie są obowiązkowe do ukończenia przepływu rejestracji. W związku z tym, gdy wszystkie atrybuty są opcjonalne, muszą zostać przesłane przed zweryfikowaniem nazwy użytkownika. W przeciwnym razie rejestracja zostanie ukończona bez opcjonalnych atrybutów.

Poniższa tabela zawiera podsumowanie, kiedy można przesłać atrybuty użytkownika do punktów końcowych firmy Microsoft Entra.

Format wartości atrybutów użytkownika

Należy określić informacje, które chcesz zebrać od użytkownika, konfigurując ustawienia przepływu użytkownika w centrum administracyjnym firmy Microsoft Entra. Skorzystaj z artykułu Zbieranie atrybutów użytkownika niestandardowego podczas rejestracji , aby dowiedzieć się, jak zbierać wartości zarówno dla atrybutów wbudowanych, jak i niestandardowych.

Można również określić typ danych wejściowych użytkownika dla skonfigurowanych atrybutów. W poniższej tabeli przedstawiono podsumowanie obsługiwanych typów danych wejściowych użytkownika oraz sposób przesyłania wartości zebranych przez kontrolki interfejsu użytkownika do firmy Microsoft Entra.

Oto przykładowe żądanie pokazujące sposób przesyłania wartości atrybutów:

POST /{tenant_subdomain}.onmicrosoft.com/signup/v1.0/continue HTTP/1.1
Host: {tenant_subdomain}.ciamlogin.com
Content-Type: application/x-www-form-urlencoded
 
continuation_token=ABAAEAAAAtfyo... 
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444 
&grant_type=attributes 
&attributes={"jobTitle": "Software Engineer", "extension_2588abcdwhtfeehjjeeqwertc_language": "Norwegian", "extension_2588abcdwhtfeehjjeeqwertc_hobbies": "Dancing,Swimming,Traveling"}
&continuation_token=AQABAAEAAAAtn...

Dowiedz się więcej o typach wejściowych atrybutów użytkownika w artykule Niestandardowe typy danych wejściowych atrybutów użytkownika.

Jak odwoływać się do atrybutów użytkownika

Podczas tworzenia przepływu użytkownika rejestracji należy skonfigurować atrybuty użytkownika, które mają być zbierane od użytkownika podczas rejestracji. Nazwy atrybutów użytkownika w centrum administracyjnym firmy Microsoft Entra różnią się od sposobu odwoływania się do nich w natywnym interfejsie API uwierzytelniania.

Na przykład nazwa wyświetlana w centrum administracyjnym firmy Microsoft Entra jest przywoływana jako displayName w interfejsie API.

Skorzystaj z artykułu Atrybuty profilu użytkownika, aby dowiedzieć się, jak odwoływać się zarówno do wbudowanych, jak i niestandardowych atrybutów użytkownika w natywnym interfejsie API uwierzytelniania.

Dokumentacja interfejsu API logowania

Użytkownicy muszą zalogować się przy użyciu metody uwierzytelniania, której używają. Na przykład użytkownicy, którzy zarejestrują się przy użyciu poczty e-mail przy użyciu metody uwierzytelniania haseł, muszą zalogować się do poczty e-mail i hasła.

Aby zażądać tokenów zabezpieczających, aplikacja współdziała z trzema punktami końcowymi, /initiatei /challenge /token.

Punkty końcowe interfejsu API logowania

Typy wyzwań logowania

Interfejs API umożliwia aplikacji anonsowanie obsługiwanych przez nią metod uwierzytelniania, gdy wykonuje wywołanie do firmy Microsoft Entra. W tym celu aplikacja używa parametru challenge_type w żądaniach. Ten parametr zawiera wstępnie zdefiniowane wartości, które reprezentują różne metody uwierzytelniania.

W przypadku danej metody uwierzytelniania wartości typu wyzwania, które aplikacja wysyła do firmy Microsoft podczas przepływu rejestracji, są takie same jak w przypadku logowania aplikacji. Na przykład wiadomość e-mail z metodą uwierzytelniania haseł używa wartości typu zadania oob, hasła i przekierowania dla przepływów rejestracji i logowania.

Dowiedz się więcej o typach wyzwań w artykule dotyczącym typów wyzwań uwierzytelniania natywnego.

Szczegóły protokołu przepływu logowania

Diagram sekwencji przedstawia przepływ procesu logowania.

W poniższych sekcjach podsumujemy przepływ diagramu sekwencji do trzech podstawowych kroków.

Krok 1. Żądanie uruchomienia przepływu logowania

Przepływ uwierzytelniania rozpoczyna się od aplikacji wysyłającej żądanie POST do punktu końcowego /initiate w celu uruchomienia przepływu logowania.

Oto przykład żądania (przedstawiamy przykładowe żądanie w wielu wierszach na potrzeby czytelności):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/oauth2/v2.0/initiate
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&challenge_type=password redirect
&username=contoso-consumer@contoso.com 

Odpowiedź na powodzenie

Oto przykład pomyślnej odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "continuation_token": "uY29tL2F1dGhlbnRpY..."
}

Jeśli aplikacja nie może obsługiwać wymaganej metody uwierzytelniania przez firmę Microsoft Entra, wymagany jest powrót do przepływu uwierzytelniania opartego na sieci Web. W tym scenariuszu firma Microsoft Entra informuje aplikację, zwracając typ wyzwania przekierowania w odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json

{     
   "challenge_type": "redirect" 
} 

Ta odpowiedź jest uznawana za pomyślną, ale aplikacja jest wymagana do przełączenia się do przepływu uwierzytelniania internetowego. W takim przypadku zalecamy użycie utworzonej i obsługiwanej przez firmę Microsoft biblioteki uwierzytelniania.

Odpowiedź na błąd

Przykład:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{ 
    "error": "invalid_request", 
    "error_description": "AADSTS901007: The challenge_type list parameter does not include the 'redirect' type.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: yyyy-...",
    "error_codes": [ 
        901007 
    ], 
    "timestamp": "yyyy-mm-dd 10:15:00Z",
    "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333", 
    "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
} 

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Jeśli parametr błędu ma wartość invalid_client, firma Microsoft Entra zawiera suberror parametr w odpowiedzi. Poniżej przedstawiono możliwe wartości parametru suberror dla błędu invalid_client :

Krok 2. Wybieranie metody uwierzytelniania

Aby kontynuować przepływ, aplikacja używa tokenu kontynuacji uzyskanego z poprzedniego kroku, aby poprosić firmę Microsoft Entra o wybranie jednego z obsługiwanych typów wyzwań dla użytkownika do uwierzytelnienia. Aplikacja wysyła żądanie POST do punktu końcowego /challenge .

Oto przykład żądania (przedstawiamy przykładowe żądanie w wielu wierszach w celu zapewnienia czytelności):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/oauth2/v2.0/challenge
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&challenge_type=password redirect 
&continuation_token=uY29tL2F1dGhlbnRpY... 

Odpowiedź na powodzenie

HTTP/1.1 200 OK
Content-Type: application/json

{
    "continuation_token": "uY29tL2F1dGhlbnRpY...",
    "challenge_type": "oob",
    "binding_method": "prompt ", 
    "challenge_channel": "email",
    "challenge_target_label ": "c***r@co**o**o.com ",
    "code_length": 8
} 

HTTP/1.1 200 OK
Content-Type: application/json

{   
   "continuation_token": "uY29tL2F1dGhlbnRpY",   
   "challenge_type": "password" 
} 

Jeśli aplikacja nie może obsługiwać wymaganej metody uwierzytelniania przez firmę Microsoft Entra, wymagany jest powrót do przepływu uwierzytelniania opartego na sieci Web. W tym scenariuszu firma Microsoft Entra informuje aplikację, zwracając typ wyzwania przekierowania w odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json

{     
   "challenge_type": "redirect" 
} 

Ta odpowiedź jest uznawana za pomyślną, ale aplikacja jest wymagana do przełączenia się do przepływu uwierzytelniania internetowego. W takim przypadku zalecamy użycie utworzonej i obsługiwanej przez firmę Microsoft biblioteki uwierzytelniania.

Odpowiedź na błąd

Przykład:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{ 
    "error": "invalid_request", 
    "error_description": "AADSTS901007: The challenge_type list parameter does not include the 'redirect' type.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: yyyy-...",
    "error_codes": [ 
        901007 
    ], 
    "timestamp": "yyyy-mm-dd 10:15:00Z",
    "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333", 
    "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
} 

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Krok 3. Żądanie tokenów zabezpieczających

Aplikacja wysyła żądanie POST do punktu końcowego /token i udostępnia poświadczenia użytkownika wybrane w poprzednim kroku, w tym przypadku hasło, w celu uzyskania tokenów zabezpieczających.

Oto przykład żądania (przedstawiamy przykładowe żądanie w wielu wierszach na potrzeby czytelności):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/oauth2/v2.0/token
Content-Type: application/x-www-form-urlencoded

continuation_token=uY29tL2F1dGhlbnRpY...
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444 
&grant_type=password 
&password={secure_password}
&scope=openid offline_access 

Pomyślna odpowiedź

Oto przykład pomyślnej odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "token_type": "Bearer",
    "scope": "openid profile",
    "expires_in": 4141,
    "access_token": "eyJ0eXAiOiJKV1Qi...",
    "refresh_token": "AwABAAAA...",
    "id_token": "eyJ0eXAiOiJKV1Q..."
}

Odpowiedź na błąd

Przykład:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{ 
    "error": "invalid_grant", 
    "error_description": "AADSTS901007: Error validating credentials due to invalid username or password.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: yyyy-...",
    "error_codes": [ 
        50126 
    ], 
    "timestamp": "yyyy-mm-dd 10:15:00Z",
    "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333", 
    "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
} 

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Jeśli parametr błędu ma wartość invalid_grant, firma Microsoft Entra zawiera suberror parametr w odpowiedzi. Poniżej przedstawiono możliwe wartości parametru suberror dla błędu invalid_grant :

Samoobsługowe resetowanie hasła (SSPR)

Jeśli używasz poczty e-mail i hasła jako metody uwierzytelniania w aplikacji, użyj interfejsu API samoobsługowego resetowania hasła (SSPR), aby umożliwić użytkownikom klienta resetowanie hasła. Użyj tego interfejsu API w przypadku scenariuszy zapomnianych haseł lub zmiany hasła.

Samoobsługowe punkty końcowe interfejsu API resetowania haseł

Aby użyć tego interfejsu API, aplikacja współdziała z punktem końcowym pokazanym w poniższej tabeli:

Typy wyzwań dotyczących samoobsługowego resetowania hasła

Interfejs API umożliwia aplikacji anonsowanie obsługiwanych przez nią metod uwierzytelniania, gdy wykonuje wywołanie do firmy Microsoft Entra. W tym celu aplikacja używa parametru challenge_type w żądaniach. Ten parametr zawiera wstępnie zdefiniowane wartości, które reprezentują różne metody uwierzytelniania.

W przypadku przepływu samoobsługowego resetowania hasła wartości typu wyzwania to oob i przekierowanie.

Dowiedz się więcej o typach wyzwań w typach wyzwań uwierzytelniania natywnego.

Szczegóły protokołu przepływu samoobsługowego resetowania hasła

Diagram sekwencji przedstawia przepływ procesu resetowania hasła.

Ten diagram wskazuje, że aplikacja zbiera nazwę użytkownika (adres e-mail) i hasło od użytkownika w różnym czasie (i prawdopodobnie na oddzielnych ekranach). Możesz jednak zaprojektować aplikację, aby zebrać nazwę użytkownika (adres e-mail) i nowe hasło na tym samym ekranie. W takim przypadku aplikacja przechowuje hasło, a następnie przesyła je za pośrednictwem punktu końcowego /submit , w którym jest to wymagane.

Krok 1. Żądanie uruchomienia przepływu samoobsługowego resetowania hasła

Przepływ resetowania hasła rozpoczyna się od aplikacji wysyłającej żądanie POST do /start punktu końcowego w celu uruchomienia przepływu samoobsługowego resetowania hasła.

Oto przykład żądania (przedstawiamy przykładowe żądanie w wielu wierszach w celu zapewnienia czytelności):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/resetpassword/v1.0/start
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444 
&challenge_type=oob redirect 
&username=contoso-consumer@contoso.com 

Odpowiedź na powodzenie

Przykład:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "continuation_token": "uY29tL2F1dGhlbnRpY..."
}

Jeśli aplikacja nie może obsługiwać wymaganej metody uwierzytelniania przez firmę Microsoft Entra, wymagany jest powrót do przepływu uwierzytelniania opartego na sieci Web. W tym scenariuszu firma Microsoft Entra informuje aplikację, zwracając typ wyzwania przekierowania w odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json

{     
   "challenge_type": "redirect" 
} 

Ta odpowiedź jest uznawana za pomyślną, ale aplikacja jest wymagana do przełączenia się do przepływu uwierzytelniania internetowego. W takim przypadku zalecamy użycie utworzonej i obsługiwanej przez firmę Microsoft biblioteki uwierzytelniania.

Odpowiedź na błąd

Przykład:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{ 
    "error": "invalid_request", 
    "error_description": "AADSTS901007: The challenge_type list parameter does not include the 'redirect' type.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: yyyy-...",
    "error_codes": [ 
        901007 
    ], 
    "timestamp": "yyyy-mm-dd 10:15:00Z",
    "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333", 
    "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
} 

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Jeśli parametr błędu ma wartość invalid_client, firma Microsoft Entra zawiera suberror parametr w odpowiedzi. Poniżej przedstawiono możliwe wartości parametru suberror dla błędu invalid_client :

Krok 2. Wybieranie metody uwierzytelniania

Aby kontynuować przepływ, aplikacja używa tokenu kontynuacji uzyskanego z poprzedniego kroku, aby poprosić firmę Microsoft Entra o wybranie jednego z obsługiwanych typów wyzwań dla użytkownika do uwierzytelnienia. Aplikacja wysyła żądanie POST do punktu końcowego /challenge . Jeśli to żądanie zakończy się pomyślnie, firma Microsoft Entra wyśle jednorazowy kod dostępu do adresu e-mail konta użytkownika. Obecnie obsługujemy tylko protokół OTP poczty e-mail.

Oto przykład (przedstawiamy przykładowe żądanie w wielu wierszach w celu zapewnienia czytelności):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/resetpassword/v1.0/challenge
Content-Type: application/x-www-form-urlencoded

client_id=client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&challenge_type=oob redirect
&continuation_token=uY29tL2F1dGhlbnRpY... 

Odpowiedź na powodzenie

Przykład:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "continuation_token": "uY29tL2F1dGhlbnRpY...",
    "challenge_type": "oob",
    "binding_method": "prompt ", 
    "challenge_channel": "email",
    "challenge_target_label ": "c***r@co**o**o.com ",
    "code_length": 8
} 

Jeśli aplikacja nie może obsługiwać wymaganej metody uwierzytelniania przez firmę Microsoft Entra, wymagany jest powrót do przepływu uwierzytelniania opartego na sieci Web. W tym scenariuszu firma Microsoft Entra informuje aplikację, zwracając typ wyzwania przekierowania w odpowiedzi:

HTTP/1.1 200 OK
Content-Type: application/json

{     
   "challenge_type": "redirect" 
} 

Ta odpowiedź jest uznawana za pomyślną, ale aplikacja jest wymagana do przełączenia się do przepływu uwierzytelniania internetowego. W takim przypadku zalecamy użycie utworzonej i obsługiwanej przez firmę Microsoft biblioteki uwierzytelniania.

Odpowiedź na błąd

Przykład:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{ 
    "error": "invalid_request", 
    "error_description": "AADSTS901007: The challenge_type list parameter does not include the 'redirect' type.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: yyyy-...",
    "error_codes": [ 
        901007 
    ], 
    "timestamp": "yyyy-mm-dd 10:15:00Z",
    "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333", 
    "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
} 

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Krok 3. Przesyłanie jednorazowego kodu dostępu

Następnie aplikacja wysyła żądanie POST do punktu końcowego /continue . W żądaniu aplikacja musi uwzględnić poświadczenia użytkownika wybrane w poprzednim kroku i token kontynuacji wystawiony z punktu końcowego /challenge .

Oto przykład żądania (przedstawiamy przykładowe żądanie w wielu wierszach w celu zapewnienia czytelności):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/resetpassword/v1.0/continue
Content-Type: application/x-www-form-urlencoded

continuation_token=uY29tL2F1dGhlbnRpY... 
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444 
&grant_type=oob 
&oob={otp_code}

Odpowiedź na powodzenie

Przykład:

HTTP/1.1 200 OK
Content-Type: application/json

{ 
    "expires_in": 600,
    "continuation_token": "czZCaGRSa3F0MzpnW...",
} 

Odpowiedź na błąd

Przykład:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{ 
    "error": "invalid_request", 
    "error_description": "AADSTS55200: The continuation_token is invalid.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: yyyy-...",
    "error_codes": [ 
        55200 
    ], 
    "timestamp": "yyyy-mm-dd 10:15:00Z",
    "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333", 
    "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
} 

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Jeśli parametr błędu ma wartość invalid_grant, firma Microsoft Entra zawiera suberror parametr w odpowiedzi. Poniżej przedstawiono możliwe wartości parametru suberror dla błędu invalid_grant :

Krok 4. Przesyłanie nowego hasła

Aplikacja zbiera nowe hasło od użytkownika, a następnie używa tokenu kontynuacji wystawionego przez /continue punkt końcowy do przesłania hasła przez wysłanie żądania POST do punktu końcowego /submit .

Oto przykład (przedstawiamy przykładowe żądanie w wielu wierszach w celu zapewnienia czytelności):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/resetpassword/v1.0/submit
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&continuation_token=czZCaGRSa3F0Mzp...
&new_password={new_password}

Odpowiedź na powodzenie

Przykład:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "continuation_token": "uY29tL2F1dGhlbnRpY...",
    "poll_interval": 2
}

Odpowiedź na błąd

Przykład:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{ 
    "error": "invalid_request", 
    "error_description": "AADSTS901007: The challenge_type list parameter does not include the 'redirect' type.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: yyyy-...",
    "error_codes": [ 
        901007 
    ], 
    "timestamp": "yyyy-mm-dd 10:15:00Z",
    "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333", 
    "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
} 

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Jeśli parametr błędu ma wartość invalid_grant, firma Microsoft Entra zawiera suberror parametr w odpowiedzi. Poniżej przedstawiono możliwe wartości parametru suberror :

Krok 5. Sondowanie stanu resetowania hasła

Na koniec, ponieważ aktualizacja konfiguracji użytkownika przy użyciu nowego hasła powoduje pewne opóźnienie, aplikacja może użyć /poll_completion punktu końcowego do sondowania stanu resetowania hasła przez firmę Microsoft Entra. Minimalny czas w sekundach oczekiwania aplikacji między żądaniami sondowania jest zwracany z punktu końcowego /submit w parametrze poll_interval .

Oto przykład (przedstawiamy przykładowe żądanie w wielu wierszach w celu zapewnienia czytelności):

POST https://{tenant_subdomain}.ciamlogin.com/{tenant_subdomain}.onmicrosoft.com/resetpassword/v1.0/poll_completion
Content-Type: application/x-www-form-urlencoded

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&continuation_token=czZCaGRSa3F0... 

Odpowiedź na powodzenie

Przykład:

HTTP/1.1 200 OK
Content-Type: application/json

{
    "status": "succeeded",
    "continuation_token":"czZCaGRSa3F0..."
} 

Poniżej przedstawiono możliwe stany zwracane przez firmę Microsoft Entra (możliwe wartości parametru status ):

Odpowiedź na błąd

Przykład:

HTTP/1.1 400 Bad Request
Content-Type: application/json

{ 
    "error": "expired_token", 
    "error_description": "AADSTS901007: The continuation_token is expired.\r\nTrace ID: 0000aaaa-11bb-cccc-dd22-eeeeee333333\r\nCorrelation ID: aaaa0000-bb11-2222-33cc-444444dddddd\r\nTimestamp: yyyy-...",
    "error_codes": [ 
        552003 
    ], 
    "timestamp": "yyyy-mm-dd 10:15:00Z",
    "trace_id": "0000aaaa-11bb-cccc-dd22-eeeeee333333", 
    "correlation_id": "aaaa0000-bb11-2222-33cc-444444dddddd"
} 

Poniżej przedstawiono możliwe błędy, które można napotkać (możliwe wartości parametru error ):

Powiązana zawartość

• Skonfiguruj niestandardowego dostawcę oświadczeń.