Tema 2
La identidad digital es la base sobre la que se construyen la autenticación y la autorización. Si esa base está mal modelada, el resto del sistema hereda ambigüedad, permisos inconsistentes, integraciones frágiles y problemas de auditoría. Por eso conviene entender con precisión qué representa una identidad y cómo se relaciona con cuentas, atributos y credenciales.
Cuando una aplicación implementa login, a menudo empieza creando una tabla de usuarios y una contraseña. Ese enfoque puede ser suficiente para un prototipo, pero resulta limitado cuando el sistema crece, debe integrarse con otros servicios o necesita reglas más finas de acceso.
La razón es simple: una identidad digital no es solo un registro con un nombre y un secreto. Es una representación estructurada de un sujeto dentro de un ecosistema. Esa representación incluye atributos, relaciones, estados, pertenencias, credenciales y eventos asociados.
Comprender esta diferencia es clave porque muchas decisiones de seguridad malas empiezan por un modelado deficiente de la identidad. Si el sujeto está mal representado, luego cuesta autenticar bien, autorizar con precisión, federar correctamente y auditar de forma útil.
La identidad digital es la representación de un sujeto en un contexto informático. Permite que sistemas, aplicaciones y servicios reconozcan a ese sujeto, lo distingan de otros y le asocien información relevante.
Esa identidad puede pertenecer a:
La identidad no debe verse como un dato aislado. Es un objeto lógico con continuidad en el tiempo. Aunque cambien el correo, el apellido, el sector o la credencial, la identidad subyacente puede seguir siendo la misma.
Una de las confusiones más comunes es equiparar identidad con cuenta. Una cuenta es un mecanismo operativo para acceder a una aplicación o dominio concreto. La identidad, en cambio, es el concepto más amplio que agrupa y explica a esas cuentas.
Por ejemplo, una persona puede tener:
Todas esas cuentas pueden corresponder a una sola identidad organizacional. Si la empresa trata cada cuenta de forma aislada, pierde consistencia. Si en cambio modela una identidad principal y deriva cuentas asociadas, puede automatizar altas, bajas, cambios y revisiones de acceso.
| Concepto | Qué representa | Ejemplo |
|---|---|---|
| Identidad | El sujeto lógico en el ecosistema | Empleado Diego Moisset en la organización |
| Cuenta | Instancia de acceso en un sistema específico | `dmoisset` en la intranet |
| Sesión | Estado temporal tras autenticación exitosa | Sesión web activa en un navegador |
| Credencial | Prueba usada para autenticar | Contraseña, passkey o certificado |
Una identidad digital suele estar formada por varias piezas. No todos los sistemas necesitan el mismo nivel de detalle, pero conviene conocer los componentes más comunes.
Esta estructura permite tratar la identidad como una entidad gobernable, no solo como un dato de autenticación.
Cuando se habla de identidad, muchos piensan exclusivamente en personas. Sin embargo, los sistemas modernos están llenos de identidades no humanas: servicios, workloads, cuentas técnicas, procesos automáticos, agentes de integración y dispositivos.
Estas identidades suelen ser especialmente sensibles porque operan sin interacción humana directa y, en muchos casos, con privilegios elevados. Un secreto comprometido de una cuenta técnica puede resultar más dañino que la contraseña de un usuario común.
Es útil separar ambas categorías porque sus necesidades difieren:
Toda identidad necesita al menos un identificador. Ese identificador permite referenciarla de forma única, pero no siempre coincide con el dato que el usuario usa para ingresar.
Conviene distinguir entre:
Separar estos conceptos evita problemas cuando un dato visible cambia. Si el correo electrónico se usa como llave interna y luego cambia por una reestructuración organizacional, pueden aparecer inconsistencias difíciles de corregir. Un identificador interno estable reduce ese riesgo.
Los atributos son propiedades asociadas a una identidad. Pueden servir para mostrar información, tomar decisiones de autorización, segmentar audiencias o alimentar flujos de negocio.
Algunos ejemplos comunes son:
No todos los atributos son igual de confiables ni igual de estables. Algunos son administrados internamente, otros vienen de sistemas maestros y otros son autoreportados por el usuario. Esa diferencia importa porque afecta cuánto puede confiarse en ellos para decisiones sensibles.
No alcanza con almacenar atributos; hay que entender su naturaleza. Un modelo maduro suele distinguir entre varios tipos:
Además, conviene evaluar calidad de datos: quién mantiene el atributo, con qué frecuencia cambia, si tiene formato validado y si existe una fuente autoritativa. Un atributo mal mantenido puede degradar tanto la seguridad como la operación.
Las credenciales son los mecanismos que permiten autenticar una identidad. No forman la identidad en sí misma, pero están asociadas a ella. Una misma identidad puede tener varias credenciales válidas según el canal y el contexto.
Ejemplos frecuentes:
Un diseño correcto evita tratar la credencial como el centro de la identidad. Si una persona cambia su contraseña o registra una passkey nueva, su identidad sigue siendo la misma. Cambia el mecanismo de prueba, no el sujeto.
Una identidad no solo existe: también tiene estados. Esos estados condicionan si puede autenticarse, qué flujos de verificación requiere o si sus permisos deben quedar temporalmente suspendidos.
| Estado | Significado | Implicancia típica |
|---|---|---|
| Pendiente | La identidad fue creada pero aún no completó validaciones | Acceso parcial o nulo |
| Activa | La identidad está habilitada para operar | Puede autenticarse según políticas vigentes |
| Bloqueada | Se detectó riesgo, abuso o incidente | Se impide autenticación o se requiere revisión |
| Suspendida | El acceso se pausa por una razón operativa o administrativa | Se mantiene la identidad pero no se habilita uso |
| Revocada o de baja | La identidad deja de estar autorizada en el ecosistema | Se retiran credenciales, sesiones y permisos |
Separar claramente el estado de la identidad, el estado de la cuenta y el estado de la credencial evita comportamientos confusos. Una cuenta puede estar bloqueada sin que la identidad se elimine. Una credencial puede revocarse sin dar de baja a la identidad.
En muchos sistemas la identidad no se entiende de forma aislada, sino en relación con otras identidades o estructuras. Estas relaciones suelen influir en autorización y gobernanza.
Estas relaciones son importantes porque gran parte de la autorización moderna deriva de contexto y pertenencia, no solo de permisos asignados uno por uno.
En ecosistemas grandes, la identidad suele originarse o enriquecerse desde múltiples fuentes: recursos humanos, CRM, directorios corporativos, plataformas académicas, sistemas de clientes o proveedores externos.
Esto obliga a responder una pregunta crítica: ¿cuál es la fuente autoritativa de cada dato? Si varias aplicaciones actualizan el mismo atributo sin criterio, aparecen conflictos y errores de sincronización.
Un enfoque maduro define:
Supongamos una empresa donde Recursos Humanos crea una nueva alta. A partir de ese evento, el sistema IAM genera una identidad organizacional con un identificador interno único y atributos como nombre, sector, fecha de ingreso, jefe y ubicación.
Luego, distintos sistemas crean cuentas derivadas: correo, VPN, intranet, herramientas de desarrollo y ERP. La autorización puede depender del área y el cargo, mientras que la autenticación puede centralizarse en un proveedor de identidad con MFA.
Si esa persona cambia de sector, la identidad sigue siendo la misma, pero se actualizan atributos y se recalculan permisos. Si deja la empresa, no basta con bloquear una cuenta puntual: debe gestionarse la baja coordinada de credenciales, sesiones y accesos relacionados.
Ahora pensemos en un microservicio que consume una API interna. Ese servicio también necesita identidad. Puede tener un identificador de cliente, un certificado, scopes específicos y políticas que definan qué endpoints puede invocar.
A diferencia de una identidad humana, aquí no hay recuperación de contraseña ni experiencia interactiva. Lo importante es el ciclo de vida del secreto, la rotación automatizada, la minimización de privilegios y la trazabilidad de quién es dueño operativo de esa identidad técnica.
Este ejemplo demuestra por qué identidad digital no debe reducirse a “usuarios con login”. Si el modelo mental queda limitado a personas, se diseña mal gran parte del acceso entre sistemas.
Estos errores suelen parecer menores al inicio, pero luego bloquean la adopción de SSO, MFA, federación, automatización de permisos y auditoría adecuada.
La identidad digital es la capa estructural sobre la que se apoya todo el control de acceso. Si esa capa está bien definida, el sistema puede autenticar mejor, autorizar con más precisión y administrar cambios sin perder consistencia. Si está mal resuelta, cada nueva integración o política de seguridad se vuelve más costosa y más propensa a errores.
En el próximo tema distinguiremos con mayor precisión autenticación, autorización, accounting e identidad, para evitar confusiones conceptuales que suelen trasladarse al diseño técnico.