Autenticación, autorización e identidad: diferenciá estos 3 conceptos clave de seguridad

Introducción

Cuando hablamos de seguridad en aplicaciones web o sistemas distribuidos, es común que los términos autenticación, autorización e identidad se mezclen sin distinguir sus roles. Aunque guardan relación, cada uno resuelve un problema distinto:

• La identidad responde a ¿quién eres? (una representación del sujeto).
• La autenticación verifica si sos realmente quien decís ser (una prueba de identidad).
• La autorización determina qué podés hacer (permisos y capacidades sobre recursos).

Entender estas diferencias es esencial para diseñar sistemas robustos, cumplir normativas (como GDPR, ISO 27001) y evitar brechas de seguridad costosas. Este artículo explica cada concepto con ejemplos prácticos, un diagrama visual que los relaciona y mejores prácticas que podés aplicar hoy mismo.

Definiciones básicas

Autenticación

La autenticación es el proceso de demostrar que la identidad declarada es verdadera. Funciona como una contraseña que abre una caja fuerte: primero hay que probar que se tiene la clave correcta antes de que la caja se desbloquee.

Casos de uso típicos:

• Inicio de sesión con usuario/contraseña.
• Inicio de sesión con factor multifactor (SMS, Google Authenticator, token hardware).
• Verificación con credenciales memorizadas (biometría, facial, por voz).
• Validación con tokens de acceso (JWT, OAuth2).

Ejemplo de flujo de autenticación

# Pseudocódigo simplificado de un endpoint de login
POST /auth/login
{
  "user": "alice",
  "pass": "secret123"
}

# 1. Buscar usuario en base de datos
user = db.users.find_one({"username": "alice"})

# 2. Verificar contraseña (hash comparado)
if not bcrypt.checkpw("secret123", user["password_hash"]):
    return 401, {"error": "Credenciales inválidas"}

# 3. Generar token firmado (JWT)
token = jwt.encode({"sub": user["_id"], "exp": now + 3600}, SECRET_KEY)
return 200, {"access_token": token}

Conclusión clave: Si la autenticación falla, el sistema nunca avanza a la parte de autorización.

Autorización

La autorización responde a ¿qué recursos o acciones puede realizar el sujeto autenticado? Una vez verificada la identidad, el sistema asigna permisos basados en roles, relaciones, atributos o políticas.

Técnicas comunes:

• Control de acceso basado en roles (RBAC).
• Control de acceso basado en atributos (ABAC).
• Listas de control de acceso (ACL).
• Evaluación de políticas con herramientas como OPA, Zanzibar, etc.

Ejemplo de verificación de autorización

def check_permission(user_id, resource_id, action):
    # 1. Recuperar el rol del usuario (simplificado)
    role = db.user_roles.find_one({"user_id": user_id})["role"]

    # 2. Obtener permisos del rol
    perms = db.roles_permissions.find_one({"role": role})["permissions"]

    # 3. Comprobar si el permiso existe
    if f"{resource_id}:{action}" in perms:
        return True
    return False

# Uso dentro de una ruta protegida
if not check_permission(current_user_id, target_resource, "write"):
    return 403, {"error": "Prohibido"}

Conclusión clave: La autorización no depende solo de quién eres, sino de qué se te permite hacer.

Identidad

La identidad es la representación formal de una entidad (usuario, servicio, dispositivo, cosa) dentro del sistema. No incluye verificación ni permisos; simplemente define los atributos básicos del sujeto (por ejemplo, un ID de usuario, nombre, email, atributos técnicos).

Tipos de identidad:

• Identidades de usuario: perfiles humanos.
• Identidades de servicio: cuentas de aplicaciones, microservicios.
• Identidades máquina-a-máquina: nodos, contenedores.

Ejemplo de modelo de identidad

{
  "user_id": "u_12345",
  "username": "alice",
  "email": "alice@example.com",
  "attributes": {
    "department": "engineering",
    "level": "staff",
    "mfa_enabled": true
  },
  "created_at": "2024-01-15T09:23:00Z",
  "last_login": "2024-09-02T14:11:00Z"
}

