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 :
- Relying Party (votre application) : le service qui demande la vérification d'identité
- Fournisseur de services eIDAS : le middleware qui relie votre application au réseau eIDAS
- Portefeuille eID national : l'application mobile de l'utilisateur (par ex. ID Austria, Smart-ID, BankID)
- 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 :
- Gestionnaire de protocole :
eidas://ou des schémas spécifiques à un pays commeat.gv.eid:// - Identifiant de session : relie cette vérification à votre session backend
- Point de terminaison du fournisseur de services : l'adresse à laquelle le portefeuille doit envoyer la requête de vérification
- 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 :
- Récupère la requête complète : télécharge la requête signée depuis le
request_uri - Valide les signatures : s'assure que la requête provient d'un fournisseur légitime
- Vérifie la portée : confirme que les attributs demandés sont appropriés et légaux
- 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
- L'utilisateur lance l'application ID Austria en scannant le QR code
- L'application affiche : "eidas-pro.com demande : vérification d'âge (plus de 18 ans)"
- L'utilisateur vérifie puis appuie sur "Approuver"
- Invite biométrique : "Utilisez votre empreinte pour confirmer"
- L'utilisateur s'authentifie avec son empreinte
- 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 :
- Vérification de signature : confirme que la réponse est signée par le fournisseur d'identité national légitime
- Chaîne de certificats : valide toute la chaîne de confiance jusqu'à l'autorité de certification racine nationale
- Statut de révocation : vérifie que le certificat de signature n'a pas été révoqué
- 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 :
- Signatures numériques : chaque réponse est signée numériquement par le fournisseur d'identité national
- Contrôles temporels : les réponses doivent être utilisées dans une fenêtre courte (en général 60 secondes)
- Vérification du nonce : chaque requête inclut un nonce cryptographique qui doit être renvoyé dans la réponse
- 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
Conformité RGPD simplifiée : comment eIDAS minimise la collecte de données
Découvrez comment la vérification d'identité fondée sur eIDAS permet une conformité RGPD optimale grâce à la minimisation des données, une architecture de protection des données dès la conception et un contrôle utilisateur renforcé. Réduisez votre responsabilité en matière de données tout en améliorant la sécurité.
11 min de lecture
Mettre en place la vérification d'âge dans WooCommerce avec eIDAS
Guide complet pour intégrer une vérification d'âge basée sur eIDAS à votre boutique WooCommerce. Découvrez comment déployer un contrôle conforme et fluide pour l'alcool, le tabac et les autres produits soumis à restriction d'âge.
11 min de lecture
Partager cet article
Aidez les autres à en savoir plus sur la vérification eIDAS