Cierre de sesión único para aplicaciones OIDC

Editar en línea

Con el cierre de sesión único (SLO), los usuarios pueden cerrar sesión en todas las aplicaciones de inicio de sesión único al mismo tiempo. Esta función mejora la seguridad al impedir el acceso no autorizado a cualquier sesión activa, especialmente cuando se comparte un dispositivo con otras personas.

Al implementar las funciones de cierre de sesión único (SLO), existen tres tipos de sesiones.

Sesión de solicitud: Aunque la aplicación utiliza el protocolo OP ( OpenID ) para autenticar a los usuarios, es posible que realice un seguimiento del usuario que ha iniciado sesión en la aplicación. Por lo general, una aplicación realiza un seguimiento de las sesiones mediante una cookie del navegador. La aplicación se encarga de borrar la sesión al cerrar sesión.
Servidor de autorización: Proveedor de servicios de autenticación (OP) de OpenID : Sesión: Un servidor de autorización también mantiene una sesión de usuario y la almacena en una cookie. Un servidor de autorización cierra la sesión del usuario al cerrar sesión, junto con las autorizaciones y los tokens relacionados con dicha sesión.
Identidad, Fuente, Sesión: Los usuarios pueden iniciar sesión mediante una sesión de usuario procedente de una fuente de identidades. Al cerrar sesión, es posible que el usuario también desee cerrar la sesión de usuario.

Nota: El cierre de sesión único no admite el cierre de sesión de una sesión del proveedor de identidad. Tampoco permite cerrar la sesión en las aplicaciones de SAML. Aunque SAML dispone de un punto final similar para realizar el cierre de sesión iniciado por IdP-initiated y SP, no está integrado con el cierre de sesión único de OIDC.

Existen dos mecanismos para que un servidor de autorización (OP) notifique a la aplicación que se ha iniciado un cierre de sesión: el canal principal y el canal secundario. En ambos mecanismos, la aplicación registra un punto final de cierre de sesión al que recurre el servidor de autorización. Este punto final engloba el código que utiliza la aplicación para borrar su sesión. Llamar al punto final de cierre de sesión de la aplicación no es fiable, ya IBM® Verify que no existe la obligación de volver a intentarlo ni de garantizar que la aplicación borre correctamente su sesión. El cierre de sesión a través del canal secundario es el mecanismo recomendado.

Cerrar sesión del canal principal

El cierre de sesión en el canal frontal o el cierre de sesión del lado del cliente es un método de cierre de sesión único (SLO) en el que el cliente (normalmente un navegador web) se comunica directamente con el servidor para invalidar la sesión del usuario. Normalmente, esto se hace enviando una solicitud al servidor para que elimine la cookie de sesión o el token. A continuación, el servidor responde para confirmar el cierre de sesión. Este método es sencillo y funciona bien en casos en los que solo hay un dominio. Sin embargo, es posible que no sea adecuado para entornos complejos, con varios dominios o que utilicen múltiples protocolos, debido a posibles problemas relacionados con la comunicación entre dominios y la seguridad. Cuando se utiliza el mecanismo de canal frontal, el servidor de autorización (OP) genera

<iframe
src="frontchannel_logout_uri">

una página para activar una HTTP GET llamada al punto final de cierre de sesión de la aplicación. La aplicación puede solicitar al servidor de autorización que envíe la identificación de sesión (sid) y la información del emisor (iss) como parámetros de consulta adicionales. Si el cliente de la aplicación se crea mediante el registro dinámico de clientes, establezca frontchannel_logout_session_required el metadato del cliente en «true». IBM VerifyDe hecho, cuando se configura una aplicació OpenID e en la interfaz de usuario de administración, la configuración está disponible en la pestaña «Inicio de sesión ». Desplázate hasta la sección «Configuración de cierre de sesión único» y marca la casilla «Sesión obligatoria ». La aplicación puede utilizar esa información para validar la solicitud y determinar de qué sesiones debe cerrar la sesión. Si el sid no coincide con la sesión actual o reciente con el servidor de autorización (OP), es posible que la aplicación ignore la solicitud de cierre de sesión.

Nota: OIDC Front-channel Logout recomienda utilizar un iframe para llamar al punto final de cierre de sesión del canal frontal. iframeLos navegadores modernos bloquean por defecto el reenvío de cookies de terceros. Si el dominio de la aplicación es diferente al del servidor de autorización, esta no recibe ninguna cookie, lo que podría impedir que la aplicación cierre la sesión del usuario correctamente. El usuario deberá configurar su navegador para permitir las cookies de terceros del dominio del servidor de autorización.

