Au-delà de la liste blanche IP : Tunneling développeur basé sur l’identité en 2026

L’approche du “ trou dans le pare-feu ” pour le tunneling développeur est morte. Depuis des années, exposer un port local à Internet signifiait percer votre pare-feu, croiser les doigts, et espérer qu’une liste blanche IP suffisait. Ce n’était pas le cas alors, et en 2026, ce n’est absolument pas le cas maintenant.

Cet article explore toute cette évolution : des politiques d’identité basées sur YAML dans ngrok aux garanties architecturales des plateformes Zero Trust open-source, et au danger très réel et exploitable qui se cache dans ce sous-domaine éphémère que vous avez enregistré pour tester votre flux OAuth.

Du port forwarding aux bords à identité-aware

La question fondamentale a changé. Nous ne demandons plus “D’où vient cette requête ?” — une adresse IP peut être usurpée, les VPN peuvent être compromis, et le travail à distance a brisé l’idée d’un réseau d’entreprise fiable. La nouvelle question est “Qui fait cette requête, et sa session a-t-elle été validée par notre fournisseur d’identité ?”

Ce passage de l’identité réseau à l’identité humaine définit ce qu’est le tunneling Zero Trust.

Le moteur de politique de trafic ngrok

La évolution la plus significative dans ngrok ces deux dernières années est le passage de simples flags en ligne de commande à un moteur de politique de trafic entièrement déclaratif basé sur YAML. Ce n’est pas cosmétique. Cela repositionne fondamentalement ngrok d’un outil de commodité à quelque chose qui se rapproche d’une passerelle d’edge.

La politique de trafic vous permet d’intercepter et d’agir sur les requêtes dans le cloud ngrok — avant même qu’elles n’atteignent localhost:3000. Le moteur utilise des expressions Common Expression Language (CEL) pour filtrer le trafic conditionnellement, et les actions s’exécutent dans une chaîne de gestion : chaque fonction rejette une requête ou la passe au gestionnaire suivant.

Les phases d’authentification supportées sont on_tcp_connect, on_http_request, et on_http_response. Les méthodes d’authentification que vous pouvez appliquer à la frontière incluent Basic Auth, OAuth, OpenID Connect (OIDC), validation JWT, Mutual TLS (mTLS), et restrictions IP — tout cela sans toucher à votre code applicatif.

OAuth à la frontière du tunnel

Pour protéger votre port local derrière une connexion Google, vous définissez la politique dans un fichier YAML et la passez à l’agent ngrok :

# oauth-policy.yml
on_http_request:
  - actions:
      - type: oauth
        config:
          provider: google
          allow_domains: ["yourcompany.com"]

ngrok http 3000 --traffic-policy-file oauth-policy.yml

Lorsqu’un utilisateur accède à votre URL de tunnel, ngrok le redirige vers Google, complète le flux OAuth, et ne transfère la requête à votre machine que si l’authentification réussit. ngrok transmet les métadonnées d’identité en tant qu’en-têtes — Ngrok-Auth-User-Email, Ngrok-Auth-User-Id, et Ngrok-Auth-User-Name — afin que votre application puisse prendre des décisions d’autorisation sans gérer le flux d’authentification.

OIDC pour IdPs d’entreprise

Pour les équipes utilisant un IdP d’entreprise comme Okta, Azure AD, ou tout fournisseur compatible OIDC, l’action openid-connect offre la même enforcement à la frontière avec une sémantique d’identité d’entreprise complète :

on_http_request:
  - actions:
      - type: openid-connect
        config:
          issuer_url: "https://your-org.okta.com"
          client_id: "<your-oidc-client-id>"
          client_secret: "<your-oidc-client-secret>"
          scopes:
            - openid
            - profile
            - email
  - actions:
      - type: add-headers
        config:
          headers:
            x-identity-token: "${actions.ngrok.oidc.identity_token}"
            x-user-email: "${actions.ngrok.oidc.identity.email}"

