Compartir a través de

Inicio de sesión web con OpenID Connect en Azure Active Directory B2C

Importante

A partir del 1 de mayo de 2025, Azure AD B2C ya no estará disponible para la compra por parte de nuevos clientes. Obtenga más información en nuestras preguntas más frecuentes.

OpenID Connect es un protocolo de autenticación basado en OAuth 2.0, que se puede usar para iniciar sesión de forma segura a los usuarios en aplicaciones web. Mediante la implementación de Azure Active Directory B2C (Azure AD B2C) de OpenID Connect, puede subcontratar el registro, el inicio de sesión y otras experiencias de administración de identidades en las aplicaciones web a Microsoft Entra ID. En esta guía se muestra cómo hacerlo de forma independiente del lenguaje. Describe cómo enviar y recibir mensajes HTTP sin usar ninguna de nuestras bibliotecas de código abierto.

Nota:

La mayoría de las bibliotecas de autenticación de código abierto adquieren y validan los JWT de la aplicación. Se recomienda explorar esas opciones, en lugar de implementar su propio código. Para obtener más información, vea Información general de la biblioteca de autenticación de Microsoft (MSAL) y la biblioteca de autenticación web de identidad de Microsoft.

OpenID Connect amplía el protocolo de autorización de OAuth 2.0 para su uso como protocolo de autenticación . Este protocolo de autenticación le permite realizar el inicio de sesión único. Presenta el concepto de un token de identificador, que permite al cliente comprobar la identidad del usuario y obtener información básica del perfil sobre el usuario.

OpenID Connect también permite a las aplicaciones adquirir de forma segura tokens de acceso. Puede usar tokens de acceso para acceder a los recursos que protege el servidor de autorización . Recomendamos OpenID Connect si estás desarrollando una aplicación web que hospedas en un servidor y a la que accedes a través de un navegador. Para más información sobre los tokens, consulte Introducción a los tokens en Azure Active Directory B2C.

Azure AD B2C amplía el protocolo OpenID Connect estándar para realizar más que la autenticación y autorización simples. Presenta el parámetro de flujo de usuario, que permite usar OpenID Connect para agregar experiencias de usuario a la aplicación, como registro, inicio de sesión y administración de perfiles.

Envío de solicitudes de autenticación

Cuando la aplicación web necesita autenticar al usuario y ejecutar un flujo de usuario, puede dirigir al usuario al /authorize punto de conexión. El usuario realiza una acción en función del flujo de usuario.

En esta solicitud, el cliente indica los permisos que necesita adquirir del usuario en el scope parámetro y especifica el flujo de usuario que se va a ejecutar. Para obtener una sensación de cómo funciona la solicitud, pegue la solicitud en el explorador y ejecútelo. Reemplazar:

  • {tenant} por el nombre del inquilino.
  • 00001111-aaaa-2222-bbbb-3333cccc4444 por el id. de una aplicación que registró en el inquilino.
  • {application-id-uri}/{scope-name} por el URI del identificador de aplicación y el ámbito de una aplicación que registró en el inquilino.
  • {policy} por el nombre de directiva que tiene en el inquilino, por ejemplo 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
