Wie die eIDAS-Verifizierung funktioniert: eine technische Tiefenanalyse

Überblick über den Verifizierungsablauf

eIDAS-basierte Identitätsverifizierung folgt einer präzise orchestrierten Abfolge, die Sicherheit, Datenschutz und Nutzererlebnis in Balance bringt. Dieses Ablaufverständnis ist entscheidend für Entwickler, die Identitätsverifizierung in ihre Anwendungen integrieren.

Der vollständige Verifizierungsprozess umfasst vier Hauptakteure:

Relying Party (Ihre Anwendung): Der Dienst, der die Identitätsverifizierung anfordert
eIDAS-Dienstanbieter: Vermittlungsschicht, die Ihre Anwendung mit dem eIDAS-Netzwerk verbindet
Nationale eID-Wallet: Die mobile App des Nutzers (z. B. ID Austria, Smart-ID, BankID)
Nationaler Identitätsanbieter: Das staatliche System, das digitale Identitäten ausstellt und validiert

Gehen wir jeden Schritt dieses Prozesses im Detail durch.

Schritt 1: Initialisierung der Verifizierungssitzung

Wenn Ihre Anwendung die Identität eines Nutzers verifizieren muss, beginnt der Prozess mit der Erstellung einer Verifizierungssitzung.

Anfrage zur Sitzungserstellung

Ihre Anwendung sendet einen API-Aufruf an Ihren eIDAS-Dienstanbieter:

POST /api/verification/create
{
  "requestedAttributes": ["age_over_18"],
  "purpose": "Altersverifizierung für einen Kauf",
  "returnUrl": "https://yourapp.com/verification/callback"
}

Das Feld requestedAttributes definiert exakt, welche Informationen Sie benötigen. eIDAS Pro fokussiert sich auf die Verifizierung boolescher Attribute – Sie erhalten true/false-Antworten statt personenbezogener Daten:

Altersverifizierung:

age_over_18: Ist der Nutzer 18 Jahre oder älter?
age_over_21: Ist der Nutzer 21 Jahre oder älter?
age_over_25: Ist der Nutzer 25 Jahre oder älter?

Standort-/Wohnsitzverifizierung:

is_eu_resident: Ist der Nutzer in der EU ansässig?
is_eu_citizen: Ist der Nutzer EU-Bürger?

Warum boolesche Attribute?

Dieser Ansatz bietet maximalen Datenschutz bei minimalem DSGVO-Haftungsrisiko:

Sie erfahren nur, was Sie wissen müssen (Ja/Nein)
Keine Namen, Geburtsdaten oder Adressen, die gespeichert oder abgesichert werden müssen
Keine Verarbeitung besonderer Kategorien personenbezogener Daten
Deutlich reduziertes Risiko im Fall eines Datenvorfalls

Datenschutzhinweis: eIDAS Pro beschränkt verfügbare Attribute bewusst auf boolesche Antworten. Wenn Sie vollständige Identitätsdaten (Namen, Adressen) benötigen, sind dokumentbasierte Verifizierungsansätze erforderlich – mit den entsprechenden DSGVO-Pflichten und Kosten. Viele Organisationen nutzen eIDAS für EU-spezifische Minimaldaten-Anwendungsfälle und dokumentbasierte Verifizierung für Szenarien, die vollständige Identitätsdaten erfordern.

Hinweis für Verantwortliche: Auch wenn eIDAS die Datenerhebung minimiert, bleibt Ihre Organisation Verantwortlicher für alle gespeicherten Verifizierungsergebnisse. Details zu den verbleibenden Pflichten finden Sie in unserem Leitfaden zur DSGVO-Compliance.

Sitzungsantwort

Der Dienstanbieter erzeugt eine eindeutige Verifizierungssitzung und gibt Folgendes zurück:

{
  "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"
}

Die Sitzung läuft typischerweise nach 5-10 Minuten ab, um veraltete Verifizierungsanfragen zu verhindern.

Schritt 2: Erzeugung und Anzeige des QR-Codes

Der QR-Code bildet die Brücke zwischen Ihrer Webanwendung und dem mobilen Gerät des Nutzers.

