Saltar al contenido principal

Inicio de sesión único (SSO) - Un login para todas las aplicaciones

Lectura de 2 min aprox.

El inicio de sesión único (SSO: Single Sign-On) es un mecanismo que permite acceder a múltiples servicios y aplicaciones con una sola autenticación. Los usuarios ya no necesitan introducir una contraseña distinta para cada servicio, lo que mejora notablemente la comodidad. Se utiliza ampliamente en los sistemas internos de las empresas y en los servicios en la nube. Cuantos más servicios en la nube utiliza una misma persona en su trabajo, más difícil resulta gestionar una contraseña distinta para cada uno, por lo que resulta necesario concentrar la autenticación en un único punto mediante SSO.

La diferencia entre SSO y OAuth

SSO y OAuth son tecnologías relacionadas, pero resuelven problemas distintos. SSO aporta la comodidad de autenticación de «iniciar sesión en múltiples servicios con una sola autenticación». OAuth aporta la seguridad de autorización de «delegar permisos a una aplicación sin entregar la contraseña». En cuanto a su implementación, el SSO se realiza mediante protocolos como SAML 2.0 y OpenID Connect (OIDC). OIDC añade una capa de autenticación sobre OAuth 2.0, integrando la función de autorización de OAuth con la función de autenticación del SSO. En el SSO empresarial predomina SAML, mientras que en el inicio de sesión social orientado al consumidor predomina OIDC.

Cómo funciona el SSO

En el SSO, un servidor de autenticación central (IdP: Identity Provider) gestiona de forma centralizada la autenticación de los usuarios. Cuando un usuario completa la autenticación en el IdP, se emite un token de autenticación, y cada servicio vinculado verifica este token para conceder el acceso. Entre los IdP representativos se encuentran Okta, Microsoft Entra ID (antes Azure AD) y Google Workspace.

Casos de uso reales

Por ejemplo, cuando se consolida en una plataforma de SSO una organización en la que los sistemas internos y los servicios en la nube tienen cada uno su propia contraseña, el primer cambio visible no suele ser el inicio de sesión diario, sino el trabajo del servicio de asistencia con los restablecimientos de contraseña. Como la creación de cuentas al incorporarse y su desactivación al salir también se concentran en el lado del IdP, resulta mucho menos probable que la cuenta de alguien que se marcha quede olvidada en un servicio concreto. Por otro lado, si quedan herramientas de trabajo que no admiten SSO, el beneficio sigue siendo parcial. El resultado depende en gran medida de si se hizo un inventario previo de qué servicios pueden quedar cubiertos.

El flujo del SSO

Acceder al servicio A
Redirigir al IdP
Autenticarse en el IdP
Emitir un token
Acceso posible a los servicios A / B / C

Riesgos y contramedidas en la práctica

El SSO es cómodo, pero conlleva el riesgo de convertirse en un «punto único de fallo». Si las credenciales del SSO se filtran, todos los servicios vinculados se ven afectados. Para mitigar este riesgo, configura una contraseña aleatoria especialmente fuerte para la cuenta de SSO y habilita siempre la autenticación multifactor. Un error frecuente en la práctica es pensar que «la gestión de contraseñas ya no es necesaria» solo porque se ha implantado el SSO. Siguen existiendo servicios que no admiten SSO, y estos requieren sus propias contraseñas fuertes e individuales. También es importante tener en cuenta el riesgo de no poder iniciar sesión en ningún servicio cuando el proveedor de SSO sufre una interrupción, y asegurar de antemano un método de acceso alternativo para emergencias.

Términos relacionados

¿Te resultó útil este artículo?