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

Tres toques, seis decisiones

Sara López quiere un préstamo de 5.000 $. Abre la app de su banco, escribe su email y su contraseña, mete un código del móvil, elige el préstamo, confirma con su PIN de operaciones y, unos segundos después, la pantalla dice “Préstamo aprobado”. Para ella fueron tres toques. Por debajo, los sistemas del banco respondieron tres preguntas distintas y apuntaron cada respuesta: ¿quién dices ser?, ¿puedes demostrarlo?, ¿tienes permiso para hacer esto?

Esas tres preguntas son las etapas de toda decisión de acceso: identificación, autenticación y autorización. A su lado funciona una cuarta pieza que no es una etapa, sino un pilar que atraviesa las tres: la auditoría. En el dominio de fundamentos vimos qué es una identidad digital, los tipos modernos de identidad, cómo encaja el IAM en la ciberseguridad, las olas históricas, los cinco dominios y el ciclo operativo. Ahora entramos en el corazón técnico de la gestión de accesos: cómo decide una aplicación, en cada petición, si una identidad puede hacer algo o no.

Si separas bien estas piezas, todo lo que viene después, los factores de MFA, los modelos de autorización, Zero Trust, la gestión de sesiones, encaja solo. Si las mezclas, te liarás tú y, en una conversación real, liarás a la gente con la que trabajas. Además es una pregunta clásica en las entrevistas para puestos de IAM: “explica en menos de un minuto la diferencia entre autenticación y autorización”. La mayoría tropieza. Responderla bien, y añadir el matiz de la identificación y la auditoría, te hace destacar.

Primero, lo de las “3 o 4 A”

Si has leído sobre IAM por tu cuenta, seguramente te has topado con versiones que parecen contradecirse. Unos libros y cursos hablan de “las 3 A”: autenticación, autorización y registro (accounting). Otros hablan de “las 4 A” y añaden la auditoría. Y muchos ponen en fila identificación, autenticación, autorización y auditoría como si fueran cuatro etapas equivalentes.

El término AAA viene de RADIUS, el protocolo de autenticación y control de acceso que se usa en redes empresariales desde los años 90 y que vimos entre los veteranos. En su definición original, las tres A son autenticación, autorización y accounting, un registro del uso para facturar o auditar. La identificación queda implícita dentro de la autenticación, porque el sujeto se identifica al presentar una credencial, y la auditoría es en esencia el accounting con otro nombre. Algunas escuelas separan el registro técnico de la auditoría, la revisión que interpreta esos registros, y de ahí salen las “4 A”. En la práctica son lo mismo con dos etiquetas.

En este artículo y en todo el programa usaremos una versión más limpia: tres etapas seguidas, identificación, luego autenticación y luego autorización, más un pilar que las atraviesa todas, la auditoría. No son cuatro pasos en fila. La auditoría no espera al final; funciona a la vez que las otras tres y registra cada evento desde que el sujeto dice quién es hasta que la acción se ejecuta o se bloquea.

El flujo completo de un vistazo

Antes de desmontar cada etapa, aquí está el flujo de principio a fin.

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 seguidas, identificación (quién dices ser), autenticación (cómo lo demuestras) y autorización (qué puedes hacer), antes de que la acción se ejecute o se rechace. Cada etapa, y la acción final, envía registros a un pilar transversal de auditoría que funciona en paralelo al flujo.
  S([Sujeto]) --> ID[1. Identificación<br/>¿Quién dices ser?]
  ID --> AUTHN[2. Autenticación<br/>¿Cómo lo demuestras?]
  AUTHN --> AUTHZ[3. Autorización<br/>¿Qué puedes hacer?]
  AUTHZ --> ACTION[Acción ejecutada<br/>o rechazada]
  AUDIT[(Auditoría<br/>pilar transversal)]
  ID -.registra.-> AUDIT
  AUTHN -.registra.-> AUDIT
  AUTHZ -.registra.-> AUDIT
  ACTION -.registra.-> AUDIT

