Comment fonctionne la vérification eIDAS : analyse technique approfondie

Une analyse technique complète du flux de vérification eIDAS, de la génération du QR code à la validation des attributs, avec les protocoles, les mesures de sécurité et les modèles d'intégration.

Équipe eIDAS Pro
22 janvier 2026
12 min de lecture

Vue d'ensemble du flux de vérification

La vérification d'identité fondée sur eIDAS suit une séquence soigneusement orchestrée, conçue pour équilibrer sécurité, protection de la vie privée et expérience utilisateur. Comprendre ce flux est essentiel pour les développeurs qui intègrent la vérification d'identité dans leurs applications.

Le processus complet de vérification implique quatre acteurs principaux :

  1. Relying Party (votre application) : le service qui demande la vérification d'identité
  2. Fournisseur de services eIDAS : le middleware qui relie votre application au réseau eIDAS
  3. Portefeuille eID national : l'application mobile de l'utilisateur (par ex. ID Austria, Smart-ID, BankID)
  4. Fournisseur d'identité national : le système public qui émet et valide les identités numériques

Parcourons chaque étape de ce processus en détail.

Étape 1 : initialisation de la session de vérification

Lorsque votre application doit vérifier l'identité d'un utilisateur, le processus commence par la création d'une session de vérification.

Requête de création de session

Votre application effectue un appel API vers votre fournisseur de services eIDAS :

POST /api/verification/create
{
  "requestedAttributes": ["age_over_18"],
  "purpose": "Age verification for purchase",
  "returnUrl": "https://yourapp.com/verification/callback"
}

Le champ requestedAttributes précise exactement les informations dont vous avez besoin. eIDAS Pro se concentre sur la vérification d'attributs booléens : vous recevez des réponses true/false, pas de données personnelles.

Vérification d'âge :

  • age_over_18 : l'utilisateur a-t-il 18 ans ou plus ?
  • age_over_21 : l'utilisateur a-t-il 21 ans ou plus ?
  • age_over_25 : l'utilisateur a-t-il 25 ans ou plus ?

Vérification de localisation/résidence :

  • is_eu_resident : l'utilisateur est-il résident de l'UE ?
  • is_eu_citizen : l'utilisateur est-il citoyen de l'UE ?

Pourquoi des attributs booléens ?

Cette approche offre une confidentialité maximale avec une exposition RGPD minimale :

  • Vous n'obtenez que l'information strictement nécessaire (oui/non)
  • Aucun nom, date de naissance ou adresse à stocker et à sécuriser
  • Aucun traitement de données de catégorie particulière
  • Une responsabilité en cas de fuite fortement réduite

Note de confidentialité : eIDAS Pro limite volontairement les attributs disponibles à des réponses booléennes. Si vous avez besoin de données d'identité complètes (noms, adresses), il faudra recourir à des approches de vérification documentaire, avec les obligations RGPD et les coûts associés. De nombreuses organisations utilisent eIDAS pour des cas d'usage européens à données minimales, et la vérification documentaire pour les scénarios qui exigent des données d'identité complètes.

Note sur le rôle de responsable de traitement : même si eIDAS minimise la collecte de données, votre organisation reste responsable de traitement pour tous les résultats de vérification que vous stockez. Consultez notre guide de conformité RGPD pour connaître vos obligations restantes.

Réponse de session

Le fournisseur de services génère une session de vérification unique et renvoie :

{
  "sessionId": "vs_a8f2b3c1...",
  "qrCodeData": "eidas://verify?session=vs_a8f2b3c1...",
  "deepLink": "at.gv.eid://verify?session=vs_a8f2b3c1...",
  "expiresAt": "2026-01-22T15:30:00Z",
  "statusUrl": "https://api.provider.com/verification/vs_a8f2b3c1/status"
}

La session expire généralement au bout de 5 à 10 minutes afin d'éviter les requêtes de vérification obsolètes.

Étape 2 : génération et affichage du QR code

