OAuth dins d’una VPN: quines etapes encara requereixen TLS

L’encaminament privat decideix qui arriba al servidor; les regles de transport d’OAuth decideixen com viatja cada missatge. Un navegador, un servidor d’autorització, un punt de terminació de token i un servidor de recursos poden ser tots darrere de la mateixa VPN i tot i així intercanviar missatges per etapes diferents. Cada etapa té el seu propi requisit de transport, i la VPN no en relaxa cap. La frontera de la VPN i la frontera del protocol són línies diferents.

La decisió és més fàcil si deixeu de preguntar si la xarxa és de confiança i comenceu a preguntar quin intercanvi travessa quina frontera.

Decidiu per etapa, no per xarxa

Anoteu els punts de terminació per separat: punt de terminació d’autorització, punt de terminació de token, URI de redirecció, URL del servidor de recursos, punt de terminació de TLS i passarel·la VPN. Després marqueu quina part origina cada sol·licitud i on va la resposta.

Una VPN que acaba en una passarel·la xifra el segment fins a aquesta passarel·la. La sol·licitud pot continuar com a HTTP simple darrere seu, i aquesta etapa restant no s’ha convertit en HTTPS pel fet que un segment anterior s’hagi xifrat. Aquesta continuació és l’etapa que importa al protocol. Xifrar el primer salt no fa segur el segon salt.

El transport també comporta una comprovació d’identitat del servei. El navegador valida el certificat per a l’URL de l’aplicació; una VPN no fa aquesta validació en nom del navegador, i no fa acceptable un punt de terminació no validat. El certificat anomena el punt de terminació que el client creu que està cridant. Un túnel cap a una passarel·la no reanomena aquest punt ni el valida.

La resposta d’autorització i l’URI de redirecció

La millor pràctica de seguretat vigent d’OAuth prohibeix transmetre respostes d’autorització per connexions no xifrades. Això cobreix la redirecció que porta el codi d’autorització o els tokens de tornada al client, no només la sol·licitud inicial.

La mateixa guia no permet URI de redirecció HTTP, excepte el cas de bucle local especificat per a clients natius. Un nom d’amfitrió intern no crea una excepció nova, i un nom DNS que només es resol dins de la VPN continua sent un URL HTTP si l’esquema ho diu. Comproveu l’esquema a l’URI registrat, no només el nom d’amfitrió.

Registreu l’URI de redirecció HTTPS exacte al servidor d’autorització i manteniu la validació de certificats activada al client. Una drecera de desenvolupament que suprimeix el requisit HTTPS produeix un flux que es comporta de manera diferent de la configuració de producció que hauria de modelar.

El punt de terminació de token i les sol·licituds amb bearer token

La sol·licitud de token porta credencials o un codi que es pot bescanviar per accés. Enviar-la per una etapa no protegida exposa material en què el servidor de recursos confiarà després, encara que la xarxa del voltant sigui privada. Un proxy que pot llegir la sol·licitud també pot llegir la credencial que porta.

Per a les sol·licituds de recursos amb bearer token, RFC 6750 considera TLS obligatori d’implementar i d’usar en aquesta especificació. Qualificar la subxarxa d’oficina de confiança no és l’excepció general de protocol que necessita un desplegament de bearer en text pla.

Utilitzeu els URL segurs documentats dels punts de terminació per a totes dues etapes. Si una biblioteca es nega a cridar un punt de terminació de token HTTP, aquest rebuig és l’especificació que funciona, no un error de configuració a evitar. Anoteu aquest URL a la configuració del client en lloc de derivar-lo en temps d’execució.

On acaba TLS i què deixa això

Si TLS acaba en un frontal autoritzat, anomeneu aquest frontal i reviseu el camí des d’ell fins a l’aplicació. El frontal passa a ser responsable de l’encaminament, la confiança i la confidencialitat en el segment restant, i l’arquitectura suportada del servei hauria de descriure aquesta disposició.

Una VPN en un altre punt del camí no resol aquestes responsabilitats. Tampoc no us diu si l’URL de l’aplicació que veu el navegador coincideix amb el certificat que presenta el frontal.

Per a un desplegament intern, anoteu el punt de terminació i la identitat que presenta. Un frontal que acaba TLS amb un certificat per a un altre nom crea un avís al navegador que els operadors sovint suprimeixen en lloc de corregir.

L’excepció de bucle local natiu és estreta

L’excepció de redirecció de bucle local fa referència a una crida de retorn al mateix dispositiu de l’usuari, on el client i el navegador comparteixen aquest dispositiu. Aquesta disposició pertany a una crida de retorn en un sol dispositiu, i no autoritza servir un servidor d’autorització normal o una API amb tokens per HTTP a una subxarxa d’oficina.

Mantingueu l’excepció limitada al tipus de client i a la crida de retorn que descriu. Aplicar-la a una aplicació web, a un servei intern compartit o a un URI de redirecció en un altre amfitrió canvia el desplegament, no l’excepció.

Proveu el flux real a cada frontera i compareu-lo amb el tipus de client. Una redirecció que funciona no diu res sobre si cada etapa que portava un token va fer servir la protecció requerida, i una icona verda de VPN no diu res sobre l’esquema de la sol·licitud següent.