¿Qué es la identidad digital?

Una cajera que no comprueba nada

Imagina que entras en tu sucursal bancaria un lunes a las diez de la mañana. La cajera no te reconoce, tu nombre no aparece en su pantalla y aun así te entrega 500 dólares en efectivo porque dijiste que eras tú. Suena absurdo. Pero esa misma escena, trasladada al mundo digital, ocurre a diario en aplicaciones mal diseñadas: alguien escribe un correo y una contraseña, y el sistema se fía sin comprobar nada más.

La identidad digital es lo que evita ese absurdo. Cada decisión de seguridad, qué puedes ver, qué puedes cambiar, qué puedes pagar, se toma sobre una identidad. Si esa base es débil, todo lo que se construye encima también lo es. Por eso un concepto que parece introductorio es en realidad el más importante de todo el programa.

Este artículo cubre tres cosas sobre las que descansa todo lo demás. Primero, qué es de verdad una identidad digital. Después, la diferencia entre cuatro palabras que se usan muchas veces como si significaran lo mismo: sujeto, identidad, cuenta y perfil. Y por último, las piezas que hacen que una identidad funcione en la práctica: atributos, claims, derechos y credenciales. Los tipos modernos de identidad, personas, dispositivos, cargas de trabajo y agentes de IA, y la idea de la identidad como “nuevo perímetro” tienen su propio artículo, el siguiente de este bloque.

Qué es de verdad una identidad digital

La definición formal viene del estándar NIST SP 800-63: una identidad digital es la representación única de un sujeto en una transacción en línea.

Suena más complicado de lo que es. Dicho de forma sencilla, una identidad digital es lo que un sistema sabe de ti para poder decidir qué hacer cuando interactúas con él. Es como tu expediente en la consulta del médico, solo que vive en una base de datos y no en un archivador.

Piensa en tu identidad en el mundo físico. Tienes un documento de identidad con tu foto, tu nombre y tu fecha de nacimiento. Tienes un pasaporte que además lleva los sellos de los países que has visitado. Tienes un carné de conducir que dice qué vehículos puedes manejar y una tarjeta de crédito que demuestra que un banco confía en ti hasta cierto límite. Todos esos documentos representan a la misma persona, tú, pero cada uno te identifica para algo distinto. Ninguno eres tú; cada uno es una representación válida de ti en un contexto concreto. Y nadie te entrega el documento de identidad sin que antes demuestres quién eres, normalmente con otro documento o con tu huella en el registro.

La identidad digital funciona igual, solo que los documentos viven en bases de datos y las pruebas viajan por conexiones cifradas. Tu identidad en una app fintech es como tu documento de identidad dentro del sistema de esa fintech. Tu identidad en el correo del trabajo es como tu credencial de empleado. Tu identidad en un servicio de streaming es como un carné de socio. Todas representan a la misma persona, pero cada una vive en su propio mundo.

En esa definición caben cuatro ideas. Una identidad digital es una representación, no la persona: tú eres una persona, y tu identidad es lo que el sistema sabe de ti. Es única dentro de un contexto: tu identidad en tu banco es única allí, y también la de tu servicio de streaming, pero son dos identidades distintas que apuntan a la misma persona. Es práctica: existe para que un sistema tome decisiones, como si este usuario puede leer este archivo o si este pago debe hacerse. Y lleva asociados atributos, credenciales y derechos; sin ellos, una identidad sería una etiqueta vacía.

Una forma de visualizarlo es un árbol con cuatro ramas. La raíz es la identidad, y cada rama agrupa un tipo de información distinto: los datos que te describen, la prueba de que eres tú, lo que tienes permitido hacer y el momento en el que estás actuando.

Así se ve en la vida real. Cuando Sara abre una cuenta en una app fintech, su identidad digital empieza a existir en ese momento. La fintech no tiene su cara, ni su partida de nacimiento, ni su documento de identidad físico. Lo que tiene es un correo y un teléfono que verificó, una contraseña que ella eligió, un PIN o una huella que registró para pagar, una foto de su documento de identidad que pasó por una verificación de identidad, un nivel de cuenta, básico o premium, que limita lo que puede hacer y, con el tiempo, un historial de inicios de sesión desde su teléfono de siempre. Esa combinación es la identidad digital de Sara en la fintech. Es distinta de su identidad en el banco, en una app de comida a domicilio o en un servicio de streaming, aunque todas representen a la misma Sara.

