El inicio de sesión único (SSO) permite a los usuarios autenticarse una sola vez con un proveedor de identidad (IdP) centralizado y acceder a múltiples aplicaciones sin tener que volver a ingresar sus credenciales. El SSO elimina la fatiga de contraseñas al trasladar la responsabilidad de la autenticación de las aplicaciones individuales a una autoridad central que mantiene el estado de autenticación.

Cuando se autentica con su red corporativa y accede inmediatamente a Slack, GitHub o una base de conocimientos interna sin tener que volver a ingresar las contraseñas de cada aplicación, está experimentando el funcionamiento del SSO tal como fue diseñado.

La implementación del SSO ofrece beneficios inmediatos y cuantificables tanto para los equipos de seguridad como para los de desarrollo, puesto que centraliza el control y estandariza la experiencia de autenticación.

Centralización de la seguridad y el cumplimiento

• Reducción de la superficie de ataque. Al centralizar la autenticación en un único evento de autenticación principal, se reduce el número de credenciales que los usuarios gestionan activamente en todo el ecosistema, lo que ayuda a minimizar la superficie de ataque general y el potencial de vulneración.
• Implementación uniforme de políticas. El SSO ayuda a implementar políticas de autenticación sólidas, incluida la autenticación multifactor (MFA), en el IdP. Esto elimina la necesidad de implementar medidas redundantes en decenas de sistemas.
• Auditorías más sencillas. Los registros de autenticación centralizados agilizan la creación de registros de auditoría e informes de cumplimiento, lo que proporciona a los equipos de seguridad una única fuente de verdad para el acceso de los usuarios en todo el ecosistema de aplicaciones.

Mejora de la velocidad y la experiencia de usuario (UX)

• Erradicación de la redundancia. Para los equipos de desarrollo, el SSO elimina la necesidad de implementar y mantener la lógica de autenticación en cada aplicación nueva, lo que permite a los desarrolladores centrarse en las funciones principales.
• Reducción de la sobrecarga de soporte. Adoptar el SSO minimiza el volumen de solicitudes de la mesa de ayuda para restablecimientos de contraseñas y bloqueos de cuentas, lo que permite a los equipos de soporte centrarse en problemas más importantes.
• Aceleración del aprovisionamiento. La incorporación y el desaprovisionamiento de usuarios se simplifican, ya que el acceso a múltiples sistemas se concede o se revoca mediante una única acción dentro del sistema de identidad centralizado.

El SSO funciona mediante una serie de redireccionamientos seguros basados en sesiones, que se apoya en una relación de confianza criptográfica entre una aplicación (el proveedor de servicios o SP) y el IdP.

Flujo de SSO principal

1. Solicitud inicial. Un usuario intenta acceder a una aplicación protegida (SP). El SP, al detectar la solicitud no autenticada, redirige el navegador del usuario al extremo de inicio de sesión del IdP.
2. Autenticación y sesión con el IdP. El usuario se autentica con el IdP mediante un método preferido (como una contraseña, una clave de acceso o datos biométricos). El IdP valida la identidad, establece una sesión autenticada y almacena un identificador de sesión seguro (normalmente, en una cookie HttpOnly con indicadores Secure y SameSite).
3. Emisión de tokens. El IdP redirige al usuario de vuelta al SP con un artefacto de seguridad adaptado a esa aplicación.

• En el caso de Security Assertion Markup Language (SAML) 2.0, especificado por OASIS, este artefacto es una afirmación XML firmada que contiene información de identidad del usuario.
• En el caso de OpenID Connect (OIDC), tal como lo especifica OpenID Foundation, esto implica el intercambio de un código de autorización por un token de ID y un token de acceso, junto con un token de actualización opcional, según el tipo de cliente y la configuración del ámbito. Para obtener más información sobre esta distinción, consulte Autenticación vs. autorización.

4. Acceso concedido. El SP valida la afirmación o el token comprobando la información de firma, fecha de caducidad (exp), fecha de inicio de validez (nbf), emisor (iss) y público (aud), y establece una sesión local para el usuario.

Acceso posterior sin interrupciones

Cuando el mismo usuario, dentro de la misma sesión del navegador, accede a una segunda aplicación que confía en el mismo IdP:

1. La segunda aplicación detecta la solicitud no autenticada y redirige al usuario al IdP.
2. El IdP detecta inmediatamente la sesión autenticada actual a través de su cookie de sesión.
3. El IdP emite un nuevo token de seguridad específico para la aplicación sin pedir al usuario que vuelva a autenticarse.
4. El usuario obtiene acceso sin problemas a la segunda aplicación.

Esta reutilización del evento de autenticación central es la base técnica del SSO.

En la actualidad, el SSO se basa en protocolos estandarizados que rigen el intercambio de datos de identidad y autorización. Seleccionar el protocolo correcto (o, a menudo, admitir ambos) es necesario para lograr flexibilidad en la integración.

Protocolo	Formato de token	Caso de uso principal	Nivel de complejidad
SAML 2.0	Afirmaciones XML	Federación B2B empresarial, sistemas heredados	Más detallado; requiere gestión de certificados X.509 para la verificación de firmas y cifrado opcional, lo que incluye la rotación de certificados y la supervisión de caducidad
OIDC	Tokens web JSON (JWT)	Aplicaciones web modernas, móviles y orientadas a API	Más simple, RESTful y más sencillo de usar para desarrolladores

• OIDC es la capa de identidad con tecnología de OAuth 2.0. Utiliza JWT firmados para la información de identidad en los tokens de ID y se alinea de forma nativa con las arquitecturas de API. Para aplicaciones nuevas, orientadas a internet o móviles, OIDC con el flujo de código de autorización y PKCE es la práctica de seguridad de OAuth 2.0 recomendada actualmente.
• SAML 2.0 sigue siendo el estándar predominante para la federación B2B, especialmente durante la integración con infraestructuras de identidad de los clientes (como Active Directory Federation Services, AD FS), ya que suele ser un requisito obligatorio para las grandes empresas.

En un contexto de SaaS B2B, la aplicación suele tener que ser compatible con ambos protocolos, ya que el IdP del cliente define los requisitos de integración.

En SaaS B2B, el SSO multiinquilino requiere que una aplicación (el SP) realice la federación con el IdP independiente de cada organización cliente.

• Configuración específica para cada inquilino. Una aplicación debe almacenar y gestionar de forma segura los metadatos de configuración únicos del IdP (como los certificados de firma de SAML o los secretos de cliente de OIDC) para cada cliente.
• Detección del dominio de origen (HRD). La aplicación debe determinar qué IdP del cliente usar para dirigir la solicitud de autenticación. Esto se suele lograr enrutando la aplicación en función del dominio de correo electrónico del usuario o de un identificador de organización ingresado antes de iniciar sesión.
• Aprovisionamiento justo a tiempo (JIT). El aprovisionamiento JIT crea automáticamente la cuenta local del usuario en la aplicación durante el flujo de autenticación de SSO inicial, de acuerdo con la información que recibe del IdP. Esto elimina el aprovisionamiento manual de cuentas de usuario para usuarios empresariales.
• Autorización posterior a la autenticación. Tras una autenticación de SSO exitosa, una aplicación debe hacer cumplir políticas de autorización, como el control de acceso basado en roles (RBAC), para determinar a qué recursos puede acceder el usuario. El SSO confirma la identidad, y la capa de autorización de la aplicación controla los permisos.

Si bien el SSO centraliza la autenticación, también consolida el riesgo. Los desarrolladores deben asegurarse de que el SP esté protegido contra vulnerabilidades relacionadas con los tokens.

