Definición rápida
Single Sign-On (SSO) es un sistema de autenticación que permite a un usuario acceder a múltiples aplicaciones o servicios con una sola sesión de inicio de sesión, sin necesidad de autenticarse nuevamente en cada sistema.
¿Qué es Single Sign-On (SSO)?
El SSO resuelve uno de los dolores más comunes del trabajo digital: gestionar docenas de contraseñas para docenas de aplicaciones. Sin SSO, un empleado de una empresa media tiene que recordar (o guardar en un password manager) credenciales para Slack, Notion, Jira, GitHub, Google Workspace, Salesforce, y decenas de otras herramientas.
Con SSO, el empleado inicia sesión una sola vez —generalmente en el Identity Provider (IdP) corporativo como Okta, Microsoft Azure AD o Google Workspace— y automáticamente tiene acceso a todas las aplicaciones configuradas, sin volver a ingresar usuario y contraseña.
Para las empresas, SSO no es solo comodidad —es seguridad. Cuando un empleado es despedido, revocar el acceso al SSO revoca automáticamente el acceso a todas las aplicaciones conectadas. Sin SSO, hay que darse de baja manualmente en cada sistema, y frecuentemente se olvidan algunas.
¿Cómo funciona SSO en la práctica?
El SSO se implementa principalmente con dos protocolos:
- SAML 2.0 (Security Assertion Markup Language): El protocolo enterprise clásico. Usa XML. Es el estándar para integraciones entre empresas y aplicaciones SaaS enterprise. Funciona así: el usuario intenta acceder a una app → la app redirige al IdP → el usuario se autentica → el IdP envía una «aserción» XML firmada confirmando la identidad → la app permite el acceso.
- OIDC (OpenID Connect) + OAuth 2.0: El protocolo moderno basado en JSON y JWT. Más simple que SAML y más compatible con aplicaciones cloud-native. Es el que usan los botones «Login with Google/GitHub».
El proceso de SSO involucra tres actores:
- Identity Provider (IdP): Okta, Azure AD, Google Workspace, Auth0. Gestiona las identidades y la autenticación.
- Service Provider (SP): La aplicación a la que el usuario quiere acceder (Slack, Salesforce, GitHub).
- Usuario: El empleado o cliente que se autentica.
Ejemplos reales en LATAM
Empresas corporativas en Chile, Colombia y México: Las grandes corporaciones LATAM (Falabella, Bancolombia, FEMSA) usan SSO con Microsoft Azure AD para gestionar el acceso de miles de empleados a sus aplicaciones corporativas. Un empleado que ingresa a la empresa recibe acceso configurado en Azure AD, y desde ahí tiene acceso a todas las herramientas.
Startups SaaS B2B en LATAM: Plataformas como Buk (RR.HH. en Chile) y otros SaaS que venden a grandes empresas ofrecen integración SSO como feature enterprise. Los clientes enterprise casi siempre lo requieren como condición para adoptar un nuevo software.
Universidades: Instituciones como la Pontificia Universidad Católica de Chile y la UNAM en México usan SSO para que estudiantes y docentes accedan con una sola credencial a email, sistema de notas, biblioteca digital y otras plataformas académicas.
SSO vs Password Manager
| Característica | SSO | Password Manager |
|---|---|---|
| Gestión centralizada | Sí (por la empresa) | Por usuario individualmente |
| Revocación de acceso | Inmediata y centralizada | Manual por cada app |
| MFA | Una vez, aplica a todo | Por app individualmente |
| Costo | Empresa paga IdP | Usuario paga o gratis |
| Ideal para | Organizaciones con múltiples apps | Uso personal o pequeñas empresas |
Errores comunes con SSO
- SSO sin MFA: Un IdP comprometido sin autenticación multifactor (MFA) compromete automáticamente todas las apps conectadas. SSO siempre debe ir acompañado de MFA.
- No configurar el offboarding: Si cuando alguien sale de la empresa no se desactiva su cuenta en el IdP inmediatamente, sigue teniendo acceso a todas las aplicaciones. El offboarding en el IdP debe ser el primer paso.
- «SSO Tax»: Muchos SaaS cobran un recargo significativo por la integración SSO (el llamado «SSO tax»). Verifica los precios de integración SSO antes de comprometerte a una plataforma.
- Dependencia total del IdP: Si el IdP cae, nadie puede acceder a ninguna aplicación. Tener un proceso de acceso de emergencia (break-glass accounts) es importante para servicios críticos.
Preguntas Frecuentes (FAQ)
¿Cuándo necesita mi startup implementar SSO?
Cuando empiezas a vender a clientes enterprise (más de 200 empleados), ellos típicamente lo requerirán. También cuando tu equipo supera las 20-30 personas, el SSO interno se convierte en una necesidad de seguridad y eficiencia operacional.
¿Cuánto cuesta implementar SSO?
Para ofrecer SSO a tus clientes, puedes usar servicios como Auth0 (desde $240/mes para SAML), Okta CIAM, o Clerk. Para uso interno de tu empresa, Google Workspace ($6-18/usuario/mes) y Microsoft 365 incluyen SSO con Azure AD. Hay también soluciones self-hosted como Keycloak (open source).
¿SSO es lo mismo que LDAP?
No. LDAP (Lightweight Directory Access Protocol) es un protocolo para gestionar directorios de usuarios (ej: Active Directory de Microsoft). SSO es el sistema que usa esos directorios para autenticación única. LDAP puede ser la fuente de verdad de identidades que alimenta un sistema SSO.