Le QR code sert de passerelle entre votre application web et l'appareil mobile de l'utilisateur.

Contenu du QR code

Le QR code encode plusieurs informations critiques :

  1. Gestionnaire de protocole : eidas:// ou des schémas spécifiques à un pays comme at.gv.eid://
  2. Identifiant de session : relie cette vérification à votre session backend
  3. Point de terminaison du fournisseur de services : l'adresse à laquelle le portefeuille doit envoyer la requête de vérification
  4. Attributs demandés : les informations à vérifier

Standards modernes : OpenID4VP

Les implémentations eIDAS modernes utilisent OpenID for Verifiable Presentations (OpenID4VP), qui standardise la manière de demander et de présenter des justificatifs vérifiables. Le QR code contient :

openid4vp://?
  client_id=https://yourprovider.com
  &request_uri=https://yourprovider.com/request/vs_a8f2b3c1

Le request_uri pointe vers un JWT signé contenant la requête de vérification complète, ce qui garantit l'intégrité et empêche toute altération.

Bonnes pratiques d'affichage

Design adaptatif : sur mobile, affichez un bouton "appuyer pour ouvrir" au lieu d'un QR code, en utilisant des deep links pour lancer directement l'application portefeuille appropriée.

États de chargement : affichez une animation de scan et des instructions claires ("Scannez avec votre application eID nationale").

Options de secours : proposez des méthodes de vérification alternatives pour les utilisateurs sans portefeuille eID.

Étape 3 : authentification dans l'application portefeuille

Une fois le QR code scanné, l'application portefeuille eID nationale de l'utilisateur prend le relais.

Validation de la requête

L'application portefeuille :

  1. Récupère la requête complète : télécharge la requête signée depuis le request_uri
  2. Valide les signatures : s'assure que la requête provient d'un fournisseur légitime
  3. Vérifie la portée : confirme que les attributs demandés sont appropriés et légaux
  4. Affiche l'écran de consentement : montre à l'utilisateur exactement quelles informations seront partagées

Authentification utilisateur

Avant de transmettre la moindre information, le portefeuille exige une authentification forte. Les méthodes varient selon les pays, mais incluent généralement :

Authentification biométrique (la plus courante) :

  • Empreinte digitale
  • Reconnaissance faciale
  • Scan de l'iris

PIN/mot de passe : un code PIN numérique ou un mot de passe alphanumérique

Sécurité matérielle : de nombreux portefeuilles eID nationaux utilisent des éléments sécurisés (SE) ou des environnements d'exécution de confiance (TEE) sur l'appareil, ce qui garantit que les clés cryptographiques ne quittent jamais l'enclave sécurisée.

Exemple : flux ID Austria

  1. L'utilisateur lance l'application ID Austria en scannant le QR code
  2. L'application affiche : "eidas-pro.com demande : vérification d'âge (plus de 18 ans)"
  3. L'utilisateur vérifie puis appuie sur "Approuver"
  4. Invite biométrique : "Utilisez votre empreinte pour confirmer"
  5. L'utilisateur s'authentifie avec son empreinte
  6. L'application génère et signe la réponse de vérification

L'ensemble du flux in-app prend 3 à 5 secondes pour les utilisateurs récurrents.

Étape 4 : échange et validation des attributs

Après l'authentification utilisateur, le portefeuille prépare une réponse signée cryptographiquement contenant les attributs demandés.

Structure de la réponse

Le portefeuille génère une Verifiable Presentation en SD-JWT VC (Selective Disclosure JWT Verifiable Credentials), le format réellement utilisé par le portefeuille d'identité numérique de l'UE :

