¿Qué es la identidad digital?

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 NIU es como tu DUI dentro del sistema de NIU; tu identidad en tu correo de trabajo es como tu credencial de empleado; tu identidad en Spotify 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:

1. Es una representación, no el sujeto mismo. Tú eres una persona; tu identidad digital es lo que el sistema sabe sobre ti.
2. Es única dentro de un contexto. Para tu banco, tu identidad digital es única; para Netflix, también, pero son identidades distintas que casualmente representan a la misma persona.
3. Es operacional, no contemplativa. Existe para tomar decisiones: ¿este usuario puede leer este archivo? ¿este pago puede ejecutarse?
4. 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

Para que sea más fácil verlo, 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. Una rama para los datos que te describen, otra para las pruebas de que eres tú, otra para lo que tienes permiso de hacer y otra para el momento concreto en el que estás actuando. Aquí está el esquema:

flowchart TB
  accTitle: Anatomía de una identidad digital
  accDescr: Diagrama tipo árbol con la raíz Identidad Digital ramificándose en cuatro grupos (atributos, credenciales, derechos, contexto) cada uno expandido con ejemplos concretos.
  ID([Identidad Digital])
  ID --> ATR[Atributos]
  ID --> CRED[Credenciales]
  ID --> DER["Derechos / Entitlements"]
  ID --> CTX[Contexto]
  ATR --> A1[Nombre]
  ATR --> A2[Email]
  ATR --> A3[Departamento]
  CRED --> C1[Contraseña]
  CRED --> C2[Llave FIDO2]
  CRED --> C3[Certificado]
  DER --> D1[Roles]
  DER --> D2[Permisos]
  DER --> D3[Grupos]
  CTX --> CT1[Dispositivo]
  CTX --> CT2[Ubicación]
  CTX --> CT3[Hora]

Lectura rápida del esquema: cuatro brazos. Lo que el sistema sabe sobre ti (atributos), lo que tú usas para demostrar que eres tú (credenciales), lo que el sistema te permite hacer (derechos), y desde dónde estás actuando ahora mismo (contexto). Vamos a ver cada uno en detalle más adelante, pero quédate con esta imagen mental — es la que vamos a ir rellenando todo el artículo.

Un ejemplo concreto: tu identidad en una fintech

Cuando abres tu cuenta en una fintech salvadoreña como NIU o n1co, 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 NIU. Es distinta de tu identidad digital en tu banco, en Uber Eats o en Netflix, aunque todas representen a la misma persona.

Sujeto, identidad, cuenta y perfil: cuatro palabras que se confunden

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: María García, 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. María tiene una identidad en su banco, otra en NIU, otra en su correo de trabajo, otra en Spotify. Las cuatro tienen el mismo sujeto detrás (María), pero son cuatro identidades distintas, cada una con sus propios atributos, credenciales y derechos.

