¿Qué es la identidad digital?
Guía introductoria al concepto fundacional de IAM: definición de identidad digital, los conceptos que se confunden (sujeto, identidad, cuenta, perfil) y los bloques que la construyen (atributos, claims, derechos y credenciales).
Por qué este concepto importa más de lo que parece
Imagina que llegas a una sucursal de tu banco un lunes a las 10 AM. La cajera no te reconoce, no aparece tu nombre en su pantalla, y aun así te entrega 500 dólares en efectivo “porque dijiste que eras tú”. Suena absurdo. Pero esa misma escena, traducida al mundo digital, ocurre cada día en aplicaciones mal diseñadas: alguien escribe un correo y una contraseña, y un sistema confía sin verificar nada más.
La identidad digital es el cimiento que evita ese absurdo. Toda decisión de seguridad — qué puedes ver, qué puedes modificar, qué puedes pagar — se toma sobre una identidad. Si el cimiento es débil, todo lo demás también lo es. Por eso este concepto, que parece introductorio, en realidad es el más importante de todo el programa.
En esta guía vamos a recorrer tres bloques que sientan las bases para todo lo demás: la definición misma de identidad digital, la diferencia (a menudo confundida) entre sujeto, identidad, cuenta y perfil, y los componentes que arman una identidad operativa — atributos, claims, derechos y credenciales. Si quieres profundizar después en los tipos de identidades modernas (personas, dispositivos, workloads y agentes IA) y en por qué la identidad es hoy el “nuevo perímetro”, esos temas viven en el segundo artículo de este bloque.
Definición: ¿qué es realmente una identidad digital?
La definición formal proviene 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.
Esa frase suena más complicada de lo que es. Tradúcela así: una identidad digital es lo que un sistema “sabe de ti” para poder decidir qué hacer cuando interactúas con él. Es como tu ficha en la oficina del médico, pero viviendo dentro de una base de datos en lugar de un archivero.
Una analogía con el mundo físico
Piensa en tu identidad en el mundo físico. Tienes un DUI con tu foto, tu nombre y tu fecha de nacimiento. Tienes un pasaporte que adicionalmente lleva sellos de los países que has visitado. Tienes una licencia de conducir que dice qué tipos de vehículo puedes manejar. Tienes una tarjeta de crédito que prueba que el banco confía en ti hasta cierto monto.
Todos esos documentos representan la misma persona — tú — pero cada uno te identifica para un propósito distinto. Ninguno es “tú” como tal: son representaciones tuyas válidas en contextos específicos. Y nadie te entrega el DUI a menos que pruebes primero que eres quien dices ser, generalmente con otro documento o con tu huella en el RNPN.
La identidad digital funciona exactamente igual, solo que los documentos viven en bases de datos y las pruebas pasan por canales cifrados. Tu identidad en una app fintech es como tu DUI dentro del sistema de esa fintech; tu identidad en tu correo de trabajo es como tu credencial de empleado; tu identidad en un servicio de streaming es como una tarjeta de membresía. Todas representan al mismo sujeto, pero cada una vive en su propio universo.
Las cuatro ideas dentro de la definición
Para que la definición sea útil en la práctica, conviene desempaquetarla en cuatro ideas:
- Es una representación, no el sujeto mismo. Tú eres una persona; tu identidad digital es lo que el sistema sabe sobre ti.
- Es única dentro de un contexto. Para tu banco, tu identidad digital es única; para un servicio de streaming, también, pero son identidades distintas que casualmente representan a la misma persona.
- Es operacional, no contemplativa. Existe para tomar decisiones: ¿este usuario puede leer este archivo? ¿este pago puede ejecutarse?
- Tiene atributos, credenciales y derechos asociados. Sin esas tres piezas, una identidad sería solo una etiqueta vacía.
La anatomía de una identidad digital
Piensa en una identidad digital como un árbol con cuatro ramas. La raíz es la identidad y cada rama agrupa un tipo distinto de información: los datos que te describen, las pruebas de que eres tú, lo que tienes permiso de hacer y el momento concreto en el que estás actuando.
Un ejemplo concreto: tu identidad en una fintech
Cuando abres tu cuenta en una app fintech, tu identidad digital empieza a existir en ese momento. La fintech no tiene tu cara, no tiene tu certificado de nacimiento, no tiene tu DUI físico. Lo que tiene es:
- Un email y un teléfono que verificó (atributos)
- Una contraseña que tú estableciste (credencial)
- Un PIN o biometría que registraste para transacciones (credenciales adicionales)
- Una foto de tu DUI procesada por un sistema de identity proofing (atributo verificado)
- Un nivel de cuenta — básico, premium — que define qué puedes hacer (derechos)
- Un historial de logins desde tu celular habitual (contexto que va aprendiendo)
Esa combinación es tu identidad digital en la fintech. Es distinta de tu identidad digital en tu banco, en una app de delivery de comida o en un servicio de streaming, aunque todas representen a la misma persona.
Sujeto, identidad, cuenta y perfil: cuatro palabras que se confunden
En una línea: el sujeto es la entidad del mundo real, la identidad es cómo un sistema concreto representa a ese sujeto, la cuenta es el registro técnico que almacena la identidad, y el perfil es una vista parcial de la identidad expuesta en un contexto dado.
Estos cuatro términos se usan a veces como sinónimos. No lo son. Confundirlos es la fuente de errores arquitectónicos más comunes en proyectos IAM. Vamos uno por uno, con calma.
Sujeto (Subject)
El sujeto es la entidad real, la cosa que existe en el mundo y que la identidad digital representa. Puede ser:
- Una persona física: Sara López, 32 años, residente en San Salvador.
- Un dispositivo: el iPhone 15 con número de serie ABC123.
- Un servicio: el microservicio de cobros que corre en Kubernetes.
- Un agente IA: el bot que negocia citas en tu calendario.
El sujeto vive fuera del sistema digital. Es el referente. Una persona puede tener muchas identidades digitales (una por cada sistema), pero sigue siendo un solo sujeto.
Identidad (Identity)
La identidad es la representación digital del sujeto en un contexto específico. Cada vez que un sujeto se inscribe en un sistema, nace una identidad digital. Sara tiene una identidad en su banco, otra en su app fintech, otra en su correo de trabajo, otra en un servicio de streaming. Las cuatro tienen el mismo sujeto detrás (Sara), pero son cuatro identidades distintas, cada una con sus propios atributos, credenciales y derechos.
Una buena forma de probarte que entiendes la diferencia: si Sara se cambia el apellido al casarse, su sujeto sigue siendo el mismo (es la misma persona), pero cada una de sus identidades digitales tiene que actualizar el atributo “apellido” por separado, en cada sistema. Eso te dice claramente que sujeto e identidad son cosas distintas — uno es la persona, otro es lo que cada sistema sabe de la persona.
Cuenta (Account)
La cuenta es la implementación técnica de una identidad dentro de una aplicación o sistema concreto. Mientras que “identidad” es un concepto, “cuenta” es la fila en la base de datos del sistema, con su username, su password hash, sus permisos y sus columnas de auditoría.
Una identidad puede tener varias cuentas: la identidad de Sara en su trabajo puede tener cuenta en el directorio corporativo, cuenta en el CRM, cuenta en la herramienta de chat, cuenta en el repositorio de código. Todas son cuentas de la misma identidad. Esta distinción es crítica en IGA: las “cuentas huérfanas” son cuentas cuya identidad ya no existe (típicamente porque la persona se fue de la empresa pero su acceso en alguna app nunca se eliminó).
Perfil (Profile)
El perfil es una vista parcial y contextual de una identidad. Es lo que un sistema decide mostrar o exponer en un momento dado. Tu perfil público en una red social profesional es distinto de tu perfil privado en esa misma red (que solo tú ves), y ambos son distintos de tu perfil que ven los recruiters de pago.
El perfil sirve para dos cosas: presentación (cómo te ves a otros) y minimización de datos (cuántos atributos exponer en cada interacción). Una buena arquitectura nunca te muestra al mundo más de lo necesario — ni tu fecha de nacimiento al cajero, ni tu salario al CRM de marketing.
Tabla comparativa rápida
| Concepto | Vive en… | Multiplicidad | Ejemplo (app fintech) |
|---|---|---|---|
| Sujeto | Mundo real | 1 por persona/cosa | Sara, persona física |
| Identidad | Sistema lógico de IAM | Muchas por sujeto | ”Sara en la app fintech” |
| Cuenta | Base de datos de la app | Una o más por identidad | Fila en tabla users, fila en tabla wallet_accounts |
| Perfil | UI / API expuesta | Múltiples vistas | Tu pantalla “Mi cuenta”, tu vista pública en P2P |
Caso de Sara, paso a paso
Sara es socióloga, vive en Santa Tecla, tiene 32 años. Esa es la persona, el sujeto.
Sara descarga su app fintech. En el momento en que valida su email y su DUI, nace su identidad digital “Sara en la app fintech”. Esa identidad tiene atributos (nombre, fecha de nacimiento, teléfono), credenciales (contraseña, PIN, biometría) y derechos (cliente nivel básico, puede transferir hasta $500 al día).
En la base de datos de la fintech, esta identidad se materializa como tres cuentas distintas:
- Una fila en
customers(datos personales) - Una fila en
auth_credentials(credenciales) - Una fila en
wallet_accounts(su saldo y movimientos)
Cuando Sara entra a la app, ve su perfil personal: balance, últimas transacciones, su nombre. Cuando otro usuario le manda dinero por P2P y Sara aparece en la búsqueda, lo que se ve es un perfil público mucho más reducido: solo su nombre y su foto.
Mismo sujeto, una identidad, tres cuentas, dos perfiles.
Un segundo ejemplo para reforzar
Para que la idea quede asentada, veamos el caso de Daniel, dueño de una pequeña tienda de electrónica en San Miguel. Daniel se conecta cada mañana a tres sistemas distintos:
- Su herramienta de chat empresarial para atender clientes.
- Su sistema de inventario que usa para registrar entradas de mercancía.
- Su cuenta empresarial en un procesador de pagos en línea para procesar cobros con tarjeta.
El sujeto es uno solo: Daniel, persona física con un DUI. Las identidades digitales son tres distintas, una por sistema. En cada una hay cuentas técnicas (en la herramienta de chat son varias, una por número de negocio; en el procesador de pagos podría tener cuentas separadas para “comerciante” y “facturación”). Y los perfiles cambian según quién mira: sus clientes ven un perfil público en el chat con su foto y horarios; el SAT — si fiscaliza — vería un perfil con sus datos tributarios; sus proveedores ven uno con su límite de crédito.
El mismo Daniel, pero con cuatro lentes distintos. La pregunta interesante para IAM es: ¿qué pasa si Daniel cambia su número de teléfono? ¿se actualiza en los tres sistemas automáticamente? Casi nunca. Por eso la disciplina de IAM existe: para gobernar esa orquestación.
Los bloques de construcción: atributos, claims, derechos y credenciales
Una identidad operativa se compone de cuatro bloques: atributos (hechos sobre ella), credenciales (lo que usa para demostrar que es ella), derechos (lo que tiene permitido hacer) y claims (afirmaciones firmadas que transportan atributos entre sistemas).
Ahora vamos al detalle de cada uno. Estas cuatro piezas son el vocabulario operativo de IAM — las palabras que vas a oír cada día si trabajas en este dominio.
Atributos
Los atributos son hechos sobre la identidad. Si alguna vez has llenado un formulario de registro en una app, ya sabes lo que son: cada casilla que rellenaste es un atributo. Pueden ser inmutables (fecha de nacimiento), de cambio lento (apellido, departamento) o dinámicos (ubicación actual, dispositivo en uso).
Ejemplos típicos:
- Nombre, apellido
- Email, teléfono
- Fecha de nacimiento, DUI, NIT
- Departamento, manager, oficina
- Idioma preferido
- Última fecha de login
Los atributos viven en el repositorio de identidades (Active Directory, LDAP, base de usuarios). Las aplicaciones los consumen para tomar decisiones o para personalizar la experiencia.
Una pregunta útil que te puedes hacer al diseñar un sistema: para cada atributo, ¿quién lo escribe, quién lo actualiza, quién lo lee? La mayoría de los problemas de “datos desactualizados” en una organización vienen de no responder esas tres preguntas.
Claims (afirmaciones)
Un claim es una afirmación firmada digitalmente que un emisor hace sobre una identidad, dirigida a un destinatario. La pieza clave es la palabra firmada: un claim es confiable porque viene con una firma criptográfica del emisor.
Una analogía rápida: imagina que un amigo en común te dice “esta persona es de fiar, le presté dinero y me lo devolvió”. Le crees no porque la persona te caiga bien, sino porque viene avalada por alguien en quien tú confías. Un claim funciona igual: si Google firma “este email pertenece a Sara”, la app receptora le cree porque la firma de Google es difícil de falsificar y proviene de una fuente que ya está en su lista de confianza.
Cuando inicias sesión con tu cuenta de Google en una app de terceros, lo que la app recibe es un conjunto de claims firmados por Google. Esos claims se ven así:
{
"iss": "https://accounts.google.com",
"sub": "1234567890abcdef",
"email": "sara@gmail.com",
"email_verified": true,
"name": "Sara López",
"iat": 1714579200,
"exp": 1714582800
}Si nunca has visto un payload así, déjame traducirlo: iss es el emisor (issuer, en este caso Google), sub es el identificador único de Sara dentro de Google, email_verified: true es el claim que la app realmente quería — saber que ese correo le pertenece de verdad —, e iat/exp son las fechas de emisión y expiración. La app no necesita preguntarle a Google si el email es realmente de Sara. La firma de Google sobre el JWT le basta. Eso es un claim.
Derechos (Entitlements)
Los derechos describen lo que la identidad puede hacer. Si las credenciales son la llave que abre la puerta, los derechos son lo que te permiten hacer una vez dentro: ¿puedes entrar a todas las habitaciones o solo al lobby? ¿puedes mover muebles o solo mirarlos? Se expresan como permisos, roles, scopes, grupos o políticas, dependiendo del modelo.
Tabla de equivalencias por contexto:
| Contexto | Cómo se llama el derecho |
|---|---|
| Linux/Unix | Permisos rwx, sudoers |
| AWS IAM | Policies, roles |
| Active Directory | Membresía en security groups, GPOs |
| OAuth 2.0 | Scopes |
| Aplicación de negocio | Roles funcionales (admin, editor, viewer) |
| Modelo ReBAC | Relaciones (es miembro de, es dueño de) |
La distinción importante para esta etapa: los derechos no se evalúan al momento de autenticarte, sino cada vez que intentas hacer algo. Te logueas una vez al día; tus derechos se chequean cada vez que aprietas un botón. Profundizaremos en derechos cuando lleguemos a modelos de autorización xBAC en la pista de autorización.
Credenciales
Las credenciales son lo que la identidad presenta para probar que es ella. La metáfora más simple: son las “llaves” que abren la puerta. Algunas llaves son baratas y fáciles de copiar (una contraseña en un papelito), otras son caras y muy difíciles de duplicar (tu huella o una llave física tipo YubiKey). Cuanto más valioso es lo que protege la puerta, más fuerte conviene que sea la llave. Se clasifican por factor:
| Factor | Ejemplos | Fortaleza |
|---|---|---|
| Algo que sabes | Contraseña, PIN, frase | Baja a media |
| Algo que tienes | Smartphone, llave hardware (YubiKey), smart card | Media a alta |
| Algo que eres | Huella, rostro, iris, voz | Alta (con liveness) |
| Algo que haces | Patrón de tipeo, gestos | Auxiliar |
Las credenciales modernas pueden ser asimétricas (clave pública/privada como en FIDO2/WebAuthn) en lugar de secretos compartidos como las contraseñas. La diferencia importante: con una contraseña, tú y el servidor comparten el mismo secreto, así que si el servidor lo filtra, tu identidad queda comprometida en cualquier sitio donde uses esa misma clave. Con una credencial asimétrica como un passkey, la clave privada nunca abandona tu dispositivo; el servidor solo guarda la pública, que por sí sola no sirve para autenticarte. Eso elimina prácticamente la posibilidad de phishing.
El ensamblaje: cómo las piezas trabajan juntas
Hasta aquí hemos visto cada componente por separado. Ahora juntémoslos. El flujo a continuación muestra el viaje completo: un sujeto del mundo real a la izquierda, una identidad digital construida con atributos y credenciales, dos puertas (autenticación y autorización), y una acción que se ejecuta o se bloquea a la derecha. Un token firmado lleva los claims de la identidad a través del límite, y los derechos deciden qué ocurre una vez adentro.
Recapitulación rápida
Antes de cerrar, una imagen mental que conviene llevarse:
- Un sujeto vive en el mundo real. Tú, tu teléfono, un microservicio.
- Cada sujeto puede tener varias identidades digitales — una por cada sistema donde existe.
- Cada identidad se materializa en una o varias cuentas dentro de bases de datos concretas.
- Las identidades exponen perfiles parciales según el contexto.
- Cada identidad tiene cuatro componentes que la hacen operativa: atributos (lo que se sabe de ella), credenciales (con qué se prueba), derechos (qué puede hacer) y contexto (desde dónde está actuando ahora).
- Cuando una identidad se autentica, se emite un claim firmado por un IdP. Cuando intenta hacer algo, sus derechos se evalúan contra una política.
Si entendiste eso, ya tienes el vocabulario para hablar con cualquier persona del dominio IAM y entenderle.
Pon a prueba lo aprendido
Tres preguntas para comprobar que los conceptos aterrizaron. Intenta responderlas mentalmente antes de seguir — y luego compruébalo en el lab compañero.
- Sara usa una app para pedir comida. Identifica al sujeto, la identidad, dos cuentas posibles y dos perfiles que el sistema podría exponer.
- Tu equipo construye un sistema interno donde los empleados aprueban gastos. ¿Cuáles serían los atributos clave de cada identidad, qué derechos diferenciarías y qué credenciales recomendarías?
- Si una app recibe un token JWT firmado por un IdP en el que no confía, ¿qué debería hacer y por qué?
Preguntas frecuentes
¿Una identidad digital es lo mismo que una cuenta de usuario?
No. Una identidad digital es la representación de un sujeto dentro de un contexto; una cuenta es el registro técnico que almacena esa identidad dentro de un sistema concreto. Una misma identidad puede tener varias cuentas en distintos sistemas.
¿Una persona puede tener más de una identidad digital?
Sí. Un mismo sujeto del mundo real suele tener una identidad digital por cada sistema o contexto — por ejemplo, identidades separadas en un banco, una app fintech y el correo del trabajo — todas refiriéndose a la misma persona.
¿Cuál es la diferencia entre un atributo y un claim?
Un atributo es un dato sobre una identidad, como un correo, que vive en un directorio. Un claim es ese dato afirmado y firmado criptográficamente por un emisor y transportado en un token, de modo que el sistema receptor puede confiar en él sin volver a verificar la fuente.
¿Las credenciales y los derechos son lo mismo?
No. Las credenciales son lo que una identidad usa para demostrar quién es, como una contraseña, un passkey o una huella. Los derechos definen qué puede hacer esa identidad una vez autenticada, como roles, permisos o scopes.