RFC 8707

Definicion

Aquí hay un problema de seguridad que pilla desprevenidos a muchos desarrolladores: solicitas un token OAuth para acceder a una API, pero ese mismo token potencialmente podría usarse para acceder a una API completamente diferente si comparten el mismo servidor de autorización. RFC 8707 aborda esta vulnerabilidad permitiéndote especificar explícitamente para qué API (recurso) debería funcionar un token.

Piénsalo de esta manera: cuando solicitas un access token de Google, ¿debería ese token funcionar con Gmail, Google Drive, YouTube y todos los demás servicios de Google? Eso violaría el principio de mínimo privilegio. RFC 8707 introduce el parámetro “resource”, permitiéndote decir “solo quiero un token que funcione con Gmail” - nada más.

Esto es especialmente importante en entornos empresariales donde un único proveedor de identidad gestiona el acceso a docenas de APIs internas. Sin indicadores de recursos, un token emitido para el sistema de RRHH podría teóricamente funcionar contra el sistema de nóminas o la base de datos de clientes. Con RFC 8707, cada token está bloqueado a APIs específicas, reduciendo dramáticamente el radio de impacto si un token se ve comprometido. El token en sí lleva un claim de “audience” (audiencia) que la API de destino valida - si la audiencia no coincide, el acceso se deniega.

Ejemplo

Plataformas multi-API: Slack tiene APIs para mensajería, archivos, gestión de usuarios y funciones de administración. Cuando una app solicita un token, RFC 8707 le permite especificar exactamente qué APIs necesita: resource=https://api.slack.com/messages&resource=https://api.slack.com/files. El token es inútil contra APIs de administración.

Arquitecturas de microservicios: En un sistema con servicios separados para pedidos, inventario, envíos y facturación, cada servicio tiene su propio indicador de recurso. Un token emitido para el servicio de pedidos no puede usarse para acceder a datos de inventario, incluso si ambos servicios usan el mismo servidor de autenticación.

APIs bancarias: Las regulaciones de open banking requieren control de acceso preciso. Una app de presupuestos podría obtener un token solo válido para resource=https://banco.com/accounts/read - no puede iniciar transferencias aunque el token se filtre.

Integraciones de terceros: Cuando una empresa permite que apps de terceros se integren, los indicadores de recursos aseguran que esas apps solo puedan acceder a las APIs específicas para las que fueron aprobadas - no curiosear por todo el sistema.

Analogia

La Tarjeta de Acceso Específica del Edificio: En lugar de una llave maestra que abre todas las puertas en un campus corporativo, recibes una tarjeta programada solo para edificios específicos. Incluso si alguien roba tu tarjeta, solo pueden acceder a los edificios para los que estabas autorizado - no a la torre ejecutiva o al centro de datos.

El Billete de Clase de Avión: Tu billete de clase turista te sube al avión, pero no te da acceso al lounge business o la cabina de primera clase. Cada privilegio está explícitamente especificado. Los tokens de RFC 8707 funcionan igual - el acceso está explícitamente delimitado.

La Pulsera de Zona del Concierto: En grandes eventos, diferentes pulseras dan acceso a diferentes zonas: entrada general, VIP, backstage. No puedes usar tu pulsera de entrada general para ir al backstage, aunque estés “dentro” del recinto. Los indicadores de recursos crean estas zonas para APIs.

La Categoría de Alquiler de Coches: Cuando alquilas un coche, estás autorizado para una categoría específica de vehículo. Tu reserva de coche compacto no te deja irte con un SUV de lujo, aunque estén todos en el mismo aparcamiento. Los indicadores de recursos te restringen a “categorías” específicas de APIs.

Code Example

// Petición de token con indicador de recurso
POST /token [HTTP/1.1](https://reference.apios.info/es/terms/http-1-1/)
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=AUTH_CODE&
redirect_uri=https://app.com/callback&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET&
resource=https://api.example.com&
resource=https://files.example.com

// La respuesta incluye el claim de audience
{
  "access_token": "eyJhbGc...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "scope": "read write"
}

// El payload del JWT incluye el claim aud
{
  "aud": [
    "https://api.example.com",
    "https://files.example.com"
  ],
  "iss": "https://auth.example.com",
  "sub": "user123",
  "exp": 1516239022
}

Notas de Seguridad