Pour la configuration Okta, vous enregistrez https://idp.ngrok.com/oauth2/callback comme URI de redirection de connexion dans le tableau de bord d’administration Okta, puis vous configurez la politique comme ci-dessus. Le jeton d’identité OIDC est transmis à votre service en amont via des en-têtes, permettant une logique d’autorisation en aval sans que votre application ait à gérer le flux OIDC elle-même.

Superposition de règles

Les règles de la politique de trafic s’exécutent dans l’ordre, ce qui permet de superposer l’authentification avec d’autres actions. Une configuration pratique de niveau production pourrait appliquer d’abord l’authentification OIDC, puis limiter le débit, puis vérifier la réputation IP — tout dans le même fichier YAML. La chaîne de gestion des gestionnaires signifie que les requêtes invalides — non authentifiées, limitées en débit, ou provenant d’IPs signalées — sont rejetées à la frontière et ne touchent jamais votre service.

Octelium : le concurrent open-source pour Zero Trust unifié

Alors qu’ngrok fonctionne comme une plateforme SaaS, Octelium s’est imposé comme la solution pour les équipes nécessitant une architecture Zero Trust entièrement auto-hébergée et unifiée. Il est entièrement open source (Apache 2.0), et il n’y a pas de plan de contrôle propriétaire basé sur le cloud — une distinction importante pour les organisations avec des exigences de souveraineté des données.

Octelium fournit une architecture Zero Trust évolutive pour un accès basé sur l’identité, au niveau applicatif (L7), via à la fois des accès privés client via WireGuard/QUIC, et un accès public sans client à la BeyondCorp. Les décisions d’accès sont prises au niveau de chaque requête en utilisant le contexte et la politique, pas des règles simples d’autoriser ou bloquer au niveau réseau.

Le modèle d’accès sans secret

Une des capacités les plus distinctives d’Octelium est l’accès sans secret. Une couche de proxy basée sur l’identité appelée Vigil intercepte les requêtes, évalue si l’utilisateur est autorisé, et — s’il l’est — injecte des identifiants applicatifs à la volée. Les clés API HTTP, mots de passe de bases de données, clés privées SSH, et certificats TLS restent verrouillés dans le coffre-fort de secrets d’Octelium. L’utilisateur ne les voit jamais, et ils ne quittent jamais la plateforme.

Cela élimine toute une classe de problèmes liés à la gestion des identifiants : plus besoin de distribuer des clés API aux développeurs, plus de proliferation de clés SSH, plus de tokens statiques dans les variables d’environnement CI/CD.

Politique-as-Code avec CEL et OPA

Le contrôle d’accès d’Octelium utilise ABAC (Contrôle d’accès basé sur les attributs) exprimé via CEL et Open Policy Agent (OPA). Cela permet des règles granulaires, sensibles au contexte, que les tunnels traditionnels de niveau réseau ne peuvent pas exprimer :

Accorder l’accès uniquement si l’utilisateur est sur un appareil géré dans une région géographique spécifique.
Permettre aux runners CI/CD d’accéder à votre serveur MCP (Model Context Protocol) local en utilisant des assertions d’identité de charge de travail OIDC plutôt que des clés API statiques.
Appliquer un contrôle d’accès par requête plutôt que par session — une session compromise ne donne pas un accès global.

Le chemin réseau lui-même est piloté par l’identité : si un utilisateur n’est pas autorisé, le chemin de service n’existe pas pour lui. Il n’y a pas d’IP à scanner, pas de port à sonder. Contrairement à un tunnel traditionnel où le point d’extrémité est “actif” et en attente, visible par tout scanner sur Internet.

Architecture

Octelium est construit sur Kubernetes et supporte à la fois des tunnels client WireGuard/QUIC sans configuration et un accès basé sur navigateur sans client. Il s’intègre avec tout fournisseur d’identité OIDC ou SAML 2.0, et expose une pile d’observabilité native OpenTelemetry pour l’audit en temps réel. Le projet publie également une GitHub Action permettant aux runners CI/CD de se connecter directement à un cluster Octelium depuis un workflow.

