EIP-4361 : Le Sign-In With Ethereum expliqué en détail pour les développeurs

SAMI
April 12, 2025 6 mins to read
Share

Dans l’univers Web3, l’authentification décentralisée est essentielle pour garantir que les utilisateurs peuvent interagir avec les applications sans sacrifier leur vie privée. EIP-4361, ou Sign-In With Ethereum, propose une méthode standardisée pour s’authentifier en utilisant un wallet Ethereum, sans avoir besoin de créer un mot de passe ou de partager des informations personnelles telles qu’un email.

Ce document explique le fonctionnement technique de l’EIP-4361 et la manière dont les développeurs peuvent l’intégrer dans leurs applications décentralisées (DApps).


Qu’est-ce qu’un EIP et pourquoi EIP-4361 ?

Un EIP (Ethereum Improvement Proposal) est une proposition visant à améliorer les protocoles Ethereum ou à introduire de nouvelles normes dans l’écosystème. EIP-4361 est une proposition qui vise à standardiser l’authentification via un message signé, utilisant Ethereum comme mécanisme d’identité.

Cette méthode élimine les mots de passe traditionnels, remplaçant ainsi les mécanismes d’authentification classiques par des signatures cryptographiques vérifiables. Ce processus simplifie l’intégration des DApps tout en garantissant une sécurité renforcée par l’infrastructure décentralisée d’Ethereum.


Le Processus d’Authentification EIP-4361

L’authentification par EIP-4361 repose sur une signature cryptographique effectuée via un wallet Ethereum. Voici un aperçu détaillé du flux technique :

  1. Initialisation de la demande d’authentification
    • L’application génère une demande d’authentification, qui contient un message structuré à signer par l’utilisateur.
    • Le message inclut des informations essentielles telles que l’adresse Ethereum de l’utilisateur, le domaine de l’application, le nonce, etc.
  2. Signature du message
    • L’utilisateur signe le message via son wallet Ethereum (par exemple, MetaMask ou WalletConnect).
    • Le message signé ne modifie pas l’état de la blockchain et ne génère pas de frais de gas. Il s’agit uniquement d’une preuve cryptographique que l’utilisateur contrôle l’adresse Ethereum.
  3. Vérification de la signature
    • L’application reçoit la signature et la vérifie en utilisant la clé publique associée à l’adresse Ethereum.
    • Si la signature est valide, l’utilisateur est authentifié, et l’application peut lui accorder l’accès.

Structure du Message à Signer

Le message que l’utilisateur signe doit suivre une structure spécifique définie par EIP-4361. Voici les champs de base que le message contiendra :

Structure du message :

{
  "domain": "example.com",
  "address": "0xAbC123...",
  "statement": "Sign in to DAppX",
  "uri": "https://example.com",
  "version": "1",
  "chainId": "1",
  "nonce": "k1G9w4",
  "issuedAt": "2025-04-11T09:00:00Z",
  "expirationTime": "2025-04-12T09:00:00Z",
  "notBefore": "2025-04-11T08:00:00Z"
}




  • domain : Domaine de l’application demandant l’authentification (ex. example.com).
  • address : L’adresse Ethereum de l’utilisateur, sous forme de chaîne hexadécimale.
  • statement : Message personnalisé indiquant l’intention de la signature (ex. “Sign in to DAppX”).
  • uri : L’URL de l’application pour laquelle l’authentification est demandée.
  • version : Version du message, par défaut à “1”.
  • chainId : ID de la chaîne (ex. 1 pour la mainnet Ethereum).
  • nonce : Identifiant unique pour empêcher les attaques par replay.
  • issuedAt : Timestamp indiquant quand le message a été émis.
  • expirationTime : Heure d’expiration du message.
  • notBefore : Temps avant lequel le message ne peut pas être utilisé.

Le message est ensuite signé avec la clé privée de l’utilisateur, ce qui génère une signature cryptographique unique.


Vérification de la Signature

