OAuth derrière un VPN : quels segments exigent encore TLS

Le routage privé décide qui atteint le serveur ; les règles de transport d’OAuth décident comment chaque message voyage. Un navigateur, un serveur d’autorisation, un point de terminaison de jeton et un serveur de ressources peuvent tous se trouver derrière le même VPN et échanger malgré tout des messages par des segments différents. Chaque segment a sa propre exigence de transport, et le VPN n’en assouplit aucune. La frontière du VPN et la frontière du protocole sont deux lignes différentes.

La décision est plus simple si vous cessez de demander si le réseau est de confiance et commencez à demander quel échange franchit quelle frontière.

Décidez par segment, pas par réseau

Notez les points de terminaison séparément : point de terminaison d’autorisation, point de terminaison de jeton, URI de redirection, URL du serveur de ressources, point de terminaison TLS et passerelle VPN. Indiquez ensuite quelle partie émet chaque requête et où va la réponse.

Un VPN qui se termine à une passerelle chiffre le segment jusqu’à cette passerelle. La requête peut continuer en HTTP simple derrière elle, et ce segment restant n’est pas devenu HTTPS parce qu’un segment antérieur a été chiffré. C’est précisément cette continuation qui compte pour le protocole. Chiffrer le premier saut ne rend pas le second sûr.

Le transport porte aussi une vérification de l’identité du service. Le navigateur valide le certificat de l’URL de l’application ; un VPN n’effectue pas cette validation à la place du navigateur et ne rend pas acceptable un point de terminaison non validé. Le certificat nomme le point de terminaison que le client croit appeler. Un tunnel vers une passerelle ne renomme pas ce point de terminaison et ne le valide pas.

La réponse d’autorisation et l’URI de redirection

La meilleure pratique de sécurité actuelle d’OAuth interdit de transmettre des réponses d’autorisation sur des connexions non chiffrées. Cela couvre la redirection qui rapporte le code d’autorisation ou les jetons au client, pas seulement la requête initiale.

La même recommandation interdit les URI de redirection HTTP, sauf le cas de bouclage local spécifié pour les clients natifs. Un nom d’hôte interne ne crée pas une nouvelle exception, et un nom DNS qui ne se résout qu’à l’intérieur du VPN reste une URL HTTP si le schéma le dit. Vérifiez le schéma dans l’URI enregistrée, pas seulement le nom d’hôte.

Enregistrez l’URI de redirection HTTPS exacte auprès du serveur d’autorisation et gardez la validation des certificats activée sur le client. Un raccourci de développement qui supprime l’exigence HTTPS produit un flux qui se comporte différemment de la configuration de production qu’il est censé modéliser.

Le point de terminaison de jeton et les requêtes avec jeton porteur

La requête de jeton porte des identifiants ou un code qui peut être échangé contre un accès. L’envoyer sur un segment non protégé expose une matière à laquelle le serveur de ressources fera ensuite confiance, même si le réseau alentour est privé. Un proxy qui peut lire la requête peut aussi lire l’identifiant qu’elle porte.

Pour les requêtes de ressources avec jeton porteur, RFC 6750 considère TLS comme obligatoire à implémenter et à utiliser pour cette spécification. Qualifier de confiance le sous-réseau du bureau n’est pas l’exception de protocole générale dont a besoin un déploiement porteur en clair.

Utilisez les URL sécurisées documentées des points de terminaison pour les deux segments. Si une bibliothèque refuse d’appeler un point de terminaison de jeton HTTP, ce refus est la spécification qui fonctionne, pas un défaut de configuration à contourner. Enregistrez cette URL dans la configuration du client plutôt que de la dériver à l’exécution.

Où TLS se termine et ce qu’il en reste

Si TLS se termine à un frontal autorisé, nommez ce frontal et examinez le chemin qui va de lui à l’application. Le frontal devient responsable du transfert, de la confiance et de la confidentialité sur le segment restant, et l’architecture prise en charge du service devrait décrire cette disposition.

Un VPN situé ailleurs sur le chemin ne règle pas ces responsabilités. Il ne vous dit pas non plus si l’URL de l’application que voit le navigateur correspond au certificat que présente le frontal.

Pour un déploiement interne, consignez le point de terminaison et l’identité qu’il présente. Un frontal qui termine TLS avec un certificat pour un autre nom crée un avertissement du navigateur que les opérateurs suppriment souvent au lieu de le corriger.

L’exception de bouclage local natif est étroite

L’exception de redirection en bouclage local concerne un rappel sur l’appareil de l’utilisateur lui-même, où le client et le navigateur partagent cet appareil. Cette disposition relève d’un rappel sur un seul appareil et n’autorise pas à servir un serveur d’autorisation normal ou une API porteuse de jetons en HTTP vers un sous-réseau de bureau.

Gardez l’exception limitée au type de client et au rappel qu’elle décrit. L’appliquer à une application web, à un service interne partagé ou à une URI de redirection sur un autre hôte change le déploiement, pas l’exception.

Testez le flux réel à chaque frontière et comparez-le au type de client. Une redirection qui fonctionne ne dit rien sur le fait que chaque segment ayant porté un jeton ait utilisé la protection requise, et une icône VPN verte ne dit rien sur le schéma de la requête suivante.