El sujeto entra por la izquierda y cruza tres puertas en orden. Primero dice quién es, luego lo demuestra y después el sistema comprueba si tiene permiso para lo que quiere hacer. Si pasa las tres, la acción se ejecuta; si falla cualquiera, se rechaza. Mientras tanto, la auditoría mira desde un lado. No interviene, pero lo apunta todo.

Etapa 1: identificación

La identificación es el sujeto diciendo quién es. Es el primer paso, el más sencillo y el que más se confunde con la autenticación. Cuando Sara escribe sara.lopez@email.com en la pantalla de inicio de sesión, se está identificando. Afirma ser la dueña de esa dirección. El sistema todavía no la cree; solo ha recibido su afirmación. De todas las identidades posibles, esa es la que ella dice que es suya.

La confusión con la autenticación viene de la pantalla. En la mayoría de los formularios de acceso, los dos pasos ocurren en una sola interacción visible: escribes el email y la contraseña en el mismo formulario, pulsas Intro y entras o no entras. Parece un solo paso. Conceptualmente son dos: la identificación es la afirmación (“soy Sara”) y la autenticación es la comprobación de que es cierta. En el mostrador de facturación del aeropuerto primero das tu nombre y luego entregas el pasaporte. Con el nombre solo no te subes al avión.

La identificación aparece de muchas formas. En un inicio de sesión web clásico es el campo de email o de usuario. En el inicio de sesión federado es elegir tu cuenta en la lista del proveedor. En una llamada a una API con un JWT es el claim sub dentro del token. Con una tarjeta inteligente es el número de serie del chip, en una conexión SSH es el usuario que va antes de la @, y en una llamada al banco es el nombre y el número de cliente que le das a quien te atiende.

En todos los casos, el identificador es solo una etiqueta. No demuestra nada por sí mismo, y por eso no tiene por qué ser secreto. Un email es público, un nombre de usuario es público, el nombre de una carga de trabajo puede ser público. La fuerza viene de la etapa siguiente, no de esconder el identificador. Un antipatrón frecuente es tratar la identificación como si fuera una credencial, por ejemplo sistemas que dan por buena la identidad de alguien solo porque conoce un número de cliente. Si yo sé tu número de cliente, no soy tú. Un atacante con tu identificador puede empezar el flujo, pero nunca debería pasar de la primera puerta. En 2026, “introduce tu número de tarjeta” como única comprobación es indefendible.

Etapa 2: autenticación

La autenticación es comprobar que la afirmación de la identificación es cierta. Sara dijo “soy Sara”; ahora tiene que demostrarlo. La prueba son uno o más factores, evidencias que idealmente solo el verdadero dueño de esa identidad podría aportar. Las tres categorías clásicas son algo que sabes (una contraseña, un PIN, una frase de paso), algo que tienes (un móvil, una llave de hardware, una tarjeta inteligente) y algo que eres (una huella, la cara, la voz). Hay dos categorías más recientes que ganan peso: algo que haces, como tu ritmo al teclear, y algo de tu contexto, como la ubicación, un dispositivo conocido o la hora habitual. El siguiente artículo las repasa en detalle.

Un solo factor es autenticación de un factor. Dos o más de categorías distintas es autenticación multifactor (MFA). Una contraseña más un PIN no es MFA, porque los dos son algo que sabes.

El flujo combinado siempre es “afirmo ser X” y luego “demuestra que eres X”. El sistema recibe la identificación, busca lo que tiene guardado para esa identidad (hashes de contraseña, claves públicas, métodos de MFA registrados), pide los factores correspondientes, compara lo recibido con lo guardado y decide. Si lo que falló fue la propia identificación porque ese usuario no existe, la buena práctica es responder con el mismo mensaje genérico que cuando falla la autenticación, “usuario o contraseña no válidos”, para que un atacante no pueda averiguar qué identificadores existen. Ese detalle muestra cómo la identificación se cuela en el primer paso de la autenticación: visualmente es un bloque, conceptualmente son dos.

