Entrevista de backend: ¿Cómo manejas un HTTP 407 a través de una cadena de proxies?

Planteamiento y alcance

Un cliente de servicio se comunica con una API externa a través de varios proxies explícitos. Algunas solicitudes devuelven 407 y otras 401. Explica el límite entre ellos, los desafíos de proxy salto a salto (hop-by-hop), los túneles CONNECT, el almacenamiento de credenciales, los reintentos y la observabilidad.

Esta es una pregunta de redes y seguridad de backend. La cantidad de proxies y la tasa de fallas son supuestos para el ejercicio, no afirmaciones del mercado.

Qué está evaluando el entrevistador

• Si separas la autenticación del servidor de recursos de la autenticación del proxy del siguiente salto.
• Si explicas dónde se consumen Proxy-Authenticate y Proxy-Authorization.
• Si manejas múltiples saltos, CONNECT, pools de conexiones y rotación de credenciales.
• Si las credenciales del proxy se mantienen alejadas del origen y de los registros (logs).

Preguntas de aclaración para hacer

1. ¿El cliente está utilizando un proxy explícito o transparente, y se utiliza CONNECT?
2. ¿Qué esquema utiliza cada proxy y se reutilizan las conexiones?
3. ¿Pueden el cliente y los gateways preservar los encabezados 401 y 407 originales?
4. ¿Es la solicitud una lectura segura o crea, cobra o muta el estado?
5. ¿Quién rota las credenciales y hay un proxy de salida de respaldo disponible?

Una respuesta de 30 segundos

“Un 407 es un desafío del proxy del siguiente salto; un 401 proviene del recurso de destino. Registro los identificadores de salto y de solicitud, leo Proxy-Authenticate y envío el Proxy-Authorization correspondiente únicamente a ese proxy. El siguiente proxy de entrada lo consume; no debe llegar al origen. Para CONNECT, autentico el proxy antes de crear el túnel y luego manejo un 401 a nivel de túnel como autenticación de origen. Reintento únicamente solicitudes seguras de reproducir y mido los 407 por proxy, esquema y versión de credencial”.

Diseño paso a paso

1. Separar 401 y 407

WWW-Authenticate en un 401 describe un desafío del recurso de destino, respondido habitualmente con Authorization. Proxy-Authenticate en un 407 describe un desafío del proxy del siguiente salto, respondido con Proxy-Authorization. Números de estado similares no justifican cachés compartidas ni un único manejador de errores.

2. Autenticar un salto a la vez

Cada proxy recibe únicamente las credenciales que solicitó. El RFC 9110 define Proxy-Authorization para el siguiente proxy de entrada que lo requirió; en una cadena, el primer proxy que espera credenciales consume el campo. El cliente aísla las credenciales por proxy o conexión y nunca reenvía el encabezado de proxy al origen.

GET https://api.example/report HTTP/1.1
Host: api.example
Proxy-Authorization: Basic <proxy-credential>

3. Manejar túneles CONNECT

Para un destino HTTPS, el cliente envía primero CONNECT al proxy. Una vez que la autenticación del proxy tiene éxito y el proxy devuelve 2xx, el cliente crea el túnel TLS. Las solicitudes dentro de él pertenecen al origen; un 401 del origen utiliza Authorization y no se confunde con un 407 de proxy. Un desafío de proxy fallido sigue perteneciendo al salto de CONNECT.

4. Aislar pools y credenciales

La clave del pool incluye la dirección del proxy, el esquema de autenticación, el tenant y la versión de las credenciales. Durante la rotación, deja de reutilizar conexiones antiguas o reautentica según lo requiera el proxy. No coloques Proxy-Authorization en una plantilla de encabezados entre solicitudes ni registres su valor en sistemas de rastreo (tracing).

5. Limitar reintentos y efectos secundarios

Tras un 407, reintenta únicamente cuando no se haya enviado ningún cuerpo irreversible o la operación sea seguramente reproducible. Para POST, cobros o creación de recursos, utiliza una clave de idempotencia de negocio y verifica si el servidor ya procesó el intento. El manejo de desafíos, la actualización de credenciales y la reproducción deben ser eventos observables, no un bucle sin límites.

6. Instrumentar el diagnóstico y la seguridad

Para cada salto, registra la identidad del proxy, la fase de CONNECT, el esquema, la versión de la credencial, el recuento de 407, el resultado del reintento y el estado final; conserva solo resúmenes redactados. Compara 401, 407, fallas de TLS, reutilización del pool y cambios al proxy de salida de respaldo para localizar fallas en el destino, en las políticas del proxy o en la rotación. Inyecta fallas para demostrar que un intermediario no puede filtrar ni reescribir el encabezado de autorización de origen.

Modelo de respuesta de alta calidad

“Divido la ruta en capas de proxy y de recursos. El siguiente proxy desafía con 407 y el origen desafía con 401, utilizando Proxy-Authorization y Authorization respectivamente. Las credenciales se aíslan por identidad de proxy; el primer proxy de entrada que espera el campo de proxy lo consume y este nunca llega al origen. HTTPS autentica el proxy durante el CONNECT antes del tráfico del túnel. Los pools se separan por proxy y versión de credencial, y la rotación retira las conexiones antiguas. Solo las solicitudes seguras se reproducen tras un 407; los efectos secundarios se recuperan con idempotencia y consultas de estado. Las métricas a nivel de salto identifican la falla”.

Errores comunes

• Tratar 407 como 401 → las credenciales cruzan el límite incorrecto → maneja los desafíos de proxy y de recursos por separado.
• Reenviar credenciales de proxy al origen → se filtran secretos → deja que el siguiente proxy de entrada las consuma y las elimine.
• Enviar tráfico de túnel antes de que CONNECT tenga éxito → el estado del protocolo es incorrecto → finaliza la autenticación de proxy y recibe primero el CONNECT 2xx.
• Compartir todo el estado de autenticación de conexión → se mezclan tenants o versiones de credenciales → aísla por proxy, tenant y versión.
• Reintentar 407 indefinidamente → las fallas y los efectos secundarios se amplifican → limita los intentos, prueba la seguridad de reproducción y consulta el estado.

Preguntas de seguimiento y respuestas

¿Puedo enviar varios valores de Proxy-Authorization para varios proxies?

No trates el campo como una lista genérica de credenciales. Envía lo que el proxy de entrada actual espera; después de que consuma el campo, maneja un desafío posterior según el esquema de ese salto y verifica que la implementación permita un reenvío seguro.

¿Por qué no diagnosticar a partir del 407 final únicamente?

Los gateways pueden reescribir o suprimir respuestas intermedias, y la reutilización de conexiones puede asociar un desafío a la solicitud incorrecta. Conserva registros de saltos, identificadores de conexión y el desafío original para identificar al emisor real.

¿Qué ocurre si la autenticación del proxy tiene éxito pero el túnel devuelve 401?

Mantén el estado de autenticación del proxy y responde al desafío WWW-Authenticate del origen con Authorization. No vuelvas a enviar las credenciales del proxy ni coloques las credenciales del recurso en la caché de autenticación del proxy.