Audiencia (en tokens)

Definición

Imagina que recibes un cheque a tu nombre por 1000 euros. Ese cheque solo lo puedes cobrar tú - tiene tu nombre como destinatario. Si alguien intentara cobrarlo en otro banco o a nombre de otra persona, sería rechazado. El claim “audience” (aud) en tokens JWT funciona exactamente igual - especifica para quién está destinado ese token, y cualquier servicio que lo reciba debe verificar que es el destinatario legítimo.

El audience es uno de los claims más importantes pero frecuentemente ignorados en JWTs. Cuando Auth0 o cualquier servidor de autorización emite un token, incluye el campo “aud” que dice “este token es válido SOLO para api.example.com”. Si ese mismo token se envía a payments.example.com, aunque la firma sea perfectamente válida, payments.example.com debe rechazarlo porque no es el destinatario previsto.

¿Por qué es tan crítico? Sin validación de audience, un atacante podría robar un token de un servicio menos crítico (como un servicio de notificaciones) y usarlo para acceder a uno más sensible (como el servicio de pagos). El token es técnicamente válido - misma firma, mismo usuario - pero no estaba destinado para ese uso. Es como usar tu pase del gimnasio para entrar en la zona VIP del hotel: mismo formato de tarjeta, pero diferente propósito.

Ejemplo

Microservicios con Diferentes Niveles de Sensibilidad: Tu plataforma tiene api.users.com (datos básicos) y api.payments.com (transacciones financieras). Un token con audience “api.users.com” permite ver perfiles, pero si alguien intenta usarlo en api.payments.com para transferir dinero, debe ser rechazado aunque el usuario tenga permisos de pago - el token simplemente no era para ese servicio.

Aplicaciones Multi-Tenant: En una plataforma SaaS, diferentes clientes tienen diferentes APIs. Un token emitido para tenant-a.api.com no debe funcionar en tenant-b.api.com, aunque ambos usen el mismo servidor de autorización. El audience garantiza el aislamiento entre tenants.

APIs Públicas vs Internas: Tu empresa tiene una API pública para desarrolladores externos y una API interna para aplicaciones propias. Los tokens para la API pública tienen audience “public.api.mycompany.com” y no deben aceptarse en “internal.api.mycompany.com”, donde hay operaciones más sensibles.

Single Sign-On Empresarial: Cuando un empleado inicia sesión via SSO, obtiene tokens específicos para cada aplicación que accede. El token para Slack tiene audience de Slack, el de Jira tiene audience de Jira. Si alguien intercepta el token de Slack, no puede usarlo para acceder a los datos de Jira.

Analogía

El Cheque Nominativo: Un cheque dice “Páguese a: Juan Pérez.” Solo Juan puede cobrarlo. Si María encuentra el cheque e intenta cobrarlo, el banco lo rechaza aunque el cheque sea auténtico y tenga fondos. El audience es el nombre del beneficiario en el token.

La Entrada del Concierto con Zona Asignada: Tu entrada dice “Zona A - Pista.” Te permite entrar al recinto pero no a la zona VIP aunque el código de barras sea válido. La entrada fue emitida para un propósito específico, y el personal de cada zona verifica que corresponde.

La Receta Médica: Una receta válida para una farmacia dice “Dispensar en: Farmacia Central.” Aunque la receta sea auténtica y el medicamento esté disponible en otras farmacias, solo la indicada debe dispensarla. Esto previene fraudes y controla la distribución.

El Paquete con Dirección Específica: Un paquete tiene remitente, destinatario y contenido válidos. Si el cartero lo entrega en otra dirección porque “es del mismo barrio”, estaría mal. El paquete solo debe entregarse en la dirección indicada, sin importar que otras direcciones “podrían” recibirlo.

Code Example

// Validación de audiencia en middleware JWT
const jwt = require('jsonwebtoken')

const validateAudience = (req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1]

  if (!token) {
    return res.status(401).json({ error: 'Token no proporcionado' })
  }

  try {
    const decoded = jwt.verify(token, process.env.JWT_SECRET, {
      // CRÍTICO: Siempre validar audiencia
      audience: 'https://api.miservicio.com',
      // También validar emisor
      issuer: 'https://auth.miservicio.com',
      algorithms: ['RS256'] // Prevenir confusión de algoritmo
    })

    req.user = decoded
    next()
  } catch (err) {
    if (err.name === 'JsonWebTokenError' && err.message.includes('audience')) {
      return res.status(403).json({
        error: 'Token no destinado para este servicio',
        details: 'Audiencia no coincide'
      })
    }
    return res.status(401).json({ error: 'Token inválido' })
  }
}

// Soporte para múltiples audiencias (cuando el token es válido para varios servicios)
const validateMultiAudience = (req, res, next) => {
  const token = req.headers.authorization?.split(' ')[1]

  const decoded = jwt.verify(token, process.env.JWT_SECRET, {
    // Aceptar token si CUALQUIERA de estas audiencias coincide
    audience: [
      'https://api.miservicio.com',
      'https://api-v2.miservicio.com'
    ]
  })

  req.user = decoded
  next()
}

Notas de Seguridad