// SD-JWT VC with selective disclosure - only revealing age_over_18
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjK3NkLWp3dCJ9.
eyJpc3MiOiJodHRwczovL2lzc3Vlci5laWRhcy5ldSIsImlhdCI6MTY0MzI4NDgwMCwiZXhwIjoxNjQzMjg4NDAwLCJ2Y3QiOiJodHRwczovL2V4YW1wbGUuZXUvcGlkIiwic3ViIjoiZGlkOmp3azpleUp1SWpvaVJGTkJJaXdpZVNJNklqWTNOell4TWpFMk15SjkiLCJfc2QiOlsiRzVFbmhPQU9vVTlYXzhRQUFBQUFBQUFBQUEiLCJKNlVWck9uQUFBQUFBQUFBQUFBQUFBQSJdLCJfc2RfYWxnIjoic2hhLTI1NiJ9.
kLJkC5RhcvkKU-VU8-U5Ng7Iq4r8KxP9I_gKU8U8U8U8U

// Disclosures array (only age_over_18 disclosed, other attributes hidden)
~WyJhQUFBQUFBQSIsImFnZV9vdmVyXzE4Iix0cnVlXQ

// Key Binding JWT (proves holder controls the wallet)
eyJhbGciOiJFUzI1NiIsInR5cCI6ImtiK2p3dCJ9.
eyJub25jZSI6IjEyMzQ1Njc4OTAiLCJhdWQiOiJodHRwczovL3ZlcmlmaWVyLmNvbSIsImlhdCI6MTY0MzI4NDgwMCwic2RfaGFzaCI6ImtoMlA1LVl0QmQzSnVIbVFQQUFBQUFBIn0.
signature_proving_holder_possession

Note sur la divulgation sélective : l'exemple ci-dessus utilise SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credential), qui est le standard actuel imposé par les actes d'exécution eIDAS 2.0. Même si les preuves à divulgation nulle de connaissance (ZKP) sont étudiées pour de futures améliorations de confidentialité, l'implémentation actuelle du portefeuille EUDI utilise la divulgation sélective via les formats SD-JWT VC et mdoc. La vérification d'âge fonctionne en divulguant uniquement l'attribut age_over_18: true, et non via un ZKP cryptographique.

Composants clés de SD-JWT VC :

  • Header + payload : contient l'émetteur, la date d'émission et des claims divulguables de manière sélective (hachés)
  • Disclosures : uniquement les attributs que l'utilisateur choisit de révéler (dans ce cas, age_over_18: true)
  • Key binding : preuve cryptographique que la personne qui présente le justificatif contrôle bien le portefeuille

Bénéfice de confidentialité : le vérificateur apprend UNIQUEMENT que age_over_18 est vrai. Les autres attributs comme le nom, la date de naissance et l'adresse restent cryptographiquement masqués.

Validation cryptographique

Votre fournisseur de services valide :

  1. Vérification de signature : confirme que la réponse est signée par le fournisseur d'identité national légitime
  2. Chaîne de certificats : valide toute la chaîne de confiance jusqu'à l'autorité de certification racine nationale
  3. Statut de révocation : vérifie que le certificat de signature n'a pas été révoqué
  4. Validation temporelle : garantit que la réponse est récente et n'a pas été rejouée

Cette validation se fait en quelques millisecondes grâce à des clés publiques pré-cachées et à des listes de révocation de certificats.

Extraction des attributs

Une fois validés, les attributs spécifiques sont extraits et renvoyés à votre application :

{
  "status": "success",
  "sessionId": "vs_a8f2b3c1...",
  "attributes": {
    "age_over_18": true
  },
  "verifiedAt": "2026-01-22T12:00:05Z",
  "providerId": "AT",  // Austria
  "assuranceLevel": "high"  // eIDAS assurance level
}

Étape 5 : mises à jour de statut en temps réel

Pendant que l'utilisateur s'authentifie sur son appareil mobile, votre application web doit savoir quand le processus est terminé.

Server-Sent Events (SSE)

La solution la plus élégante consiste à utiliser les Server-Sent Events pour des mises à jour en temps réel :

const eventSource = new EventSource(
  `https://api.provider.com/verification/${sessionId}/stream`
);