Una vez autenticado, el sujeto recibe una prueba de autenticación que acompaña a cada petición posterior: una cookie de sesión firmada por el servidor, un token (un JWT o un token opaco) emitido por el proveedor de identidad, o una aserción SAML en los escenarios federados. Esa prueba no es estática. Tiene una vida limitada y condiciones en las que se revoca, y hay que comprobarla en cada uso. La autenticación no termina en el inicio de sesión; se renueva de forma implícita en cada petición cuando el sistema confirma que el token sigue siendo válido.

Etapa 3: autorización

La autorización es decidir qué puede hacer una identidad ya autenticada. La autenticación responde “¿eres de verdad Sara?”. La autorización responde “ya sé que eres Sara, pero ¿esto en concreto entra dentro de tus permisos?”.

Aquí está el error más habitual: estar autenticado no implica permiso para nada en concreto. Sara puede ser Sara de verdad y aun así no tener permiso para abrir el informe de saldos premium que intenta consultar. Su identidad está confirmada; esa acción no está autorizada. Cuando el vigilante de un edificio de oficinas comprueba tu documento en la entrada, te ha autenticado. Todavía no te ha autorizado a subir a la séptima planta. Eso depende de lo que permita tu pase de visitante o tu tarjeta de empleado.

Cada vez que un sujeto autenticado intenta hacer algo, el sistema lee los claims del token o la sesión (rol, scopes, atributos del usuario), lee la política que se aplica al recurso (quién puede leer esta tabla, quién puede aprobar este pago) y combina las dos cosas en una decisión: permitir o denegar. Esa decisión ocurre en cada acción, no una sola vez. Estás autenticado durante horas, pero se te autoriza en cada clic.

Los modelos formales de autorización son un tema propio, y los artículos posteriores dedican uno a cada modelo. En resumen: con DAC el dueño de un recurso decide quién accede; con MAC el sistema impone reglas estrictas, como en entornos militares; con RBAC los permisos se agrupan en roles y los usuarios reciben roles; con ABAC las decisiones dependen de atributos del sujeto, el recurso, la acción y el contexto; con PBAC se escriben políticas explícitas en un lenguaje formal, como el Rego de OPA; y con ReBAC los permisos salen de relaciones, como ser miembro de un equipo o propietario de un documento.

Un hábito práctico cuando diseñas una API o una app: pregúntate de forma explícita en qué parte del código ocurre la autenticación y en cuál la autorización. Si la respuesta es “en el mismo middleware”, probablemente las estás mezclando. Mantenerlas separadas hace mucho más fácil probar, depurar y reutilizar.

El pilar que lo atraviesa todo: la auditoría

La auditoría no espera al final del flujo como una etapa más. Trabaja en paralelo y registra cada evento de las otras tres. Dibujarla como cuarta etapa sugiere que ocurre después de autorizar, y eso es falso. Ocurre a la vez, atravesándolo todo, y por eso el diagrama de arriba la pone debajo, unida a cada etapa con líneas de puntos: cada etapa le envía registros sin alterar su propio flujo.

Un registro de auditoría útil recoge quién intentó qué (la identidad y la acción solicitada), cuándo (con fecha, hora y zona horaria), desde dónde (dirección IP, dispositivo y, si procede, ubicación), el resultado (éxito o fallo y, si falló, por qué) y, en las operaciones que modifican datos, qué cambió, antes y después. Los inicios de sesión correctos y fallidos, los cambios de contraseña, las solicitudes de acceso a un recurso, las acciones privilegiadas, los cierres de sesión y los cambios de configuración son eventos que merece la pena auditar.

