Un cierre de sesión back-channel de OIDC finaliza las sesiones de un usuario en una aplicación. No revoca el tenant del cliente

Un back-channel logout de OIDC cierra las sesiones de un usuario en una sola aplicación. No revoca el tenant del cliente

La pregunta que un MSP escucha de su cliente tras una llamada de incidente es: “nuestro IdP envió un back-channel logout, así que todo el tenant del cliente ha quedado cortado, ¿verdad?”. La respuesta corta es no. Según OpenID Connect Back-Channel Logout 1.0, el proveedor de identidad envía mediante POST un Logout Token firmado a una relying party, y ese token identifica a un único usuario final (issuer más subject) y/o una única sesión. Si no hay identificador de sesión, la relying party cierra todas las sesiones de ese usuario en esa relying party, y nada más. No hay ningún claim de tenant ni ningún significado de “revocar a todos”.

Esta FAQ responde a seis preguntas que plantean los MSP cuando una señal de logout se confunde con un offboarding. ¿Qué demuestra un 200 OK del endpoint de logout y qué no demuestra? ¿Por qué las integraciones machine-to-machine quedan totalmente fuera del flujo de logout? ¿Por qué cerrar la sesión en el IdP no cierra automáticamente las sesiones en las aplicaciones, como señala NIST SP 800-63C-4 (26 de agosto de 2025)? ¿Dónde se ubica una señal de revocación con alcance de tenant o de política, con CAEP sobre el Shared Signals Framework, y por qué ni siquiera eso sustituye la comprobación de autorización en cada solicitud? ¿Y por qué el logout no es desaprovisionamiento?

La regla de este artículo es sencilla: el offboarding de un tenant es una acción de administración y de autorización, nunca un efecto secundario de un logout. Las fuentes son los textos de OpenID, IETF, NIST y OWASP verificados el 5 de octubre de 2026. No hay construcción de tokens ni afirmación alguna de que un producto de Altovar transmita o reciba estos eventos de logout o de señales compartidas.

¿Se revoca todo el tenant del cliente cuando el IdP envía un back-channel logout? En palabras del cliente: “han cerrado sesión, así que todos los de ese cliente están fuera”. La respuesta es no. Una solicitud de Back-Channel Logout es un POST del proveedor de identidad a la relying party que contiene un Logout Token firmado, tal como lo define la sección 2.4 de OIDC Back-Channel Logout 1.0. El token identifica a un usuario final por issuer y subject, y/o una sesión por su ID. Ese es el radio que el estándar da a la señal.

Cuando falta el ID de sesión, la relying party cierra todas las sesiones de ese usuario en esa relying party. Ese es el máximo alcance que prevé el estándar. Sigue siendo un usuario y una aplicación. Cerrar todas las sesiones de navegador que Alice tiene en el portal de tickets no cierra las sesiones de Bob en el mismo portal, ni las de Alice en otro portal que nunca recibió un Logout Token.

El Logout Token no lleva ningún claim de tenant ni significa “revocar a todos”. Una relying party que trata un logout como revocación del tenant se está inventando un comportamiento que la especificación no define. La revocación de un tenant, entendida como un conjunto de actos administrativos separados y no como un recorrido por un producto, consiste en desactivar el registro del tenant, revocar sus grants y registros de clientes, rotar las credenciales que posee y hacer que el punto de decisión de políticas deniegue sus solicitudes. Cada acto tiene un responsable y un registro de auditoría. Ninguno de ellos es un logout.

Una breve nota sobre las firmas, sin entrar en detalle: la especificación exige que el Logout Token esté firmado y sea de corta duración precisamente para que una relying party no actúe sobre un logout falsificado o reenviado. Este artículo no describe cómo se construye ni cómo se verifica un token. Lo que importa al MSP es el radio: un usuario, una aplicación, no el tenant del cliente.

El endpoint de logout devolvió 200 OK. ¿Están muertos todos los tokens del usuario? No necesariamente. Un 200 OK significa que la relying party limpió el estado de las sesiones que se le indicaron. Es un acuse de recibo de esa relying party, no una prueba de que todos los tokens hayan desaparecido en todas partes.

Los refresh tokens siguen una regla más estricta, según la sección 2.7 de Back-Channel Logout. Los refresh tokens vinculados a la sesión cerrada y emitidos sin offline_access DEBERÍAN revocarse; los refresh tokens de offline access normalmente NO DEBERÍAN revocarse. Es una propiedad genérica del estándar. Este artículo no la vincula a la configuración de ningún proveedor ni cita valores de inactividad o de duración.

Con los access tokens la historia es distinta. Un access token autocontenido (JWT) sigue siendo válido hasta que caduca, salvo que el resource server lo compruebe en tiempo real mediante introspección (RFC 7662) o que el token se revoque en el authorization server (RFC 7009). La propia sección 3 de la RFC 7009 señala que la revocación inmediata de access tokens autocontenidos requiere una coordinación adicional y no estandarizada entre authorization server y resource server, o bien tokens de vida corta. Un 200 OK en el logout no es esa coordinación.

Una salvaguarda sobre la introspección, en una frase: active: true significa que el token fue emitido y no está revocado ni caducado. No dice nada sobre si este tenant o esta acción están autorizados. Es una cuestión aparte, que este artículo no desarrolla. La OWASP Session Management Cheat Sheet añade una línea más: el logout debe invalidar la sesión en el servidor; borrar una cookie del navegador no es lo mismo.

¿Corta el logout las integraciones machine-to-machine? No. Back-Channel Logout cierra sesiones de usuarios finales en las relying parties. Un cliente de máquina que obtiene tokens mediante el grant client credentials no tiene sesión de usuario ni ID de sesión, así que un Logout Token no puede dirigirse a él. La señal no tiene dónde aterrizar.