Cerrar sesión en el canal secundario

El cierre de sesión por canal secundario o por el lado del servidor es un método de cierre de sesión único (SLO) en el que el proveedor de identidad ( IdP ) se comunica directamente con el proveedor de servicios (SP) para invalidar la sesión del usuario. Normalmente se lleva a cabo a través de un canal seguro que se establece entre el servidor de autenticación ( IdP ) y el proveedor de servicios (SP) durante el proceso de autenticación inicial. Cuando se utiliza el mecanismo de canal secundario, el servidor de autorización (n) envía una solicitud POST de tipo « HTTP » al punto final de cierre de sesión de la aplicación a través de una API de canal secundario directa. El servidor de autorización emite un token JWT de cierre de sesión que contiene la siguiente información.

Nombre de reclamación	Uso	Descripción
`iss`	Obligatorio	Identificador del emisor.
`sub`	Opcional	Identificador de sujeto. Debe estar presente cuando `sid` no lo está.
`aud`	Obligatorio	Público o públicos.
`iat`	Obligatorio	Publicado en su momento.
`exp`	Obligatorio	Hora de vencimiento.
`jti`	Obligatorio	Identificador único del token.
`events`	Obligatorio	http://schemas.openid.net/event/backchannel-logoutObjeto JSON que contiene el nombre del miembro.
`sid`	Opcional	Identificador de sesión. Debe estar presente cuando `sub` no lo está.

El servidor de autorización (OP) utiliza la misma configuración para firmar, cifrar o ambas cosas el token JWT de cierre de sesión que el token de identificación.

end_session_endpointEn un escenario de cierre de sesión iniciado por la parte que depende de la aplicación (RP), la aplicación activa el cierre de sesión redirigiendo a la URL del servidor de autorización, que se publica en el punto de acceso de descubrimiento del servidor de autorización. La aplicación podría enviar los siguientes parámetros de solicitud.

Nombre del parámetro	Uso	Descripción
`id_token_hint`	Recomendado	El token de identificación que el servidor de autorización ha emitido como indicación de la sesión autenticada del usuario con la aplicación.
`logout_hint`	Opcional	Una indicación para el servidor de autorización sobre el usuario que está cerrando la sesión.
client_id	Opcional	El identificador de cliente de la aplicación.
`post_logout_redirect_uri`	Opcional	La URI a la que la aplicación solicita que se redirija el agente de usuario del usuario tras cerrar la sesión.
`state`	Opcional	Un valor opaco que utiliza la aplicación para mantener el estado entre la solicitud de cierre de sesión y la llamada de retorno al `post_logout_redirect_uri` punto final.
`ui_locales`	Opcional	Los idiomas y alfabetos preferidos por el usuario para la interfaz de usuario.

Cuando no se especifica el id_token_hint o el token de identificación no pertenece al usuario que ha iniciado sesión, el servidor de autorización pregunta al usuario si desea borrar la sesión del servidor de autorización. A continuación, al igual que en el caso del cierre de sesión iniciado por el OP, el servidor de autorización busca la lista de aplicaciones que se conectaron con la misma sesión del servidor de autorización (OP). Notifica a las aplicaciones mediante uno de los mecanismos de desconexión del canal. A continuación, si el usuario da su consentimiento, el servidor de autorización borra su propia sesión. Si se especifica el post_logout_redirect_uri y se puede validar con la configuración del cliente, al final del proceso de cierre de sesión se lleva a cabo la redirección a ese URI. De lo contrario, el servidor de autorización muestra el informe resumido de cierre de sesión.

Consejo: Si estás creando un punto final de cierre de sesión para una aplicación personalizada,

Para cerrar sesión en el canal principal

Verify espera que el punto final de cierre de sesión de la aplicación responda en un plazo de 3 segundos.

Para cerrar sesión en el canal secundario

Verify espera que el punto final devuelva el código de estado 2xx en caso de éxito y 400 en caso de error.
Verify espera que el punto final de cierre de sesión de la aplicación responda en un plazo de 3 segundos.
Para acelerar la validación del token de cierre de sesión JWT, el punto final de cierre de sesión de la aplicación almacena en caché el Verify punto final JWKS.