OAuth dentro de uma VPN: que trechos ainda exigem TLS

O encaminhamento privado decide quem chega ao servidor; as regras de transporte do OAuth decidem como viaja cada mensagem. Um navegador, um servidor de autorização, um endpoint de token e um servidor de recursos podem estar todos atrás da mesma VPN e ainda assim trocar mensagens por trechos diferentes. Cada trecho tem o seu próprio requisito de transporte, e a VPN não afrouxa nenhum deles. A fronteira da VPN e a fronteira do protocolo são duas linhas diferentes.

A decisão é mais fácil se deixar de perguntar se a rede é de confiança e começar a perguntar que troca atravessa que fronteira.

Decida por trecho, não por rede

Anote os endpoints separadamente: endpoint de autorização, endpoint de token, URI de redirecionamento, URL do servidor de recursos, ponto de terminação TLS e gateway VPN. Depois marque qual parte origina cada pedido e para onde vai a resposta.

Uma VPN que termina num gateway cifra o segmento até esse gateway. O pedido pode continuar como HTTP simples por trás dele, e esse trecho restante não passou a HTTPS por um segmento anterior ter sido cifrado. É precisamente essa continuação o trecho que interessa ao protocolo. Cifrar o primeiro salto não torna o segundo salto seguro.

O transporte também transporta uma verificação da identidade do serviço. O navegador valida o certificado do URL da aplicação; uma VPN não realiza essa validação em nome do navegador e não torna aceitável um endpoint não validado. O certificado nomeia o endpoint que o cliente pensa estar a chamar. Um túnel para um gateway não renomeia esse endpoint nem o valida.

A resposta de autorização e o URI de redirecionamento

A melhor prática de segurança atual do OAuth proíbe a transmissão de respostas de autorização por ligações não cifradas. Isso abrange o redirecionamento que leva o código de autorização ou os tokens de volta ao cliente, não apenas o pedido inicial.

A mesma orientação não permite URI de redirecionamento HTTP, exceto no caso de loopback especificado para clientes nativos. Um nome de anfitrião interno não cria uma exceção nova, e um nome DNS que só se resolve dentro da VPN continua a ser um URL HTTP se o esquema o disser. Verifique o esquema no URI registado, não apenas o nome de anfitrião.

Registe o URI de redirecionamento HTTPS exato no servidor de autorização e mantenha a validação de certificados ativa no cliente. Um atalho de desenvolvimento que suprime o requisito HTTPS produz um fluxo que se comporta de forma diferente da configuração de produção que deveria modelar.

O endpoint de token e os pedidos com token de portador

O pedido de token transporta credenciais ou um código que pode ser trocado por acesso. Enviá-lo por um trecho não protegido expõe material em que o servidor de recursos confiará mais tarde, mesmo que a rede em volta seja privada. Um proxy que consegue ler o pedido também consegue ler a credencial que ele transporta.

Para pedidos de recursos com token de portador, a RFC 6750 considera o TLS obrigatório de implementar e de utilizar nessa especificação. Chamar de confiança à sub-rede do escritório não é a exceção geral de protocolo de que uma implementação de portador em texto simples precisa.

Utilize os URL seguros documentados dos endpoints para ambos os trechos. Se uma biblioteca se recusar a chamar um endpoint de token HTTP, essa recusa é a especificação a funcionar, não um defeito de configuração a contornar. Registe esse URL na configuração do cliente em vez de o derivar em tempo de execução.

Onde o TLS termina e o que isso deixa

Se o TLS terminar num frontend autorizado, nomeie esse frontend e reveja o caminho desde ele até à aplicação. O frontend passa a ser responsável pelo encaminhamento, pela confiança e pela confidencialidade no segmento restante, e a arquitetura suportada do serviço deve descrever essa disposição.

Uma VPN noutro ponto do caminho não resolve essas responsabilidades. Também não lhe diz se o URL da aplicação que o navegador vê corresponde ao certificado que o frontend apresenta.

Para uma implementação interna, registe o ponto de terminação e a identidade que apresenta. Um frontend que termina o TLS com um certificado para outro nome cria um aviso do navegador que os operadores muitas vezes suprimem em vez de corrigir.

A exceção de loopback nativo é estreita

A exceção de redirecionamento em loopback diz respeito a uma chamada de retorno no próprio dispositivo do utilizador, onde o cliente e o navegador partilham esse dispositivo. Essa disposição pertence a uma chamada de retorno num único dispositivo, e não autoriza a servir um servidor de autorização normal ou uma API com tokens por HTTP a uma sub-rede de escritório.

Mantenha a exceção limitada ao tipo de cliente e à chamada de retorno que descreve. Aplicá-la a uma aplicação web, a um serviço interno partilhado ou a um URI de redirecionamento noutro anfitrião altera a implementação, não a exceção.

Teste o fluxo real em cada fronteira e compare-o com o tipo de cliente. Um redirecionamento a funcionar não diz nada sobre se cada trecho que transportou um token utilizou a proteção exigida, e um ícone verde de VPN não diz nada sobre o esquema do pedido seguinte.