Parámetro Obligatorio Descripción
{inquilino} Sí Nombre del inquilino de Azure AD B2C. Si usa un dominio personalizado, reemplace tenant.b2clogin.com por el dominio, por ejemplo, fabrikam.com.
{política} Sí Flujo de usuario o directiva que ejecuta la aplicación. Especifique el nombre de un flujo de usuario que crear en el tenant de Azure AD B2C. Por ejemplo: b2c_1_sign_in, b2c_1_sign_up, o b2c_1_edit_profile.
ID de cliente Sí Identificador de aplicación asignado a la aplicación en Azure Portal .
valor de seguridad Recomendado Valor incluido en la solicitud (generada por la aplicación) que se incluye en el token de ID resultante como una declaración. A continuación, la aplicación puede comprobar este valor para mitigar los ataques de reproducción de tokens. El valor suele ser una cadena única aleatoria que se puede usar para identificar el origen de la solicitud.
tipo_de_respuesta Sí Debe incluir un token de identificador para OpenID Connect. Si la aplicación web también necesita tokens para llamar a una API web, puede usar code+id_token.
alcance Sí Lista de ámbitos separados por espacios. El ámbito openid indica un permiso para iniciar sesión con el usuario y obtener los datos del usuario en forma de tokens de identificador. El ámbito offline_access es opcional para las aplicaciones web. Indica que la aplicación necesita un token de actualización para el acceso extendido a los recursos. El https://{tenant-name}/{app-id-uri}/{scope} indica un permiso para los recursos protegidos, como una API web. Para obtener más información, consulte Solicitud de un token de acceso.
inmediato No Tipo de interacción del usuario que necesita. El único valor válido en este momento es login, que obliga al usuario a escribir sus credenciales en esa solicitud.
URI de redirección Sí Parámetro redirect_uri de la aplicación, donde el servidor envía respuestas de autenticación a la aplicación. Debe coincidir exactamente con uno de los redirect_uri parámetros que registró en Azure Portal, salvo que debe estar codificado con dirección URL.
modo_de_respuesta No Método que se usa para devolver el código de autorización resultante a la aplicación. Puede ser query, form_posto fragment. Se recomienda usar el modo de respuesta form_post para conseguir la mejor seguridad.
estado No Valor que puede incluir en la solicitud que devuelve el servidor de autorización en la respuesta del token. Puede ser una cadena de cualquier contenido que desee. Normalmente se usa un valor único generado aleatoriamente para evitar ataques de falsificación de solicitudes entre sitios. El estado también se usa para codificar información sobre el estado del usuario en la aplicación antes de que se produjera la solicitud de autenticación, como la página en la que estaban. Si no desea registrar varias direcciones URL de redireccionamiento en Azure Portal, puede usar el state parámetro para diferenciar las respuestas de la aplicación del servicio Azure AD B2C debido a solicitudes diferentes.
sugerencia_de_inicio_de_sesión No Se puede usar para rellenar previamente el campo de nombre de usuario en la página de inicio de sesión. Para obtener más información, consulte Rellenar previamente el nombre de inicio de sesión.
indicador_de_dominio No Proporciona una sugerencia a Azure AD B2C sobre el proveedor de identidades sociales que se debe usar para el inicio de sesión. Si se incluye un valor válido, el usuario va directamente a la página de inicio de sesión del proveedor de identidades. Para obtener más información, consulte Redireccionamiento del inicio de sesión a un proveedor de redes sociales.
Parámetros personalizados No Parámetros personalizados que se pueden usar con directivas personalizadas. Por ejemplo, el URI de contenido de página personalizada dinámica o los solucionadores de notificaciones de clave-valor.

En este momento, se le pide al usuario que complete el flujo de trabajo. Es posible que el usuario tenga que escribir su nombre de usuario y contraseña, iniciar sesión con una identidad social o registrarse en el directorio. Puede haber cualquier otro número de pasos en función de cómo se define el flujo de usuario.

Una vez que el usuario complete el flujo de usuario, se devuelve una respuesta a la aplicación en el parámetro indicado redirect_uri mediante el método especificado en el response_mode parámetro . La respuesta es la misma para cada uno de los casos anteriores, independientemente del flujo de usuario.

Una respuesta correcta con response_mode=fragment tendría el siguiente aspecto:

GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response
Parámetro Descripción
token de identificación Token de identificador que solicitó la aplicación. Puede usar el token de identificador para comprobar la identidad del usuario y comenzar una sesión con el usuario.
código El código de autorización que solicitó la aplicación, si usó response_type=code+id_token. La aplicación puede usar el código de autorización para solicitar un token de acceso para un recurso de destino. Los códigos de autorización suelen expirar después de unos 10 minutos.
estado Si un parámetro state está incluido en la solicitud, debería aparecer el mismo valor en la respuesta. La aplicación debe comprobar que los state valores de la solicitud y la respuesta son idénticos.

Las respuestas de error también se pueden enviar al redirect_uri parámetro para que la aplicación pueda controlarlas correctamente:

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
Parámetro Descripción
error Código que se puede usar para clasificar los tipos de errores que se producen.
descripción_del_error Mensaje de error específico que puede ayudar a identificar la causa principal de un error de autenticación.
estado Si un parámetro state está incluido en la solicitud, debería aparecer el mismo valor en la respuesta. La aplicación debe comprobar que los state valores de la solicitud y la respuesta son idénticos.

Validar el token de identificador

La recepción de un token de identificador no es suficiente para autenticar al usuario. Debe validar la firma del token de identificador y comprobar las notificaciones en el token en función de los requisitos de la aplicación. Azure AD B2C usa tokens web JSON (JWT) y criptografía de clave pública para firmar tokens y comprobar que son válidos.

Nota:

La mayoría de las bibliotecas de autenticación de código abierto validan los JWT de la aplicación. Se recomienda explorar esas opciones, en lugar de implementar su propia lógica de validación. Para obtener más información, vea Información general de la biblioteca de autenticación de Microsoft (MSAL) y la biblioteca de autenticación web de identidad de Microsoft.

Azure AD B2C tiene un punto de conexión de metadatos de OpenID Connect, que permite a una aplicación obtener información sobre Azure AD B2C en tiempo de ejecución. Esta información incluye puntos de conexión, contenido de tokens y claves de firma de tokens. Hay un documento de metadatos JSON para cada flujo de usuario en la entidad B2C. Por ejemplo, el documento de metadatos del flujo de usuario b2c_1_sign_in en fabrikamb2c.onmicrosoft.com se encuentra en:

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

Una de las propiedades de este documento de configuración es jwks_uri, cuyo valor para el mismo flujo de usuario sería:

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

Para determinar qué flujo de usuario se usó para firmar un token de identificador, tiene dos opciones. En primer lugar, el nombre del flujo de usuario se incluye en la notificación acr en el token de identificador; consulte Notificación que representa el flujo de usuario. La otra opción consiste en codificar el flujo de usuario en el valor del state parámetro al emitir la solicitud y, a continuación, descodificarlo para determinar qué flujo de usuario se usó. Cualquiera de los métodos es válido.

Después de adquirir el documento de metadatos del punto de conexión de metadatos de OpenID Connect, puede usar las claves públicas RSA 256 para validar la firma del token de identificador. Podría haber varias claves enumeradas en este punto de conexión, cada una identificada con una kid. El encabezado del token de identificador también contiene una kid reclamación, que indica cuál de estas claves se usó para firmar el token de identificador.

Para comprobar los tokens de Azure AD B2C, debe generar la clave pública mediante exponent(e) y modulus(n). Para ello, debe aprender a generar la clave pública en un lenguaje de programación de su elección. La documentación oficial sobre la generación de claves públicas con el protocolo RSA se puede encontrar aquí: https://tools.ietf.org/html/rfc3447#section-3.1

Después de validar la firma del token de ID, hay varias afirmaciones que debe comprobar. Por ejemplo:

  • Valide la notificación nonce para evitar ataques de reproducción del token. El valor debe ser el que usted especificó en la solicitud de inicio de sesión.
  • Valide la aud afirmación para asegurarse de que el token de ID se emitió para su aplicación. Su valor debe ser el identificador de aplicación de la aplicación.
  • Valide las notificaciones iat y exp para asegurarse de que el token de identificador no ha expirado.

También hay varias validaciones más que debe realizar. Las validaciones se describen en detalle en la especificación de OpenID Connect Core. Es posible que también quiera validar más afirmaciones, en función de su escenario. Algunas validaciones comunes incluyen:

  • Asegúrese de que el usuario o la organización se han registrado en la aplicación.
  • Asegúrese de que el usuario tiene los privilegios o autorización adecuados.
  • Asegúrese de que se ha producido una cierta seguridad de la autenticación, como la autenticación multifactor de Microsoft Entra.

Una vez validado el token de identificador, puede iniciar una sesión con el usuario. Puede usar las reclamaciones en el token de identificación para obtener información sobre el usuario en su aplicación. Entre los usos de esta información se incluyen la visualización, los registros y la autorización.

Obtención de un token

Si necesita que la aplicación web solo ejecute flujos de usuario, puede omitir las secciones siguientes. Estas secciones solo se aplican a las aplicaciones web que necesitan realizar llamadas autenticadas a una API web, que está protegida por el propio Azure AD B2C.

Puede canjear el código de autorización que adquirió (mediante response_type=code+id_token) por un token para el recurso deseado; para ello, debe enviar una solicitud POST al punto de conexión /token. En Azure AD B2C, puede solicitar tokens de acceso para otras API como de costumbre especificando sus ámbitos en la solicitud.