Le piège du détournement de redirection OAuth

Voici une vulnérabilité encore répandue en 2026, encore mal comprise, et toujours à l’origine de violations réelles. Elle se niche dans l’écart entre la commodité pour le développeur et l’hygiène de sécurité en production.

La configuration

Vous testez une intégration “Login with GitHub” en local. Vous lancez un tunnel ngrok en version gratuite et obtenez un sous-domaine éphémère — quelque chose comme cool-app.ngrok-free.app. Vous enregistrez cette URL comme URI de redirection OAuth valide dans les paramètres de votre GitHub App, terminez vos tests, puis fermez le tunnel. Le sous-domaine retourne dans le pool gratuit.

L’attaque

Un attaquant utilisant un script de revendication de sous-domaine récupère cool-app.ngrok-free.app. Désormais, tout utilisateur cliquant sur un ancien lien “Se connecter” — depuis un email en cache, un message Slack de staging, ou autre — s’authentifie avec GitHub et est redirigé vers votre ancien sous-domaine avec un code d’autorisation dans l’URL : ?code=abc123.

Le serveur de l’attaquant, maintenant sur ce sous-domaine, capture le code. Il l’échange contre un jeton d’accès. Il est maintenant authentifié en tant qu’utilisateur.

Ce n’est pas une théorie. Des recherches en sécurité documentées lors de Black Hat Asia ont montré comment des incohérences dans l’analyseur d’URL des fournisseurs OAuth permettaient aux attaquants de détourner des comptes dans plusieurs applications réelles. Counter Threat Unit de Secureworks a documenté la prise de contrôle d’URI de redirection Azure comme une voie d’attaque concrète où des acteurs malveillants obtiennent des jetons d’accès en se faisant passer pour des utilisateurs légitimes. Des recherches de début 2025 ont révélé une faille similaire intégrée dans des dizaines de systèmes de réservation de compagnies aériennes, mettant des millions d’utilisateurs en danger.

L’attaque est aggravée par des configurations d’URI de redirection “joker”. Lorsqu’une application OAuth autorise toute correspondance de sous-domaine (*.ngrok-free.app), un attaquant n’a pas besoin de revendiquer un sous-domaine précis — n’importe quel sous-domaine qu’il contrôle sous ce pattern fonctionne comme cible de redirection valide.

L’anatomie d’une sonde silencieuse

La variante 2026 de cette attaque n’attend pas que les utilisateurs cliquent sur d’anciens liens. En créant des URLs d’autorisation avec prompt=none, les attaquants peuvent silencieusement vérifier si un utilisateur a une session active avec un IdP et le rediriger vers un sous-domaine hijacké sans jamais afficher d’écran de connexion. L’utilisateur ne voit rien. L’attaquant obtient un code.

Mitigations réellement efficaces

N’utilisez jamais de sous-domaines éphémères pour OAuth. Enregistrez un domaine personnalisé que vous possédez et contrôlez — dev.yourcompany.com — et utilisez-le comme URI de redirection. Quand le tunnel se ferme, le domaine ne va nulle part.

Implémentez PKCE (Proof Key for Code Exchange). PKCE ajoute un code_verifier à l’échange de jeton, généré côté client et jamais transmis sur le réseau. Même si un attaquant intercepte le code d’autorisation, il ne peut pas l’échanger contre un jeton sans le vérificateur. C’est la mitigation la plus efficace contre l’interception de code d’autorisation, et elle doit être obligatoire dans tous vos flux OAuth.

Exigez une correspondance exacte de l’URI de redirection. Configurez votre IdP pour requérir une correspondance exacte — pas de jokers, pas de préfixes, pas de règles basées sur des motifs. La spécification OAuth recommande cela, mais beaucoup de fournisseurs permettent une correspondance plus lâche par défaut.