Inhalte des QR-Codes

Der QR-Code kodiert mehrere kritische Informationen:

Protokoll-Handler: eidas:// oder länderspezifische Schemes wie at.gv.eid://
Sitzungskennung: Verknüpft diese Verifizierung mit Ihrer Backend-Sitzung
Endpunkt des Dienstanbieters: Wohin die Wallet die Verifizierungsanfrage senden soll
Angeforderte Attribute: Welche Informationen verifiziert werden müssen

Moderne Standards: OpenID4VP

Moderne eIDAS-Implementierungen verwenden OpenID for Verifiable Presentations (OpenID4VP). Dieser Standard definiert, wie verifizierbare Nachweise angefordert und präsentiert werden. Der QR-Code enthält:

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

Die request_uri verweist auf ein signiertes JWT mit der vollständigen Verifizierungsanfrage. Das stellt Integrität sicher und verhindert Manipulation.

Empfehlungen für die Anzeige

Responsives Design: Auf Mobilgeräten statt QR-Code einen „Tippen zum Öffnen“-Button anzeigen und Direktlinks (Deep Links) nutzen, um die passende Wallet-App direkt zu starten.

Ladezustände: Eine Scan-Animation und klare Hinweise anzeigen („Mit Ihrer nationalen eID-App scannen“).

Alternativoptionen: Alternative Verifizierungsmethoden für Nutzer ohne eID-Wallet anbieten.

Schritt 3: Authentifizierung in der Wallet-App

Sobald der Nutzer den QR-Code scannt, übernimmt die nationale eID-Wallet-App.

Validierung der Anfrage

Die Wallet-App:

Lädt die vollständige Anfrage: Ruft die signierte Anfrage über die request_uri ab
Prüft Signaturen: Stellt sicher, dass die Anfrage von einem legitimen Dienstanbieter stammt
Prüft den Umfang: Verifiziert, dass die angeforderten Attribute angemessen und rechtlich zulässig sind
Zeigt den Einwilligungsbildschirm: Zeigt dem Nutzer exakt, welche Informationen geteilt werden

Nutzerauthentifizierung

Bevor Informationen freigegeben werden, verlangt die Wallet eine starke Authentifizierung. Die Methoden variieren je nach Land, umfassen typischerweise jedoch:

Biometrische Authentifizierung (am häufigsten):

Fingerabdruckscan
Gesichtserkennung
Iris-Scan

PIN/Passwort: Eine numerische PIN oder ein alphanumerisches Passwort

Hardware-Sicherheit: Viele nationale eID-Wallets nutzen Secure Elements (SE) oder Trusted Execution Environments (TEE) auf dem Gerät. Dadurch verlassen kryptografische Schlüssel niemals die sichere Ausführungsumgebung.

Beispiel: ID-Austria-Ablauf

Nutzer startet die ID-Austria-App durch Scannen des QR-Codes
Die App zeigt an: „eidas-pro.com fordert an: Altersverifizierung (über 18)“
Nutzer prüft die Anfrage und tippt auf „Zustimmen“
Biometrie-Prompt: „Fingerabdruck zur Bestätigung verwenden“
Nutzer authentifiziert sich per Fingerabdruck
Die App erzeugt und signiert die Verifizierungsantwort

Der gesamte In-App-Ablauf dauert für wiederkehrende Nutzer 3-5 Sekunden.

Schritt 4: Attributaustausch und Validierung

Nach der Nutzerauthentifizierung erstellt die Wallet eine kryptografisch signierte Antwort mit den angeforderten Attributen.

Antwortstruktur

Die Wallet erzeugt eine verifizierbare Präsentation mit SD-JWT VC (Selective Disclosure JWT Verifiable Credentials), dem tatsächlich in der EU Digital Identity Wallet verwendeten Format:

// SD-JWT VC mit selektiver Offenlegung - es wird nur age_over_18 offengelegt
eyJhbGciOiJFUzI1NiIsInR5cCI6InZjK3NkLWp3dCJ9.
eyJpc3MiOiJodHRwczovL2lzc3Vlci5laWRhcy5ldSIsImlhdCI6MTY0MzI4NDgwMCwiZXhwIjoxNjQzMjg4NDAwLCJ2Y3QiOiJodHRwczovL2V4YW1wbGUuZXUvcGlkIiwic3ViIjoiZGlkOmp3azpleUp1SWpvaVJGTkJJaXdpZVNJNklqWTNOell4TWpFMk15SjkiLCJfc2QiOlsiRzVFbmhPQU9vVTlYXzhRQUFBQUFBQUFBQUEiLCJKNlVWck9uQUFBQUFBQUFBQUFBQUFBQSJdLCJfc2RfYWxnIjoic2hhLTI1NiJ9.
kLJkC5RhcvkKU-VU8-U5Ng7Iq4r8KxP9I_gKU8U8U8U8U

// Disclosures-Array (nur age_over_18 wird offengelegt, andere Attribute bleiben verborgen)
~WyJhQUFBQUFBQSIsImFnZV9vdmVyXzE4Iix0cnVlXQ

// Key-Binding-JWT (belegt, dass der Inhaber die Wallet kontrolliert)
eyJhbGciOiJFUzI1NiIsInR5cCI6ImtiK2p3dCJ9.
eyJub25jZSI6IjEyMzQ1Njc4OTAiLCJhdWQiOiJodHRwczovL3ZlcmlmaWVyLmNvbSIsImlhdCI6MTY0MzI4NDgwMCwic2RfaGFzaCI6ImtoMlA1LVl0QmQzSnVIbVFQQUFBQUFBIn0.
signature_proving_holder_possession

Hinweis zur selektiven Offenlegung: Das obige Beispiel nutzt SD-JWT VC (Selective Disclosure JSON Web Token Verifiable Credential), den aktuellen Standard aus den eIDAS-2.0-Durchführungsrechtsakten. Zero-Knowledge-Proofs (ZKP) werden für zukünftige Datenschutzverbesserungen erforscht; die aktuelle EUDI-Wallet-Implementierung verwendet jedoch selektive Offenlegung über SD-JWT VC- und mdoc-Formate. Altersverifizierung funktioniert hier durch Offenlegung ausschließlich des Attributs age_over_18: true, nicht über kryptografische ZKP.

Zentrale Komponenten von SD-JWT VC:

Header + Payload: Enthalten Aussteller, Ausstellungszeitpunkt und selektiv offenlegbare Aussagen (gehasht)
Disclosures: Nur die Attribute, die der Nutzer freigibt (in diesem Fall age_over_18: true)
Key Binding: Kryptografischer Nachweis, dass die präsentierende Person die Wallet kontrolliert

Datenschutzvorteil: Die prüfende Stelle erfährt NUR, dass age_over_18 wahr ist. Andere Attribute wie Name, Geburtsdatum und Adresse bleiben kryptografisch verborgen.

Kryptografische Validierung

Ihr Dienstanbieter validiert:

Signaturprüfung: Bestätigt, dass die Antwort vom legitimen nationalen Identitätsanbieter signiert wurde
Zertifikatskette: Validiert die vollständige Vertrauenskette bis zur nationalen Stammzertifizierungsstelle
Sperrstatus: Prüft, ob das Signaturzertifikat widerrufen wurde
Zeitstempelvalidierung: Stellt sicher, dass die Antwort aktuell ist und nicht durch einen Replay-Angriff wiederverwendet wurde

Diese Validierung erfolgt in Millisekunden mit vorgecachten öffentlichen Schlüsseln und Zertifikatswiderrufslisten.

Attributextraktion

Nach erfolgreicher Validierung werden die relevanten Attribute extrahiert und an Ihre Anwendung zurückgegeben:

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

Schritt 5: Echtzeit-Statusupdates

Während der Nutzer sich auf seinem Mobilgerät authentifiziert, muss Ihre Webanwendung wissen, wann der Prozess abgeschlossen ist.

Server-Sent Events (SSE)

