## Fondo Comencé a construir Logto porque noté que la Gestión de Identidad y Acceso (IAM) se había vuelto cada vez más compleja y expansiva con el tiempo. El concepto de IAM es incluso lo suficientemente grande como para dar lugar a nuevos conceptos, como WIAM (Workforce IAM) y CIAM (Customer IAM). Aunque WIAM y CIAM comparten la misma base, tienen casos de uso distintos: WIAM se utiliza típicamente para usuarios internos, mientras que CIAM se utiliza para clientes externos. Algunos ejemplos: - **WIAM** Tu empresa tiene un sistema de identidad unificado para empleados, por lo tanto todos pueden usar la misma cuenta para acceder a los recursos de la empresa, como suscripciones de software, servicios de computación en la nube, etc. - **CIAM** Tu librería en línea requiere un sistema de identidad de usuario para clientes y vendedores. La experiencia de inicio de sesión es una parte crítica del proceso de incorporación, ya que se encuentra en la parte superior del embudo de conversión. Logto comenzó con el CIAM por varias razones (tendremos otro artículo hablando sobre esto). Durante el desarrollo, nos dimos cuenta de que sería beneficioso construir un entendimiento unificado en todo el equipo antes de llevar nuestro producto al siguiente nivel. Esperamos que esto también te ayude a obtener una mejor comprensión del panorama del IAM. ¡Vamos a empezar! ## Los fundamentos del CIAM Independientemente de sus diferencias, WIAM y CIAM tienen la misma base: autenticación y autorización. Estos dos conceptos están en el núcleo de sus características. En este artículo, nos centraremos en los conceptos fundamentales de CIAM y los problemas que podemos encontrar durante o después del flujo de autenticación. También discutiremos el inicio de sesión único (SSO) y sus escenarios relacionados. ### Autenticación y autorización - Autenticación (AuthN) responde a la pregunta “¿Qué identidad posees?” - Autorización (AuthZ) responde a la pregunta “¿Qué puedes hacer?” > 💡 La autenticación se define inicialmente como "¿Quién eres?". Sin embargo, al hablar de identidades digitales, es más preciso demostrar la autenticación "probando la propiedad de la identidad". (Crédito a [Calm-Card-2424](https://www.reddit.com/r/programming/comments/10uycg0/comment/j7eyhrb/)) Si descubres algo que no encaja en ninguna de estas dos categorías, probablemente no sea esencial para el negocio de identidad. - **Ejemplos de autenticación** - Inicio de sesión con contraseña, inicio de sesión sin contraseña, inicio de sesión social, etc. - Autenticación Máquina a Máquina - **Ejemplos de autorización** - Control de Acceso Basado en Roles - Control de Acceso Basado en Atributos - **Ejemplos de excepciones** - Datos no relacionados con la identidad - Web hooks ### Identidad e Inquilino La identidad normalmente representa a un usuario o una máquina. Tras una autenticación exitosa, se emite un Token de Identidad como una Identidad. En otras palabras, el propósito principal de la autenticación es obtener una Identidad. Un Inquilino es un grupo de identidades: ```mermaid graph TD Tenant --- A[Identity: User 1] Tenant --- B[Identity: User 2] Tenant --- C[Identity: Machine 1] ``` Cuando hablamos de "Multi-inquilino", nos referimos a múltiples instancias de Logto que están aisladas de identidad entre sí. En otras palabras, múltiples instancias de Logto. ```mermaid graph TD T1[Tenant 1] --- A[Identity: User 1] T2[Tenant 2] --- B[Identity: User 1] T2[Tenant 2] --- C[Identity: Machine 1] subgraph IS2[Identity system 2] T2 B C end subgraph IS1[Identity system 1] T1 A end ``` Nota que tiene dos sistemas de identidad **aislados**, es decir, no puedes usar la Identidad del Inquilino 1 en el Inquilino 2, incluso para el mismo identificador (correo electrónico, teléfono, etc.). Es como que tu membresía de Costco no sea válida en Whole Foods. 🧱 En resumen, hay “muros físicos” entre Inquilinos. La definición de "Inquilino" varía entre productos CIAM. Algunos se refieren al término "Organización" en Logto, que se introducirá más adelante. ### Aplicación e Inquilino Al igual que la Identidad, una Aplicación también pertenece a un Inquilino. Varias cosas a recordar: - Típicamente no hay relación directa entre una Aplicación y una Identidad. - Una Identidad puede representar una Aplicación, pero no hay conexión directa entre ellas. - Al igual que los usuarios, las aplicaciones también son a nivel de Inquilino. - Las aplicaciones son código, mientras que los usuarios son humanos. - El único propósito de las Aplicaciones es completar la autenticación, es decir, obtener una Identidad. ### Proveedor de Identidad (IdP) y Proveedor de Servicios (SP) La diferencia entre estos dos proveedores es complicada pero importante. - **Proveedor de Identidad** es un servicio que proporciona autenticación (AuthN) y emite identidades. Puedes encontrar varias explicaciones sobre Proveedor de Servicios en Google, aunque pueden no ser satisfactorias. En mi mente, Proveedor de Servicios es un concepto relativo: - **Proveedor de Servicios (o Parte Dependiente en [OIDC](https://openid.net/specs/openid-connect-core-1_0.html))** es un servicio o cliente que inicia la autenticación (AuthN) y solicita el resultado a los Proveedores de Identidad. #### Cuestionario Considera un escenario típico de inicio de sesión social: ```mermaid graph LR A[iOS App] --> |Invoke sign-in| Logto --> |Redirect| GitHub GitHub --> |Return GitHub ID| Logto --> |Return Logto ID| A ``` **❓ ¿Cuántos Proveedores de Servicios y Proveedores de Identidad hay en este gráfico?**

