Las tres etapas: identificación, autenticación, autorización

Bienvenido al Access Management

En el dominio de fundamentos construimos una base sólida: sabemos qué es una identidad digital, los cuatro tipos modernos, cómo encaja IAM en ciberseguridad, las cuatro olas históricas, los cinco dominios y cómo se ve el ciclo operativo en la práctica. Ahora entramos al corazón técnico del Access Management: cómo las aplicaciones deciden, en cada solicitud, si una identidad puede o no ejecutar una acción.

Toda esa decisión se descompone en tres etapas secuenciales — identificación, autenticación y autorización — más un pilar transversal que las acompaña: la auditoría. Si separas bien estas piezas, todo lo que veremos después (factores MFA, modelos xBAC, Zero Trust, gestión de sesiones) cae en su lugar. Si las mezclas, vas a confundirte y, peor, a confundir a tus stakeholders en una conversación real.

Antes de empezar: una aclaración sobre “las 3 vs 4 A’s”

Si has investigado IAM por tu cuenta, te habrás encontrado con dos versiones que parecen contradecirse:

• Algunos libros y cursos hablan de “las 3 A’s”: Authentication, Authorization, Accounting.
• Otros hablan de “las 4 A’s”: Authentication, Authorization, Accounting y Audit.
• Y muchos materiales listan identificación, autenticación, autorización y auditoría juntos como si fueran etapas equivalentes.

Aclaremos primero el origen del término. AAA viene del estándar RADIUS, un protocolo de autenticación y control de acceso usado en redes empresariales desde los años 90. En su definición original, las tres A’s son:

• Authentication (autenticación)
• Authorization (autorización)
• Accounting (contabilidad — registro de uso para facturación o auditoría)

La identificación queda implícita dentro de la autenticación (porque el sujeto se identifica al presentar su credencial) y la auditoría es esencialmente lo mismo que accounting con otra etiqueta. Algunas escuelas separan accounting (registro técnico) de audit (revisión interpretativa de esos registros) y por eso aparecen “4 A’s”, pero en la práctica son la misma cosa con dos nombres.

Para este artículo y para todo el programa vamos a usar una versión limpia y aterrizada:

• Tres etapas secuenciales del flujo de acceso: identificación → autenticación → autorización.
• Un pilar transversal que las atraviesa todas: auditoría.

No son cuatro etapas en serie. La auditoría no espera al final como un cuarto paso — opera al mismo tiempo que las otras tres, registrando cada evento desde que el sujeto dice quién es hasta que la acción se ejecuta o bloquea.

Vista general: el flujo completo

Antes de profundizar en cada etapa, mira el flujo de cabo a rabo. Es la película que vamos a desarmar a continuación:

flowchart LR
  accTitle: Las tres etapas de una decisión de acceso, con la auditoría como pilar transversal
  accDescr: Un sujeto pasa por tres etapas secuenciales — identificación (quién dices ser), autenticación (cómo lo pruebas) y autorización (qué puedes hacer) — antes de que la acción se ejecute o deniegue. Cada etapa, y la acción final, emite registros hacia un pilar de auditoría transversal que corre en paralelo al flujo.
  S([Sujeto]) --> ID[1. Identificación<br/>¿Quién dices ser?]
  ID --> AUTHN[2. Autenticación<br/>¿Cómo lo pruebas?]
  AUTHN --> AUTHZ[3. Autorización<br/>¿Qué puedes hacer?]
  AUTHZ --> ACTION[Acción ejecutada<br/>o denegada]
  AUDIT[(Auditoría<br/>pilar transversal)]
  ID -.registra.-> AUDIT
  AUTHN -.registra.-> AUDIT
  AUTHZ -.registra.-> AUDIT
  ACTION -.registra.-> AUDIT

Lectura del diagrama: el sujeto entra por la izquierda. Pasa por tres puertas en orden — primero declara quién es (identificación), luego prueba esa declaración (autenticación), luego se evalúa si tiene permiso para lo que quiere hacer (autorización). Si pasa las tres, la acción se ejecuta; si falla cualquiera, se deniega. Mientras eso ocurre, la auditoría va observando todo desde el costado, sin intervenir, pero registrando.

Etapa 1: Identificación

Qué es exactamente

La identificación es el sujeto declarando quién es. Es el primer paso, el más simple, y también el que más se confunde con la autenticación.