Importa por tres razones. Normas como SOX, HIPAA, PCI DSS o el RGPD exigen registrar los eventos de identidad, y sin auditoría no pasas una auditoría externa. La detección de amenazas depende de ella: el ITDR, uno de los cinco dominios, vive de los logs de auditoría, y sin ellos no puedes detectar comportamientos anómalos. Y cuando ocurre un incidente, los logs son la única forma de reconstruir lo que pasó. Un registro de auditoría completo, fiable e imposible de manipular es lo que separa un programa de IAM serio de uno improvisado.

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

Las tres etapas forman la cadena de producción horizontal del acceso. La auditoría está debajo, recibe eventos de cada etapa y alimenta a tres consumidores: el SIEM o el SOC para el análisis general de seguridad, el ITDR para la detección de amenazas propias de la identidad y el cumplimiento normativo para los informes regulatorios.

Vuelta al préstamo de Sara

Esto es lo que pasó debajo de esos tres toques.

sequenceDiagram
  accTitle: Aprobación de un préstamo en la banca móvil a través de las tres etapas y la auditoría
  accDescr: Sara se autentica en una app bancaria con email, contraseña y un código de 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 de operaciones adicional, el préstamo se aprueba. El IdP, el motor y el servicio de préstamos envían a la auditoría los eventos de inicio de sesión, MFA, decisión de autorización y préstamo aprobado.
  actor M as Sara
  participant App as App del banco
  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 la identidad
  IdP-->>Aud: Evento: intento de inicio de sesión
  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 (dentro del límite, tipo de cuenta válido)
  M->>App: 5. PIN de operaciones (factor adicional)
  Lend-->>Aud: Evento: préstamo aprobado
  Lend->>App: 6. Confirmación

Sara se identifica con su email y presenta su primer factor, la contraseña, y el proveedor de identidad registra el intento. Le pide un segundo factor; ella mete el código del móvil y el proveedor registra que el MFA fue correcto. Después emite un JWT firmado con los claims relevantes (sub=sara.lopez, aal=2, account_type=premium). En este punto, la identificación y la autenticación están completas.

La app llama al servicio de préstamos con ese token. El servicio extrae los claims y se los envía al motor de autorización junto con la petición concreta, un préstamo de 5.000 $ a 24 meses. El motor lee la política, un máximo de 10.000 $ al año, cuentas premium habilitadas, clientes con más de seis meses en el banco, y decide permitirlo. Como es una acción de alto valor, la app le pide a Sara su PIN de operaciones, una autenticación escalonada (step-up) además de la sesión que ya tiene. Cuando llega, el préstamo se tramita y aparece la confirmación. La auditoría ha registrado el inicio de sesión, el MFA, la decisión de autorización, el paso adicional y la aprobación.

Si algo hubiera fallado por el camino, una contraseña incorrecta, un MFA rechazado, una política que deniega el préstamo, un PIN equivocado, el flujo se habría detenido y el fallo también habría quedado registrado. Esa secuencia ordenada de etapas, con el registro en paralelo al lado, es lo que permite a un investigador reconstruir cualquier evento meses después en pocos minutos.

Dónde falla cada etapa

Muchos fallos de seguridad en aplicaciones se reducen a confundir o saltarse una de estas etapas, y cada una tiene sus sospechosos habituales.

En la identificación, el error clásico es tratar el identificador como un secreto: diseñar un sistema dando por hecho que conocer un número de cliente o de empleado basta para autorizar algo, cuando esos identificadores se filtran con facilidad por un email comprometido, un pósit o una llamada. Los mensajes de error que revelan si un usuario existe (“el usuario no existe”) permiten a un atacante enumerar cuentas válidas; mejor un “credenciales no válidas” genérico. Y los sistemas que aceptan un email, un nombre de usuario o un número de empleado pero los tratan por dentro como tres identidades distintas acaban con permisos en una que no se aplican en las otras.

