Inicio de sesión web con OpenID Connect en Azure Active Directory B2C
OpenID Connect es un protocolo de autenticación basado en OAuth 2.0 que se puede usar para que los usuarios inicien sesión de forma segura en las aplicaciones web. Al utilizar la implementación Azure Active Directory B2C (Azure AD B2C) de OpenID Connect, puede externalizar el registro, el inicio de sesión y otras experiencias de administración de identidades en sus aplicaciones web a Microsoft Entra ID. Esta guía le enseñará cómo hacerlo de manera independiente del lenguaje. En ella se describe cómo enviar y recibir mensajes HTTP sin utilizar 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 tokens JWT para la aplicación. Se recomienda explorar esas opciones en lugar de implementar su propio código. Para obtener más información, vea Introducción a la Biblioteca de autenticación de Microsoft (MSAL) y Biblioteca de autenticación de Microsoft Identity Web.
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 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 del perfil básica 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. Nosotros recomendamos OpenID Connect si va a crear una aplicación web que hospede en un servidor y a la que se acceda mediante un explorador. Para más información sobre los tokens, consulte Información general de tokens de Azure Active Directory B2C.
Azure AD B2C extiende el protocolo OpenID Connect estándar para realizar algo más que una autorización y autenticación simples. Presenta el parámetro de flujo de usuario, que le permite usar OpenID Connect para agregar experiencias de usuario (como registro, inicio de sesión y administración de perfiles) a su aplicación.
Envío de solicitudes de autenticación
Cuando su aplicación web necesite autenticar al usuario y ejecutar el flujo de usuario, puede dirigir al usuario al punto de conexión /authorize. 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 parámetro scope y especifica el flujo de usuario que se va a ejecutar. Para hacerse una idea de cómo funciona la solicitud, péguela en el explorador y ejecútela. Sustituya:
{tenant}por el nombre del inquilino.90c0fe63-bcf2-44d5-8fb7-b8bbc0b29dc6por 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 ejemplob2c_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
| Parámetro | Obligatorio | Descripción |
|---|---|---|
| {tenant} | Sí | Nombre de su inquilino de Azure AD B2C. Si usa un dominio personalizado, reemplace tenant.b2clogin.com por el dominio, por ejemplo, fabrikam.com. |
| {policy} | Sí | Flujo de usuario o directiva que ejecuta la aplicación. Especifique el nombre del flujo de usuario que cree en el inquilino de Azure AD B2C. Por ejemplo: b2c_1_sign_in, b2c_1_sign_up o b2c_1_edit_profile. |
| client_id | Sí | Identificador de aplicación que Azure Portal asignó a la aplicación. |
| valor de seguridad | Sí | Un valor incluido en la solicitud, generada por la aplicación, que se incluirá en el token de identificador resultante como una notificación. La aplicación puede comprobar este valor para mitigar los ataques de reproducción de token. Normalmente, el valor es una cadena única aleatoria que se puede usar para identificar el origen de la solicitud. |
| response_type | Sí | Debe incluir un token de identificador para OpenID Connect. Si su aplicación web también necesita tokens para llamar a una API web, puede usar code+id_token. |
| scope | Sí | Una lista de ámbitos separada 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 un acceso ampliado a los recursos. El https://{tenant-name}/{app-id-uri}/{scope} indica un permiso para los recursos protegidos, como una API web. Para más información, consulte Solicitud de un token de acceso. |
| símbolo del sistema | 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. |
| redirect_uri | 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 parámetros redirect_uri que registró en Azure Portal, con la excepción de que debe estar codificado como URL. |
| response_mode | No | El método que se usa para devolver el código de autorización resultante a la aplicación. Puede ser query, form_post o fragment. Se recomienda usar el modo de respuesta form_post para mejorar la seguridad. |
| state | 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. Se utiliza normalmente un valor único generado de forma aleatoria para evitar los 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 haya producido la solicitud de autenticación, por ejemplo, la página en la que estaban. Si no desea registrar varias direcciones URL de redireccionamiento en Azure Portal, puede usar el parámetro state para diferenciar las respuestas de la aplicación del servicio Azure AD B2C originadas por diferentes solicitudes. |
| login_hint | No | Se puede usar para rellenar previamente el campo de nombre de inicio de sesión de la página de inicio de sesión. Para más información, consulte Rellenar previamente el nombre de inicio de sesión. |
| domain_hint | No | Proporciona una sugerencia a Azure AD B2C acerca del proveedor de identidades sociales que debe usarse para iniciar 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 más información, consulte Redirección del inicio de sesión a un proveedor social. |
| 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 punto se pedirá al usuario que complete el flujo de trabajo. Puede 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. Podría haber cualquier otro número de pasos en función de cómo se define el flujo de usuario.
Una vez que el usuario haya completado el flujo de usuario, se devuelve una respuesta a la aplicación en el parámetro redirect_uri indicado, mediante el método especificado en el parámetro response_mode. La respuesta es la misma para cada uno de los casos anteriores, con independencia del flujo de usuario.
Una respuesta correcta al usar response_mode=fragment tiene 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 |
|---|---|
| ID_token | El 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 utilizar el código de autorización con el fin de solicitar un token de acceso para un recurso de destino. Los códigos de autorización normalmente expiran después de unos 10 minutos. |
| state | 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 valores state de la solicitud y de la respuesta sean idénticos. |
Las respuestas de error también se pueden enviar al parámetro redirect_uri para que la aplicación pueda controlarlas de manera adecuada:
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 | Un código que puede usarse para clasificar los tipos de errores que se producen. |
| error_description | Un mensaje de error específico que puede ayudarlo a identificar la causa raíz de un error de autenticación. |
| state | 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 valores state de la solicitud y de la respuesta sean idénticos. |
Validar el token de identificador
Recibir 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 la criptografía de clave pública para firmar los tokens y comprobar que son válidos.
Nota:
La mayoría de las bibliotecas de autenticación de código abierto validan los tokens JWT para 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 Introducción a la Biblioteca de autenticación de Microsoft (MSAL) y Biblioteca de autenticación de Microsoft Identity Web.
Azure AD B2C tiene un extremo de metadatos OpenID Connect, que permite a una aplicación obtener información sobre Azure AD B2C en tiempo de ejecución. En esta información se incluyen los extremos, los contenidos del token y las claves de firma de los token. Hay un documento de metadatos JSON para cada flujo de usuario en el inquilino de 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 ha usado 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 parámetro state al emitir la solicitud y luego descodificarlo para determinar qué flujo de usuario se ha usado. Cualquiera de estos métodos es válido.
Después de adquirir el documento de metadatos del punto de conexión de metadatos de OpenID Connect, podrá 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 notificación kid, 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 el exponente(e) y el módulo(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 identificador, hay varias notificaciones que debe verificar. Por ejemplo:
- Valide la notificación
noncepara evitar ataques de reproducción del token. Su valor debería ser el que especificó en la solicitud de inicio de sesión. - Valide la notificación
audpara asegurarse de que se ha generado el token de identificador para su aplicación. Su valor debería ser el identificador de la aplicación. - Valide las notificaciones
iatyexppara asegurarse de que el token de identificador no ha expirado.
También hay otras validaciones que deberá llevar a cabo. Las validaciones se describen en detalle en la especificación de OpenID Connect Core. Podría también querer validar notificaciones adicionales, en función de su escenario. Algunas validaciones comunes incluyen:
- Asegurarse de que el usuario o la organización se han registrado en la aplicación.
- Asegurarse de que el usuario tiene la autorización o los privilegios adecuados.
- Garantizar que se ha producido un determinado nivel de autenticación, como la autenticación multifactor de Microsoft Entra.
Cuando se haya validado el token de id., podrá iniciar una sesión con el usuario. Puede usar las notificaciones del token de identificador para obtener información sobre el usuario en la aplicación. Entre los usos de esta información se incluye 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 siguientes secciones. Estas secciones son aplicables solo a las aplicaciones web que necesitan efectuar llamadas autenticadas a una API web y que también están protegidas por 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 id. de cliente de la aplicación como ámbito solicitado, lo que da como resultado un token de acceso con ese id. de cliente como "público":
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
| Parámetro | Obligatorio | Descripción |
|---|---|---|
| {tenant} | Sí | Nombre de su inquilino de Azure AD B2C. |
| {policy} | Sí | El flujo de usuario usado 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 de POST. |
| client_id | Sí | Identificador de aplicación que Azure Portal asignó a la aplicación. |
| client_secret | Sí, en Web Apps. | El secreto de la aplicación se generó en Azure Portal. Los secretos de cliente se usan en este flujo para escenarios de aplicaciones web, donde el cliente puede almacenar de forma segura un secreto de cliente. En el caso de escenarios de aplicación nativa (cliente público), los secretos de cliente no se pueden almacenar de forma segura, por lo tanto no se usan en este flujo. Si se usa un secreto de cliente, cámbielo periódicamente. |
| code | Sí | El código de autorización que adquirió al principio del flujo de usuario. |
| grant_type | Sí | El tipo de concesión, que debe ser authorization_code para el flujo de código de autorización. |
| redirect_uri | No | El parámetro redirect_uri de la aplicación en la que recibió el código de autorización. |
| scope | No | Una lista de ámbitos separada 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 ámbito offline_access indica que la aplicación necesita un token de actualización para un acceso ampliado a los recursos. |
Una respuesta correcta del token tiene el siguiente aspecto:
{
"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...",
}
| Parámetro | Descripción |
|---|---|
| not_before | La época en la que el token pasa a ser válido. |
| token_type | El valor del tipo de token. Bearer es el único tipo admitido. |
| access_token | El token JWT firmado solicitado. |
| scope | Ámbitos válidos para el token. |
| expires_in | El período de validez del token de acceso (en segundos). |
| expires_on | La época en la que el token de acceso deja de ser válido. |
| refresh_token | Un token de actualización de OAuth 2.0. La aplicación puede usar este token para adquirir más tokens una vez que expire el actual. Los tokens de actualización pueden usarse para conservar el acceso a los recursos durante largos periodos. El ámbito offline_access debe haberse usado en las solicitudes de token y de autorización para recibir un token de actualización. |
Las respuestas de error tienen un aspecto similar al siguiente:
{
"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 | Un código que puede usarse para clasificar los tipos de errores que se producen. |
| error_description | Un mensaje que puede ayudar a identificar la causa raíz 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 API 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 identificación tienen una corta duración. Una vez expirados, debe actualizarlos para poder seguir obteniendo acceso a los recursos. Al actualizar el token de acceso, Azure AD B2C devuelve un nuevo token. En el token de acceso actualizado también se habrán actualizado los valores de notificación nbf (no antes), iat (emitido en) y 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 solicitud POST al punto de conexión /token. Esta vez, proporcione el parámetro refresh_token en lugar del parámetro 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
| Parámetro | Obligatorio | Descripción |
|---|---|---|
| {tenant} | Sí | Nombre de su inquilino de Azure AD B2C. |
| {policy} | Sí | El flujo de usuario usado 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 de POST. |
| client_id | Sí | Identificador de aplicación que Azure Portal asignó a la aplicación. |
| client_secret | Sí, en Web Apps. | El secreto de la aplicación se generó en Azure Portal. Los secretos de cliente se usan en este flujo para escenarios de aplicaciones web, donde el cliente puede almacenar de forma segura un secreto de cliente. En el caso de escenarios de aplicación nativa (cliente público), los secretos de cliente no se pueden almacenar de forma segura, por lo tanto no se usan en esta llamada. Si se usa un secreto de cliente, cámbielo periódicamente. |
| grant_type | Sí | El tipo de concesión, que debe ser refresh_token para esta parte del flujo de código de autorización. |
| refresh_token | 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. |
| redirect_uri | No | El parámetro redirect_uri de la aplicación en la que recibió el código de autorización. |
| scope | No | Una lista de ámbitos separada 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 ámbito offline_access indica que la aplicación necesita un token de actualización para un acceso ampliado a los recursos. |
Una respuesta correcta del token tiene el siguiente aspecto:
{
"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"
}
| Parámetro | Descripción |
|---|---|
| not_before | La época en la que el token pasa a ser válido. |
| token_type | El valor del tipo de token. Bearer es el único tipo admitido. |
| access_token | El token JWT firmado que se solicitó. |
| scope | Ámbitos válidos para el token. |
| expires_in | El período de validez del token de acceso (en segundos). |
| refresh_token | Un token de actualización de OAuth 2.0. La aplicación puede usar este token para adquirir tokens adicionales una vez que expire el actual. Los tokens de actualización pueden usarse para conservar el acceso a los recursos durante largos periodos. |
| refresh_token_expires_in | Período de tiempo durante el que el token de actualización es válido (en segundos). |
Las respuestas de error tienen un aspecto similar al siguiente:
{
"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 | Un código que puede usarse para clasificar los tipos de errores que se producen. |
| error_description | Un mensaje que puede ayudar a identificar la causa raíz de un error de autenticación. |
Envío de una solicitud de cierre de sesión
Si desea cerrar la sesión del usuario de la aplicación, no basta con borrar las cookies de la aplicación o finalizar la sesión con el usuario. Redireccione al usuario a Azure AD B2C para cerrar la sesión. Si no lo hace, el usuario podría autenticarse de nuevo en su aplicación sin volver a escribir sus credenciales. Para más información, consulte Comportamiento de la sesión en Azure AD B2C.
Para cerrar la sesión del usuario, redirija a end_session_endpoint que aparece en el documento de metadatos de OpenID Connect que se ha 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 |
|---|---|---|
| {tenant} | Sí | Nombre de su inquilino de Azure AD B2C. Si usa un dominio personalizado, reemplace tenant.b2clogin.com por el dominio, por ejemplo, fabrikam.com. |
| {policy} | Sí | Flujo de usuario que especifique en la solicitud de autorización. Por ejemplo, si el usuario ha iniciado sesión con el flujo de usuario b2c_1_sign_in, 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. La pista id_token_hint garantiza que el 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. |
| client_id | No* | Identificador de aplicación que Azure Portal asignó a la aplicación. *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. |
| post_logout_redirect_uri | No | La dirección URL a la que se debe redirigir al usuario después de un cierre de sesión correcto. Si no se incluye, Azure AD B2C mostrará un mensaje genérico al usuario. A menos que proporcione un valor id_token_hint, no debe registrar esta dirección URL como una dirección URL de respuesta en la configuración de la aplicación de Azure AD B2C. |
| state | No | Si incluye un parámetro state 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 valor state de la solicitud y de la respuesta sean 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 la sesión con los proveedores de identidades federados. Para 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 que especifique en el parámetro post_logout_redirect_uri, independientemente de las direcciones URL de respuesta que especifique para la aplicación. Sin embargo, si se pasa un valor de id_token_hint válido y la opción Requerir token de identificador en solicitudes de cierre de sesión está activada, Azure AD B2C comprueba que el valor de post_logout_redirect_uri coincida con uno de los URI de redirección configurados de la aplicación antes de realizar la redirección. Si no se configuró ninguna dirección URL de respuesta coincidente para la aplicación, se muestra un mensaje de error y no se redirige al usuario.
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.
Pasos siguientes
- Más información sobre la sesión de Azure AD B2C.