Sujeto, identidad, cuenta y perfil

En una frase: el sujeto es la cosa real, la identidad es cómo la representa un sistema, la cuenta es el registro técnico donde se guarda esa identidad y el perfil es una vista parcial de la identidad que se muestra en un contexto concreto.

Estas cuatro palabras se usan a menudo como sinónimos. No lo son, y confundirlas está detrás de algunos de los errores de diseño más habituales en los proyectos de IAM.

Sujeto

El sujeto es la entidad real, lo que existe en el mundo y lo que representa la identidad digital. Puede ser una persona, Sara López, de 32 años, que vive en San Salvador. Puede ser un dispositivo, un iPhone con número de serie ABC123. Puede ser un servicio, el microservicio de facturación que corre en Kubernetes. O puede ser un agente de IA, el bot que agenda reuniones en tu calendario. El sujeto vive fuera del sistema digital; es aquello de lo que habla el sistema. Una persona puede tener muchas identidades digitales, una por sistema, y seguir siendo un único sujeto.

Identidad

La identidad es la representación digital del sujeto en un contexto concreto. Cada vez que un sujeto se da de alta en un sistema, nace una identidad nueva. Sara tiene una identidad en su banco, otra en su app fintech, otra en el correo del trabajo y otra en un servicio de streaming. Las cuatro tienen detrás al mismo sujeto, pero son cuatro identidades distintas, cada una con sus propios atributos, credenciales y derechos.

Una buena prueba de que la diferencia ha quedado clara: si Sara se cambia el apellido al casarse, su sujeto no cambia, sigue siendo la misma persona, pero cada una de sus identidades tiene que actualizar el apellido por separado, sistema a sistema. Es la señal más clara de que sujeto e identidad son cosas distintas. Uno es la persona; la otra es lo que cada sistema sabe de ella.

Cuenta

La cuenta es la implementación técnica de una identidad dentro de una aplicación concreta. “Identidad” es un concepto; “cuenta” es la fila en la base de datos del sistema, con un nombre de usuario, el hash de una contraseña, permisos y columnas de auditoría.

Una identidad puede tener varias cuentas. La identidad laboral de Sara puede tener una cuenta en el directorio corporativo, otra en el CRM, otra en la herramienta de chat y otra en el repositorio de código, todas de la misma identidad. La distinción importa mucho en el gobierno de identidades, donde las cuentas huérfanas son cuentas cuya identidad ya no existe, normalmente porque alguien se fue de la empresa y nadie le quitó el acceso a alguna aplicación.

Perfil

El perfil es una vista parcial de una identidad que depende del contexto. Es lo que un sistema decide mostrar en un momento dado. Tu perfil público en una red profesional es distinto de la vista privada que solo ves tú, y los dos son distintos de lo que ven los reclutadores que pagan.

Un perfil cumple dos funciones. Es presentación, cómo te ven los demás, y es minimización de datos, cuántos atributos se exponen en cada interacción. Un buen diseño nunca enseña al mundo más de lo necesario: ni tu fecha de nacimiento al cajero ni tu salario al CRM de marketing.

Sara, de principio a fin

Sara es socióloga, vive en Santa Tecla y tiene 32 años. Esa es la persona, el sujeto. Se descarga su app fintech y, en cuanto confirma su correo y su documento de identidad, nace la identidad “Sara en la fintech”. Tiene atributos (nombre, fecha de nacimiento, teléfono), credenciales (contraseña, PIN, huella) y derechos (clienta básica, puede transferir hasta 500 dólares al día).

En la base de datos de la fintech esa identidad se convierte en tres cuentas: una fila en customers con sus datos personales, otra en auth_credentials con sus credenciales y otra en wallet_accounts con su saldo y sus movimientos. Cuando Sara abre la app, ve su propio perfil: saldo, movimientos recientes, su nombre. Cuando otra persona quiere enviarle dinero y la busca, ve un perfil público mucho más pequeño, solo su nombre y su foto.

