Saltar al contenido principal
(SSO) se produce cuando un usuario inicia sesión en una aplicación y luego queda conectado automáticamente en otras aplicaciones, independientemente de la plataforma, la tecnología o el dominio que esté usando. El usuario inicia sesión una sola vez, de ahí el nombre de la función (inicio de sesión único). Por ejemplo, si inicias sesión en un servicio de Google como Gmail, quedas autenticado automáticamente en YouTube, AdSense, Google Analytics y otras aplicaciones de Google. Del mismo modo, si cierras sesión en Gmail u otras aplicaciones de Google, la sesión se cerrará automáticamente en todas las aplicaciones; esto se conoce como cierre de sesión único. El SSO ofrece una experiencia fluida a los usuarios cuando usan tus aplicaciones y servicios. En lugar de tener que recordar credenciales distintas para cada aplicación o servicio, los usuarios simplemente inician sesión una vez y acceden a toda tu suite de aplicaciones. Cada vez que los usuarios acceden a un dominio que requiere autenticación, se les redirige al dominio de autenticación, donde es posible que se les pida iniciar sesión. Si el usuario ya inició sesión en el dominio de autenticación, se le puede redirigir inmediatamente al dominio original sin volver a iniciar sesión.

​
Cómo funciona

El inicio y el cierre de sesión únicos son posibles mediante sesiones. Un usuario con SSO puede tener hasta tres sesiones diferentes:
  • Sesión local gestionada por la aplicación
  • Sesión del , si SSO está habilitado
  • Sesión del , si el usuario decidió iniciar sesión a través de un (como Google, Facebook o un proveedor de identidad empresarial)
Con SSO, un dominio central realiza la autenticación y luego comparte la sesión con otros dominios. La forma de compartir una sesión puede variar según el protocolo SSO, pero el concepto general es el mismo. Por ejemplo, el dominio de autenticación puede generar un JSON Web Token (JWT) firmado (cifrado con JSON Web Encryption (JWE)), que contiene toda la información necesaria para identificar al usuario en cualquier otro dominio que requiera autenticación. Este token se envía al cliente, pero, como está firmado, el cliente no puede modificarlo de ninguna manera. El token puede enviarse al dominio original mediante una redirección y ser utilizado por el dominio de autenticación y cualquier otro dominio para identificar al usuario.

​
SSO con Universal Login

La forma más sencilla y segura de implementar el inicio de sesión único (SSO) con Auth0 es usar Universal Login para la autenticación. De hecho, actualmente el SSO solo es posible en plataformas nativas (como iOS o Android) si la aplicación usa . Las guías de inicio rápido de Swift y Android ofrecen algunos ejemplos de cómo usar Universal Login. Si no puedes usar Universal Login con tu aplicación, consulta lo siguiente para obtener más información sobre la autenticación integrada:
Si usas Passwordless con inicio de sesión único, los parámetros de conexión sms y email no utilizan la sesión existente de Auth0, por lo que se le pedirá al usuario que inicie sesión.

​
SSO en el primer inicio de sesión

Para el SSO con Auth0, el servicio central es el de Auth0. Veamos un ejemplo del flujo de SSO cuando un usuario inicia sesión por primera vez:
  1. Tu aplicación redirige al usuario a la página de inicio de sesión.
  2. Auth0 comprueba si ya existe una cookie de SSO.
  3. Como es la primera vez que el usuario visita la página de inicio de sesión y no existe ninguna cookie de SSO, se le pedirá que inicie sesión con una de las conexiones que hayas configurado.
    Pantalla de inicio de sesión de ejemplo de una aplicación de hojas de horas
  4. Una vez que el usuario haya iniciado sesión, Auth0 establecerá una cookie de SSO y lo redirigirá a tu aplicación, devolviendo un ID Token que contiene información de identidad del usuario.

​
SSO en inicios de sesión sucesivos

Veamos un ejemplo del flujo de SSO cuando un usuario vuelve a tu sitio web en una visita posterior:
  1. Tu aplicación redirige al usuario a la página de inicio de sesión.
  2. Auth0 comprueba si ya existe una cookie de SSO.
  3. Auth0 encuentra la cookie de SSO y, si es necesario, la actualiza. No se muestra ninguna pantalla de inicio de sesión.
  4. Auth0 redirige al usuario a tu aplicación y devuelve un ID Token que contiene información de identidad del usuario.

​
Comprobar el estado de SSO del usuario

