Entrevista de diseño de sistemas: ¿Cómo diseñarías un verificador de autoridad delegada vinculada a la solicitud?

Planteamiento y alcance

Diseña una capa de verificación de autoridad delegada para un agente, carga de trabajo o trabajo por lotes que actúa en nombre de una persona u organización para gastar dinero, consumir recursos medidos, divulgar datos regulados o mutar el estado de producción. El sistema debe demostrar una autoridad delimitada antes de procesar una solicitud protegida. El planteamiento hace referencia a un Internet-Draft de HTTPAPI de la IETF de 2026; sigue siendo un trabajo en progreso, no es un RFC final y no es un protocolo de pagos.

Qué evalúa el entrevistador

• Separar la autenticación de identidad, la autorización delegada, la integridad de la solicitud y la liquidación.
• Diseñar desafíos 401, denegaciones 403, nonces, expiración y vinculación de solicitudes.
• Manejar la reproducción (replay), la reutilización entre inquilinos (cross-tenant), proxies, rotación de claves y auditabilidad.
• Hacer cumplir presupuestos, políticas y límites con fallo seguro (fail-closed) antes de acciones de alto impacto.

Preguntas para aclarar antes de responder

1. ¿La acción protegida es una exportación de datos, una escritura en producción, una llamada descendente (downstream) o un consumo presupuestado?
2. ¿Quién opera el principal, el emisor, el solicitante delegado y el verificador?
3. ¿La autoridad debe vincularse al método HTTP, URI de destino, digest de la solicitud o solo a un alcance de recursos?
4. ¿Se permite la verificación sin conexión (offline) y cómo se manejan la disponibilidad de nonces y el desfase de reloj (clock skew)?
5. ¿Un fallo debería rechazar la solicitud, requerir aprobación humana o degradarse a solo lectura?

Marco de respuesta de 30 segundos

Divide el problema en cuatro capas: la identidad existente demuestra quién es el solicitante; la delegación indica en nombre de quién actúa, qué puede hacer y el límite; la vinculación de la solicitud restringe la prueba a una sola solicitud; la política decide si la ejecución está permitida ahora. Devuelve un desafío 401 cuando no exista una prueba aceptable y 403 cuando la prueba se comprenda pero sea insuficiente. Incluye emisor, solicitante, principal, expiración, nonce, método, URI, digest y límites de presupuesto. Ejecuta solo después de la verificación, aplica fallo seguro y audita cada denegación.

Análisis detallado paso a paso

1. Definir roles y límites de confianza

El principal es una persona, organización o servicio. El solicitante delegado es un agente, dispositivo, trabajo o carga de trabajo. El emisor firma una prueba para el principal, y el verificador se ubica en el recurso protegido o en la puerta de enlace (gateway). OAuth Token Exchange u otro sistema de emisión puede obtener la prueba; el verificador gestiona el desafío y la presentación, no el consentimiento ni la vinculación de cuentas.

2. Diseñar el desafío y la respuesta

Sin una prueba aceptable, devuelve 401, WWW-Authenticate: Delegation y Cache-Control: no-store. Devuelve 403 cuando la prueba sea sintácticamente válida pero exceda la política local. Problem Details puede explicar el fallo, pero los campos explicativos no deben relajar el desafío.

HTTP/1.1 401 Unauthorized
Cache-Control: no-store
WWW-Authenticate: Delegation realm="api.example",
  version=1, profile="budget", nonce="n-123", max-age=300

El verificador controla el nonce, el perfil y las ventanas de expiración para que una prueba no pueda copiarse entre solicitudes.

3. Vincular la prueba a la solicitud futura

Vincula al menos el método HTTP, el origen de confianza, la URI de destino, el digest de la solicitud y la expiración. Si un proxy reescribe el Host o la ruta, reconstruye el origen únicamente a partir de una configuración de gateway de confianza; nunca confíes en un X-Forwarded-* no validado. Define la canonicalización para mayúsculas/minúsculas del método, ordenamiento de queries y codificación porcentual.

{
  "principal": "org-42",
  "requester": "job-7",
  "method": "POST",
  "origin": "https://api.example",
  "target_hash": "sha-256:...",
  "nonce": "n-123",
  "expires": "2026-08-04T05:00:00Z",
  "limits": {"USD": 250}
}

4. Establecer el orden de verificación y el comportamiento de fallo seguro

Analiza la versión y el formato, luego verifica la firma, la confianza del emisor, la frescura del nonce, la ventana de tiempo, la vinculación de la solicitud y el presupuesto local. Rechaza cuando una dependencia no esté disponible, CBOR no sea determinista, falle una firma o se pierda el estado del nonce. Verifica las credenciales de identidad y las pruebas de delegación como capas separadas; una prueba válida no debe autorizar una API key no relacionada.