Cuando escribes tu email en una pantalla de login, eso es identificación. Estás afirmando “soy el dueño de maria@empresa.com”. El sistema todavía no te cree, solo recibe tu afirmación. Es una pregunta de clasificación: dentro del universo de identidades posibles, ¿cuál dice ser?

Por qué se confunde con autenticación

Mucha gente — incluyendo desarrolladores experimentados — usa “identificar” y “autenticar” como sinónimos. La razón es que en muchas pantallas de login los dos pasos ocurren en una sola interacción visible: escribes el email y la contraseña en la misma forma, presionas Enter, y entras o no entras. Parece un solo paso.

Pero conceptualmente son dos cosas distintas:

• Identificación = afirmación: “yo digo que soy María”.
• Autenticación = verificación: el sistema comprueba que esa afirmación es cierta.

Una analogía útil: cuando llegas a un aeropuerto para hacer check-in, primero le das tu nombre al agente (identificación) y luego le entregas tu pasaporte (autenticación). El nombre por sí solo no te deja viajar — necesitas la prueba.

Ejemplos concretos

Qué hace bien y qué no hace

La identificación es solo una etiqueta. No prueba nada por sí sola. Por eso una identidad no debería ser secreta — un email es público, un usuario es público, una identidad de máquina puede ser pública. La fortaleza viene del siguiente paso (la autenticación), no de mantener el identificador oculto.

Un anti-patrón muy común es tratar la identificación como si fuera una credencial. Por ejemplo, sistemas que asumen que conocer un número de cliente es prueba suficiente de identidad. Eso es un error grave: si yo conozco tu número de cliente, no soy tú. Un atacante con tu identificador puede empezar el flujo, pero no debería poder pasar de la primera etapa.

Etapa 2: Autenticación

Qué es

La autenticación es la verificación de que la afirmación de identificación es cierta. Si en la etapa 1 dijiste “soy María”, en la etapa 2 tienes que probarlo. La prueba consiste en presentar uno o más factores — pedazos de evidencia que, idealmente, solo el verdadero dueño de esa identidad podría tener.

Los factores se clasifican en tres categorías clásicas (que veremos en detalle en el siguiente artículo):

• Algo que sabes — contraseña, PIN, frase.
• Algo que tienes — celular, llave hardware, smart card.
• Algo que eres — huella, rostro, voz.

A esto se suman dos categorías modernas que están ganando peso:

• Algo que haces — patrón de tipeo, gestos.
• Algo que pasa con tu contexto — geolocalización, dispositivo conocido, hora habitual.

Si presentas un factor, es autenticación de un solo factor (SFA). Si presentas dos o más de categorías distintas, es autenticación multifactor (MFA). Pedir contraseña + PIN no es MFA — son dos cosas de la misma categoría (“algo que sabes”).

Cómo se complementa con la identificación

El flujo conjunto es siempre: “yo afirmo X” → “demuestra que eres X”. El sistema:

1. Recibe la identificación.
2. Busca en su almacén la información asociada a esa identidad (hashes de contraseña, claves públicas, métodos MFA registrados).
3. Pide al sujeto los factores correspondientes.
4. Compara lo recibido con lo almacenado.
5. Decide: autenticado o no.

Si la identificación falló (no existe ese usuario), una buena práctica es responder con el mismo mensaje genérico que cuando la autenticación falla (“usuario o contraseña incorrectos”) — para no permitir a un atacante enumerar identificadores válidos. Nota cómo la identificación se cuela en ese primer paso, antes de la autenticación: en la mayoría de UIs son visualmente un único bloque, pero conceptualmente son dos cosas distintas.

Resultado de la autenticación

Una vez autenticado, el sujeto recibe una prueba de autenticación que viajará con cada solicitud subsiguiente. Esa prueba puede ser:

• Una cookie de sesión firmada por el servidor.
• Un token (JWT, opaque token) emitido por el IdP.
• Una assertion SAML para casos federados.

Lo importante es que esta prueba no es estática — tiene tiempo de vida limitado, condiciones de revocación, y debe verificarse en cada uso. La autenticación no termina al login; “se renueva” implícitamente en cada solicitud cuando el sistema valida que el token sigue siendo válido.

Etapa 3: Autorización

Qué es y por qué es distinta de autenticación

La autorización es la decisión de qué puede hacer una identidad ya autenticada. Si autenticación responde “¿eres realmente María?”, autorización responde “ya sé que eres María, ¿pero esto que quieres hacer está dentro de tus permisos?”.