Die eleganteste Lösung sind Server-Sent Events für Echtzeit-Updates:

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') {
    // Nutzer hat den QR-Code gescannt
    showMessage('Warten auf Authentifizierung...');
  } else if (data.status === 'completed') {
    // Verifizierung erfolgreich
    redirectToSuccessPage();
  } else if (data.status === 'failed') {
    // Verifizierung fehlgeschlagen
    showError(data.reason);
  }
});

Polling als Alternative

Für Umgebungen ohne SSE-Unterstützung sollte Polling mit exponentiellem Backoff implementiert werden:

async function pollStatus(sessionId) {
  const maxAttempts = 60;  // 5 Minuten
  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;
    }

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

  throw new Error('Zeitüberschreitung bei der Verifizierung');
}

Sicherheitsprotokolle und Verschlüsselung

eIDAS-Verifizierung nutzt mehrere Sicherheitsebenen, um unterschiedliche Angriffsvektoren abzuwehren.

Transport Layer Security

Alle Kommunikationskanäle verwenden TLS 1.3 mit starken Cipher Suites. Für mobile Anwendungen wird Certificate Pinning empfohlen, um Man-in-the-Middle-Angriffe zu verhindern.

Signierung von Anfragen

Verifizierungsanfragen werden mit JSON Web Signatures (JWS) signiert:

Algorithmus: ES256 (ECDSA mit P-256 und SHA-256)
Schlüsselspeicherung: Hardware Security Modules (HSMs) für Dienstanbieter-Schlüssel
Rotation: Regelmäßige Schlüsselrotation mit überlappenden Gültigkeitszeiträumen

Validierung von Antworten

Antworten werden über folgende Mechanismen geprüft:

Digitale Signaturen: Jede Antwort ist vom nationalen Identitätsanbieter digital signiert
Zeitstempelprüfung: Antworten dürfen nur innerhalb eines kurzen Zeitfensters genutzt werden (typischerweise 60 Sekunden)
Nonce-Verifizierung: Jede Anfrage enthält eine kryptografische Nonce, die in der Antwort enthalten sein muss
Session-Bindung: Antworten sind an spezifische Sitzungen gebunden und können nicht wiederverwendet werden

Datenschutzfreundliche Techniken

Selektive Offenlegung: Nutzer können wählen, welche Attribute sie teilen, selbst wenn mehr angefordert wurden.

Zero-Knowledge-Proofs (ZKP) (perspektivisch): Eigenschaften von Daten nachweisen, ohne die Daten selbst offenzulegen. Beispiel: nachweisen, dass man über 18 ist, ohne das Geburtsdatum preiszugeben.

Attributverschlüsselung: Während der Übertragung sind Attribute mit sitzungsspezifischen Schlüsseln verschlüsselt. Dadurch kann selbst die Infrastruktur des Dienstanbieters erst dann zugreifen, wenn die Daten an Ihre Anwendung ausgeliefert werden.

Integrationsmuster

Unterschiedliche Anwendungsarchitekturen erfordern unterschiedliche Integrationsansätze.

Muster 1: Backend-zu-Backend (serverseitig)

Optimal für serverseitig gerenderte Anwendungen oder native mobile Apps:

// 1. Sitzung im eigenen Backend erstellen
POST /api/verification/create
→ { sessionId, qrCodeData }

// 2. QR-Code für Nutzer anzeigen
// 3. Status im Backend pollen oder streamen
GET /api/verification/:sessionId/status

// 4. Nach Abschluss Attribute abrufen
GET /api/verification/:sessionId/result
→ { attributes: { age_over_18: true } }

Vorteile: Volle Kontrolle, höhere Sicherheit, Attribute berühren nie das Frontend.

Muster 2: JavaScript-Widget (clientseitig)

Optimal für SPAs und schnelle Integrationen:

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

const widget = new EidasWidget({
  apiKey: 'your_api_key',
  onSuccess: (attributes) => {
    console.log('Verifiziert:', attributes);
  },
  onError: (error) => {
    console.error('Verifizierung fehlgeschlagen:', error);
  }
});

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

Vorteile: Schnelle Integration, die Benutzeroberfläche wird automatisch gehandhabt, responsives Design.

Muster 3: E-Commerce-Plugin