Una buena forma de probarte que entiendes la diferencia: si María 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 María en su trabajo puede tener cuenta en Active Directory, cuenta en Salesforce, cuenta en Slack, cuenta en GitHub. 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 LinkedIn es distinto de tu perfil privado en LinkedIn (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

Diagrama de relación (UML class)

Si te ayuda verlo en notación UML — esos cuadritos con propiedades que probablemente ya viste si trabajas con bases de datos o programación orientada a objetos —, las relaciones entre los cuatro conceptos quedan así. Las flechas se leen como “tiene” o “se materializa en”, y los números (1, 0..*, 1..*) indican cuántos elementos de un lado se conectan con el otro. Por ejemplo, 1 → 1..* significa “uno con uno o más”:

classDiagram
  accTitle: Relaciones entre Sujeto, Identidad, Cuenta y Perfil
  accDescr: Diagrama UML de clases con cuatro cajas (Sujeto, Identidad, Cuenta, Perfil) conectadas por flechas que se leen como tiene, se materializa en y se proyecta como, con cardinalidades del tipo uno a muchos.

  class Sujeto {
    +nombreReal: String
    +tipoEntidad: String
    +fechaNacimiento: DateTime
  }
  class Identidad {
    +identityId: String
    +atributos: Atributos
    +credenciales: List~Credencial~
    +derechos: List~Derecho~
  }
  class Cuenta {
    +accountId: String
    +username: String
    +sistema: String
    +estado: String
  }
  class Perfil {
    +contextoUso: String
    +atributosVisibles: Map
  }
  Sujeto "1" --> "1..*" Identidad : tiene
  Identidad "1" --> "0..*" Cuenta : se materializa en
  Identidad "1" --> "0..*" Perfil : se proyecta como

Caso de María, paso a paso

María es socióloga, vive en Santa Tecla, tiene 32 años. Esa es la persona, el sujeto.

María descarga la app de NIU. En el momento en que valida su email y su DUI, nace su identidad digital “María en NIU”. 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 NIU, 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 María entra a la app, ve su perfil personal: balance, últimas transacciones, su nombre. Cuando otro usuario le manda dinero por P2P y María 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 Roberto, dueño de una pequeña tienda de electrónica en San Miguel. Roberto se conecta cada mañana a tres sistemas distintos:

• Su WhatsApp Business para atender clientes.
• Su sistema de inventario que usa para registrar entradas de mercancía.
• Su cuenta empresarial en n1co para procesar cobros con tarjeta.

El sujeto es uno solo: Roberto, persona física con un DUI. Las identidades digitales son tres distintas, una por sistema. En cada una hay cuentas técnicas (en WhatsApp Business son varias, una por número de WhatsApp; en n1co 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 WhatsApp 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 Roberto, pero con cuatro lentes distintos. La pregunta interesante para IAM es: ¿qué pasa si Roberto 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

Ahora vamos al detalle de los componentes. 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 María”, 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": "maria@gmail.com",
  "email_verified": true,
  "name": "María García",
  "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 María 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 María. 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:

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:

Las credenciales modernas pueden ser asimétricas (clave pública/privada como en FIDO2) 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 en una sola escena. El siguiente esquema muestra el viaje completo: empieza con un sujeto del mundo real (a la izquierda), pasa por una identidad digital con sus atributos y credenciales, atraviesa dos puertas (autenticación y autorización), y termina con una acción que se ejecuta o se bloquea (a la derecha). Léelo de izquierda a derecha como si fuera la película de un usuario tratando de hacer algo en una app:

flowchart LR
  accTitle: Cómo se ensamblan las piezas de la identidad
  accDescr: Flowchart de izquierda a derecha que muestra un sujeto representado por una identidad digital construida a partir de atributos y credenciales, pasando por autenticación para obtener un token con claims firmados, y luego por autorización evaluada contra derechos que permite o bloquea la acción.
  S([Sujeto]) -. representa .-> ID[Identidad Digital]
  ATR[Atributos] --> ID
  CRED[Credenciales] --> ID
  ID --> AUTH{Autenticación}
  AUTH -->|OK| CLAIMS[Token con Claims]
  CLAIMS --> APP[Aplicación]
  DER[Derechos] --> AUTHZ{Autorización}
  APP --> AUTHZ
  AUTHZ -->|permite| ACCION[Acción ejecutada]
  AUTHZ -->|deniega| BLOQ[Acción bloqueada]

Lectura del diagrama: el sujeto está representado por una identidad. Esa identidad tiene atributos y credenciales. Cuando se autentica, se emite un token con claims firmados. La aplicación recibe ese token. Cuando la identidad intenta hacer algo, se evalúan sus derechos. Si la autorización aprueba, la acción se ejecuta. Si no, se bloquea — y ese “bloqueo” es lo que evita el escenario absurdo del banco con el que arrancamos.

Diagrama de secuencia: emisión de un claim

Bajemos un nivel y veamos qué ocurre exactamente cuando un usuario inicia sesión. El siguiente es un diagrama de secuencia: los actores aparecen en columnas en la parte de arriba, y el tiempo avanza hacia abajo. Cada flecha es una llamada de red o una operación interna; los pasos están numerados para que los puedas seguir uno a uno como si fuera una receta. Si has trabajado con APIs, es básicamente la traza de un login OIDC visto desde fuera:

sequenceDiagram
  accTitle: Secuencia de emisión de un claim durante un login OIDC
  accDescr: Diagrama de secuencia con cinco actores (usuario, aplicación cliente, identity provider, directorio, API protegida) mostrando los once pasos desde el login hasta el acceso exitoso al recurso.
  actor U as Usuario
  participant App as Aplicación cliente
  participant IdP as Identity Provider
  participant Dir as Directorio
  participant API as API protegida
  U->>App: 1. Login (usuario + contraseña)
  App->>IdP: 2. Reenvía credenciales
  IdP->>Dir: 3. Valida credenciales y obtiene atributos
  Dir->>IdP: 4. Atributos del usuario
  IdP->>IdP: 5. Construye y firma JWT con claims
  IdP->>App: 6. Devuelve token (JWT)
  App->>App: 7. Guarda token en sesión
  App->>API: 8. GET /recurso (Bearer token)
  API->>API: 9. Verifica firma del JWT
  API->>API: 10. Evalúa claims y derechos
  API->>App: 11. 200 OK + recurso

Este flujo es la columna vertebral de cualquier autenticación moderna basada en OIDC. Los claims firmados son lo que permite que la API confíe en la identidad sin tener que volver a consultar al IdP en cada llamada — y eso es lo que hace que el sistema sea rápido y escalable, en lugar de generar una avalancha de llamadas al IdP cada vez que cargas una página.

Una nota didáctica: notar que el IdP y el directorio aparecen como cosas separadas en este diagrama. En la realidad muchas plataformas comerciales (Okta, Entra ID) los traen integrados, así que cuando configuras un IdP “moderno” estás también configurando el directorio detrás. Pero conceptualmente son dos cosas — el directorio almacena las identidades, el IdP las autentica y emite tokens.

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.

1. María usa una app para pedir comida. Identifica al sujeto, la identidad, dos cuentas posibles y dos perfiles que el sistema podría exponer.
2. 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?
3. Si una app recibe un token JWT firmado por un IdP en el que no confía, ¿qué debería hacer y por qué?