Aquí hay un punto que muchos confunden: el hecho de estar autenticado no implica permiso para nada en particular. María puede ser legítimamente María, y aún así no tener acceso a la consulta de saldos de cuentas premium que está intentando ejecutar. Su identidad está confirmada; su acción no está autorizada.

Una forma de fijarlo: cuando un guardia verifica tu identificación oficial en la entrada de un edificio, te autenticó. Pero todavía no te ha autorizado a entrar al piso 7 — eso depende de qué dice tu pase de visitante o tu credencial corporativa.

Cómo funciona en la práctica

Cada vez que el sujeto autenticado intenta una acción, el sistema:

1. Lee los claims del token o la sesión (rol, scopes, atributos del usuario).
2. Lee la política aplicable al recurso (¿quién puede leer esta tabla? ¿quién puede aprobar este pago?).
3. Combina ambas y decide: permitir o denegar.

Esa decisión se hace en cada acción, no una sola vez. Estás autenticado por horas, pero te autorizan en cada click.

Modelos de autorización (preview)

Los modelos formales de autorización son un tema propio. Aquí un avance:

Ahora basta con saber que la autorización se materializa en uno o más de estos modelos; un artículo dedicado entra en el detalle.

El pilar transversal: auditoría

Por qué no es una cuarta etapa

La auditoría no espera al final del flujo como una etapa más. Trabaja en paralelo, registrando cada evento que ocurre en las otras tres. Si la pintamos como cuarta etapa, sugerimos que ocurre después de autorizar — y eso es falso. Ocurre al mismo tiempo, atravesando todo.

Por eso en el diagrama del inicio aparece debajo, conectada con flechas punteadas a las tres etapas: cada una emite registros hacia auditoría sin alterar su flujo principal.

Qué registra la auditoría

Una auditoría útil captura, por cada evento:

• Quién intentó qué (identidad + acción solicitada).
• Cuándo lo intentó (timestamp con zona horaria).
• Desde dónde lo intentó (IP, dispositivo, geolocalización si aplica).
• Resultado (éxito o falla, y si falló, por qué).
• Qué cambió (si fue una operación que modificó datos, el antes y después).

Ejemplos de eventos auditables: un inicio de sesión exitoso o fallido, un cambio de contraseña, una solicitud de acceso a un recurso, una acción privilegiada ejecutada, un cierre de sesión, una modificación de configuración.

Por qué importa

Tres razones principales:

1. Cumplimiento normativo: SOX, HIPAA, PCI-DSS, GDPR exigen registro de eventos de identidad. Sin auditoría no pasas auditoría externa.
2. Detección de amenazas: ITDR (uno de los cinco dominios) vive de los logs de auditoría. Sin esos logs, no puedes detectar comportamiento anómalo.
3. Forensia: cuando ocurre un incidente, los logs son la única forma de reconstruir qué pasó. Sin ellos, vuelas a ciegas.

Una auditoría completa, fiable e inmutable es lo que diferencia un programa IAM serio de uno improvisado.

La auditoría alimenta al resto del stack de seguridad

flowchart TB
  accTitle: La auditoría como pilar que alimenta SIEM, ITDR y Compliance
  accDescr: Las tres etapas — identificación, autenticación, autorización — corren como una secuencia horizontal. Un componente de auditoría transversal recibe eventos de ese flujo y a su vez alimenta a tres consumidores: un SIEM o SOC, un sistema ITDR y los reportes de Compliance.
  subgraph Flow["Flujo del acceso"]
    direction LR
    ID[1. Identificación] --> AUTHN[2. Autenticación]
    AUTHN --> AUTHZ[3. Autorización]
  end
  AUDIT[Auditoría<br/>registra todo, todo el tiempo]
  Flow -.eventos.-> AUDIT
  AUDIT -.alimenta.-> SIEM[(SIEM / SOC)]
  AUDIT -.alimenta.-> ITDR[ITDR]
  AUDIT -.alimenta.-> COMP[Compliance]

Las tres etapas viven en una secuencia horizontal — la “línea de producción” del acceso. La auditoría está debajo, recibiendo eventos de cada etapa, y a su vez alimentando a tres consumidores: SIEM/SOC para análisis general de seguridad, ITDR para detección específica de amenazas de identidad, y Compliance para reportes regulatorios.

Caso integrado: una operación de banca móvil

Para fijar todo lo anterior en un caso reconocible, sigamos a María intentando aprobar un préstamo de $5,000 desde la app móvil de su banco.

Lo que se ve en pantalla

