Identidad y acceso

Gestión de identidad y control de acceso en arquitecturas distribuidas: autenticación, autorización, JWT, OAuth2 y modelos como RBAC.

Por qué la identidad es el primer pilar de seguridad

En cualquier sistema distribuido, la primera pregunta que debe responderse ante cada request es: ¿quién eres y qué puedes hacer? Sin una gestión sólida de identidad y acceso, el resto de las medidas de seguridad pierden sentido.

La identidad no es solo “login y contraseña”. Es un sistema completo que abarca cómo se verifican las credenciales, cómo se representan los permisos, cómo se propagan las decisiones de acceso entre servicios y cómo se revocan cuando es necesario.

Autenticación vs autorización

Estos dos conceptos se confunden frecuentemente, pero son responsabilidades distintas:

Autenticación (AuthN)

Responde a la pregunta: ¿quién eres?

Verifica la identidad del usuario o servicio
Se basa en credenciales: contraseña, token, certificado, biometría
Produce un artefacto de identidad (típicamente un token)
Ocurre una vez al inicio de la sesión (o al renovar el token)

Autorización (AuthZ)

Responde a la pregunta: ¿qué puedes hacer?

Verifica los permisos del usuario autenticado
Se basa en roles, permisos, políticas o atributos
Se evalúa en cada operación que requiere acceso
Puede ser tan simple como un rol o tan complejo como políticas basadas en atributos

Usuario → [Autenticación] → "Eres Juan, rol: editor"
Juan → [Autorización] → "¿Puede Juan editar este recurso?" → Sí/No

JSON Web Tokens (JWT)

JWT es el estándar más utilizado para representar claims de identidad en arquitecturas distribuidas.

Estructura de un JWT

Un JWT tiene tres partes separadas por puntos:

header.payload.signature

{
  "header": {
    "alg": "RS256",
    "typ": "JWT"
  },
  "payload": {
    "sub": "user-456",
    "email": "maria@ejemplo.com",
    "role": "admin",
    "permissions": ["read:users", "write:users", "read:orders"],
    "iat": 1705312200,
    "exp": 1705314000,
    "iss": "auth-service",
    "aud": "api-gateway"
  }
}

Claims importantes

Claim	Significado
`sub`	Subject — identificador único del usuario
`iss`	Issuer — quién emitió el token
`aud`	Audience — para quién está destinado
`exp`	Expiration — cuándo expira
`iat`	Issued At — cuándo fue emitido
`role`	Rol del usuario (claim personalizado)
`permissions`	Permisos específicos (claim personalizado)

Ventajas del JWT en microservicios

Stateless: cada servicio puede verificar el token sin consultar una base de datos central
Propagación: el token viaja en el header Authorization entre servicios
Autocontenido: incluye toda la información necesaria para tomar decisiones de acceso

Riesgos y mitigaciones

Token robado: usar tiempos de expiración cortos (15–30 minutos)
Claims desactualizados: el token puede tener permisos que ya fueron revocados; usar refresh tokens y listas de revocación
Tamaño excesivo: no incluir datos innecesarios en el payload

OAuth 2.0

OAuth 2.0 es un framework de autorización que permite a aplicaciones de terceros acceder a recursos en nombre de un usuario, sin exponer sus credenciales.

Flujos principales

Authorization Code (con PKCE)

El flujo más seguro, recomendado para aplicaciones web y móviles:

sequenceDiagram
    participant U as Usuario
    participant App as Aplicación
    participant AS as Authorization Server
    participant API as Resource Server

    U->>App: Clic en "Iniciar sesión"
    App->>AS: Redirect a /authorize (+ code_challenge)
    AS->>U: Muestra pantalla de login
    U->>AS: Ingresa credenciales
    AS->>App: Redirect con authorization code
    App->>AS: POST /token (code + code_verifier)
    AS-->>App: Access token + refresh token
    App->>API: Request con access token
    API-->>App: Datos protegidos

Client Credentials

Para comunicación servicio-a-servicio, sin usuario involucrado:

Servicio A → POST /token (client_id + client_secret) → Access token
Servicio A → Request a Servicio B con access token

Cuándo usar OAuth 2.0

Integración con proveedores de identidad externos (Google, GitHub, Azure AD)
Aplicaciones que necesitan acceder a APIs en nombre del usuario
Escenarios donde se necesita consentimiento explícito del usuario

Modelos de control de acceso

RBAC — Role-Based Access Control

El modelo más común. Los permisos se asignan a roles, y los roles se asignan a usuarios.

Usuario → Rol → Permisos

Ejemplo:
  María → admin → [crear_usuario, eliminar_usuario, ver_reportes]
  Juan  → editor → [editar_contenido, ver_reportes]
  Ana   → viewer → [ver_reportes]

Ventajas: simple de entender, fácil de auditar, suficiente para la mayoría de aplicaciones.

Limitaciones: no maneja bien permisos condicionales (“puede editar solo sus propios recursos”).

ABAC — Attribute-Based Access Control

Los permisos se evalúan en función de atributos del usuario, del recurso y del contexto:

Política: "Un usuario puede editar un documento SI:
  - usuario.departamento == documento.departamento
  - Y documento.estado != 'publicado'
  - Y hora_actual está dentro del horario laboral"

Ventajas: extremadamente flexible, maneja casos complejos.

Limitaciones: más difícil de implementar, auditar y depurar.

Recomendación práctica

Empieza con RBAC. Solo migra a ABAC si tienes requisitos de acceso condicional que RBAC no puede resolver. Muchos sistemas combinan ambos: RBAC para la estructura base y reglas ABAC para casos específicos.

Propagación de identidad entre servicios

En una arquitectura de microservicios, la identidad debe propagarse de servicio en servicio:

Frontend → API Gateway → BFF → Servicio A → Servicio B
           [verifica]   [propaga JWT]  [propaga JWT]

Estrategias de propagación

Token passthrough: el mismo JWT del usuario se pasa entre servicios. Simple pero el token puede tener más permisos de los necesarios.
Token exchange: cada servicio solicita un nuevo token con scope reducido para el siguiente servicio. Más seguro pero más complejo.
Service mesh con mTLS: la identidad del servicio se verifica a nivel de red, y la identidad del usuario viaja en el JWT. Combina ambas capas.

Buenas prácticas

Centraliza la autenticación en un servicio dedicado (Auth Service o Identity Provider)
Usa tokens de corta duración con refresh tokens
No almacenes tokens en localStorage — usa cookies httpOnly o memoria
Implementa revocación de tokens para casos de compromiso
Registra todos los eventos de autenticación para auditoría
Usa HTTPS siempre — nunca transmitas credenciales en texto plano
Aplica el principio de mínimo privilegio: cada servicio y usuario solo tiene los permisos que necesita

Resumen

La gestión de identidad y acceso es la base sobre la que se construye toda la seguridad del sistema. JWT proporciona un mecanismo stateless para propagar identidad entre servicios, OAuth 2.0 estandariza los flujos de autorización, y modelos como RBAC y ABAC definen cómo se toman las decisiones de acceso. La clave es diseñar estos mecanismos desde el inicio, no añadirlos como un parche posterior.