eventSource.addEventListener('status', (event) => {
  const data = JSON.parse(event.data);

  if (data.status === 'scanned') {
    // L'utilisateur a scanné le QR code
    showMessage('En attente d\'authentification...');
  } else if (data.status === 'completed') {
    // Vérification réussie
    redirectToSuccessPage();
  } else if (data.status === 'failed') {
    // Échec de la vérification
    showError(data.reason);
  }
});

Alternative par polling

Pour les environnements qui ne prennent pas en charge SSE, implémentez un polling avec backoff exponentiel :

async function pollStatus(sessionId) {
  const maxAttempts = 60;  // 5 minutes
  let attempts = 0;

  while (attempts < maxAttempts) {
    const response = await fetch(
      `https://api.provider.com/verification/${sessionId}/status`
    );
    const data = await response.json();

    if (data.status !== 'pending') {
      return data;
    }

    // Backoff exponentiel : 1s, 2s, 4s, 8s, puis 10s
    const delay = Math.min(1000 * Math.pow(2, attempts), 10000);
    await sleep(delay);
    attempts++;
  }

  throw new Error('Délai de vérification dépassé');
}

Protocoles de sécurité et chiffrement

eIDAS utilise plusieurs couches de sécurité pour se protéger contre différents vecteurs d'attaque.

Sécurité de la couche transport

Toutes les communications utilisent TLS 1.3 avec des suites cryptographiques robustes. Le certificate pinning est recommandé pour les applications mobiles afin d'éviter les attaques de type homme du milieu.

Signature des requêtes

Les requêtes de vérification sont signées avec JSON Web Signatures (JWS), avec :

  • Algorithme : ES256 (ECDSA avec P-256 et SHA-256)
  • Stockage des clés : Hardware Security Modules (HSM) pour les clés du fournisseur de services
  • Rotation : rotation régulière des clés avec des périodes de validité qui se chevauchent

Validation des réponses

Les réponses sont validées via :

  1. Signatures numériques : chaque réponse est signée numériquement par le fournisseur d'identité national
  2. Contrôles temporels : les réponses doivent être utilisées dans une fenêtre courte (en général 60 secondes)
  3. Vérification du nonce : chaque requête inclut un nonce cryptographique qui doit être renvoyé dans la réponse
  4. Liaison de session : les réponses sont liées à des sessions spécifiques et ne peuvent pas être réutilisées

Techniques de préservation de la confidentialité

Divulgation sélective : les utilisateurs peuvent choisir quels attributs partager, même si d'autres ont été demandés.

Preuves à divulgation nulle de connaissance (Zero-Knowledge Proofs) (à terme dans eIDAS 2.0) : permettent de prouver des propriétés sur des données sans révéler les données elles-mêmes. Par exemple, prouver que vous avez plus de 18 ans sans révéler votre date de naissance.

Chiffrement des attributs : en transit, les attributs sont chiffrés avec des clés spécifiques à la session, ce qui garantit que même l'infrastructure du fournisseur de services ne peut pas y accéder avant leur remise à votre application.

Modèles d'intégration

Des architectures applicatives différentes exigent des approches d'intégration différentes.

Modèle 1 : backend vers backend (server-side)

Idéal pour les applications rendues côté serveur ou les applications mobiles natives :

// 1. Créer la session sur votre backend
POST /api/verification/create
→ { sessionId, qrCodeData }

// 2. Afficher le QR code à l'utilisateur
// 3. Polling ou stream du statut sur le backend
GET /api/verification/:sessionId/status

// 4. Une fois terminé, récupérer les attributs
GET /api/verification/:sessionId/result
→ { attributes: { age_over_18: true } }

Avantages : contrôle total, meilleure sécurité, les attributs ne passent jamais par le frontend.

Modèle 2 : widget JavaScript (client-side)

Idéal pour les SPA et les intégrations rapides :

import { EidasWidget } from '@eidaspro/widget';