Puedes comprobar el estado de SSO de un usuario desde una aplicación llamando al método checkSession del SDK auth0.js, que intentará autenticar al usuario de forma silenciosa dentro de un iframe. El hecho de que la autenticación se complete correctamente o no indica si el usuario tiene una cookie de SSO activa.

​
Protocolos

​
SAML y WS-Federation

Security Assertion Markup Language (SAML) y Web Services Federation () son protocolos ampliamente utilizados en implementaciones de SSO. Tanto SAML como WS-Fed intercambian datos de autorización y autenticación en formato XML; los elementos principales de este intercambio son el usuario, el proveedor de identidad y el proveedor de servicios. Con SAML o WS-Fed:
  1. Un usuario solicita un recurso al proveedor de servicios.
  2. El proveedor de servicios consulta al proveedor de identidad para determinar si el usuario debe tener acceso al recurso.
  3. El proveedor de identidad verifica la identidad del usuario y, si es válida, le confirma al proveedor de servicios que el usuario debe tener acceso.

​
OpenID Connect

Connect (OIDC) es un protocolo de autenticación que se usa habitualmente en implementaciones de SSO orientadas a consumidores. El protocolo OIDC gestiona la autenticación mediante y un proveedor de identidad central. Con OIDC:
  1. Un usuario solicita acceso a una aplicación.
  2. La aplicación redirige al usuario al proveedor de identidad para autenticarse.
  3. El proveedor de identidad verifica al usuario y, si la verificación es correcta, le pide que conceda a la aplicación acceso a sus datos.
  4. Si se concede el acceso, el proveedor de identidad genera un ID Token, que contiene información sobre la identidad del usuario que la aplicación puede utilizar.
  5. El proveedor de identidad devuelve al usuario a la aplicación.

​
AD/LDAP

Lightweight Directory Access Protocol (LDAP) es un protocolo de aplicación que se utiliza para acceder a un directorio de credenciales que puede compartirse entre varias aplicaciones; se usa habitualmente en intranets. Cuando se combina con Active Directory (AD), LDAP proporciona una ubicación centralizada para la identidad de los usuarios, por lo que la aplicación realiza una solicitud de autenticación al servidor LDAP/AD. El protocolo LDAP intercambia información en el formato LDAP Data Interchange Format (LDIF).

​
SSO iniciado por el proveedor de servicios

Para el SSO iniciado por el proveedor de servicios, Auth0 es el proveedor de servicios (SP) del SSO. Cuando un usuario inicia sesión en una aplicación:
  1. La aplicación le presenta al usuario uno o varios proveedores de identidad externos.
  2. El usuario selecciona un proveedor de identidad para autenticarse e inicia sesión.
  3. Tras autenticarse correctamente, el usuario vuelve a la aplicación.
En Auth0, el SSO iniciado por el SP se gestiona mediante conexiones.

​
SSO iniciado por el proveedor de identidad

En el caso del SSO iniciado por el proveedor de identidad, un proveedor de identidad (IdP) externo actúa como proveedor de SSO. Cuando un usuario inicia sesión en una aplicación:
  1. La aplicación redirige al usuario a un proveedor de identidad.
  2. El proveedor de identidad externo lleva a cabo la autenticación y la autorización.
  3. Tras autenticarse correctamente, el usuario regresa a la aplicación.
Al planificar una implementación de SSO iniciada por IdP, puede optar por usar la extensión SSO Dashboard de Auth0, que le permite crear un panel con varias aplicaciones empresariales que pueden habilitarse para SSO. Después, este panel se presenta a sus usuarios para que inicien sesión.

​
Casos de uso

​
De empresa a empresa

Para escenarios de empresa a empresa (B2B), el SSO puede simplificar la preparación de su aplicación para su uso en entornos empresariales. Con Auth0, sus aplicaciones pueden admitir escenarios comunes de federación empresarial, como Active Directory (AD), Lightweight Directory Access Protocol (LDAP), Ping o Security Assertion Markup Language (SAML). Esto permite que sus socios y clientes empresariales inicien sesión con las tecnologías de identidad empresarial que prefieran.

​
CIAM de empresa a consumidor

Para escenarios de Business to Consumer (B2C) o de Customer Identity Access Management (CIAM), el SSO puede proporcionar acceso sin fricciones a sus aplicaciones o servicios. Puede permitir que los clientes se autentiquen mediante proveedores populares de identidad social, como Google, Facebook, LinkedIn, X y Microsoft, en lugar de exigirles que creen otra cuenta.