• Validación innegociable de tokens. Cada extremo de API protegido debe realizar una validación de JWT completa. Esto incluye verificar la integridad de la firma, comprobar la información de exp y confirmar la información de iss y aud para garantizar que el token sea auténtico y esté destinado a su aplicación.
• Almacenamiento seguro. Evite almacenar tokens de acceso o de actualización confidenciales en localStorage o sessionStorage, ya que esto aumenta el riesgo de ataques de secuencias de comandos entre sitios (XSS). Para aplicaciones de una sola página, use almacenamiento en memoria con actualización automática. En el caso de aplicaciones web tradicionales, use cookies HttpOnly y Secure con indicadores SameSite.
• PKCE para OIDC. Use siempre el flujo de código de autorización con Proof Key for Code Exchange (PKCE) para todas las aplicaciones basadas en OIDC, incluidas las móviles y web, a fin de mitigar los ataques de interceptación de códigos de autorización.
• Tokens de corta duración. Use tokens de acceso de corta duración (con una duración máxima de 15 a 60 minutos) e implemente la rotación de tokens de actualización. Cada operación de actualización emite un nuevo token e invalida el anterior, lo que permite la detección inmediata del robo de tokens.
• Prevención de fijación de sesiones. Tras validar el token del IdP, el proveedor de servicios debe regenerar inmediatamente su identificador de sesión local para evitar ataques de fijación de sesión. Esto es responsabilidad del SP (no del IdP).

Manejo inseguro de sesiones de SP

Los proveedores de servicios suelen validar correctamente el token del IdP, pero no consiguen proteger la sesión de su propia aplicación. Tras la autenticación con SSO, el SP debe establecer una sesión segura con el tiempo de espera adecuado, protección CSRF e indicadores de cookies seguras.

Políticas de duración de tokens inadecuadas

Aceptar sesiones de IdP de larga duración (más de 24 horas) sin reautenticación genera riesgos. Implemente tiempos de espera de sesión adecuados y use la autenticación escalonada para solicitar la reautenticación antes de realizar acciones de alto riesgo.

Falta de atención a la complejidad del cierre de sesión

El cierre de sesión de SSO requiere coordinación entre el IdP y todos los SP activos. Las implementaciones incompletas dejan sesiones activas en algunas aplicaciones después de cerrar sesión, lo que crea una falsa sensación de seguridad. Implemente un sistema de cierre de sesión centralizado (cierre de sesión único/SLO) o comunique claramente cómo será el comportamiento de la sesión.

Confianza en afirmaciones de IdP sin validación

Los proveedores de servicios deben validar la firma, la fecha de caducidad, el público y la información del emisor de cada token. Omitir la validación porque “proviene de nuestro proveedor de identidad” es una vulnerabilidad que los atacantes pueden aprovechar mediante la falsificación de tokens o ejecutando ataques de repetición.

¿Cómo funciona el SSO con las aplicaciones móviles?

El SSO móvil usa el protocolo OIDC con flujo de código de autorización y PKCE. Requiere el navegador del sistema (ASWebAuthenticationSession en iOS o Custom Tabs en Android) en lugar de vistas web integradas. El navegador del sistema comparte la cookie de sesión del IdP entre las aplicaciones que usan el mismo dominio de autenticación, lo que permite un SSO real. Sin embargo, el comportamiento de uso compartido de sesiones varía según la plataforma y la configuración de privacidad. ASWebAuthenticationSession de iOS crea sesiones efímeras de forma predeterminada, lo que exige a los usuarios activar la persistencia de sesión. Las vistas web incrustadas no pueden acceder al almacén de cookies del sistema y, por lo tanto, interrumpen la experiencia de SSO.

¿El SSO sustituye a la autenticación multifactor (MFA)?

No. El SSO determina dónde se realiza la autenticación (en un IdP central). La MFA determina la solidez de la autenticación. Las organizaciones deberían combinar ambas: aplicar la MFA en el IdP central para que una única autenticación robusta proteja el acceso a todas las aplicaciones conectadas.

¿Cuándo no es correcto implementar el SSO?

La complejidad y los requisitos de infraestructura del SSO suelen superar los beneficios en aplicaciones pequeñas orientadas al consumidor o sitios web de contenido sencillo. Los beneficios del SSO se aprovechan al máximo en entornos empresariales con gestión de TI centralizada, donde los usuarios necesitan un acceso unificado a varios recursos protegidos.

Implementar SSO desde cero es una tarea compleja, especialmente si es compatible con SAML y OIDC. Usar una plataforma de identidad dedicada, como Auth0, puede ayudar a manejar la complejidad del protocolo, la gestión de sesiones y el refuerzo de la seguridad, lo que permite a los desarrolladores centrarse en las funciones principales de las aplicaciones.

Explore nuestra serie de Introducción a la IAM para conocer más temas relacionados con la gestión de identidades y accesos.

Más información