Respuesta

Ambos tienen dos. La App de iOS es un proveedor de servicios para Logto, mientras que Logto es un proveedor de identidad. Logto también es un proveedor de servicios para GitHub, mientras que GitHub es un proveedor de identidad. Por lo tanto, Logto es un Proveedor de Servicios y también un Proveedor de Identidad.

## Estudio de caso: Una empresa de soluciones tecnológicas Eres un CTO de una empresa de soluciones tecnológicas, tienes más de 100 socios comerciales y has entregado más de 300 proyectos. - Cada proyecto es una aplicación web o una aplicación móvil con un servicio de backend. - Para cada socio comercial, deseas reestructurar el sistema de usuarios para proporcionar SSO en sus proyectos. **❓ ¿Cómo puede ayudar Logto (o un producto CIAM)?**

Respuesta

Crea una instancia de Logto para cada socio comercial. Cada socio tiene un Inquilino. Los proyectos se asignan a "Aplicaciones" en Logto. ```mermaid graph TD T1[Tenant 1] --- A[App 1] T1 --- B[App 2] T1 --- C[App 3] T1 --- U1[User 1] T1 --- U2[User 2] T2[Tenant 2] --- D[App 1] T2 --- E[App 2] T2 --- U21[User 1] T2 --- U22[User 2] ``` Logto ofrece una experiencia de inicio de sesión universal (es decir, SSO) dentro de un Inquilino, por lo que los usuarios no requieren iniciar sesión nuevamente al acceder a otra aplicación en el mismo Inquilino si ya han iniciado sesión.

## Lo que hablamos cuando hablamos de SSO Descubrimos que el término “SSO” a menudo causa confusión. Consideramos que el inicio de sesión único (SSO) es un comportamiento, no un concepto de negocio. Por lo tanto, SSO no equivale a “SSO en WIAM”. Cuando decimos “necesita SSO”, puede referirse a uno de los siguientes casos: ### Caso SSO 1 > 👉🏽 En una gran corporación, los empleados utilizan las mismas credenciales para iniciar sesión en todos los recursos con licencia de la empresa (por ejemplo, correo electrónico, IM, servicios en la nube). Es el escenario típico de WIAM. En este caso, solo se involucra un Proveedor de Identidad. No nos importa por ahora. ### Caso SSO 2 > 👉🏽 Los usuarios finales utilizan las mismas credenciales para iniciar sesión en todos los servicios desarrollados por la misma empresa (por ejemplo, GSuite). Logto se centra actualmente en el enfoque descrito anteriormente. Pueden existir múltiples proveedores de identidad externos, como un proveedor de inicio de sesión social de terceros, de manera independiente y sin conexión. A pesar de esto, Logto sigue siendo la única fuente de verdad para las Identidades, simplemente "tomándolas prestadas" de otros proveedores. En este caso, Logto actúa como un Proveedor de Identidad (para las aplicaciones de GSuite) y un Proveedor de Servicios (para los Proveedores de Identidad externos). ### Caso SSO 3 > 👉🏽 Los usuarios finales solo pueden usar el Proveedor de Identidad específico dentro del dominio del correo electrónico correspondiente para completar la autenticación. Por ejemplo, iniciar sesión en Figma con Google Workspace. Este es el caso de uso más común para SSO en CIAM. Vamos a echar un vistazo más de cerca. Si queremos iniciar sesión en Figma usando nuestro correo @silverhand.io, podemos usar el inicio de sesión Social o SSO. Las figuras siguientes ilustran la diferencia entre los dos:

En palabras: - Después del inicio de sesión social, los usuarios son libres de establecer una contraseña o cambiar la dirección de correo electrónico en Figma - Después de SSO, los usuarios no pueden establecer una contraseña ni cambiar ninguna información personal, incluida la dirección de correo electrónico, ya que sus Identidades son gestionadas por Google Workspace En este caso, Logto es tanto un Proveedor de Identidad como un Proveedor de Servicios. Parece que SSO es más complejo que un proceso normal de inicio de sesión. ¿Cuáles son los beneficios para el propietario de la identidad? - **Control centralizado:** Mantener la información de identidad y los procesos de autenticación en un solo lugar, y asegurar que la información del usuario esté siempre actualizada. No hay necesidad de agregar y remover licencias en diferentes aplicaciones por cambios. - **Mejora de la experiencia del usuario:** Los propietarios de identidad que requieren SSO son generalmente corporaciones. Sus empleados pueden usar las mismas credenciales y sesión compartida para aplicaciones cruzadas de la empresa, como Figma, Zoom, Slack, etc. - **Seguridad mejorada:** Puedes haber notado que algunas corporaciones requieren métodos específicos de inicio de sesión, como códigos de verificación dinámica. Usar SSO puede asegurar que cada empleado use la misma combinación de métodos de inicio de sesión para acceder a todos los recursos. > 🤔 Tan inteligente como tú, debes haber notado que esto es en realidad **Caso SSO 1** desde la perspectiva de SaaS. Es hora de discutir la "X" en el gráfico de SSO. Esto representa el proceso de Figma conectando el dominio de correo electrónico a un Proveedor de Identidad específico. Pero, ¿cómo funciona? ## Mapeo SSO Dado que la solicitud a menudo proviene de clientes empresariales, nos referimos al proceso de "Caso SSO 3" de la sección anterior como "SSO Empresarial" para mayor claridad. Podemos idear fácilmente una solución ingenua: crear un mapeo entre dominios de correo electrónico y métodos SSO, luego actualizarlo manualmente. La acción del proceso “X” ahora es clara: > 🔍 **Encuentra el método SSO Empresarial mapeado para el dominio de correo electrónico dado** Por lo tanto, si configuras `silverhand.io` como un dominio de correo electrónico válido que se conecta con una URL de SSO de Google Workspace, los usuarios que intenten iniciar sesión con un correo @silverhand.io serán redirigidos a la página de inicio de sesión correspondiente de Google Workspace, en lugar de ser procesados en el lugar. Cuando solo tienes unas pocas docenas de clientes que necesitan SSO Empresarial, administrar el mapeo manualmente está bien. Sin embargo, hay más consideraciones que tener en cuenta: 1. _¿Qué pasa si hay cientos o miles de clientes de SSO Empresarial?_ 2. _¿Cuál es la relación entre “usuarios normales” y “usuarios de SSO Empresarial”?_ 3. _¿Se deben aislar los datos entre diferentes clientes de SSO Empresarial?_ 4. _¿Hay necesidad de proporcionar un tablero para que los administradores de SSO Empresarial vean usuarios activos, registros de auditoría, etc.?_ 5. _¿Cómo se pueden desactivar automáticamente las cuentas cuando un usuario es eliminado del Proveedor de Identidad de SSO Empresarial?_ Y muchas más. Dado que casi todos los SSO Empresariales están basados en dominios de correo electrónico, podemos encontrar rápidamente una mejor solución: - Si el usuario puede probar la propiedad de ese dominio, pueden configurar el SSO empresarial de ese dominio de manera autosuficiente. Esta solución aborda las dos primeras preguntas: > _1. ¿Qué pasa si hay cientos o miles de clientes de SSO Empresarial?_ - Pueden configurar el SSO Empresarial de manera autosuficiente. > _2. ¿Cuál es la relación entre “usuarios normales” y “usuarios de SSO Empresarial”?_ - Abrimos todos los posibles métodos de inicio de sesión para usuarios normales, excepto SSO Empresarial; mientras que limitamos el método de inicio de sesión solo a SSO Empresarial para los usuarios que intentan iniciar sesión con los dominios configurados. En cuanto a la tercera pregunta: > _3. ¿Se deben aislar los datos entre diferentes clientes de SSO Empresarial?_ - Sí y no. Es hora de introducir la organización. ## Organización Mencionamos usar dominios de correo electrónico para reconocer el método SSO Empresarial específico a utilizar; en otras palabras, aplicar un tratamiento específico para un lote específico de usuarios. Sin embargo, los requisitos del cliente a menudo son más que solo SSO Empresarial; por ejemplo, las preguntas 4 y 5 en la sección anterior. A lo largo de los años, una modelo maduro ha sido desarrollado por compañías SaaS destacadas para abordar este tipo de problemas: Organizaciones. **Reglas de las organizaciones** 1. Una organización es un grupo de identidades, típicamente más pequeño que un Inquilino. 2. Todas las organizaciones están asociadas con un Inquilino. Puedes ver otros términos, como "Workspace", “Equipo”, o incluso "Inquilino" en el software. Para identificar si es el concepto que estamos discutiendo, simplemente verifica si representa “un grupo de Identidades”. En este artículo, utilizaremos el término "Organización" por consistencia. 🤹🏽‍♀️ En la mayoría de los casos, "un grupo de Identidades" es equivalente a "un grupo de usuarios". Sin embargo, **la misma Identidad puede existir en múltiples Organizaciones**. En Notion, puedes crear y unirte a múltiples workspaces (i.e. Organizaciones) con la misma dirección de correo electrónico y cambiar entre ellas fácilmente. Para Slack, parece ser lo mismo, pero sospechamos que usa diferentes Identidades detrás de escena ya que necesitamos crear una cuenta nueva para cada workspace.