También puede solicitar un token de acceso para la propia API web de back-end de la aplicación. En este caso, se usa el identificador de cliente de la aplicación como ámbito solicitado, lo que da como resultado un token de acceso con ese identificador de cliente como "audiencia":

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
Parámetro Obligatorio Descripción
{inquilino} Sí Nombre del inquilino de Azure AD B2C
{política} Sí Flujo de usuario que se usó para adquirir el código de autorización. No puede usar un flujo de usuario diferente en esta solicitud. Agregue este parámetro a la cadena de consulta, no al cuerpo POST.
ID de cliente Sí Identificador de aplicación asignado a la aplicación en Azure Portal .
secreto_del_cliente Sí, en Web Apps Secreto de aplicación que se generó en Azure Portal. Los secretos de cliente se usan en este flujo para escenarios de aplicación web, donde el cliente puede almacenar de forma segura un secreto de cliente. En escenarios de aplicación nativa (cliente público), los secretos de cliente no se pueden almacenar de forma segura, por lo que no se usan en este flujo. Si usa un secreto de cliente, cámbielo periódicamente.
código Sí El código de autorización que adquirió al principio del flujo de usuario.
tipo_de_subvención Sí El tipo de concesión, que debe ser authorization_code para el flujo de código de autorización.
URI de redirección No El parámetro redirect_uri de la aplicación en la que obtuviste el código de autorización.
alcance No Lista de ámbitos separados por espacios. El ámbito openid indica un permiso para iniciar sesión con el usuario y obtener datos de este en forma de parámetros id_token. Se puede usar para obtener tokens para la propia API web de back-end de la aplicación, representada por el mismo id. de aplicación que el cliente. El offline_access ámbito indica que la aplicación necesita un token de actualización para el acceso extendido a los recursos.

Una respuesta de token correcta es similar a la siguiente:

{
    "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...",
}
Parámetro Descripción
no antes de La época en la que el token se convierte en válido.
tipo_de_token Valor del tipo de token. Bearer es el único tipo que se admite.
token de acceso JWT firmado que solicitó.
alcance Ámbitos válidos para el token.
expira_en El período de tiempo que el token de acceso es válido (en segundos).
vence_el La época en la que el token de acceso deja de ser válido.
token de actualización Un token de actualización de OAuth 2.0. La aplicación puede usar este token para adquirir más tokens después de que expire el token actual. Los tokens de actualización se pueden usar para conservar el acceso a los recursos durante largos períodos de tiempo. El ámbito offline_access debe haberse usado en las solicitudes de autorización y token para recibir un token de actualización.

Las respuestas de error son similares a las siguientes:

{
    "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"
}
Parámetro Descripción
error Código que se puede usar para clasificar los tipos de errores que se producen.
descripción_del_error Mensaje que puede ayudar a identificar la causa principal de un error de autenticación.

Uso del token

Después de adquirir correctamente un token de acceso, puede usar el token en las solicitudes a las APIs web de back-end incluyéndolo en el encabezado Authorization.

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

Actualización del token

Los tokens de acceso y los tokens de identificador son de corta duración. Una vez que expiren, debe actualizarlos para seguir accediendo a los recursos. Al actualizar el token de acceso, Azure AD B2C devuelve un nuevo token. El token de acceso actualizado tendrá actualizados nbf (no antes), iat (emitidos en) y valores de notificación exp (expiración). Todos los demás valores de notificación son similares a los del token de acceso anterior.

Actualice un token mediante el envío de otra POST petición al endpoint /token. Esta vez, proporcione el refresh_token parámetro en lugar del code parámetro :

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
Parámetro Obligatorio Descripción
{inquilino} Sí Nombre del inquilino de Azure AD B2C
{política} Sí Flujo de usuario que se usó para adquirir el token de actualización original. No puede usar un flujo de usuario diferente en esta solicitud. Agregue este parámetro a la cadena de consulta, no al cuerpo POST.
ID de cliente Sí Identificador de aplicación asignado a la aplicación en Azure Portal .
secreto_del_cliente Sí, en Web Apps Secreto de aplicación que se generó en Azure Portal. Los secretos de cliente se usan en este flujo para escenarios de aplicación web, donde el cliente puede almacenar de forma segura un secreto de cliente. En escenarios de aplicación nativa (cliente público), los secretos de cliente no se pueden almacenar de forma segura, por lo que no se usan en esta llamada. Si usa un secreto de cliente, cámbielo periódicamente.
tipo_de_subvención Sí Tipo de concesión, que debe ser refresh_token para esta parte del flujo de código de autorización.
token de actualización Sí El token de actualización original que adquirió en la segunda parte del flujo. El ámbito offline_access debe usarse en las solicitudes de token y de autorización para recibir un token de actualización.
URI de redirección No El parámetro redirect_uri de la aplicación en la que obtuviste el código de autorización.
alcance No Lista de ámbitos separados por espacios. El ámbito openid indica un permiso para iniciar sesión con el usuario y obtener los datos del usuario en forma de tokens de identificador. Se puede usar para enviar tokens para la propia API web de back-end de la aplicación, representada por el mismo id. de aplicación que el cliente. El offline_access ámbito indica que la aplicación necesita un token de actualización para el acceso extendido a los recursos.

