Tunneling en auto-souverain : utiliser les DIDs pour remplacer les tokens d'authentification centralisés
0tape Stop faisant confiance à des fournisseurs tiers avec vos tokens d’authentification. Voici comment l’Identité Auto-Souveraine (SSI) et les Identifiants Décentralisés (DIDs) permettent une nouvelle génération de tunnels peer-to-peer — où votre portefeuille d’identité est la seule “connexion” dont vous aurez jamais besoin.
Introduction : La transition vers un tunneling décentralisé
Pendant la majeure partie du début des années 2020, la boîte à outils des développeurs pour l’exposition locale-vers-public était dominée par quelques fournisseurs centralisés de “tunnel en tant que service”. ngrok, Cloudflare Tunnel, et leurs contemporains sont devenus des noms familiers dans le cercle des développeurs. Pratique, oui. Mais architecturally défectueux d’une manière critique : le fournisseur devenait le gardien de votre identité.
Pour ouvrir un tunnel, vous aviez besoin d’un compte. Pour authentifier, vous aviez besoin d’un Bearer Token stocké dans un fichier .yml. Si la base de données de ce fournisseur était compromise — ou si vous aviez accidentellement commis votre configuration dans un dépôt public — votre point d’entrée local était totalement exposé.
L’industrie évolue maintenant à travers une correction fondamentale. Les développeurs ne louent plus des identités auprès de fournisseurs ; ils apportent les leurs. C’est l’ère des SSI-Tunnels — des poignées cryptographiques entre entités souveraines, basées sur les Identifiants Décentralisés (DIDs) et le réseautage peer-to-peer, sans intermédiaire.
Qu’est-ce que l’Identité Auto-Souveraine ?
Avant d’aborder spécifiquement les tunnels, il est utile de comprendre la fondation plus large qui les sous-tend.
L’Identité Auto-Souveraine (SSI) est un modèle de gestion d’identité qui donne aux individus et aux systèmes la pleine propriété et contrôle de leurs identités numériques, sans dépendre d’une autorité centrale. Comme l’a établi le groupe de travail DID du W3C via sa spécification DID v1.0, un DID est un nouveau type d’identifiant unique mondial permettant une identité numérique vérifiable et décentralisée — contrôlée par le propriétaire, et non par une entreprise ou un registre gouvernemental.
L’architecture SSI repose sur trois participants :
- Détenteur — l’entité (personne, serveur ou appareil) qui crée et contrôle un DID via un portefeuille numérique et reçoit des Credentials Vérifiables.
- Émetteur — l’autorité qui délivre des Credentials Vérifiables cryptographiquement signés concernant le détenteur.
- Vérificateur — la partie qui vérifie la crédentiale sans jamais avoir besoin de contacter directement l’émetteur.
Ce “triangle de confiance” sous-tend tout, des diplômes numériques et dossiers de santé aux flux d’authentification dans les outils de développement.
Le marché SSI reflète cette dynamique. Selon des projections récentes, le marché mondial SSI devrait passer d’environ 3,49 milliards de dollars en 2025 à un exceptionnel 1,15 trillion de dollars d’ici 2034, avec un taux de croissance annuel composé supérieur à 90%. Que cette prévision s’avère précise ou non, le signal est clair : l’identité décentralisée devient une infrastructure.
Qu’est-ce qu’un SSI-Tunnel ?
Un SSI-Tunnel est un pont réseau sécurisé et crypté établi entre deux points — généralement une machine locale de développeur et un client distant — où l’authentification est gérée exclusivement via les protocoles SSI.
Contrairement aux tunnels traditionnels qui s’appuient sur un serveur relais central pour valider une clé API, un SSI-tunnel utilise un DID (Identifiant Décentralisé) pour prouver la propriété d’un point d’extrémité. Il n’y a pas de compte à créer, pas de token à stocker, et pas de base de données fournisseur susceptible d’être compromise.
Composants clés
DIDs (Identifiants Décentralisés) Une norme W3C pour une nouvelle classe d’identifiants permettant une identité numérique vérifiable et auto-souveraine. Chaque DID aboutit à un Document DID contenant les clés publiques nécessaires à la vérification.
Le portefeuille d’identité Un CLI ou une application qui détient vos clés privées et signe les défis d’authentification. Considérez-le comme votre clé de sécurité matérielle, mais pour l’internet ouvert.
KERI (Infrastructure de Réception d’Événements Clés) Proposé par Samuel M. Smith et documenté dans arXiv:1907.02143, KERI fournit un protocole sans registre pour gérer les rotations de clés et établir une “Root of Trust” sans nécessiter une blockchain pour chaque événement d’authentification. KERI introduit des Identifiants Autonomes (AID) — des identifiants auto-certifiants liés à des paires de clés cryptographiques dès l’inception, avec un Journal d’Événements Clés (KEL) en chaîne de hachages que tout pair peut vérifier indépendamment.
libp2p (Transport P2P) La pile réseau sous-jacente initialement développée pour IPFS et maintenant largement adoptée dans l’écosystème décentralisé. Elle gère la traversée NAT (“hole punching”) pour connecter deux machines derrière des pare-feux directement, sans faire passer le trafic par un serveur relais.
La fin du token d’authentification
Depuis des années, le ngrok-auth-token était un point d’entrée connu pour les attaques. Une pipeline CI/CD mal configurée, un fichier .env commis par erreur, ou une fuite dans la base de données du fournisseur — et votre environnement de développement local devenait une porte ouverte à votre réseau interne.
Dans un SSI-Tunnel, il n’y a pas de token d’authentification persistant. La connexion suit un flux Zero-Trust :
- Requête — Un client tente de se connecter à votre adresse de tunnel.
- Défi — Le logiciel du tunnel émet un défi cryptographique (nonce).
- Signature — Vous “vous connectez” en signant ce défi avec la clé privée de votre Wallet d’Identité.
- Vérification — Le client vérifie la signature avec votre DID public, résolvable via un DHT ou une blockchain comme Polygon ou Cheqd.
Pas de mot de passe. Pas de base de données fournisseur. Aucun point central de défaillance.
La pile technique en profondeur
Établir un tunnel sans fournisseur central nécessite de résoudre deux problèmes fondamentaux : identité et connectivité.
La couche identité : DIDs et KERI
L’industrie s’éloigne des systèmes d’identité “lourds” sur registre pour les tâches de réseautage. Les premiers SSI dépendaient de l’écriture de chaque changement de clé sur une blockchain — coûteux, lent, et fragile opérationnellement. KERI offre une alternative plus pratique.
Avec KERI, lorsque vous démarrez un tunnel, votre CLI génère un Journal d’Événements Clés (KEL). Ce journal est une séquence en chaîne de hachages d’événements — Inception, Rotation, Interaction — ancrée sans registre externe. Parce que le journal est end-verifiable, tout pair peut confirmer votre identité en rejouant le journal. Aucun fournisseur d’identité (IdP) requis. Aucun appel réseau à un nœud blockchain nécessaire.
L’infrastructure SSI réelle mûrit autour de ce modèle. Des projets comme Hyperledger Indy (Linux Foundation), la Sovrin Foundation, et l’EBSI (European Blockchain Services Infrastructure) déploient activement des systèmes de crédentiels vérifiables à grande échelle — fournissant la plateforme éprouvée sur laquelle les SSI-Tunnels peuvent s’appuyer.
La couche connectivité : libp2p et hole punching
Sans relais central, comment deux ordinateurs derrière différents pare-feux et NAT se trouvent-ils ?
Les SSI-Tunnels utilisent la découverte peer décentralisée basée sur des Tables de Hachage Distribuées (DHT) basées sur Kademlia. Votre tunnel annonce son DID au DHT. Lorsqu’un client veut se connecter, il recherche le DID, récupère la “multiadresse” la plus récente (une combinaison structurée d’IP, port, et protocole), et initie une poignée de main STUN/TURN pour percer le NAT — établissant une connexion directe sans faire passer le trafic par un serveur tiers.
Comparaison des approches
| Fonctionnalité | Tunnel centralisé (Legacy) | SSI-Tunnel |
|---|---|---|
| Authentification | Bearer Token / OAuth | Signature DID / Wallet |
| Modèle de confiance | Faire confiance au fournisseur | Faire confiance à la cryptographie |
| Chemin des données | Via serveur relais | Peer-to-Peer (Direct) |
| Journalisation | Côté fournisseur (opaque) | Journaux KERI vérifiables (Vérifiables) |
| Point de défaillance | Fuite de la base de données du fournisseur | Aucun (pas de stockage central) |
| Coût | Abonnement mensuel | Infrastructure libre / Open source |
Pourquoi la pression réglementaire accélère cette transition
Plusieurs forces convergentes — pas seulement des préférences de sécurité — rendent les tunnels authentifiés par DID de plus en plus nécessaires, notamment dans les industries réglementées.
eIDAS 2.0 et le portefeuille d’identité numérique européen
Le règlement eIDAS révisé de l’UE (Règlement UE 2024⁄1183), entré en vigueur le 20 mai 2024, impose à chaque État membre de l’UE de rendre disponible au moins un Portefeuille d’Identité Numérique UE (EUDI Wallet) pour les citoyens et résidents d’ici décembre 2026. Ce portefeuille doit supporter les Credentials Vérifiables, la divulgation sélective d’attributs, et des pistes d’audit cryptographiquement vérifiables.
Pour les développeurs en FinTech, MedTech, ou tout contexte réglementé en UE, ce n’est pas une aspiration — c’est une échéance légale. Les organisations dans la finance, la santé, les télécommunications, et l’infrastructure numérique doivent pouvoir accepter l’authentification via portefeuille et produire des pistes d’audit conformes. Les tunnels relais tiers, qui acheminent un trafic non chiffré ou opaque, sont fondamentalement incompatibles avec ces exigences.
La Commission a également adopté des standards techniques pour l’interopérabilité transfrontalière des portefeuilles en novembre 2024, donnant aux développeurs une cible concrète pour la construction.
HIPAA et la chaîne de garde des données
Aux États-Unis, la mise à jour des directives HIPAA insiste de plus en plus sur le concept de “chaîne de garde des données” — la capacité à démontrer, avec certitude cryptographique, qui a accédé à quelles données, quand, et par quel canal. Un fournisseur de tunnel tiers qui enregistre les connexions de manière opaque ne peut pas fournir cela. Un SSI-Tunnel basé sur KERI, où chaque événement de connexion est signé dans un Journal d’Événements Clés immuable, peut.
Sécurité post-quantique : une préoccupation réelle
Les tokens d’authentification traditionnels — et les signatures RSA ou ECDSA sous-jacentes à la majorité du TLS moderne — sont vulnérables à une classe d’attaques connue sous le nom de “collecte maintenant, déchiffrement plus tard”, où un adversaire stocke le trafic crypté aujourd’hui, en prévision de le déchiffrer lorsqu’un ordinateur quantique cryptographiquement pertinent sera disponible.
Ce n’est plus une menace future hypothétique. NIST a finalisé ses trois premiers standards de Cryptographie Post-Quantique (PQC) en août 2024 :
- FIPS 203 (ML-KEM, dérivé de CRYSTALS-Kyber) — pour l’encapsulation de clés et le chiffrement.
- FIPS 204 (ML-DSA, dérivé de CRYSTALS-Dilithium) — standard principal pour les signatures numériques résistantes aux quantiques.
- FIPS 205 (SLH-DSA, dérivé de SPHINCS+) — une scheme de backup basée sur le hachage.
Un quatrième standard, FIPS 206 (FN-DSA, dérivé de FALCON), progresse dans le pipeline de standardisation et est particulièrement pertinent pour les SSI-Tunnels : FALCON produit des signatures compactes adaptées à l’authentification à haut débit — précisément le type de charge de travail que représentent les handshakes de tunnel.
En mars 2025, NIST a également sélectionné HQC comme cinquième algorithme, fournissant un KEM basé sur le code en backup de ML-KEM.
Les implémentations modernes de SSI-Tunnel peuvent intégrer directement des signatures PQC (ML-DSA ou FN-DSA) dans le Document DID, garantissant que les handshakes d’authentification restent sécurisés contre les adversaires classiques et quantiques. C’est une propriété qu’aucun système basé sur un Bearer Token ne peut offrir.
La valeur ajoutée de l’audit : réseau prêt pour l’audit
Une des fonctionnalités opérationnelles les plus importantes des SSI-Tunnels est leur capacité intrinsèque d’audit.
Dans un modèle de tunnel basé sur un fournisseur, vous faites confiance à l’exactitude des logs du fournisseur — mais vous ne pouvez pas les vérifier indépendamment. Le fournisseur contrôle le journal. Dans un modèle SSI, le Journal d’Événements Clés (KEL) est le registre. Il est enchaîné par hachage, en append-only, et vérifiable indépendamment par toute partie disposant du journal et de la clé d’inception du DID.
Pour un développeur FinTech déboguant un problème en production via une session de tunnel, cela signifie que vous pouvez démontrer à un auditeur de conformité — avec une preuve cryptographique — qu’une seule DID autorisée a accédé au système durant cette session. Le journal n’est pas un rapport généré après coup ; c’est une propriété structurelle du protocole.
Cela correspond directement à la catégorie “Attestation Électronique d’Attributs” récemment définie sous eIDAS 2.0, où les services de confiance doivent fournir des enregistrements vérifiables cryptographiquement des interactions.
Un flux de travail conceptuel
Bien que les outils de production spécifiques continuent de mûrir, le flux de travail pour un SSI-Tunnel diffère fondamentalement du modèle basé sur un compte :
Étape 1 : Initialiser votre DID
Au lieu de ngrok config add-authtoken <token>, vous générez une identité contrôlée localement :
# Générer un nouveau Identifiant Autonome basé sur KERI
ssi-tunnel identity create --name "noeud-dev-local"
# Résultat : did:keri:Emkr4SGBXRoRPiWXW3GR7Q...
Étape 2 : Établir le tunnel
Vous définissez le port local à exposer et le liez à votre DID :
# Démarrer un tunnel P2P lié à votre identité DID
ssi-tunnel share http://localhost:3000 --id did:keri:Emkr4SGBXRoRPiWXW3GR7Q...
# Tunnel actif à : did:keri:Emkr4SGBXRoRPiWXW3GR7Q.tunnel
Étape 3 : Authentification peer
Lorsqu’un collaborateur ou client souhaite se connecter, leur environnement ne “tape” pas simplement l’URL. Leur client effectue une poignée de main DIDAuth :
- Le client envoie une Demande DIDAuth contenant un défi cryptographique (nonce).
- Votre machine locale envoie une notification push à votre Wallet d’Identité.
- Vous approuvez la connexion.
- La réponse signée est vérifiée contre votre Document DID public.
- Le flux P2P est établi — directement, sans passer par un relais.
Tout l’échange est enregistré dans le KEL des deux côtés.
Infrastructure SSI existante : ce qui est déjà en place
Le concept de SSI-Tunnel ne repose pas sur des hypothèses. Il hérite d’une infrastructure de production déjà déployée :
- Hyperledger Indy / Aries (Linux Foundation) — une implémentation blockchain conçue pour l’identité décentralisée, avec un cadre d’agents pour l’échange de crédentiels. Utilisée par des gouvernements et entreprises à l’échelle mondiale.
- Sovrin Network — une infrastructure SSI open-source utilisant un registre permissionné pour les Credentials Vérifiables.
- EBSI (European Blockchain Services Infrastructure) — une initiative paneuropéenne supportant diplômes numériques, identité transfrontalière, et services gouvernementaux, directement conforme à eIDAS 2.0.
- ID Union (Allemagne) — un réseau d’identité décentralisée impliquant banques, universités, et autorités.
- MyData Finlande — un cadre de données personnelles contrôlé par le citoyen, en production dans les services publics et privés.
Ce ne sont pas des preuves de concept. Ce sont les couches d’infrastructure sur lesquelles la tooling de développement authentifiée par DID peut s’appuyer aujourd’hui.
Limitations et avertissements honnêtes
Une évaluation crédible doit reconnaître où les SSI-Tunnels sont encore en maturation :
Écart d’utilisabilité. La gestion des clés cryptographiques, des Documents DID, et des wallets d’identité reste complexe. La transition place la responsabilité de la sécurité des clés sur le développeur ou l’utilisateur — perdre votre clé privée, et la récupération est difficile. Les mots de passe traditionnels sont mauvais ; les clés perdues, pires.
Fragmentation de l’interopérabilité. Plusieurs méthodes DID existent (did:web, did:key, did:keri, did:ion, etc.), et elles n’interopèrent pas toutes parfaitement. L’absence d’un protocole universel crée des frictions dans l’écosystème.
Immaturité des outils. Les outils SSI-Tunnel de production sont encore en développement. Les développeurs qui adoptent ce pattern aujourd’hui sont des early adopters, utilisant des bibliothèques et protocoles, pas des produits finis.
Scalabilité des systèmes basés sur KERI. Bien que KERI évite la surcharge blockchain pour chaque connexion, une infrastructure de témoins à haute fréquence nécessite une conception opérationnelle soignée.
Équité numérique. Les systèmes SSI supposent un accès Internet fiable, des appareils compatibles, et une literacy numérique suffisante. C’est une limite réelle même dans un contexte de développement.
Ce qui vient ensuite
La trajectoire est claire, même si le calendrier est incertain :
Support DID natif dans les navigateurs. Des propositions existent au W3C pour que les navigateurs gèrent nativement les handshakes DIDAuth, supprimant le besoin de clients CLI séparés côté utilisateur. La mise en œuvre de eIDAS 2.0 pour l’intégration du portefeuille EUDI dans les grandes plateformes en 2027 accélérera cela.
Identité autonome pour microservices. Les serveurs utiliseront des DIDs pour négocier des connexions entre eux pour la communication microservice, évoluant vers une couche d’infrastructure réellement “sans fournisseur”.
Découverte de services décentralisée. Des noms lisibles par l’humain liés aux DIDs via des services de noms décentralisés (ENS, .did) remplaceront le modèle de sous-domaine aléatoire actuel.
DID post-quantum natifs. Avec l’adoption accélérée de ML-DSA et FN-DSA après la finalisation par NIST en 2024, on peut s’attendre à ce que les DID intègrent par défaut des clés post-quantum plutôt que des options.
Conclusion
La transition vers les SSI-Tunnels est plus qu’une mise à niveau de sécurité — c’est une correction structurelle d’une erreur architecturale de longue date. Les fournisseurs centralisés se sont insérés comme gardiens d’identité non pas parce que la technologie l’exigeait, mais parce que l’outillage pour faire autrement n’existait pas encore. Cet outillage existe maintenant, ou est en train d’être rapidement construit.
La norme DID du W3C est finalisée. KERI est spécifié et en développement actif. Les standards cryptographiques post-quantiques de NIST sont publiés. eIDAS 2.0 est loi. Les industries réglementées, qui représentent les cas d’utilisation les plus précieux pour les développeurs, convergent vers exactement les propriétés — pistes d’audit vérifiables, identité souveraine, absence de point de défaillance central — que les SSI-Tunnels offrent par conception.
Votre token d’authentification a toujours été une responsabilité. Votre portefeuille d’identité est une preuve cryptographique. La différence a de l’importance.
Lectures complémentaires : Spécification DID Core du W3C · Article sur le protocole KERI (arXiv:1907.02143) · Standards PQC de NIST · Règlement eIDAS 2.0 (UE 2024⁄1183) · Hyperledger Indy · Sovrin Foundation
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Related Topics
Keep building with InstaTunnel
Read the docs for implementation details or compare plans before you ship.