SSO iniciado por IdP vs SSO iniciado por SP

Terminología#

• Proveedor de Identidad (IdP): El servicio que almacena y autentica identidades de usuario.
• Proveedor de Servicios (SP): Un sitio web o servicio que proporciona servicios a los usuarios.
• Inicio de Sesión Único (SSO): Un servicio de sesión y autenticación de usuario que permite a un usuario utilizar un conjunto de credenciales de inicio de sesión (por ejemplo, nombre y contraseña) para acceder a múltiples aplicaciones.
• SAML: Security Assertion Markup Language es un estándar abierto para intercambiar datos de autenticación y autorización entre partes, en particular, entre un proveedor de identidad y un proveedor de servicios. Es un protocolo comúnmente utilizado para SSO. Una vez que un usuario es autenticado con éxito por el IdP, el IdP envía una aserción SAML al SP, que el SP valida y concede acceso al usuario.
• OIDC: OpenID Connect es un protocolo más moderno y seguro para SSO. Está construido sobre OAuth 2.0 y proporciona una manera de verificar la identidad del usuario basada en la autenticación realizada por el IdP. Una vez que un usuario es autenticado con éxito por el IdP, el IdP envía un token en formato JWT al SP, que el SP valida y concede acceso al usuario.

¿Qué es el SSO iniciado por SP?#

Como su nombre indica, el SSO iniciado por SP es iniciado por el proveedor de servicios. El usuario comienza el proceso de autenticación accediendo a un recurso en el sitio web del SP. Luego, el SP redirige al usuario al IdP para la autenticación. Una vez que el usuario está autenticado, el IdP genera un token (OIDC) o una aserción SAML (SAML) y lo envía de vuelta al SP. El SP valida el token o la aserción y concede acceso al usuario.

1. El usuario visita el sitio web del SP e intenta acceder a un recurso.
2. El usuario hace clic en el botón de inicio de sesión del proveedor SSO (por ejemplo, Google, Azure AD, Okta, etc).
3. El SP redirige al usuario al IdP para la autenticación.
4. El usuario inicia sesión en el IdP.
5. El IdP envía un token o aserción de vuelta al SP.
6. El SP valida el token o aserción y concede acceso al usuario.

¿Qué es el SSO iniciado por IdP?#

A diferencia del SSO iniciado por SP, el SSO iniciado por IdP es iniciado por el proveedor de identidad. El usuario comienza el proceso de autenticación desde el sitio web del IdP. Normalmente, el usuario encontrará una lista de aplicaciones SP compatibles en el portal del IdP. El usuario hace clic en la aplicación SP y es redirigido al sitio web del SP con una identidad preautenticada.

1. El usuario inicia sesión en el IdP.
2. El usuario visita el portal del IdP y selecciona una aplicación SP.
3. El IdP valida la sesión actual del usuario y redirige al usuario al SP con una identidad SSO preautenticada.
4. El SP valida la identidad SSO y concede acceso al usuario.

SSO iniciado por IdP vs SSO iniciado por SP#

Ventajas del SSO iniciado por IdP#

El SSO iniciado por IdP es más adoptado por grandes empresas y organizaciones que dependen de varias aplicaciones o servicios de terceros, como Workday, Salesforce, etc. Proporciona una forma centralizada de gestionar el acceso de usuarios a múltiples aplicaciones y hacer cumplir las autenticaciones SSO. Al habilitar el SSO iniciado por IdP, los empleados pueden acceder directamente a las aplicaciones conectadas desde el portal del IdP sin la necesidad de visitar el sitio web de cada aplicación. Reduciendo el tiempo de incorporación y mejorando la experiencia del usuario.

Desventajas del SSO iniciado por IdP#

El SSO iniciado por IdP conlleva más riesgo en comparación con el SSO iniciado por SP:

1. Falta de contexto de autenticación: Todas las solicitudes de autenticación iniciadas desde el IdP son no solicitadas. Por lo tanto, el SP inicia el proceso de autenticación, potencialmente abriendo la puerta al acceso no autorizado. Existe el riesgo de que la sesión del usuario pueda ser secuestrada. Un actor malicioso podría iniciar el proceso de inicio de sesión para un usuario legítimo sin su conocimiento o consentimiento.

2. Fijación de sesión: Dado que el SP no inicia el proceso de autenticación, la sesión del usuario podría estar fijada a la sesión del IdP. Esto podría llevar a ataques de fijación de sesión donde un atacante podría fijar la sesión del usuario a la sesión del IdP y obtener acceso no autorizado a la cuenta del usuario.

3. Ataques de phishing: El SSO iniciado por IdP podría ser vulnerable a ataques de phishing. Un actor malicioso podría engañar al usuario para que visite un portal falso del IdP y robe las credenciales del usuario. Una vez que el usuario inicia sesión, el atacante podría redirigir al usuario al SP con una identidad preautenticada.

