Una **lista de comprobación de bajas con SSO** verifica qué ocurre después de retirar el acceso de una persona en el proveedor de identidad. Revisa los nuevos inicios de sesión, las sesiones existentes, los tokens API, los asistentes conectados y los miembros invitados manualmente. Anota cuándo cesa realmente el acceso al espacio de trabajo, qué excepciones quedan y quién puede retirarlo si falla la sincronización del directorio.

La demostración del proveedor probablemente incluye un inicio de sesión correcto. Pide también una demostración de baja. Si un sistema de seguimiento de candidaturas almacena expedientes de candidatos, notas de entrevistas y conversaciones internas privadas, ambos resultados deben formar parte de la decisión de compra.

## ¿Por qué probar las bajas al evaluar el SSO?

Una demostración correcta de inicio de sesión único prueba que una vía de entrada funciona. No muestra qué ocurre con los accesos ya existentes cuando una persona deja la empresa.

El debate actual sobre SAML ofrece un motivo para preguntar ahora. En su artículo del 21 de septiembre, [SAML: un fractal de mal diseño](https://blog.trailofbits.com/2026/09/21/saml-a-fractal-of-bad-design/), Matt Schwager, investigador de Trail of Bits, critica la complejidad de SAML y recomienda avanzar hacia OpenID Connect. La [conversación en Hacker News](https://news.ycombinator.com/item?id=49806335) vuelve a poner la elección del protocolo en el punto de mira de los equipos de software.

Es un motivo para examinar cómo gestiona las identidades tu proveedor. No demuestra que todas las instalaciones de SAML estén comprometidas ni que elegir OpenID Connect resuelva las bajas de empleados. La decisión de compra abarca más que el protocolo de la pantalla de acceso.

Imagina que un reclutador deja la empresa. Su cuenta se desactiva en el directorio. También tiene una pestaña del ATS abierta, un token utilizado por un script de elaboración de informes y un asistente conectado al espacio de contratación. Un nuevo inicio de sesión puede fallar mientras esas otras vías requieren medidas aparte.

Trata ese escenario como una prueba que debes realizar, no como una afirmación sobre un producto concreto. Pide al proveedor que demuestre qué hace su configuración real. Incluye a quienes gestionan los accesos de contratación y a la persona que recibirá las alertas de sincronización fallida; no dejes toda la evaluación en manos de quien instaló el SSO.

Termina la evaluación con una ficha de aceptación breve: los accesos probados, el resultado esperado, el resultado observado y las excepciones aceptadas. El departamento de compras y quien gestione las futuras bajas tendrán algo más preciso que «compatible con SSO».

## Distingue inicio de sesión, aprovisionamiento y acceso a la aplicación

La autenticación, la gestión de miembros y la revocación responden a preguntas distintas. Averigua cómo las relaciona el proveedor en la configuración que vas a contratar.

| Responsabilidad | Pregunta que debes plantear |
|---|---|
| Autenticación | ¿Cómo determina la aplicación quién inicia sesión? |
| Aprovisionamiento | ¿Cómo se crean, modifican y eliminan las pertenencias al espacio de trabajo? |
| Autorización | ¿Qué puede leer o modificar esa persona ahora mismo? |
| Gestión de sesiones | ¿Qué ocurre con un navegador que ya tiene la sesión iniciada? |
| Revocación de credenciales | ¿Qué ocurre con los tokens, los clientes conectados y las conexiones en tiempo real? |

[OpenID Connect Core](https://openid.net/specs/openid-connect-core-1_0.html) define la autenticación sobre OAuth 2.0 y las declaraciones de identidad del usuario. Esas funciones no definen por sí solas todo el procedimiento de baja de tu empresa.

Las [instrucciones de Microsoft para revocar accesos](https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access) aclaran dónde empieza la responsabilidad de la aplicación. Una aplicación puede emitir su propio token de sesión y gestionar sus propias autorizaciones. Desactivar la identidad en Microsoft Entra no da a Entra control directo sobre esa sesión. Los accesos existentes dependen del comportamiento y la configuración de la aplicación.

El aprovisionamiento exige la misma atención. SCIM, un estándar para intercambiar información de gestión de identidades, incluye un atributo `active`. Su [esquema básico](https://www.rfc-editor.org/rfc/rfc7643.html#section-4.1.1) deja en manos del proveedor del servicio la definición precisa de su significado. Ver `active=false` en una petición correcta no demuestra, por sí solo, que todas las credenciales de la aplicación hayan dejado de funcionar.

El cierre de sesión también tiene un alcance concreto. La [especificación OpenID Connect Back-Channel Logout](https://openid.net/specs/openid-connect-backchannel-1_0.html), independiente del protocolo principal, describe cómo avisar a las aplicaciones para que borren las sesiones correspondientes. Su implementación es opcional y la especificación suele tratar los tokens de renovación con acceso sin conexión de forma distinta a los vinculados a una sesión. No interpretes «permite cerrar sesión» como «revoca todas las credenciales».

No necesitas saber implementar un protocolo para evaluar estos puntos. Pide una explicación clara de cada fila y una demostración de las vías importantes. Una respuesta útil indica el desencadenante, los tipos de identidad afectados, el plazo previsto y las excepciones.

## Acuerda qué inicia la baja y cuánto puede tardar

Una prueba de baja necesita un evento inicial definido y un alcance de acceso claro. De lo contrario, comprador y proveedor pueden observar la misma demostración y discrepar sobre lo que ha superado la prueba.

Anota primero la configuración: plan del producto, proveedor de identidad, obligatoriedad del SSO, conexión de aprovisionamiento y forma de incorporación del miembro de prueba. Un invitado añadido manualmente puede seguir una vía de baja distinta a la de un empleado aprovisionado desde el directorio. Usa la configuración que vayas a utilizar en la práctica.

Elige después el desencadenante. Desactivar a un usuario en el directorio, quitarle la asignación a una aplicación, retirarlo de un grupo y eliminar su pertenencia local a un espacio de trabajo son acciones distintas. Prueba la que utilizará tu procedimiento de baja. Añade pruebas independientes si la empresa depende de otros desencadenantes.

Acuerda un plazo máximo aceptable para cada vía de acceso importante. Es **tu criterio de aceptación**, no un SLA universal del sector. Pregunta al proveedor a qué se compromete, qué se limita a programar y qué debe hacer un operador si falla el procedimiento habitual.

Por ejemplo, puedes exigir que una persona autorizada retire el acceso directamente en la aplicación en caso de emergencia, sin esperar a una sincronización programada. Describe esa exigencia como un procedimiento con un responsable y los permisos necesarios. No des por hecho que existe porque normalmente un administrador pueda editar usuarios.

Registra por separado tres momentos: cuándo se ejecutó la acción en el directorio, cuándo la aplicación la recibió o procesó y cuándo rechazó una petición protegida. El mensaje de éxito de un conector permite comprobar la entrega. No es la misma prueba que un intento rechazado de leer un registro protegido.

Por último, define qué significa «retirado». Perder el acceso al espacio de tu empresa no tiene por qué implicar perder un espacio personal ajeno a ella ni cerrar sesión en todos los servicios del proveedor. A la inversa, una redirección en el navegador no basta si el token de esa persona todavía permite leer expedientes de candidatos.

## Ejecuta esta prueba de aceptación de bajas con SSO

Usa una identidad temporal y datos ficticios en un espacio de pruebas autorizado por el proveedor. Comprueba que el acceso funciona antes de retirarlo y repite después las mismas operaciones inocuas.

Mantén disponible a otro administrador para recuperar la configuración. No uses la cuenta de un empleado en activo ni datos reales de candidatos para la demostración. La ficha siguiente es nuestra propuesta de prueba, no una certificación ni un informe de pruebas generado por Kit.

### Comprueba la situación inicial

Crea un candidato ficticio u otro registro protegido sin datos sensibles reales. Verifica que el miembro de prueba pueda leerlo por cada vía admitida que vayas a evaluar. Si una operación nunca funcionó antes de la baja, su fallo posterior no te dice nada sobre la revocación.

Usa navegadores separados para el miembro y el administrador. Anota el rol del miembro, el origen de su pertenencia y las asignaciones a grupos que sean pertinentes. Haz un inventario de las credenciales creadas sin copiar sus secretos en la ficha.

Ejecuta después la acción de baja acordada y registra la hora. Mantén abierta la sesión existente del navegador. Hacer la prueba solo en una nueva sesión de navegador dejaría sin comprobar el comportamiento que necesitas examinar.

### Repite las operaciones por las vías de acceso pertinentes

| Vía de acceso | Qué hacer tras el desencadenante de la baja | Qué debes comprobar |
|---|---|---|
| Nuevo inicio de sesión | Prueba el acceso SSO habitual en una sesión nueva de navegador. | El acceso al espacio afectado se deniega antes de que venza el plazo acordado. |
| Navegador ya conectado | Solicita datos protegidos nuevos; prueba una modificación inocua autorizada. | La sesión ya abierta deja de autorizar esas operaciones. |
| Inicio de sesión alternativo | Prueba las vías disponibles con contraseña, clave de acceso o cuenta de terceros para la identidad de prueba. | Otra credencial no permite eludir la política de retirada prevista. |
| Token API | Repite una lectura del registro ficticio que antes hubiera funcionado. | El token antiguo deja de autorizar el acceso al espacio de trabajo. |
| Asistente conectado o cliente OAuth | Repite una petición a un recurso y, si se admite, una renovación de token. | Ni las credenciales existentes ni las renovadas restablecen los permisos retirados. |
| Conexión en tiempo real | Pide al administrador que publique una actualización protegida inocua. | El miembro que se ha dado de baja deja de recibir contenido protegido nuevo. |
| Miembro o invitado añadido manualmente | Repite el procedimiento de baja definido para ese tipo de identidad. | Su vía de baja específica funciona y tiene un responsable. |

Para los clientes OAuth, pide al proveedor que distinga la credencial utilizada para acceder a recursos de cualquier token de renovación que permita obtener otra. La [RFC 7009](https://www.rfc-editor.org/rfc/rfc7009.html) define por separado la revocación de tokens y sus efectos en los tokens relacionados. La ficha de aceptación debe indicar qué credenciales se probaron, no solo que «se probó OAuth».

No confundas una página antigua con un acceso que sigue activo. El texto ya mostrado en una pestaña puede permanecer visible después de que terminen los permisos. Solicita contenido protegido nuevo y comprueba si el servidor lo devuelve. Tampoco aceptes un mensaje meramente visual de «sesión cerrada» si las peticiones protegidas siguen teniendo éxito.

### Conserva pruebas que otro operador pueda interpretar

Para cada vía de acceso, registra la última respuesta autorizada observada y la primera respuesta denegada observada. Las comprobaciones delimitan lo que has observado; no determinan el instante exacto en que cambió el acceso entre comprobaciones. Una ejecución correcta tampoco demuestra cuál sería el mayor retraso posible del proveedor.

Una ficha breve puede incluir estos campos:

| Campo | Qué anotar |
|---|---|
| Configuración | Proveedor, plan, conexión, reglas de autenticación obligatorias y origen de la pertenencia |
| Desencadenante | Acción exacta en el sistema de origen y su marca de tiempo |
| Vía de acceso | Navegador, token, asistente, conexión en tiempo real o excepción |
| Resultado esperado | Operación protegida que debe denegarse y plazo máximo acordado |
| Observación | Última respuesta autorizada, primera respuesta denegada y resultado |
| Prueba documental | Referencia de un evento o petición, sin datos sensibles, que respalde el resultado |
| Seguimiento | Excepción, operador responsable, procedimiento alternativo y próxima revisión |

No incluyas tokens ni contenido privado de las respuestas en la ficha. Quien esté autorizado para revisarla necesita pruebas suficientes para reconstruir el razonamiento, no una nueva colección de credenciales o datos de candidatos.

Si una comprobación falla, indica qué operación sigue funcionando. «El navegador ya conectado puede leer notas nuevas de candidatos después del plazo aceptado» resulta más útil que «El SSO está roto». Así señalas al proveedor el control de acceso concreto que necesitas corregir.

## Registra las excepciones antes de aceptar al proveedor

Las excepciones y la gestión de fallos forman parte de la decisión de aceptación. Una prueba correcta con un empleado gestionado por el directorio no cubre a todas las personas, todas las credenciales ni todas las interrupciones.

Empieza por el origen de la pertenencia. La [documentación de Okta sobre desactivación](https://help.okta.com/oie/en-us/content/topics/users-groups-profiles/usgp-deactivate-user-account.htm) describe los requisitos y las excepciones para dar de baja a usuarios en las aplicaciones. Refuerza una pregunta práctica de compra: ¿qué aplicaciones e identidades gestiona realmente la conexión configurada?

Enumera los miembros invitados manualmente, los colaboradores externos, las cuentas de servicio y los administradores de emergencia, cuando existan. Asigna a cada uno una vía de baja y un responsable. No conviertas una cuenta de emergencia prevista en una excepción invisible: documenta quién la controla y cómo se revisa su uso.

### Prueba expresamente los fallos y la recuperación

Pregunta cómo se entera un operador de que la sincronización del directorio se ha detenido o ha rechazado un cambio. Una marca de tiempo de ayer puede resultar más útil que un indicador verde de «conectado». Solicita al proveedor un método admitido para simular un fallo, o revisa pruebas documentadas de fallos si no existe una simulación segura.

Ejecuta el procedimiento manual alternativo y repite las comprobaciones de acceso pertinentes. Solo es útil si el operador designado puede aplicarlo cuando la integración habitual no está disponible. Confirma qué permisos de administración necesita y dónde se encuentran las instrucciones.

Prueba también una reducción de los permisos del rol y una reincorporación como escenarios independientes. Tras reducir los permisos, comprueba la operación protegida que la persona ya no debería poder realizar. Tras reincorporarla, compara sus permisos con el nuevo rol aprobado. No des por hecho ni que se restauran automáticamente los permisos antiguos ni que se pierden todos los accesos de forma permanente.

### Define qué cubre la decisión

Pide la explicación del proveedor por escrito y guárdala junto con la configuración y los resultados observados. Distingue una capacidad del producto, un compromiso contractual y un resultado medido. Si una excepción pendiente afecta a datos sensibles de candidatos, decide si debes cambiar la configuración, añadir un control viable o aplazar la aceptación.

Denegar la siguiente petición no recupera por sí solo la información que alguien ya ha copiado. Los archivos descargados, las exportaciones y las copias conservadas son otro problema de gestión de datos. Centra esta evaluación en impedir nuevos accesos al espacio de trabajo.

El rigor en la recopilación de pruebas se parece al de [cerrar un informe de filtración de credenciales](/blog/leaked-credential-report-closure-checklist): identificar la vía de acceso afectada y verificar el resultado. En este caso, el objetivo es una baja planificada y la aceptación de un proveedor, no la respuesta a un incidente.

> [!CTA]
> Lleva la ficha a tu próxima evaluación de proveedores. Pide una demostración de baja con la configuración de identidad que vayas a utilizar y guarda los resultados junto a las instrucciones de configuración.

## Aplica la misma lista de comprobación a Kit

Evalúa el producto que vas a configurar, incluidos sus límites. Somete a Kit a la misma prueba de baja que pedirías a otro proveedor.

Kit admite el inicio de sesión único mediante SAML y una conexión independiente de sincronización con el directorio de Google Workspace. La integración consulta Google; no es un punto de acceso SCIM genérico. La tarea de sincronización está programada para ejecutarse cada hora y la página del directorio ofrece **Sincronizar ahora**. Un horario no garantiza un plazo de retirada de acceso: los errores en servicios externos, los retrasos de tareas y las medidas de protección pueden impedir que una ejecución termine correctamente.

La conexión gestiona las pertenencias que ha aprovisionado. No elimina al propietario de la cuenta ni a los miembros invitados manualmente. Desconectar la sincronización detiene las sincronizaciones futuras sin eliminar a los miembros existentes. Anota estos límites en la ficha antes de las pruebas. Consulta [SSO y aprovisionamiento desde el directorio](/docs/single-sign-on-and-provisioning) para conocer la configuración y el comportamiento admitido.

También existe una protección deliberada frente a bajas masivas. Se detiene cualquier sincronización que eliminaría a todos los miembros gestionados por el directorio, incluso si solo hay uno. También se detiene la eliminación de más de la mitad del conjunto gestionado cuando contiene al menos cuatro miembros. Las bajas legítimas bloqueadas por estas protecciones requieren la revisión de un operador y la vía de eliminación manual.

Cuando una baja desde el directorio elimina correctamente una pertenencia, Kit elimina los tokens API de ese usuario para la cuenta, revoca las credenciales OAuth/MCP vinculadas a ella y desconecta las conexiones en tiempo real de ese usuario con la cuenta. El alcance es el espacio de trabajo afectado. No se elimina la identidad global del usuario ni se promete cerrar sus sesiones en todos los demás espacios.

Para las bajas manuales, la documentación de [control de acceso del equipo](/docs/team-access-control) explica **Eliminar de la cuenta** y la revisión de accesos. Para los elementos protegidos de los que esa persona es la única responsable, elige a un sucesor o déjalos expresamente sin asignar antes de la baja. El propietario sigue protegido frente a la eliminación; el SSO obligatorio también conserva una excepción de acceso de emergencia para él. Revisa esa excepción junto con los [ajustes de seguridad de inicio de sesión](/docs/sign-in-security).

Son comportamientos documentados y contrastados con el código fuente, no una afirmación de que este artículo haya realizado una prueba de aceptación real de tu instalación. Tu evaluación debe seguir comprobando las filas aplicables, incluidos los miembros añadidos manualmente y los fallos de sincronización.

Una decisión sobre SSO bien fundada termina con una vía de baja demostrada, plazos registrados y un operador capaz de gestionar excepciones. Usa esta ficha durante una [prueba de Kit](/users/sign_up) o en tu próxima evaluación de proveedores, y prueba la baja con el mismo cuidado que el inicio de sesión.