OAuth dentro de una VPN: qué tramos siguen exigiendo TLS

El enrutamiento privado decide quién llega al servidor; las reglas de transporte de OAuth deciden cómo viaja cada mensaje. Un navegador, un servidor de autorización, un extremo de token y un servidor de recursos pueden estar todos detrás de la misma VPN y aun así intercambiar mensajes por tramos distintos. Cada tramo tiene su propio requisito de transporte, y la VPN no relaja ninguno de ellos. La frontera de la VPN y la frontera del protocolo son dos líneas diferentes.

La decisión es más fácil si deja de preguntar si la red es de confianza y empieza a preguntar qué intercambio cruza qué frontera.

Decida por tramo, no por red

Escriba los extremos por separado: extremo de autorización, extremo de token, URI de redirección, URL del servidor de recursos, punto de terminación de TLS y puerta de enlace VPN. Después marque qué parte origina cada solicitud y adónde va la respuesta.

Una VPN que termina en una puerta de enlace cifra el segmento hasta esa puerta. La solicitud puede continuar como HTTP simple detrás de ella, y ese tramo restante no se ha convertido en HTTPS porque se cifrara un segmento anterior. Esa continuación es el tramo que le importa al protocolo. Cifrar el primer salto no hace seguro el segundo salto.

El transporte también conlleva una comprobación de identidad del servicio. El navegador valida el certificado de la URL de la aplicación; una VPN no realiza esa validación en nombre del navegador, y no hace aceptable un extremo no validado. El certificado nombra el extremo que el cliente cree estar llamando. Un túnel hacia una puerta de enlace no renombra ese extremo ni lo valida.

La respuesta de autorización y la URI de redirección

La mejor práctica de seguridad vigente de OAuth prohíbe transmitir respuestas de autorización por conexiones no cifradas. Eso cubre la redirección que lleva el código de autorización o los tokens de vuelta al cliente, no solo la solicitud inicial.

La misma guía no permite URI de redirección HTTP, salvo el caso de bucle local especificado para clientes nativos. Un nombre de host interno no crea una excepción nueva, y un nombre DNS que solo se resuelve dentro de la VPN sigue siendo una URL HTTP si el esquema lo dice. Compruebe el esquema en la URI registrada, no solo el nombre de host.

Registre la URI de redirección HTTPS exacta en el servidor de autorización y mantenga activada la validación de certificados en el cliente. Un atajo de desarrollo que suprime el requisito HTTPS produce un flujo que se comporta de forma distinta a la configuración de producción que debería modelar.

El extremo de token y las solicitudes con token de portador

La solicitud de token lleva credenciales o un código que puede canjearse por acceso. Enviarla por un tramo no protegido expone material en el que el servidor de recursos confiará después, aunque la red circundante sea privada. Un proxy que puede leer la solicitud también puede leer la credencial que lleva.

Para solicitudes de recursos con token de portador, RFC 6750 considera TLS obligatorio de implementar y de usar en esa especificación. Calificar de confiable la subred de la oficina no es la excepción general de protocolo que necesita un despliegue de portador en texto plano.

Use las URL seguras documentadas de los extremos para ambos tramos. Si una biblioteca se niega a llamar a un extremo de token HTTP, esa negativa es la especificación funcionando, no un error de configuración que haya que sortear. Anote esa URL en la configuración del cliente en lugar de derivarla en tiempo de ejecución.

Dónde termina TLS y qué deja eso

Si TLS termina en un frontal autorizado, nombre ese frontal y revise la ruta desde él hasta la aplicación. El frontal pasa a ser responsable del reenvío, la confianza y la confidencialidad en el segmento restante, y la arquitectura admitida del servicio debería describir esa disposición.

Una VPN en otro punto de la ruta no resuelve esas responsabilidades. Tampoco le dice si la URL de la aplicación que ve el navegador coincide con el certificado que presenta el frontal.

Para un despliegue interno, anote el punto de terminación y la identidad que presenta. Un frontal que termina TLS con un certificado para otro nombre crea un aviso del navegador que los operadores a menudo suprimen en lugar de corregir.

La excepción de bucle local nativo es estrecha

La excepción de redirección de bucle local se refiere a una devolución de llamada en el propio dispositivo del usuario, donde el cliente y el navegador comparten ese dispositivo. Esa disposición pertenece a una devolución de llamada en un solo dispositivo, y no autoriza a servir un servidor de autorización normal o una API con tokens por HTTP a una subred de oficina.

Mantenga la excepción limitada al tipo de cliente y a la devolución de llamada que describe. Aplicarla a una aplicación web, a un servicio interno compartido o a una URI de redirección en otro host cambia el despliegue, no la excepción.

Pruebe el flujo real en cada frontera y compárelo con el tipo de cliente. Una redirección que funciona no dice nada sobre si cada tramo que llevó un token usó la protección requerida, y un icono verde de VPN no dice nada sobre el esquema de la solicitud siguiente.