La consecuencia para el MSP, en palabras sencillas: el conector RMM, la sincronización de facturación y el cliente API del agente de copias de seguridad siguen funcionando después de que todas las personas del cliente hayan cerrado sesión. Es el comportamiento correcto del protocolo, y es justo la razón por la que “hemos desconectado a todos” no es un registro de offboarding. Las personas han salido de las aplicaciones que recibieron un Logout Token. Las integraciones no son personas y no recibieron ninguno.

El offboarding de una integración tiene su propia checklist, redactada como resultados y no como clics en un producto: desactivar o rotar las credenciales del cliente, revocar los tokens que ya tiene y retirar su derecho sobre el tenant en el punto de decisión. Cada uno de esos pasos es un acto de administración y de autorización con un responsable. Ninguno se produce con un POST de logout.

¿Cerrar la sesión en el IdP cierra automáticamente las sesiones en las aplicaciones? No. NIST SP 800-63C-4 (revisión 4 final, página fechada el 26 de agosto de 2025) indica que finalizar la sesión del suscriptor en el IdP “no terminará necesariamente” las sesiones que ese suscriptor pueda tener en las RP posteriores (traducción propia). Ambas partes pueden intercambiarse eventos de fin de sesión si el protocolo de federación lo admite, o mediante señales compartidas. “Pueden” no es “lo harán”.

Back-Channel Logout es uno de esos mecanismos y funciona en modo best effort. La relying party debe registrar una URI de back-channel logout, el proveedor de identidad debe poder alcanzarla y solo reintenta tras errores que considera recuperables (sección 2.5 de Back-Channel Logout). Una aplicación que nunca se registró, o que no estaba accesible cuando el IdP envió el POST, conserva su sesión. Basta una regla de firewall, una URI obsoleta o un registro ausente para que quede una sesión activa.

La sección 5 de NIST SP 800-63B-4 añade una aclaración terminológica: las sesiones terminan por tiempo de espera o por logout explícito, y el comportamiento federado se remite a 63C. Así que “el IdP caducó” y “todas las aplicaciones cerraron sesión” son dos hechos distintos. Un ticket de MSP que los mezcle cerrará el trabajo equivocado.

Cerrar la sesión de un usuario tampoco elimina su pertenencia al tenant ni sus roles. NIST SP 800-63C-4 trata la baja de una cuenta de suscriptor en la relying party (eliminar identificadores, autenticadores y atributos) como un acto distinto del fin de sesión. La pertenencia y los roles son datos de aprovisionamiento y de autorización; cambiarlos es desaprovisionamiento. La frase para recordar: fin de sesión ≠ baja de la cuenta ≠ offboarding del tenant.

¿Dónde se ubica una revocación con alcance de tenant, si no es en un Logout Token? El OpenID Shared Signals Framework 1.0, junto con el Continuous Access Evaluation Profile (CAEP 1.0, ambos en versión Final), define los eventos session-revoked y token-claims-change. Su sujeto puede ser un sujeto complejo que incluya un componente de tenant. Es lo más cerca que llega un estándar a un mensaje de revocación con alcance de tenant o de política.

Sigue siendo una señal: quien la recibe decide qué hacer con ella. Recibir un evento no equivale a haber revocado el acceso. Un producto que ignora el evento, lo retrasa o lo convierte en un simple aviso no ha ejecutado la denegación. El evento es un disparador, no la decisión.

La autorización del producto debe seguir denegando por defecto y comprobar el estado del tenant y los permisos en cada solicitud, tal como lo plantea la OWASP Authorization Cheat Sheet. Un logout o un evento CAEP dispara esa comprobación, no la sustituye. Un MSP que trata “CAEP recibido” como “acceso revocado” se está saltando el punto de decisión.

Este artículo no dice qué productos transmiten o reciben CAEP. En concreto, no dice que Auris lo haga. El artículo describe únicamente el estándar y no afirma que ningún producto de Altovar admita CAEP, SSF o back-channel logout.

Esta no es una FAQ sobre PAR, PKCE o passkeys. Esos temas tratan de cómo empieza un inicio de sesión o una solicitud de autorización. Este artículo trata de lo que termina una señal de logout. Iniciar una solicitud y cerrar una sesión son tareas distintas, y mezclarlas genera el ticket equivocado.

Tampoco es una FAQ sobre group claims o SCIM. Los datos de aprovisionamiento y de roles aparecen aquí solo para decir que el logout no los modifica. Las filas de pertenencia y las asignaciones de roles sobreviven a un Logout Token salvo que un acto administrativo independiente las elimine.

Tampoco trata de DPoP ni de las ceremonias de vinculación de autenticadores. La restricción al remitente (sender constraint) y la vinculación del autenticador responden a preguntas distintas del radio del logout.

Y no trata de tokens de corta duración ni de TTL de tokens. Esos temas tratan de cuánto vive un token. Aquí importa el radio de la señal de logout (sesión o usuario frente a tenant), no la duración. Un access token de corta duración y un Logout Token pueden estar presentes en el mismo stack y aun así dejar intactos los clientes de máquina y las demás aplicaciones.

Este artículo no afirma que Auris admita back-channel logout, CAEP o SSF, que anuncie backchannel_logout_supported, que respete una backchannel_logout_uri por cliente ni que transmita eventos de señales compartidas.

La frase para repetir: una señal de logout cierra sesiones; revocar el tenant de un cliente es una decisión deliberada de administración y de autorización, que se comprueba en cada solicitud.