SSO
Una sesión, varias aplicaciones. Cómo se sostiene esa sesión, qué protocolos la hacen posible y por qué el SSO reduce la cantidad de autenticaciones sin hacerlas más fuertes.
En síntesis
SSO son las siglas de single sign-on, inicio de sesión único. Es el arreglo por el cual una persona se autentica una vez ante un proveedor de identidad y el resto de las aplicaciones aceptan el resultado de esa autenticación en lugar de pedirle credenciales otra vez.
Lo que viaja entre sistemas no es la contraseña. Es una afirmación firmada de que alguien se autenticó, con qué método y cuándo. Esa afirmación es todo el mecanismo.
Cómo se sostiene una sesión que abre varias aplicaciones
Hay tres piezas y conviene nombrarlas por separado, porque la mayoría de los problemas de un SSO viven en la relación entre ellas.
- El proveedor de identidad — el sistema que autentica a la persona y emite la afirmación. Es el único que ve el factor de autenticación.
- La aplicación — el sistema que necesita saber quién entró. No autentica: valida la firma de la afirmación y confía en su contenido.
- La sesión — el período durante el cual esa afirmación se sigue aceptando sin repetir la autenticación. Define cuánto dura la comodidad y cuánto dura el riesgo.
Los estándares que formalizan el intercambio son dos. SAML 2.0 transporta afirmaciones en XML y es el que predomina en entornos corporativos con aplicaciones instaladas hace años. OpenID Connect es una capa de identidad construida sobre OAuth 2.0 que transporta un token de identidad y es el que predomina en aplicaciones web y móviles nuevas.
OAuth 2.0 no es un protocolo de autenticación
Es la confusión más frecuente de la categoría y produce integraciones inseguras, así que conviene resolverla.
OAuth 2.0 resuelve delegación de autorización: le permite a una aplicación acceder a un recurso en nombre de una persona, sin conocer sus credenciales. Responde a la pregunta de qué puede hacer un sistema.
OpenID Connect agrega encima la pieza que falta: un token de identidad que afirma quién es la persona y cómo se autenticó. Responde a la pregunta de quién entró.
Usar un token de acceso de OAuth como si fuera prueba de identidad es tratar un permiso como una credencial. Son cosas distintas y el estándar las separó a propósito.
El SSO reduce la cantidad de autenticaciones, no las fortalece
Un SSO bien implementado mejora la experiencia y mejora el control: hay un solo lugar donde se aplica la política de acceso, un solo lugar donde se revoca y un solo registro de quién entró a qué.
También concentra el riesgo, por definición. Si la autenticación del proveedor de identidad depende de una contraseña reutilizada, ese único punto abre todo el portafolio de aplicaciones. Es lo que convierte a un credential stuffing exitoso contra el proveedor de identidad en un incidente de alcance completo, y no de una aplicación.
De ahí la regla práctica: el SSO se implementa junto con MFA sobre el proveedor de identidad, no en lugar de él. La comodidad la aporta el SSO. La fuerza la aporta el factor.
Dos decisiones más que suelen quedar sin dueño y deciden el resultado:
- Duración de la sesión — una sesión larga es cómoda y también es una ventana larga para quien roba un token. Es el parámetro que la autenticación adaptativa ajusta según el riesgo de la operación en lugar de fijarlo igual para todo.
- Cierre de sesión federado — cerrar sesión en una aplicación no cierra la sesión en el proveedor de identidad ni en las demás, salvo que el cierre federado esté implementado. Es frecuente que no lo esté.
El SSO corporativo y el inicio de sesión con redes sociales no son el mismo arreglo
Los dos usan la misma mecánica y responden a intereses distintos.
En el SSO corporativo, la organización controla el proveedor de identidad. Define la política, revoca el acceso cuando alguien se va y conserva el registro.
En el inicio de sesión con una red social o una cuenta de consumo, el proveedor de identidad es un tercero con sus propias reglas. La organización delega en él la calidad de la autenticación y, con ella, la calidad del vínculo: hereda un dato verificado por otro sin ver cómo se verificó. Para una identidad digital que después tiene que sostener una obligación regulatoria, esa herencia no alcanza.
Preguntas frecuentes
Es el arreglo por el cual una persona se autentica una sola vez ante un proveedor de identidad y varias aplicaciones aceptan esa autenticación sin volver a pedir credenciales. Entre los sistemas no viaja la contraseña, sino una afirmación firmada que dice quién se autenticó, cuándo y con qué método. Los dos estándares que lo formalizan son SAML 2.0, más presente en entornos corporativos establecidos, y OpenID Connect, más presente en aplicaciones web y móviles nuevas.
Depende de qué se compare. Reduce la cantidad de credenciales que una persona tiene que recordar, y con ellas la reutilización y las contraseñas anotadas, y concentra la política de acceso en un solo lugar donde se puede revocar y auditar. A cambio concentra el riesgo: si la autenticación del proveedor de identidad es débil, un solo acceso indebido abre todas las aplicaciones a la vez. Por eso el SSO se implementa junto con MFA sobre el proveedor de identidad, no en su lugar.
No, y responden preguntas distintas. El SSO define cuántas veces se autentica una persona; el MFA define qué tan exigente es cada una de esas autenticaciones. Se combinan bien justamente porque el SSO reduce la frecuencia de la fricción, lo que hace tolerable pedir un factor más fuerte en el único momento en que se pide.
