Tema 3
En seguridad de acceso, los errores de diseño más persistentes no siempre aparecen por desconocer una tecnología, sino por mezclar conceptos que cumplen funciones distintas. Identidad, autenticación, autorización y accounting forman un conjunto relacionado, pero no intercambiable. Separarlos con claridad mejora el diseño, la implementación y la auditoría.
En conversaciones técnicas es frecuente escuchar expresiones como “el sistema ya autentica roles” o “si el token es válido entonces está autorizado”. Estas frases muestran una confusión común: usar palabras distintas para describir etapas diferentes del mismo flujo como si fueran equivalentes.
Ese problema no es meramente terminológico. Cuando una aplicación mezcla identidad, autenticación, autorización y trazabilidad en una sola lógica difusa, aparecen permisos inconsistentes, código difícil de mantener, controles incompletos y auditoría deficiente.
Por eso este tema pone orden conceptual. Antes de estudiar factores de autenticación, modelos de permisos o protocolos como OAuth 2.0, conviene fijar con claridad qué problema resuelve cada capa.
Podemos pensar estos conceptos como partes de una cadena de confianza:
Estas piezas se alimentan entre sí, pero no se sustituyen. Un sistema puede autenticar muy bien y autorizar mal. Puede autorizar correctamente y aun así no dejar registros suficientes. Puede tener una identidad definida de forma pobre y entonces contaminar el resto del flujo.
La identidad responde a la pregunta “¿quién es este sujeto dentro del sistema?”. No se trata todavía de demostrar nada, sino de representar al sujeto de forma consistente.
Esa representación incluye identificadores, atributos, relaciones, estado y, en muchos casos, vínculos con una organización, tenant, grupo o unidad funcional. La identidad puede ser humana o no humana, persistente o temporal, local o federada.
Si la identidad está mal modelada, todos los pasos posteriores se debilitan. Por ejemplo, si un sistema no diferencia correctamente personas de cuentas técnicas, puede aplicar políticas inadecuadas. Si no distingue identidades activas de suspendidas, puede dejar accesos abiertos por error.
La autenticación responde a la pregunta “¿puedo confiar razonablemente en que este sujeto corresponde a la identidad declarada?”. Para ello evalúa pruebas: contraseñas, certificados, tokens, passkeys, OTP, biometría o combinaciones de varios factores.
Autenticar no consiste solo en validar un secreto. También implica considerar el contexto de uso, la fortaleza del mecanismo, la resistencia al replay, la vigencia de la credencial y, en entornos modernos, señales de riesgo o comportamiento anómalo.
Un error habitual es pensar que una autenticación exitosa equivale a acceso total. En realidad, autenticar es solamente habilitar la siguiente pregunta: ahora que sé quién eres con cierto nivel de confianza, ¿qué puedes hacer?
La autorización responde a la pregunta “¿qué acciones están permitidas para esta identidad sobre este recurso, en este contexto?”. No evalúa si el sujeto existe ni si la prueba de identidad fue válida; toma esas piezas como insumo.
Una autorización puede apoyarse en:
Autorización no es sinónimo de “tiene sesión”. Tampoco es igual a “trae un token válido”. Un token válido puede representar una identidad real, pero aun así no autorizar la operación que intenta ejecutar.
Accounting, en el contexto AAA, se refiere al registro de actividad relevante asociada a identidades y decisiones de acceso. En entornos modernos suele hablarse más de trazabilidad, auditoría o logging de seguridad, pero la idea central es la misma.
Esta capa responde a preguntas como:
Sin accounting no hay investigación seria, no hay posibilidad de reconstruir incidentes y no hay base sólida para cumplimiento o recertificación de accesos.
| Concepto | Pregunta principal | Entrada típica | Salida o resultado |
|---|---|---|---|
| Identidad | ¿Quién es el sujeto en este ecosistema? | Datos de registro, atributos, relaciones, fuentes maestras | Representación consistente del sujeto |
| Autenticación | ¿Es realmente ese sujeto? | Credenciales, factores, señales contextuales | Nivel de confianza o autenticación exitosa/fallida |
| Autorización | ¿Qué puede hacer? | Identidad autenticada, recurso, acción, políticas | Permitir, denegar o condicionar acceso |
| Accounting | ¿Qué ocurrió y cómo queda registrado? | Eventos, decisiones, contexto, resultados | Logs, auditoría, evidencia y trazabilidad |
Supongamos una aplicación de gestión de pagos. Una persona ingresa al portal, completa login con contraseña y segundo factor, abre una factura y trata de aprobar un pago.
Si cualquiera de estas partes falla, el flujo queda incompleto. Si la autenticación es exitosa pero la autorización está mal diseñada, la persona puede aprobar pagos fuera de su alcance. Si la operación se autoriza pero no se registra, luego no habrá evidencia suficiente para investigar.
La confusión aparece porque ambas ocurren muy cerca en el tiempo y muchas aplicaciones pequeñas las implementan juntas. Por ejemplo, después del login se carga un objeto de sesión que ya contiene roles o flags, y todo parece una sola cosa.
Sin embargo, conceptualmente siguen siendo distintas:
Si esta separación no se respeta, surgen problemas como usar “si está logueado, puede entrar” para operaciones que deberían requerir controles específicos, o reutilizar un token de autenticación como si fuera prueba suficiente de privilegio para cualquier endpoint.
Otra confusión habitual es pensar que la identidad “es” la contraseña, el token o el mecanismo de login. En realidad, la identidad existe antes y después del acto de autenticación. La autenticación es un evento o proceso; la identidad es la entidad persistente representada por el sistema.
Esto se vuelve evidente cuando una persona cambia de contraseña, registra una nueva passkey o utiliza otro proveedor de identidad. El mecanismo de autenticación cambia, pero la identidad subyacente sigue siendo la misma.
Diseñar como si identidad y autenticación fueran equivalentes hace muy difícil soportar múltiples métodos de acceso, federación, recuperación de cuenta o rotación de credenciales.
En muchos proyectos, la trazabilidad se piensa al final: primero se resuelve login, luego permisos, y recién después se agregan algunos logs. Ese enfoque es débil porque la observabilidad de seguridad no se improvisa.
Un sistema serio necesita decidir desde el diseño:
Accounting no solo sirve para incidentes. También ayuda a detectar abuso interno, revisar accesos, cumplir con normas y explicar decisiones automatizadas de autorización.
Históricamente, muchos sistemas de acceso se explicaron con AAA: Authentication, Authorization y Accounting. Ese marco sigue siendo útil porque organiza tres funciones esenciales.
Sin embargo, en arquitecturas modernas el plano de identidad amplía el problema. Ya no basta con autenticar y autorizar dentro de una única aplicación. Hay directorios, proveedores de identidad, federación, SSO, identidades no humanas, gobierno de ciclo de vida y múltiples dominios de confianza.
Por eso hoy suele hablarse de AAA dentro de un ecosistema IAM más amplio. AAA sigue siendo válido, pero ya no alcanza para describir todo el problema por sí solo.
Imaginemos una API de facturación protegida con bearer tokens.
Es un error común asumir que “token válido” equivale a “operación autorizada”. Validar el token es solo una parte. La API todavía debe decidir si la acción concreta está permitida y dejar trazabilidad suficiente.
Supongamos una organización con SSO. Un empleado inicia sesión en el proveedor de identidad y luego accede al portal de recursos humanos y al sistema financiero.
La autenticación puede ser única, pero la autorización no necesariamente lo es. Ambos sistemas consumen la misma identidad autenticada, aunque cada uno aplica reglas diferentes. Un empleado puede ver recibos de sueldo en el portal de RR.HH. y no tener ningún permiso para aprobar órdenes de compra en finanzas.
Además, cada sistema debería registrar de forma independiente y correlacionable las acciones relevantes. Compartir autenticación no elimina la necesidad de autorización local ni de accounting específico.
En sistemas modernos, estas responsabilidades suelen estar distribuidas:
Esta separación no es burocracia. Permite escalabilidad, mantenimiento, interoperabilidad y una mejor delimitación de responsabilidades. También evita que una sola pieza concentre demasiada lógica difícil de verificar.
La claridad conceptual en identidad y acceso no es un lujo académico. Es una condición práctica para construir sistemas que puedan autenticarse, autorizarse y auditarse de forma correcta. Cuando estos conceptos se mezclan, el resultado suele ser un control de acceso frágil, difícil de explicar y más difícil todavía de evolucionar.
En el próximo tema entraremos en los modelos de autenticación y en los distintos tipos de factores: conocimiento, posesión, inherencia y contexto.