Un sujeto, una identidad, tres cuentas, dos perfiles.

Daniel muestra lo mismo desde otro ángulo. Tiene una pequeña tienda de electrónica en San Miguel y cada mañana entra en tres sistemas: una app de chat para empresas donde atiende a sus clientes, un sistema de inventario donde registra la mercadería que le llega y una cuenta de comercio en un procesador de pagos en línea con el que cobra con tarjeta. El sujeto es uno, Daniel. Las identidades son tres, una por sistema. Cada una tiene sus propias cuentas técnicas; la app de chat puede tener una por número de negocio y el procesador de pagos puede separar “comercio” de “facturación”. Los perfiles cambian según quién mire. Sus clientes ven en el chat su foto y su horario, la autoridad tributaria vería sus datos fiscales si lo auditara y sus proveedores ven su límite de crédito.

La pregunta interesante para IAM es qué pasa cuando Daniel cambia de número de teléfono. ¿Se actualiza solo en los tres sistemas? Casi nunca. Mantener todo eso sincronizado es justo el trabajo para el que existe IAM.

Las piezas: atributos, claims, derechos y credenciales

Una identidad que de verdad hace algo está hecha de cuatro piezas: atributos, hechos sobre ella; credenciales, lo que usa para demostrar quién es; derechos, lo que tiene permitido hacer, y claims, afirmaciones firmadas que llevan atributos de un sistema a otro. Estas cuatro son el vocabulario de todos los días en IAM, las palabras que oirás sin parar si trabajas en este campo.

Atributos

Los atributos son hechos sobre la identidad. Si alguna vez has rellenado un formulario de registro, ya sabes lo que son: cada campo era un atributo. Algunos no cambian nunca, como la fecha de nacimiento. Otros cambian despacio, como el apellido o el departamento. Y otros cambian todo el rato, como la ubicación actual o el dispositivo que estás usando. Ejemplos típicos son el nombre y los apellidos, el correo y el teléfono, la fecha de nacimiento, el número de documento o el NIT, el departamento, el jefe y la oficina, el idioma preferido y la fecha del último inicio de sesión.

Los atributos viven en un almacén de identidades, Active Directory, LDAP o la propia base de usuarios de la aplicación, y las aplicaciones los leen para tomar decisiones o personalizar lo que ves. Cuando diseñas un sistema conviene hacerse tres preguntas sobre cada atributo: quién lo escribe, quién lo actualiza y quién lo lee. Casi todos los datos desactualizados de una organización vienen de que nadie respondió a esas preguntas.

Claims

Un claim es una afirmación firmada digitalmente que un emisor hace sobre una identidad y que va dirigida a quien la va a recibir. La palabra clave es firmada: un claim es fiable porque lleva la firma criptográfica del emisor.

Piensa en un amigo común que te dice “esta persona es de fiar; le presté dinero y me lo devolvió”. Te lo crees no porque esa persona te caiga bien, sino porque alguien en quien confías responde por ella. Un claim funciona igual. Si Google firma “este correo es de Sara”, la app que lo recibe se fía porque la firma de Google es muy difícil de falsificar y Google ya está en su lista de fuentes de confianza.

Cuando inicias sesión en otra app con tu cuenta de Google, lo que recibe la app es un conjunto de claims firmados por Google, algo así:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890abcdef",
  "email": "sara@gmail.com",
  "email_verified": true,
  "name": "Sara López",
  "iat": 1714579200,
  "exp": 1714582800
}

iss es el emisor, aquí Google. sub es el identificador único de Sara dentro de Google. email_verified: true es el claim que la app quería de verdad, la confirmación de que el correo es realmente suyo. iat y exp indican cuándo se emitió el token y cuándo caduca. La app no necesita preguntarle a Google si el correo es de Sara; basta con la firma de Google sobre el token, un JWT.

Así que un atributo y un claim no son lo mismo. Un atributo es un dato que vive en un directorio. Un claim es ese dato más un emisor que lo respalda con su firma, y viaja dentro de un token, un JWT o una aserción SAML.

Derechos

