SSO: cómo funciona el acceso único y por qué es clave para la seguridad empresaria

En una empresa se acumulan rápidamente decenas de lugares donde un empleado inicia sesión con su cuenta: correo electrónico, CRM, almacenamiento en la nube, gestor de tareas, Git, base de conocimientos, VPN, sistema de BI, paneles internos y servicios de proveedores. Si cada aplicación tiene su propio usuario y contraseña, los accesos empiezan a vivir separados entre sí. Una contraseña se olvidó desactivar, otra se repitió en varios servicios, otra se guardó en el navegador, y otra solo la conoce un empleado que ya fue despedido.

SSO, o inicio de sesión único, elimina esa fragmentación. El usuario se verifica a través del proveedor corporativo de identidad, y los servicios conectados aceptan el resultado de esa verificación. Las aplicaciones no reciben la contraseña del empleado ni la almacenan. Confían en el sistema que gestiona las cuentas, la autenticación multifactor (MFA), los grupos, las funciones y las políticas de acceso. A continuación explico con más detalle cómo está organizado.

Qué es SSO y en qué se diferencia del inicio de sesión convencional

En la autorización habitual cada aplicación verifica al usuario de forma independiente. El correo tiene su propia base de cuentas, la CRM la suya, el panel interno la suya. El administrador debe crear al usuario por separado, otorgar permisos, activar o desactivar el acceso, y luego no olvidar repetir lo mismo en otros sistemas.

En SSO la verificación la asume el proveedor de identidad. A menudo se le denomina IdP. Puede ser Microsoft Entra ID, Keycloak, Active Directory Federation Services u otro servicio de gestión de cuentas. En este esquema la aplicación se llama proveedor de servicios: no verifica la contraseña, sino que acepta la confirmación firmada por el IdP.

Este enfoque es especialmente importante al despedir a alguien, al cambiar de puesto y al trabajar con proveedores externos. Si la cuenta se desactiva en el proveedor de identidad, la persona pierde el acceso a los servicios conectados. Si un empleado pasa del departamento de ventas al departamento financiero, los permisos se pueden cambiar mediante grupos y roles, y no manualmente en cada aplicación.

SSO no sustituye a un gestor de contraseñas. Un gestor guarda contraseñas distintas y ayuda a no repetirlas. El inicio de sesión único cambia el propio esquema de acceso: el empleado se verifica en un solo lugar y las aplicaciones reciben el resultado de esa verificación. En una arquitectura corporativa razonable estas herramientas funcionan de forma complementaria. SSO protege los servicios de trabajo principales, y el gestor de contraseñas permanece para cuentas poco usadas, accesos de emergencia y sistemas sin soporte de inicio único.

Cómo funciona el inicio de sesión con SSO

Desde fuera el proceso parece sencillo: el empleado abre un servicio y elige iniciar sesión con la cuenta corporativa. Internamente se realizan varias comprobaciones. El servicio envía al usuario al proveedor de identidad, el proveedor verifica la cuenta, la contraseña, el segundo factor, el dispositivo, la dirección IP, el grupo o la función, y después devuelve a la aplicación una respuesta protegida.

1. El usuario abre un servicio corporativo.
2. El servicio detecta que no hay sesión local y redirige al usuario al IdP.
3. El IdP verifica la cuenta y aplica políticas de acceso: MFA, dispositivo, red, función, grupo.
4. Tras la verificación exitosa el IdP emite una respuesta para la aplicación.
5. La aplicación verifica la firma, el tiempo de validez, la URL de retorno y los atributos del usuario.
6. Si todo es correcto, el servicio crea una sesión y abre el acceso.

Detalle importante: la aplicación no recibe la contraseña, sino la confirmación de identidad. En SAML esto es una aserción firmada; en OpenID Connect, un ID token. La respuesta suele incluir el identificador del usuario, la dirección de correo electrónico, el nombre, grupos u otros atributos. Con esa información el servicio decide a quién dejar pasar y qué permisos otorgar.

Los errores en este esquema suelen relacionarse no con SSO en sí, sino con la configuración. Por ejemplo, una URL de retorno mal indicada, la ausencia de verificación de la firma, tokens con una vida demasiado larga, grupos que no se sincronizan o que después de una migración queda activo el inicio por contraseña local. Por eso la implementación de SSO no puede reducirse al mero intercambio de metadatos entre dos sistemas.

SAML, OpenID Connect y OAuth 2.0: dónde suelen confundirse

En solicitudes y contratos a menudo se menciona soporte de OAuth, aunque lo que la empresa necesita es el inicio de sesión de empleados con la cuenta corporativa. OAuth 2.0 en sí resuelve otra tarea: permite que una aplicación obtenga acceso limitado a un recurso en nombre del usuario o servicio. Para el inicio de usuario sobre OAuth 2.0 se utiliza OpenID Connect.