Validez le paramètre state. Le paramètre state existe pour prévenir les attaques CSRF dans les flux OAuth. Assurez-vous qu’il est généré avec une forte entropie, stocké côté serveur avant la redirection, et validé à la réception. Beaucoup d’implémentations l’omettent ou le vérifient de manière incohérente.

Gardez les tunnels à durée courte. Si vous devez utiliser un tunnel SaaS pour tester OAuth, faites-le expirer immédiatement après la fin de la session. Certaines équipes scriptent cela dans leur nettoyage de test.

Héberger soi-même le pipeline : Bore, frp, et Pangolin

Alors que les exigences de souveraineté des données se renforcent et que les coûts SaaS s’accumulent, une part croissante de la communauté technique se tourne vers le tunneling auto-hébergé. La logique est simple : un VPS à 5$/mois et un binaire Rust peuvent offrir plus de bande passante, une meilleure confidentialité, et un contrôle total sur vos données — sans coûts SaaS par utilisateur.

L’écosystème auto-hébergé a considérablement mûri. Voici où en sont les principaux outils.

Bore : Minimal, Rapide, Sûr en mémoire

Bore est un tunnel basé sur Rust, conçu pour la simplicité. Un seul binaire, pas de configuration complexe, empreinte mémoire minimale. Il est destiné aux cas où une petite équipe doit exposer des services locaux pour des tests internes sans overhead de latence.

Ce que Bore n’est pas : un proxy basé sur l’identité. C’est explicitement un “tuyau simple” — transport rapide et sécurisé sans couche d’authentification propre. Si vous déployez Bore, vous gérez la sécurité aux deux extrémités. Pour des tests temporaires, internes, entre développeurs qui se font confiance, ce compromis est acceptable. Pour tout ce qui touche des utilisateurs externes ou des données sensibles, ce n’est pas recommandé.

Idéal pour : Tunnels rapides et temporaires pour flux de travail internes.

frp (Fast Reverse Proxy) : Le couteau suisse

frp est le pilier fiable du monde auto-hébergé depuis des années, et il reste l’option la plus complète pour les cas non-HTTP. Il supporte TCP, UDP, HTTP, et HTTPS, ce qui est crucial quand vous devez tunneliser un port de base de données, une session RDP, ou un protocole personnalisé en plus du trafic web.

frp supporte des modes “Secret” nécessitant un token, un équilibrage de charge basique, et un tableau de bord optionnel. La configuration est verbose — fichiers INI ou YAML avec une courbe d’apprentissage — mais la richesse des protocoles supportés et la maturité du projet en font le choix par défaut pour des réseaux complexes.

Idéal pour : Topologies réseau complexes, protocoles non-HTTP, équipes à l’aise avec une configuration avancée.

Pangolin : La suite tout-en-un Zero Trust

Pangolin est la nouveauté la plus significative dans le domaine du tunneling auto-hébergé. Construit par Fossorial (une société Y Combinator 2025), il a accumulé près de 19 000 étoiles sur GitHub et plus de 140 000 installations en moins d’un an. La promesse : Cloudflare Tunnels, mais vous contrôlez l’infrastructure.

Pangolin combine un reverse proxy, VPN, et contrôle d’accès basé sur l’identité dans une seule stack déployable. Il utilise Traefik pour le routage et un client WireGuard personnalisé appelé Newt qui crée des tunnels cryptés entre réseaux distants vers un serveur central Pangolin — pas besoin d’ouvrir des ports sur votre routeur. Il fonctionne proprement via CGNAT, DS-Lite, et autres configurations ISP restrictives.

La couche de gestion distingue Pangolin de Bore et frp. Un tableau de bord web gère la configuration, la gestion SSL via Let’s Encrypt, le contrôle d’accès basé sur les rôles, et l’intégration SSO/OIDC — tout cela sans toucher aux fichiers de configuration. Le modèle Zero Trust de Pangolin est implémenté via un plugin Traefik appelé Badger, qui authentifie chaque requête entrante.