Vorgefertigte Plugins für Plattformen wie WooCommerce und Shopify übernehmen den gesamten Ablauf:

Fügt im Bezahlvorgang einen Verifizierungsschritt hinzu
Speichert den Verifizierungsstatus zur Bestellung
Bietet ein Admin-Dashboard für Compliance-Berichte
Behandelt Sonderfälle und Fehler automatisch

Fehlerbehandlung und Sonderfälle

Robuste Implementierungen müssen unterschiedliche Fehlerszenarien beherrschen.

Häufige Fehlerszenarien

Timeout: Nutzer scannt den QR-Code nicht innerhalb des Ablaufzeitfensters

Lösung: Neuen QR-Code anzeigen, Sitzung verlängern, sofern der Nutzer noch aktiv ist

Abbruch durch den Nutzer: Nutzer lehnt die Freigabe von Attributen ab

Lösung: Alternative Verifizierungsmethoden anbieten oder erklären, warum die Verifizierung erforderlich ist

Netzwerkfehler: Verbindungsprobleme während der Verifizierung

Lösung: Wiederholungsversuche mit exponentiellem Backoff implementieren, Sitzungsstatus erhalten

Nicht unterstützte Attribute: Angefordertes Attribut ist im eID-Schema des Nutzers nicht verfügbar

Lösung: Kontrollierte Funktionseinschränkung umsetzen oder alternative Attribute anfordern

Abweichung beim Vertrauensniveau: Die eID des Nutzers erfüllt nicht das erforderliche Vertrauensniveau

Lösung: Zusätzlichen Authentifizierungsfaktor anfordern oder die Verifizierung mit klarer Begründung ablehnen

Protokollierung und Überwachung

Implementieren Sie umfassendes Logging für:

Details zu Verifizierungsanfragen (ohne personenbezogene Daten)
Erfolgs-/Fehlerraten nach Land
Durchschnittliche Verifizierungsdauer
Fehlertypen und deren Häufigkeit

Diese Daten sind entscheidend, um Konversionsraten zu optimieren und technische Probleme frühzeitig zu identifizieren.

Performance-Optimierung

Cache-Strategien

Caching öffentlicher Schlüssel: Öffentliche Schlüssel nationaler Identitätsanbieter mit passender TTL (typischerweise 24 Stunden) im Cache halten, um wiederholte Abrufe zu vermeiden.

Validierung der Zertifikatskette: Zertifikatsketten in Zeiten niedriger Last vorab abrufen und validieren.

Geografische Verteilung: CDN-Edge-Standorte nahe an Endpunkten nationaler Identitätsanbieter nutzen, um Latenz zu minimieren.

Zielwerte für Antwortzeiten

Sitzungserstellung: < 200 ms
QR-Code-Erzeugung: < 50 ms
Attributvalidierung: < 500 ms
End-to-End-Nutzerfluss: 5-10 Sekunden (hauptsächlich Zeit für Nutzerauthentifizierung)

Fazit

eIDAS-Verifizierung basiert auf robusten kryptografischen Grundlagen, standardisierten Protokollen und datenschutzfreundlichen Architekturen. Wer den technischen Ablauf versteht – von der Sitzungsinitialisierung bis zur Attributvalidierung –, kann Integrationen bauen, die sowohl sicher als auch benutzerfreundlich sind.

Die Kombination aus OpenID4VP, verifizierbaren Nachweisen und dezentraler Identität schafft ein System, das in ganz Europa skaliert, die Privatsphäre der Nutzer schützt und gleichzeitig rechtlich belastbar bleibt.

Wenn Sie eIDAS-Verifizierung implementieren, sollten Sie den Fokus auf Fehlerbehandlung, Performance-Optimierung und klare Nutzerkommunikation legen. Die technische Komplexität wird durch die zugrunde liegenden Protokolle getragen; Ihre Aufgabe ist es, ein Erlebnis zu schaffen, das sich nahtlos und vertrauenswürdig anfühlt.

Brauchen Sie technischen Support für Ihre Integration? Unser Technikteam unterstützt Sie bei Architektur-Reviews, Implementierungsfragen und Performance-Optimierung. Kontakt aufnehmen →