En la autenticación, se toman por MFA dos factores de la misma categoría. No se invalidan las sesiones al cambiar las credenciales, aunque un cambio de contraseña, sobre todo si se debe a una sospecha de compromiso, debería cerrar todas las sesiones activas. Se confía en el cliente para comprobar las credenciales, con contraseñas verificadas en JavaScript del navegador o una app móvil que decide por su cuenta que la biometría fue correcta sin confirmarlo con el back end. Y se emiten tokens de larga duración sin forma de revocarlos, de modo que un token filtrado sigue vivo hasta que caduca, a veces durante semanas.

En la autorización, el front end hace de autorizador. Ocultar el botón de “borrar” a quien no es administrador no es autorizar; es esconder interfaz. La autorización de verdad ocurre siempre en el back end, en cada petición. Se confunde autenticación con autorización, “si has iniciado sesión, puedes ir a cualquier parte”, y cualquier usuario autenticado acaba pudiendo hacer acciones de administración porque nadie comprobó sus permisos concretos. La lógica de autorización se escribe a mano y desperdigada, if user.role == 'admin' repartido por todo el código sin un punto central, lo que hace imposible auditar quién puede hacer qué y convierte cada cambio de regla en un despliegue. Y se decide solo por el rol, sin contexto, dejando que un administrador lea cualquier dato a cualquier hora desde cualquier dispositivo, cuando las arquitecturas modernas tienen también en cuenta la hora, la ubicación y el estado del dispositivo.

En la auditoría, los logs que viven en la misma base de datos que los datos de negocio los puede borrar un atacante con credenciales de administrador; tienen que ir a un sitio donde el atacante no pueda escribir, como un almacenamiento de una sola escritura o un SIEM externo. Registrar el cuerpo completo de una petición POST puede dejar contraseñas y tokens en claro, así que decidir qué no se registra forma parte del diseño. Los logs sin contexto suficiente, “el usuario 12345 hizo X” sin zona horaria, IP, ID de sesión ni ID de petición, no se pueden correlacionar después. Y tener todos los logs sin alertar de los eventos críticos, como ascensos a administrador, cambios masivos de contraseña o accesos privilegiados fuera de horario, es como instalar cámaras y apagar la alarma.

Cada uno de estos fallos ha provocado brechas reales y publicadas. Cuando diseñas o revisas una aplicación, recorrer las tres etapas y la auditoría con esta lista en la mano lleva unos veinte minutos y puede ahorrarte un incidente muy caro.

Las tres etapas lado a lado

Resumen

Toda decisión de acceso se descompone en tres etapas seguidas y un pilar que las atraviesa. La identificación es el sujeto diciendo quién es; por sí sola no demuestra nada y es solo una etiqueta candidata. La autenticación es el sujeto demostrando esa afirmación con uno o más factores, y su resultado es una sesión o un token válidos. La autorización es el sistema decidiendo, para cada acción solicitada, si la permite o la deniega según los claims y las políticas, una y otra vez y no solo al principio. La auditoría registra en paralelo cada evento de las tres etapas y alimenta el SIEM, el ITDR y el cumplimiento normativo; no es una cuarta etapa, sino el pilar que sostiene a las otras tres.

El nombre “AAA” viene de RADIUS y agrupa autenticación, autorización y accounting. Algunos materiales lo convierten en “4 A” añadiendo la auditoría, pero el registro y la auditoría son la misma idea. Lo que importa es entender qué hace cada pieza, no cuántas A tiene la lista.

Tres preguntas para ponerte a prueba

1. Después del inicio de sesión, una app web solo guarda el nombre de usuario y nada más. ¿Está autenticando, autorizando o solo identificando? ¿Qué necesitaría la app para autorizar correctamente las acciones siguientes?
2. Diseña la auditoría de un endpoint de transferencias bancarias. ¿Qué eventos registrarías, con qué campos y en qué orden? Ten en cuenta que un investigador externo tiene que poder reconstruir todo el flujo seis meses después.
3. Tu CISO dice: “Ya tenemos MFA, así que estamos protegidos frente a accesos no autorizados”. ¿Cuál es tu contraargumento con lo que has aprendido sobre las tres etapas?