Una respuesta de token correcta es similar a la siguiente:

{
    "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"
}
Parámetro Descripción
no antes de La época en la que el token se convierte en válido.
tipo_de_token Valor del tipo de token. Bearer es el único tipo que se admite.
token de acceso JWT firmado que se solicitó.
alcance Ámbitos válidos para el token.
expira_en El período de tiempo que el token de acceso es válido (en segundos).
token de actualización Un token de actualización de OAuth 2.0. La aplicación puede usar este token para adquirir tokens adicionales después de que expire el token actual. Los tokens de actualización se pueden usar para conservar el acceso a los recursos durante largos períodos de tiempo.
refresh_token_expires_in El período de tiempo que el token de actualización es válido (en segundos).

Las respuestas de error son similares a las siguientes:

{
    "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",
}
Parámetro Descripción
error Código que se puede usar para clasificar los tipos de errores que se producen.
descripción_del_error Mensaje que puede ayudar a identificar la causa principal de un error de autenticación.

Envío de una solicitud de cierre de sesión

Cuando desea cerrar la sesión del usuario de la aplicación, no basta con borrar las cookies de la aplicación ni finalizar la sesión con el usuario. Redirigir al usuario a Azure AD B2C para cerrar la sesión. Si no lo hace, es posible que el usuario pueda volver a autenticarse en la aplicación sin volver a escribir sus credenciales. Para más información, consulte Comportamiento de la sesión de Azure AD B2C.

Para cerrar la sesión del usuario, redirija al usuario al end_session_endpoint que aparece en el documento de metadatos de OpenID Connect descrito anteriormente:

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F
Parámetro Obligatorio Descripción
{inquilino} Sí Nombre del inquilino de Azure AD B2C. Si usa un dominio personalizado, reemplace tenant.b2clogin.com por el dominio, por ejemplo, fabrikam.com.
{política} Sí Flujo de usuario que especifique en la solicitud de autorización. Por ejemplo, si el usuario ha iniciado sesión con el b2c_1_sign_in flujo de usuario, especifique b2c_1_sign_in en la solicitud de cierre de sesión.
id_token_hint No Token de id. emitido previamente para pasarse al punto de conexión de cierre de sesión como una sugerencia sobre la sesión autenticada actual del usuario final con el cliente. id_token_hint garantiza que post_logout_redirect_uri es una dirección URL de respuesta registrada en la configuración de la aplicación de Azure AD B2C. Para más información, consulte Protección de la redirección de cierre de sesión.
ID de cliente No* Identificador de aplicación asignado a la aplicación en Azure Portal .

* Esto es necesario cuando se usa la configuración de SSO de aislamiento Application y Requerir token de identificador en solicitudes de cierre de sesión se establece en No.
URI de redirección después de cierre de sesión No Dirección URL a la que se debe redirigir el usuario después de cerrar la sesión correctamente. Si no se incluye, Azure AD B2C muestra al usuario un mensaje genérico. A menos que proporcione un id_token_hint, no debe registrar esta dirección URL como dirección URL de respuesta en la configuración de la aplicación de Azure AD B2C.
estado No Si incluye un state parámetro en la solicitud de autorización, el servidor de autorización devuelve el mismo valor en la respuesta a post_logout_redirect_uri. La aplicación debe comprobar que el state valor de la solicitud y la respuesta son idénticos.

Tras una solicitud de cierre de sesión, Azure AD B2C invalida la sesión basada en cookies de Azure AD B2C e intenta cerrar sesión de proveedores de identidades federados. Para obtener más información, consulte Cierre de sesión único.

Protección de la redirección de cierre de sesión

Después del cierre de sesión, el usuario se redirige al URI especificado en el post_logout_redirect_uri parámetro , independientemente de las direcciones URL de respuesta que especifique para la aplicación. Sin embargo, si se pasa un valor válido id_token_hint y el token Requerir identificador en las solicitudes de cierre de sesión está activado, Azure AD B2C comprueba que el valor de post_logout_redirect_uri coincide con uno de los URI de redireccionamiento configurados de la aplicación antes de realizar el redireccionamiento. Si no se configuró ninguna dirección URL de respuesta coincidente para la aplicación, se muestra un mensaje de error y el usuario no se redirige.

Para establecer el token de identificador necesario en las solicitudes de cierre de sesión, consulte Configuración del comportamiento de la sesión en Azure Active Directory B2C.

Contenido relacionado