1. María abre la app y aparece la pantalla “Iniciar sesión”.
2. Escribe maria.garcia@email.com y su contraseña, presiona “Entrar”.
3. La app le pide un código de su token móvil. María lo escribe.
4. Entra al dashboard. Selecciona “Préstamos”. Selecciona uno de $5,000 a 24 meses.
5. La app le pide su PIN de transacciones (paso de seguridad adicional).
6. Aparece “Préstamo aprobado”.

Tres pasos visibles. Pero hay seis pasos lógicos pasando por debajo:

Lo que pasa por dentro

sequenceDiagram
  accTitle: La aprobación de un préstamo en banca móvil a través de las tres etapas más auditoría
  accDescr: María se autentica en una app bancaria con email, contraseña y un código MFA; el IdP del banco emite un JWT firmado; el servicio de préstamos pregunta a un motor de autorización si puede pedir 5000 dólares; tras un PIN transaccional de step-up el préstamo se aprueba. El IdP, el motor y el servicio de préstamos emiten eventos de login, MFA, decisión de autorización y préstamo aprobado hacia auditoría.
  actor M as María
  participant App as App banca
  participant IdP as IdP del banco
  participant Eng as Motor de autorización
  participant Lend as Servicio de préstamos
  participant Aud as Auditoría
  M->>App: 1. Email + contraseña (identificación + factor 1)
  App->>IdP: Verifica identidad
  IdP-->>Aud: Evento: login intento
  M->>App: 2. Código MFA (factor 2)
  IdP-->>Aud: Evento: MFA verificado
  IdP->>App: 3. JWT con claims firmados
  App->>Lend: 4. POST /loan/apply (Bearer JWT)
  Lend->>Eng: ¿Está autorizada?
  Eng-->>Aud: Evento: decisión de autorización
  Eng->>Lend: Permitido (límite no excedido, tipo de cuenta válido)
  M->>App: 5. PIN transaccional (factor adicional)
  Lend-->>Aud: Evento: préstamo aprobado
  Lend->>App: 6. Confirmación

Lectura paso a paso, mapeando a las tres etapas + auditoría:

• Paso 1: María se identifica con su email y presenta el primer factor (contraseña). El IdP valida y registra el intento en auditoría.
• Paso 2: El IdP solicita un segundo factor; María lo proporciona. Se registra que MFA fue verificado.
• Paso 3: El IdP emite un JWT firmado con los claims relevantes (sub=maria.garcia, aal=2, account_type=premium). Hasta aquí: identificación + autenticación completas.
• Paso 4: La app llama a la API del servicio de préstamos con el token. El servicio extrae los claims y los envía al motor de autorización junto con la solicitud específica (“aplicar préstamo $5,000, 24 meses”).
• Decisión de autorización: el motor evalúa si María, con su tipo de cuenta y sus atributos, puede solicitar este préstamo. Lee la política — máximo $10,000 al año, cuenta premium habilitada, cliente con más de 6 meses de antigüedad — y decide: permitir.
• Paso 5: La app le pide a María su PIN transaccional (un factor adicional, step-up authentication, para acciones de alto valor). Una vez recibido, la operación se ejecuta.
• Paso 6: Se confirma a María. Auditoría ha registrado todos los eventos: login, MFA, decisión de autorización, paso de step-up, préstamo aprobado.

Si en algún momento algo hubiese fallado — contraseña incorrecta, MFA no aprobado, política denegando el préstamo, PIN equivocado — el flujo se detenía y la falla quedaba en auditoría. Esa secuencia ordenada de etapas + el registro paralelo es lo que permite, después, que un investigador pueda reconstruir cualquier evento en minutos.

Errores típicos por etapa (anti-patrones)

Mucho de lo que sale mal en seguridad de aplicaciones se reduce a confundir o saltarse alguna de las tres etapas. Vale la pena conocer los errores más comunes para no repetirlos:

Errores en la etapa de identificación

• Tratar el identificador como secreto. Diseñar un sistema asumiendo que conocer el número de cliente o el employee ID es suficiente para autorizar acciones. Esos identificadores son fácilmente obtenibles (un correo filtrado, un papelito en el escritorio, ingeniería social).
• Mensajes que filtran si un usuario existe. Mostrar “el usuario no existe” en una pantalla de login deja a un atacante enumerar identidades válidas. La mejor práctica es responder genéricamente “credenciales inválidas” sin distinguir si falló identificación o autenticación.
• Permitir múltiples identificadores sin coherencia. Algunos sistemas dejan loguearse con email O username O número de empleado, pero internamente los tratan como tres identidades distintas. Resultado: permisos asignados a un identificador no aplican al otro.