4. Sin garantía en la validación de solicitudes: En un SSO iniciado por SP, normalmente el SP incluirá información de seguridad necesaria en la solicitud al IdP para mantener la integridad de la solicitud. Una vez que el SP recibe la respuesta de autenticación, validará esta información para evitar cualquier ataque CSRF. Por ejemplo, el parámetro state en OIDC y RelayState en SAML. Sin embargo, en el SSO iniciado por IdP, el SP no inicia el proceso de autenticación, por lo que el SP no tiene garantía sobre la validación de la solicitud.

Limitaciones del SSO iniciado por IdP:

El SSO iniciado por IdP no es compatible con OIDC debido a las vulnerabilidades mencionadas anteriormente. OIDC requiere que el SP inicie el proceso de autenticación para asegurar la validez de la solicitud. Incluso en casos donde los usuarios comiencen el proceso de autenticación desde un tercero que no sea el SP, el usuario debería ser dirigido primero al SP para iniciar el proceso de autenticación.

El SSO iniciado por IdP es más común en SSO basado en SAML. El IdP puede generar una aserción SAML sin que el SP inicie el proceso de autenticación. En un SSO iniciado por IdP en SAML, una aserción SAML sin un RequestID y RelayState adecuados podría enviarse directamente a la URL ACS del SP. El SP debería poder manejar esta clase de aserción y conceder acceso al usuario. (Nota: Sin el RequestID y RelayState, el SP no tiene garantía sobre la validez de la solicitud).

Ventajas del SSO iniciado por SP#

En todos los aspectos, el SSO iniciado por SP se considera más seguro y confiable en comparación con el SSO iniciado por IdP. Sin importar el protocolo (OIDC o SAML), asegura que el proceso de autenticación esté vinculado a una sesión de usuario activa y a una solicitud específica iniciada por el SP. Esto reduce el riesgo de ciertos ataques, tales como ataques de repetición y confusión de identidad, proporcionando los siguientes beneficios de seguridad:

1. Vinculación contextual al SP: En el SSO iniciado por SP, el proceso de autenticación comienza con el SP, que establece el contexto de la solicitud. Esto asegura que el usuario esté siendo autenticado específicamente para el SP con el que está interactuando, reduciendo el riesgo de aserciones dirigidas incorrectamente.
2. Reducción de riesgos de solicitudes no solicitadas: El SSO iniciado por SP ayuda a evitar que los atacantes inyecten o usen indebidamente tokens de autenticación o aserciones SAML, ya que el SP solicita explícitamente la autenticación del IdP, validándola contra el estado de la sesión.
3. Gestión más fuerte de la sesión: Los flujos iniciados por SP permiten que el SP tenga un mayor control sobre la creación y validación de sesiones, permitiendo una mejor gestión de sesiones y cumplimiento de seguridad a nivel del SP.

Desventajas del SSO iniciado por SP#

Aunque el SSO iniciado por SP es más seguro y es altamente recomendado en todos los escenarios, debido a los requisitos empresariales y las limitaciones de las aplicaciones de terceros, el SSO iniciado por IdP aún se usa en muchas organizaciones.

• Experiencia de usuario: El SSO iniciado por SP requiere que el usuario visite el sitio web del SP para iniciar el proceso de autenticación. Esto puede ser engorroso para los usuarios que quieren acceder a múltiples aplicaciones desde el portal del IdP. Especialmente para aquellas aplicaciones SaaS de empresa que son más comúnmente accedidas desde el portal del IdP.
• Complejidad: El SSO iniciado por SP requiere configuraciones adicionales en el lado del SP para manejar las solicitudes de autenticación. Esto puede ser complejo de configurar y mantener. Para sistemas heredados, puede requerir un esfuerzo extra integrar el SSO iniciado por SP.

Conclusión#

Tanto el SSO iniciado por IdP como el SSO iniciado por SP tienen sus casos de uso, pero el SSO iniciado por SP es fuertemente recomendado en el mundo actual, donde la privacidad de los datos y la ciberseguridad son más importantes que nunca. Ofrece mejor seguridad asegurando que las solicitudes de autenticación estén vinculadas a la sesión del Proveedor de Servicios, reduciendo riesgos de solicitudes no solicitadas y proporcionando una gestión más fuerte de la sesión. Sin embargo, el SSO iniciado por IdP sigue siendo necesario para una adopción más amplia y facilidad de acceso, especialmente en entornos donde la conveniencia del usuario y el acceso centralizado son prioridades.

Prueba Logto hoy. Con la solución SSO de Logto, puedes integrar fácilmente tanto SSO iniciado por IdP como por SP para tus aplicaciones y migrar gradualmente a un sistema de autenticación más seguro y confiable.