![Slack workspaces](https://uploads.strapi.logto.io/1/slack_workspaces_b4f0bcc978.png) _workspaces de Slack_ ![Notion workspaces](https://uploads.strapi.logto.io/1/notion_workspaces_5bdc2b7e9b.png) _workspaces de Notion_

Notion tiene un “Plan Personal” disponible, que normalmente es una Organización bajo el capó, con el único usuario (tú) dentro. No conocemos la implementación exacta de Notion, pero esta explicación es razonable y alcanzable para nuestro modelo. Cada Organización también tiene un identificador, normalmente denominado como el “dominio de la Organización”. Un “dominio de la Organización” es un identificador interno utilizado para distinguir Organizaciones. Puede diferir del “dominio de correo electrónico”, ya que el primero es gestionado por el Proveedor de Servicios, mientras que el último es generalmente proporcionado por un Proveedor de Identidad externo. Por ejemplo, puedes usar `foo` como el dominio de la Organización en Slack, pero usar `@bar.io` como el dominio de correo electrónico para esta Organización. ### Cuestionario **❓ ¿Puede una aplicación estar asociada con una Organización?**

Respuesta

Sí sí. Como discutimos al principio, una aplicación puede tener una Identidad. ¿Puedes elaborar un escenario de negocio de esto?

## Preguntas restantes > _3. ¿Se deben aislar los datos entre diferentes clientes de SSO Empresarial?_ - **Sí:** Aislar datos de negocio, como mensajes y documentos, al nivel de la Organización. - **No:** Mantener las Identidades independientes, ya que no necesitan estar asociadas con una Organización. - Nota que aquí hay tres entidades distintas involucradas: Identidades, Organizaciones y configuraciones de SSO Empresarial; lo que aumenta notablemente la complejidad. La pregunta en sí no es lo suficientemente específica. > _4. ¿Hay necesidad de proporcionar un tablero para que los administradores de SSO Empresarial vean usuarios activos, registros de auditoría, etc.?_ > > _5. ¿Cómo se puede desactivar automáticamente la cuenta cuando un usuario es eliminado del Proveedor de Identidad de SSO Empresarial?_ - Estas demandas están más orientadas al negocio y se pueden implementar al nivel de la Organización. Las dejaremos abiertas aquí. ## Notas de cierre Hemos introducido varios conceptos: Autenticación (AuthN), Autorización (AuthZ), Identidad, Inquilino, Aplicación, Proveedor de Identidad (IdP), Proveedor de Servicios (SP), Inicio de sesión único (SSO), y SSO Empresarial (Organización). Puede tomar algún tiempo para entenderlos todos. Mientras escribía este artículo, noté que interesante, los planes más costosos de los servicios en línea a menudo incluyen características exclusivas relacionadas con la autorización, que no se menciona en absoluto en este artículo. Ya puedes tener algunas preguntas sobre la autorización, tales como: - ¿Cómo podemos asignar permisos a un usuario y verificarlos? - ¿Qué modelo de autorización debo usar? - ¿Cuál es la mejor práctica para aplicar un modelo de autorización? 🔥 Tómate un descanso, ¡y nos vemos en CIAM 102!