Errores en la etapa de autenticación

• Considerar dos factores de la misma categoría como MFA. Pedir contraseña + PIN no es MFA; son dos cosas que sabes. Para que sea genuino MFA, los factores deben ser de categorías distintas.
• No invalidar la sesión al cambiar credenciales. Cuando un usuario cambia su contraseña, todas sus sesiones activas deberían invalidarse — especialmente si el cambio fue por sospecha de compromiso. Muchos sistemas no lo hacen.
• Confiar en el cliente para validar credenciales. Hacer la verificación de contraseña en JavaScript del navegador, o dejar que la app móvil decida si el biométrico fue válido sin confirmación del backend.
• No tener mecanismo de revocación de tokens. Emitir tokens de larga duración sin forma de invalidarlos. Si un token leak, queda activo hasta su expiración natural — eso pueden ser semanas.

Errores en la etapa de autorización

• Autorizar solo en el frontend. Esconder un botón “eliminar” si el usuario no es admin no es autorizar — es ocultar UI. La autorización real siempre ocurre en el backend, validando cada request.
• Confundir autenticación con autorización. El error “si está logueado, déjalo entrar a todo”. Resultado: cualquier usuario autenticado puede ejecutar acciones administrativas porque nadie verificó sus permisos específicos.
• Hardcodear lógica de autorización dispersa por el código. Reglas como if user.role == 'admin' regadas por toda la app, sin un punto central. Imposible auditar quién puede qué, y modificar las reglas requiere desplegar código.
• Autorización basada solo en rol sin contexto. Permitir que un admin lea cualquier dato a cualquier hora desde cualquier dispositivo. Las arquitecturas modernas (Zero Trust) evalúan también atributos contextuales: hora, ubicación, postura del dispositivo.

Errores en la auditoría

• Logs no inmutables. Si los logs viven en la misma base de datos que los datos del negocio, un atacante con credenciales de admin puede borrar sus huellas. Los logs deben ir a un destino donde el atacante no pueda escribir (write-once storage, SIEM externo).
• Registrar credenciales por accidente. Loguear el body completo de una request POST puede dejar contraseñas y tokens en texto plano dentro del log. Sanitizar lo que se loguea es parte del diseño.
• Logs sin contexto suficiente para reconstruir. Registrar “user 12345 did action X” sin timestamp con TZ, sin IP, sin ID de la sesión, sin ID de la request. Imposible para un investigador correlacionar después.
• No alertar sobre eventos críticos. Tener todos los logs pero no monitorear cambios sensibles (alta de admin, cambio de contraseña masivo, accesos privilegiados fuera de hora). Es como tener cámaras pero apagar las alarmas.

Tabla resumen: las tres etapas comparadas

Recapitulación

El flujo de toda decisión de acceso se descompone en tres etapas secuenciales y un pilar transversal:

• Identificación — el sujeto dice quién es. No prueba nada por sí sola; es solo una etiqueta candidata.
• Autenticación — el sujeto prueba esa afirmación con uno o más factores. Resultado: una sesión o token válido.
• Autorización — para cada acción solicitada, el sistema decide si permitir o denegar basándose en los claims y las políticas. Se evalúa una y otra vez, no solo al inicio.
• Auditoría — registra cada evento de las tres etapas en paralelo, alimentando SIEM, ITDR y Compliance. No es una cuarta etapa, es un pilar que las sostiene a las tres.

La nomenclatura “AAA” (3 A’s) viene del estándar RADIUS y agrupa Authentication, Authorization, Accounting. Algunos materiales reescriben esto como “4 A’s” añadiendo Audit, pero accounting y audit son conceptualmente lo mismo. Lo que importa es que entiendas la función de cada uno, no cuántas A’s tienes en tu lista.

Tres preguntas para autoevaluarte

1. Una app web te entrega solo el username del usuario después del login, sin más información. ¿Está autenticando, autorizando o solo identificando? ¿Qué tendría que hacer la app para autorizar correctamente las acciones siguientes?
2. Diseña la auditoría de un endpoint de transferencia bancaria. ¿Qué eventos registras, con qué campos, y en qué orden? Considera que un investigador externo debe poder reconstruir el flujo completo seis meses después.
3. Tu CISO dice “ya tenemos MFA, estamos protegidos contra acceso indebido”. ¿Cuál es tu contraargumento usando lo que aprendiste sobre las tres etapas?