Los derechos describen lo que la identidad tiene permitido hacer. Si las credenciales son la llave que abre la puerta, los derechos deciden qué puedes hacer una vez dentro: entrar en todas las habitaciones o solo en el recibidor, mover los muebles o solo mirarlos. Según el sistema se llaman de una forma u otra. En Linux son los permisos rwx y el fichero sudoers. En AWS, políticas y roles. En Active Directory, la pertenencia a grupos de seguridad. En OAuth 2.0, scopes. En una aplicación de negocio, roles como administrador, editor o lector. En un modelo basado en relaciones, relaciones como “es miembro de” o “es dueño de”.

Hay algo que conviene tener claro desde el principio: los derechos no se comprueban cuando inicias sesión, sino cada vez que intentas hacer algo. Inicias sesión una vez al día; tus derechos se comprueban cada vez que pulsas un botón. Los modelos de autorización que vienen más adelante en el programa entran mucho más a fondo en esto.

Credenciales

Las credenciales son lo que la identidad presenta para demostrar que es quien dice ser. Son las llaves de la puerta. Algunas llaves son baratas y fáciles de copiar, como una contraseña en un pósit; otras son caras y muy difíciles de duplicar, como tu huella o una llave física tipo YubiKey. Cuanto más valioso sea lo que hay detrás de la puerta, más fuerte debería ser la llave. Las credenciales se agrupan según el tipo de factor en el que se apoyan:

Las credenciales modernas pueden ser asimétricas, un par de claves pública y privada como en FIDO2/WebAuthn, en lugar de un secreto compartido como una contraseña. La diferencia importa. Con una contraseña, el servidor y tú comparten el mismo secreto, así que si el servidor lo filtra, tu identidad queda expuesta en todos los sitios donde reutilizaste esa contraseña. Con una credencial asimétrica como una passkey, la clave privada nunca sale de tu dispositivo y el servidor solo guarda la pública, que por sí sola no sirve para iniciar sesión. Eso deja el phishing prácticamente fuera de juego. Una passkey, dicho de forma sencilla, es una clave criptográfica que vive en tu teléfono o tu portátil y se desbloquea con tu huella o tu cara; el servidor nunca la ve, solo recibe la prueba de que la usaste. Es la mejor credencial que tienen hoy los usuarios corrientes.

Cómo encajan las piezas

Hasta ahora cada pieza ha aparecido por separado. Aquí están juntas. A la izquierda, un sujeto del mundo real; en medio, una identidad digital construida con atributos y credenciales, y dos puertas, la autenticación y la autorización; a la derecha, una acción que se ejecuta o se bloquea. Un token firmado lleva los claims de la identidad al otro lado, y los derechos deciden qué pasa una vez dentro.

Es la cajera del principio haciendo bien su trabajo: comprueba quién eres antes que nada, y después comprueba qué puedes hacer antes de entregarte un solo dólar.

Resumen

Un sujeto vive en el mundo real: tú, tu teléfono, un microservicio. Cada sujeto puede tener varias identidades digitales, una por cada sistema en el que existe, y cada identidad toma forma como una o varias cuentas en bases de datos reales. Las identidades muestran perfiles distintos según quién mire. Lo que hace útil a una identidad son sus atributos, lo que se sabe de ella; sus credenciales, cómo demuestra quién es; sus derechos, lo que puede hacer, y su contexto, desde dónde actúa ahora mismo. Cuando una identidad inicia sesión, un proveedor de identidad emite claims firmados sobre ella, y cada vez que intenta hacer algo, sus derechos se comprueban contra una política. Con ese vocabulario puedes seguir una conversación con cualquiera que trabaje en IAM.

Ponte a prueba

1. Sara usa una app para pedir comida. Identifica el sujeto, la identidad, dos cuentas posibles y dos perfiles que el sistema podría mostrar.
2. Tu equipo está construyendo una herramienta interna en la que los empleados aprueban gastos. ¿Cuáles serían los atributos clave de cada identidad, qué derechos distinguirías y qué credenciales recomendarías?
3. Si una app recibe un JWT firmado por un proveedor de identidad en el que no confía, ¿qué debería hacer y por qué?