OAuth dentro dunha VPN: que tramos aínda requiren TLS

O encamiñamento privado decide quen chega ao servidor; as regras de transporte de OAuth deciden como viaxa cada mensaxe. Un navegador, un servidor de autorización, un extremo de token e un servidor de recursos poden estar todos detrás da mesma VPN e aínda así intercambiar mensaxes por tramos distintos. Cada tramo ten o seu propio requisito de transporte, e a VPN non relaxa ningún deles. A fronteira da VPN e a fronteira do protocolo son dúas liñas diferentes.

A decisión é máis fácil se deixa de preguntar se a rede é de confianza e comeza a preguntar que intercambio cruza que fronteira.

Decida por tramo, non por rede

Escriba os extremos por separado: extremo de autorización, extremo de token, URI de redirección, URL do servidor de recursos, punto de terminación de TLS e pasarela VPN. Despois marque que parte orixina cada solicitude e onde vai a resposta.

Unha VPN que termina nunha pasarela cifra o segmento ata esa pasarela. A solicitude pode continuar como HTTP simple detrás dela, e ese tramo restante non se converteu en HTTPS porque se cifrase un segmento anterior. Esa continuación é o tramo que lle importa ao protocolo. Cifrar o primeiro salto non fai seguro o segundo salto.

O transporte tamén leva unha comprobación de identidade do servizo. O navegador valida o certificado da URL da aplicación; unha VPN non realiza esa validación en nome do navegador, e non fai aceptable un extremo non validado. O certificado nomea o extremo que o cliente cre está chamando. Un túnel cara a unha pasarela non renomea ese extremo nin o valida.

A resposta de autorización e a URI de redirección

A mellor práctica de seguridade vixente de OAuth prohibe transmitir respostas de autorización por conexións non cifradas. Iso cobre a redirección que leva o código de autorización ou os tokens de volta ao cliente, non só a solicitude inicial.

A mesma guía non permite URI de redirección HTTP, agás o caso de bucle local especificado para clientes nativos. Un nome de host interno non crea unha excepción nova, e un nome DNS que só se resolve dentro da VPN segue sendo unha URL HTTP se o esquema o di. Comprobe o esquema na URI rexistrada, non só o nome de host.

Rexistre a URI de redirección HTTPS exacta no servidor de autorización e manteña activada a validación de certificados no cliente. Un atallo de desenvolvemento que suprime o requisito HTTPS produce un fluxo que se comporta de forma distinta á configuración de produción que debería modelar.

O extremo de token e as solicitudes con token de portador

A solicitude de token leva credenciais ou un código que se pode trocar por acceso. Enviala por un tramo non protexido expón material no que o servidor de recursos confiará despois, aínda que a rede circundante sexa privada. Un proxy que pode ler a solicitude tamén pode ler a credencial que leva.

Para solicitudes de recursos con token de portador, RFC 6750 considera TLS obrigatorio de implementar e de usar nesa especificación. Cualificar de confianza a subrede da oficina non é a excepción xeral de protocolo que necesita un despregamento de portador en texto simple.

Use as URL seguras documentadas dos extremos para ambos os tramos. Se unha biblioteca se nega a chamar un extremo de token HTTP, esa negativa é a especificación funcionando, non un erro de configuración que haxa que sortear. Anote esa URL na configuración do cliente en lugar de derivala en tempo de execución.

Onde termina TLS e que deixa iso

Se TLS termina nun frontal autorizado, nomee ese frontal e revise a ruta desde el ata a aplicación. O frontal pasa a ser responsable do reenvío, a confianza e a confidencialidade no segmento restante, e a arquitectura admitida do servizo debería describir esa disposición.

Unha VPN noutro punto da ruta non resolve esas responsabilidades. Tampouco lle di se a URL da aplicación que ve o navegador coincide co certificado que presenta o frontal.

Para un despregamento interno, anote o punto de terminación e a identidade que presenta. Un frontal que termina TLS cun certificado para outro nome crea un aviso do navegador que os operadores adoitan suprimir en lugar de corrixir.

A excepción de bucle local nativo é estreita

A excepción de redirección de bucle local refírese a unha devolución de chamada no propio dispositivo do usuario, onde o cliente e o navegador comparten ese dispositivo. Esa disposición pertence a unha devolución de chamada nun só dispositivo, e non autoriza a servir un servidor de autorización normal ou unha API con tokens por HTTP a unha subrede de oficina.

Manteña a excepción limitada ao tipo de cliente e á devolución de chamada que describe. Aplicarla a unha aplicación web, a un servizo interno compartido ou a unha URI de redirección noutro host cambia o despregamento, non a excepción.

Probe o fluxo real en cada fronteira e compáreo co tipo de cliente. Unha redirección que funciona non di nada sobre se cada tramo que levou un token usou a protección requirida, e unha icona verde de VPN non di nada sobre o esquema da solicitude seguinte.