La vérification de la signature se fait en deux étapes clés :

Récupération de l’adresse à partir de la signature

  • En utilisant la bibliothèque eth-sig-util (ou une bibliothèque similaire), vous pouvez récupérer l’adresse Ethereum à partir du message signé.
Exemple de code en JavaScript pour vérifier la signature :

      const { recoverPersonalSignature } = require('eth-sig-util');
      const message = '0x...'; // Message à signer
      const signature = '0x...'; // Signature retournée par l'utilisateur
      
      const recoveredAddress = recoverPersonalSignature({
        data: message,
        sig: signature,
      });
      
      if (recoveredAddress === userAddress) {
        console.log("Signature vérifiée avec succès !");
      } else {
        console.log("Échec de la vérification de la signature");
      }

      Validation du message

      • L’application doit valider que le message signé correspond à celui attendu et qu’il n’a pas expiré.
      • Si tout est valide (signature, expiration, etc.), l’authentification est réussie et l’utilisateur est autorisé à se connecter.

        Intégration d’EIP-4361 dans votre DApp

        Bibliothèques et Outils

        Pour intégrer facilement EIP-4361, vous pouvez utiliser les bibliothèques suivantes :

        • eth-sig-util : Une bibliothèque JavaScript pour signer et vérifier des messages.
        • web3.js : Pour interagir avec Ethereum, notamment pour signer des messages.
        • ethers.js : Une alternative populaire à Web3.js, plus légère et moderne.

        Exemple d’intégration avec ethers.js

        import { ethers } from "ethers";
        
        async function signInWithEthereum() {
          const provider = new ethers.providers.Web3Provider(window.ethereum);
          const signer = provider.getSigner();
          
          const domain = "example.com";
          const address = await signer.getAddress();
          const nonce = Math.floor(Math.random() * 1000000); // Exemple de nonce
          const message = `Sign in to ${domain} with your address: ${address}, nonce: ${nonce}`;
        
          const signature = await signer.signMessage(message);
        
          // Envoyer le message et la signature à votre backend pour vérification
          const response = await fetch('/verify', {
            method: 'POST',
            body: JSON.stringify({ message, signature }),
            headers: { 'Content-Type': 'application/json' }
          });
        
          const data = await response.json();
          if (data.success) {
            console.log("Utilisateur authentifié avec succès !");
          } else {
            console.log("Échec de l'authentification");
          }
        }
        

        Avantages pour les Développeurs

        ✅ Facilité d’intégration

        EIP-4361 simplifie l’intégration de l’authentification décentralisée en standardisant le processus de connexion avec Ethereum. Il est compatible avec tous les wallets Ethereum populaires et ne nécessite pas de gestion de mot de passe.

        🔐 Sécurité renforcée

        En utilisant la cryptographie asymétrique d’Ethereum, les utilisateurs peuvent prouver leur identité sans exposer leurs informations personnelles. De plus, les données sensibles restent dans la blockchain, réduisant les risques de piratage ou de vol de données.

        🚀 Expérience utilisateur simplifiée

        L’authentification via signature Ethereum est fluide et rapide. L’utilisateur n’a qu’à signer un message via son wallet, ce qui est beaucoup plus simple que de se rappeler d’un mot de passe ou de passer par une vérification par email.


        Conclusion

        EIP-4361 est une avancée significative dans le domaine de l’authentification décentralisée, permettant une intégration transparente des DApps avec des processus de connexion simplifiés et sécurisés. Pour les développeurs, cela représente une méthode standard et éprouvée pour gérer l’identité des utilisateurs dans un monde Web3 décentralisé.

        En adoptant EIP-4361, vous contribuez à une expérience utilisateur plus fluide tout en renforçant la sécurité et la confidentialité des données. Il ne s’agit pas seulement d’un gain en termes de simplicité, mais aussi d’une avancée vers un internet plus privé et plus autonome.

        Leave a comment

        Your email address will not be published. Required fields are marked *