const widget = new EidasWidget({
  apiKey: 'your_api_key',
  onSuccess: (attributes) => {
    console.log('Vérifié :', attributes);
  },
  onError: (error) => {
    console.error('Échec de vérification :', error);
  }
});

widget.verify({ requestedAttributes: ['age_over_18'] });

Avantages : intégration rapide, gestion automatique de l'UI, design adaptatif.

Modèle 3 : plugin e-commerce

Des plugins préconstruits pour des plateformes comme WooCommerce et Shopify gèrent l'ensemble du flux :

  • Ajoute un point de vérification à l'étape de paiement
  • Stocke le statut de vérification avec la commande
  • Fournit un tableau de bord admin pour les rapports de conformité
  • Gère automatiquement les cas limites et les erreurs

Gestion des erreurs et cas limites

Les implémentations robustes doivent gérer différents scénarios d'échec.

Scénarios d'erreur fréquents

Dépassement de délai : l'utilisateur ne scanne pas le QR code avant la fin de validité

  • Solution : afficher un nouveau QR code, prolonger la session si l'utilisateur est toujours présent

Annulation utilisateur : l'utilisateur refuse de partager les attributs

  • Solution : proposer des méthodes de vérification alternatives ou expliquer pourquoi la vérification est nécessaire

Pannes réseau : problèmes de connexion pendant la vérification

  • Solution : implémenter des tentatives de reprise avec backoff exponentiel, conserver l'état de la session

Attributs non pris en charge : l'attribut demandé n'est pas disponible pour le schéma eID de l'utilisateur

  • Solution : dégradation élégante ou demande d'attributs alternatifs

Niveau de garantie incompatible : l'eID de l'utilisateur n'atteint pas le niveau de garantie requis

  • Solution : demander un facteur d'authentification supplémentaire ou rejeter la vérification avec une explication claire

Journalisation et supervision

Mettez en place une journalisation complète pour :

  • Détails des requêtes de vérification (sans données personnelles)
  • Taux de succès/échec par pays
  • Durée moyenne de vérification
  • Types et fréquences d'erreurs

Ces données sont essentielles pour optimiser les taux de conversion et identifier les problèmes techniques.

Optimisation des performances

Stratégies de cache

Cache des clés publiques : mettez en cache les clés publiques des fournisseurs d'identité nationaux avec un TTL adapté (en général 24 heures) pour éviter des récupérations répétitives.

Validation de la chaîne de certificats : préchargez et validez les chaînes de certificats pendant les périodes de faible trafic.

Distribution géographique : utilisez des points de présence CDN en périphérie proches des points de terminaison des fournisseurs d'identité nationaux afin de minimiser la latence.

Objectifs de temps de réponse

  • Création de session : < 200 ms
  • Génération du QR code : < 50 ms
  • Validation des attributs : < 500 ms
  • Flux utilisateur de bout en bout : 5 à 10 secondes (principalement le temps d'authentification utilisateur)

Conclusion

La vérification eIDAS repose sur des fondations cryptographiques robustes, des protocoles standardisés et des architectures respectueuses de la confidentialité. En comprenant le flux technique, de l'initialisation de session à la validation des attributs, les développeurs peuvent construire des intégrations à la fois sûres et simples à utiliser.

La combinaison d'OpenID4VP, des justificatifs vérifiables et de l'identité décentralisée crée un système qui passe à l'échelle dans toute l'Europe tout en protégeant la vie privée des utilisateurs et en conservant une validité juridique.

Lors de l'implémentation de la vérification eIDAS, concentrez-vous sur la gestion des erreurs, l'optimisation des performances et une communication utilisateur claire. La complexité technique est prise en charge par les protocoles sous-jacents ; votre rôle est de créer une expérience fluide et fiable.


Besoin d'un support technique pour votre intégration ? Notre équipe d'ingénierie peut vous aider pour les revues d'architecture, les questions d'implémentation et l'optimisation des performances. Contactez-nous →

Articles similaires

Partager cet article

Aidez les autres à en savoir plus sur la vérification eIDAS