5. Prevenir la reproducción y la reutilización entre inquilinos

Almacena nonces con un TTL corto, consumo atómico y aislamiento de inquilinos. El digest de la solicitud y el origen de destino evitan copiar una prueba a otra API. Rechaza nonces reutilizados, delimita el desfase de reloj y utiliza campos de vinculación idénticos para preflight y la solicitud final. Las acciones de alto riesgo pueden requerir una prueba de un solo uso y aprobación humana.

6. Aplicar presupuesto y políticas

Un presupuesto es un perfil de autoridad, no un pago ni una liquidación. La política puede limitar el monto, las unidades de servicio, el alcance de los datos, el entorno y las llamadas descendentes. Realiza el débito en el mismo límite transaccional que la acción, o utiliza una reserva compensatoria, para que solicitudes concurrentes no excedan conjuntamente el límite.

7. Operar claves y auditar de forma segura

Los emisores publican claves rotables y versiones. Los verificadores pueden almacenarlas en caché, pero deben admitir la revocación y la rotación de emergencia. Audita el principal, el solicitante, el destino, el resultado de la política, el ID de prueba y el motivo de denegación; nunca registres tokens completos, claves privadas ni datos sensibles. Monitorea las tasas de 401/403, reproducciones de nonces, latencia de verificación, denegaciones de políticas, excesos de presupuesto, fallos de rotación de claves y tiempo de aprobación.

Ejemplo de respuesta de alta calidad

Dividiría el sistema en capas de identidad, delegación, vinculación de solicitudes y políticas. OAuth u otro emisor demuestra la relación con el principal. La prueba de delegación transporta el principal, el solicitante, el perfil, la expiración y el presupuesto; el verificador la vincula al método HTTP, origen de confianza, URI de destino, digest de la solicitud y nonce que se ejecutarán.

Devuelve 401 con WWW-Authenticate: Delegation y no-store cuando falte una prueba; devuelve 403 cuando sea válida pero insuficiente. Verifica el formato, la firma y confianza del emisor, la frescura del nonce, la ventana de tiempo, la vinculación de la solicitud, la política de inquilinos y el presupuesto en ese orden. Cualquier fallo de firma, dependencia no disponible o pérdida de estado de nonce aplica fallo seguro. La prueba no define pagos, no reemplaza a HTTP Message Signatures ni implementa emisión o consentimiento de OAuth.

Debita el presupuesto en la transacción de la acción o mediante una reserva compensatoria, y consume atómicamente un nonce aislado por inquilino. Admite la rotación de claves y la revocación de emergencia, mientras que los registros solo conservan el ID de prueba, el principal, el destino y el resultado. Prueba la reproducción, la copia entre inquilinos, la reescritura de proxies, el sobregasto concurrente y la rotación de claves. El objetivo es demostrar "quién actúa en nombre de quién y qué se le permite hacer en esta solicitud exacta" antes de que ocurra la acción consecuente.

Errores comunes

• Tratar una prueba de delegación como identidad general, emisión de OAuth o un protocolo de pago.
• Emitir un token de larga duración sin vinculación a método, URI, digest, nonce o expiración.
• Permitir solicitudes cuando las dependencias de firmas no están disponibles.
• Confiar en valores de X-Forwarded-* reescritos por proxy o no confiables para el destino.
• Registrar credenciales completas o debitar después de la acción, dejando ventanas para reproducción y sobregasto.

Preguntas de seguimiento y respuestas

¿Por qué usar tanto 401 como 403?

401 significa que la prueba falta, no es válida o está incompleta, por lo que un cliente puede obtener una nueva prueba a partir del desafío. 403 significa que la prueba fue comprendida pero la autoridad, el presupuesto o la política local son insuficientes; reintentarla no servirá de nada.

¿Qué pasa si el servicio de nonces no está disponible temporalmente?

Aplica fallo seguro para solicitudes de alto riesgo y devuelve un error de diagnóstico no-store. Solo las acciones de solo lectura de bajo riesgo evaluadas explícitamente pueden tener un respaldo restringido; un nonce antiguo en caché no constituye un estado de un solo uso.

¿Cómo funciona esto con OAuth?

OAuth Token Exchange o GNAP pueden obtener el material de delegación. El verificador sigue comprobando la prueba vinculada a la solicitud de forma independiente. Verifica el token de identidad y la prueba de delegación por separado para que el alcance delegado no se confunda con todos los permisos del token de identidad.

¿Es este un protocolo de pago?

No. Un perfil de presupuesto puede expresar límites de monto o de unidades de servicio, mientras que la liquidación, las redes de pago y la semántica de HTTP 402 son externas. El verificador solo decide si la acción protegida satisface la política de delegación.