Conclusión clave: La identidad es estática en el sentido de que describe quién es el sujeto, pero puede evolucionar (cambios de email, atributos nuevos).

Diagrama visual: cómo se relacionan

flowchart TD
    A[Identidad] --> B[Autenticación]
    B --> C[Usuario Verificado]
    C --> D[Autorización]
    D --> E[Permisos / Acciones]
    A -.-> D
    style A fill:#e0f7fa,stroke:#006064
    style B fill:#fff3e0,stroke:#e65100
    style D fill:#f3e5f5,stroke:#6a1b9a

• Identidad es el nodo base (color azul claro). Describe la entidad.
• Autenticación (naranja) transforma esa identidad en un usuario verificado.
• Autorización (morado) recibe el usuario verificado y lo vincula (a veces directamente con la identidad) a permisos específicos.

Flujo típico en aplicaciones

1. Registro / aprovisionamiento → se crea una entrada de identidad.
2. Inicio de sesión → el usuario presenta credenciales → se ejecuta la autenticación → se emite un token / sesión.
3. Llamada a la API → el token es validado → el sistema recupera la identidad (a menudo del token) y ejecuta una política de autorización.
4. Auditoría y monitoreo → se registran los resultados de autenticación/autorización para detección de anomalías.

Ejemplo con OAuth2 + OPA (Open Policy Agent):

• El cliente envía client_credentials → el proveedor de OAuth emite un access_token (autenticación del cliente).
• El token se envía a una API que consulta OPA con el user, resource, action.
• OPA evalúa políticas almacenadas en archivos YAML → permite o deniega (autorización).

Casos de uso comunes y errores

Buenas prácticas

1. Usar un flujo de identidad unificado – almacenar la identidad en un directorio de usuarios central (LDAP, Azure AD, Okta, Keycloak). Esto garantiza consistencia y facilita auditorías.
2. Adoptar un enfoque basado en políticas – en lugar de if/else anidados, delegar autorización a un motor de políticas (OPA, Casbin, Zanzibar). Esto hace que las reglas sean declarativas y fáciles de revisar.
3. Separar el almacenamiento de tokens de la identidad – un token JWT debe contener solo lo estrictamente necesario (sub, exp, scope). Los atributos completos del usuario deben consultarse desde la base de datos de identidades al ejecutar políticas.
4. Implementar MFA para accesos sensibles – obliga a factores adicionales para operaciones de alto riesgo (cambios de contraseña, acceso a datos).
5. Auditar cada paso – registrar intentos de autenticación fallidos, decisiones de autorización y cambios en identidades. Alertar sobre patrones anómalos (ej., múltiples fallos, cambios de rol bruscos).
6. Versionar esquemas de identidad – cuando agregues un nuevo atributo, usa migraciones o un backend sin estado que maneje versiones.
7. Usar TLS en todo momento – proteger credenciales, tokens y datos de identidad tanto en tránsito como en reposo.
8. Limitar el alcance de los tokens – emitir tokens de acceso de corta duración y usar tokens de actualización rotativos. Nunca exponer tokens firmados en URLs.

Conclusión

• Identidad = quién eres (un registro).
• Autenticación = demostras que sos quien decís ser (verificación).
• Autorización = qué podés hacer (permisos y políticas).

Estos tres pilares trabajan juntos, pero cada uno resuelve un problema diferente. Diseñar sistemas claros que traten cada capa por separado hace que sea más fácil implementar medidas de seguridad, cumplir normativas y mantener la credibilidad frente a ataques.

Aplicando un diagrama de flujo mental como el que se muestra, podés validar que un usuario pasa por autenticación antes de autorizar acciones, y que la identidad de referencia nunca queda desactualizada. Empezá hoy mismo:

1. Revisa tus flujos actuales y marca dónde se mezclan autenticación, autorización e identidad.
2. Elige un proveedor de identidad sólido si aún no usas uno.
3. Implementa un motor de políticas para autorización.
4. Instrumenta logs que capturen cada paso.

Con estos cambios, tendrás un modelo de seguridad más claro, sostenible y menos propenso a errores de concepto costosos.