Une mise à jour récente a poussé Pangolin plus loin dans le territoire ZTNA : des clients natifs pour Windows, macOS, et Linux permettent désormais aux utilisateurs d’accéder aux ressources sur tous les sites connectés en utilisant des adresses LAN familières, avec des requêtes DNS routées via le tunnel sécurisé. Cela déplace Pangolin du “self-hosted Cloudflare Tunnels” vers un territoire concurrent réel à Twingate/Tailscale.

La sécurité peut être renforcée avec l’intégration CrowdSec, disponible via le script d’installation, qui ajoute une intelligence collective contre les menaces et un blocage en temps réel au gateway Pangolin.

Idéal pour : Équipes et opérateurs de homelab souhaitant des fonctionnalités équivalentes à Cloudflare — interface, SSO, RBAC, SSL automatique — avec contrôle total de l’infrastructure et sans vendor lock-in.

Comparatif : Options de tunnels auto-hébergés

Fonctionnalité	Bore	frp	Pangolin
Langage	Rust	Go	Go / WireGuard
Modèle de sécurité	Tuyau seul	Tokens / SSL	OIDC / SAML / RBAC
Support non-HTTP	Non	Oui	Oui (via clients)
Dashboard	Non	Optionnel	Oui (gestion complète)
Complexité de setup	Trivial	Modérée	Complexe (Docker/VPS)
Capacités ZTNA	Aucune	Aucune	Oui
Idéal pour	Tunnels temporaires	Réseaux complexes	Zero Trust à long terme

Mise en pratique : un workflow développeur 2026

Voici une synthèse pratique de tout cela.

Pour développeurs individuels travaillant sur des intégrations OAuth ou partageant du travail local avec un client, le moteur de politique de trafic ngrok offre une enforcement d’identité de niveau entreprise avec un minimum de formalités. Définissez votre politique OIDC ou OAuth en YAML, lancez le tunnel avec --traffic-policy-file, utilisez un domaine statique personnalisé plutôt qu’un éphémère, et implémentez PKCE dans votre flux OAuth. C’est une configuration locale sécurisée et prête pour la production.

Pour petites à moyennes équipes nécessitant la souveraineté des données et disposant d’un VPS, Pangolin est la meilleure option actuelle. Le script d’installation gère toute la stack — Pangolin, Gerbil, Traefik, Let’s Encrypt — et ajouter un nouveau site se fait en un seul conteneur Docker avec trois variables d’environnement. Le tableau de bord facilite la gestion des utilisateurs et ressources, et l’intégration OIDC permet de le connecter à votre fournisseur d’identité existant.

Pour les organisations avec des exigences de conformité, une infrastructure multi-environnement, et des ressources pour Kubernetes, Octelium est l’option la plus architecturale. Accès sans secret, évaluation de politique par requête, ABAC via CEL et OPA, observabilité native OpenTelemetry, et un plan de contrôle auto-hébergé entièrement open source le placent en catégorie à part parmi les outils open source.

L’ère de l’edge basé sur l’identité

Le tunnel n’est plus une astuce de commodité. C’est une infrastructure — et elle doit être traitée avec la même rigueur que votre environnement de production.

L’époque du “perce un trou et espère le meilleur” est terminée, clôturée par une combinaison d’outils Zero Trust matures, d’attaques de détournement OAuth de plus en plus sophistiquées, et d’exigences de souveraineté des données rendant les approches SaaS-only impossibles pour un nombre croissant d’organisations.

Les outils pour faire cela correctement — ngrok Traffic Policies, Octelium, Pangolin — sont disponibles aujourd’hui, beaucoup en open source et gratuits. La question n’est plus de savoir si vous pouvez vous permettre d’implémenter un tunneling basé sur l’identité. C’est de savoir si vous pouvez vous permettre de ne pas le faire.

Au-delà de la liste blanche IP : Tunneling développeur basé sur l'identité en 2026