Si la empresa compra un SaaS, la especificación debe ser concreta: se necesita SAML SSO o OpenID Connect para el inicio de los usuarios. De lo contrario se puede obtener una integración para APIs, pero no la autorización adecuada de empleados con la cuenta corporativa.

Qué aporta SSO a la seguridad corporativa

El efecto principal de SSO es la gestión centralizada del acceso. El administrador trabaja con una única cuenta de empleado, no con un conjunto de credenciales dispersas en distintos servicios. Esto acelera la incorporación, los traslados entre departamentos y la revocación de accesos tras un despido.

SSO es especialmente útil para empresas con empleados remotos, proveedores externos y un gran número de servicios en la nube. Pero el inicio único no sustituye otras medidas de protección. Son necesarias la autenticación multifactor, control de administradores, cuentas de emergencia separadas, monitorización de accesos, respaldo del IdP y un procedimiento claro de recuperación.

Dónde SSO puede crear nuevos riesgos

El proveedor de inicio único se convierte en un sistema crítico. Si no está disponible, los usuarios no podrán abrir servicios donde no exista una sesión activa. Si un atacante obtiene acceso a una cuenta administrativa del IdP, podrá cambiar reglas de acceso, añadir aplicaciones, otorgar permisos y eludir las restricciones habituales.

Otro riesgo son los métodos de acceso antiguos. Tras configurar SSO algunos servicios siguen aceptando contraseñas locales. El usuario parece entrar con la cuenta corporativa, pero en la aplicación queda una contraseña separada de la que se olvidaron. En un incidente ese acceso alternativo es fácil de pasar por alto.

Conviene revisar por separado las cuentas de servicio y las claves API. SSO gestiona el acceso de personas, pero no siempre revoca los accesos usados por integraciones, scripts, robots y procesos técnicos. Si un empleado creó una clave API personal para exportar datos, desactivar su cuenta SSO puede no revocar automáticamente esa clave.

• active la autenticación multifactor para los administradores del IdP sin excepciones;
• limite el acceso al panel de administración por roles;
• guarde las cuentas de emergencia por separado y verifíquelas según el reglamento;
• desactive el acceso local después de la migración, si el servicio lo admite;
• revise las claves API, los tokens y las cuentas de servicio al desvincular a empleados.

Qué soluciones considerar en 2026

La elección depende de los servicios ya utilizados y de los requisitos de despliegue. Si la empresa trabaja con Microsoft 365, Teams, SharePoint e infraestructura Windows, normalmente se considera Microsoft Entra ID. Tiene muchas integraciones corporativas listas, autenticación multifactor, acceso condicional y gestión de aplicaciones.

Para infraestructuras propias a menudo se elige Keycloak. Soporta OpenID Connect, OAuth 2.0 y SAML, puede trabajar con LDAP y Active Directory, y admite roles, grupos y proveedores externos de identidad. La ventaja de Keycloak es la flexibilidad y el control sobre el despliegue. La desventaja: el sistema hay que actualizarlo, respaldarlo, monitorizarlo y protegerlo de forma independiente.

En los servicios rusos conviene comprobar el soporte de inicio único según la documentación del proveedor y el plan contratado. En Yandex 360 para empresas SSO se configura mediante SAML 2.0. En Kontur.SSO se describe el inicio en los productos de Kontur a través de proveedores corporativos de autenticación.

Cómo implementar SSO sin errores innecesarios

Conviene empezar por una inventariación. Hay que elaborar una lista de servicios, propietarios, métodos de acceso, administradores locales, cuentas de servicio y claves API. Sin esa tabla es fácil conectar SSO solo para las aplicaciones visibles y olvidar paneles antiguos, cuentas de prueba e integraciones.

1. Reúna la lista de servicios. Indique el propietario, la criticidad, el método de acceso y el soporte de SAML u OpenID Connect.
2. Defina la fuente de usuarios. Los datos deben provenir de un directorio actualizado, LDAP, Active Directory o del sistema de recursos humanos.
3. Configure grupos y roles. Las aplicaciones deben recibir atributos claros sin ajustes manuales tras cada cambio de puesto.
4. Active MFA antes del despliegue masivo. Un inicio único sin segundo factor protege poco frente al phishing y al robo de contraseñas.
5. Realice un piloto. Empiece con un servicio y un grupo pequeño de empleados, verifique el inicio, el cierre de sesión, los roles y el registro de eventos.
6. Bloquee accesos alternativos. Tras la verificación desactive las contraseñas locales, elimine cuentas administrativas sobrantes y revise las claves API.

Después del lanzamiento es necesario revisar periódicamente los permisos. El propietario del servicio debe confirmar quién tiene acceso, qué grupos se usan y qué cuentas ya no son necesarias. Sin esa revisión el inicio único se convierte pronto en una vitrina ordenada sobre un desorden antiguo.

Preguntas frecuentes: cinco preguntas sobre SSO