API-basierte Zwei-Faktor- und Biometrische Authentifizierung: Sicherheit für moderne Unternehmensanwendungen

Kurz erklärt

Digitale Identitätssicherheit ist zu einem Kernanliegen für Unternehmen geworden, die ihre Anwendungen offen für Mitarbeiter, Partner und Kunden halten wollen. Zwei-Faktor-Authentifizierung (2FA) und biometrische Authentifizierung ergänzen klassische…

Fiktiver leerer Identitätsprüfraum mit zwei Sicherheitsschlüsseln, leerer Karte und bordeauxroter Mappe Illustration · fiktive Szene
In diesem Artikel

Digitale Identitätssicherheit ist zu einem Kernanliegen für Unternehmen geworden, die ihre Anwendungen offen für Mitarbeiter, Partner und Kunden halten wollen. Zwei-Faktor-Authentifizierung (2FA) und biometrische Authentifizierung ergänzen klassische Passwörter und steigern die Sicherheit - insbesondere bei Zugriffen über APIs. In diesem Artikel erfahren Sie, wie solche Authentifizierungsmethoden funktionieren, warum sie unverzichtbar sind und wie Sie diese sicher in Ihre Geschäftsprozesse integrieren können.

Was bedeutet Zwei-Faktor- und Biometrische Authentifizierung über APIs?

APIs (Application Programming Interfaces) sind Programmierschnittstellen, über die verschiedene Software-Komponenten miteinander kommunizieren. Über APIs laufen heutzutage Authentifizierungen häufiger als je zuvor: Drittanbieter-Apps, mobile Anwendungen und interne Systeme benötigen geschützten Zugriff auf Unternehmensressourcen.

Die Zwei-Faktor-Authentifizierung (2FA) verlangt neben dem üblichen Passwort (Wissen) noch einen zweiten Faktor - etwa ein zeitlich limitiertes Einmalpasswort, einen Authenticator-Code oder einen Code per SMS (Besitz). Biometrische Verfahren (z. B. Fingerabdruck oder Gesichtserkennung) nutzen biologisch eindeutige Merkmale als Faktor.

Unterschied zwischen klassischer 2FA und Biometrie

  • Klassische 2FA: Kombination aus Passwort (Wissen) und Besitz (z. B. OTP-App, SMS, Token).
  • Biometrische Authentifizierung: Nutzung von einzigartigen Körpermerkmalen (etwa Fingerabdruck, Iris, Stimme) als zusätzlicher oder alternativer Faktor.

Warum benötigen Unternehmen 2FA- und biometrische Authentifizierung für APIs?

APIs sind attraktive Ziele für Angreifer, da sie oft sensible Daten und Steuerungsfunktionen bereitstellen. Passwörter allein bieten keinen zuverlässigen Schutz mehr gegen Phishing, Credential Stuffing und Social-Engineering-Angriffe. Die Kombination mehrerer Faktoren erschwert unautorisierte Zugriffe erheblich und hilft Unternehmen, regulatorische Anforderungen (z. B. DSGVO, PSD2) zu erfüllen.

  • Schutz vor Datendiebstahl: Selbst bei kompromittierten Passwörtern bleibt der API-Zugriff für Angreifer gesperrt, solange sie nicht beide Faktoren kontrollieren.
  • Erfüllung gesetzlicher Vorgaben: In vielen Branchen ist starke Authentifizierung mittlerweile obligatorisch.
  • Reputationssicherung: Moderne Kunden und Partner erwarten, dass Unternehmen Sorgfalt beim Identitätsschutz walten lassen.

Wie funktioniert die Authentifizierung über eine API?

Bei der Authentifizierung über eine API erfolgt die Kommunikation direkt zwischen Clients (z. B. Apps oder Systeme) und Servern über genormte Protokolle, meist REST oder OAuth. Damit wird sichergestellt, dass Benutzer beziehungsweise ihre Geräte eindeutig identifiziert und berechtigt werden, bevor sensible Daten zugänglich sind.

Typischer Ablauf einer 2FA-Authentifizierung über API

  • Der Benutzer sendet eine erste Anfrage an die API mit seinem Benutzernamen und Passwort.
  • Die API prüft die Zugangsdaten. Bei korrekten Angaben fordert sie den zweiten Faktor an.
  • Der Benutzer erhält z. B. einen Code per Authenticator-App, SMS oder E-Mail und gibt diesen im Client ein.
  • Die API validiert den Code und stellt, bei Erfolg, ein Access-Token oder Session aus.

Biometrische Authentifizierung via API

  • Das biometrische Merkmal (etwa Fingerabdruck) wird am Gerät des Benutzers aufgenommen.
  • Lokale Sicherheitsmodule (z. B. Secure Enclave auf iOS oder Android Keystore) prüfen die Echtheit und händigen einen verschlüsselten Nachweis an die API aus.
  • Die API akzeptiert diesen Nachweis als zweiten Faktor oder Ersatz für andere Faktoren.

Entscheidend: Biometrische Rohdaten verlassen in der Regel niemals das Endgerät, sondern werden als anonymer Nachweis übermittelt.

Implementierung: So richten Sie 2FA und Biometrie für Ihre API ein

1. Planung und Auswahl der Methoden

  • Analysieren Sie Ihr Bedrohungsmodell: Welche Risiken und Compliance-Anforderungen betreffen Ihre APIs?
  • Wählen Sie geeignete 2FA-Methoden (TOTP, Push-TAN, Hardware-Token, SMS, E-Mail) oder moderne biometrische Verfahren (z. B. FIDO2, FaceID, Fingerprint APIs).
  • Berücksichtigen Sie Ihre Benutzergruppen: Technischer Hintergrund, eingesetzte Plattformen und Nutzerfreundlichkeit.

2. Integration der Authentifizierungsanbieter

  • Setzen Sie auf etablierte Identity-Provider (IdP) wie Okta, Azure AD, Auth0 oder spezialisierte FIDO2-Server.
  • Nutzen Sie möglichst API-zentrierte Authentifizierungs-Flows: OAuth 2. 0, OpenID Connect, SAML oder FIDO2/WebAuthn.
  • Stellen Sie sicher, dass Ihr Backend die Validierung sämtlicher Faktoren zuverlässig prüfen kann.

3. Entwicklung und Sicherheitsaspekte

  • Implementieren Sie sichere Token-Übertragung, z. B. via TLS-verschlüsselter Kommunikation.
  • Vermeiden Sie die Übertragung von Passwörtern oder biometrischen Rohdaten - setzen Sie auf signierte Nachweise (Proofs).
  • Registrieren und sperren Sie Geräte oder Faktoren zentral, um Missbrauch zu vermeiden.
  • Implementieren Sie Rate Limiting, Logging und Alerts bei ungewöhnlichen Zugriffsmustern.

4. Benutzererfahrung und Support

  • Gestalten Sie den 2FA- beziehungsweise biometrischen Prozess so einfach und verständlich wie möglich.
  • Stellen Sie Self-Service-Funktionen für die Wiederherstellung verlorener Faktoren bereit (Recovery Codes, Backup-Methoden).
  • Bieten Sie Schulungen und Hilfestellungen für Nutzer und Entwickler an.

Best Practices für den Einsatz in Unternehmen

  • Setzen Sie auf Multi-Faktor-Authentifizierung als Standard für alle externen und internen APIs.
  • Regelmäßige Überprüfung und Erneuerung von Faktoren: Nutzer und Geräte sollten ihre Authentifizierungen periodisch erneuern oder bestätigen.
  • Überwachen Sie die Authentifizierungsflüsse mit Analyse- und SIEM-Tools auf Anomalien.
  • Nutzen Sie Open-Source- und kommerzielle Lösungen, die regelmäßig auf Schwachstellen geprüft werden.
  • Berücksichtigen Sie Datenschutz-Aspekte (Data Minimization, Privacy by Design), insbesondere bei biometrischen Verfahren.

Fazit: Moderne Authentifizierung als Wettbewerbsvorteil

Die Einführung von Zwei-Faktor- und biometrischer Authentifizierung über Ihre APIs ist kein reines IT-Thema - sie bildet einen Grundpfeiler Ihrer digitalen Vertrauensstrategie gegenüber Kunden, Partnern und Behörden. Unternehmen, die auf moderne Authentifizierungsverfahren setzen, schützen nicht nur kritische Infrastrukturen, sondern zeigen Verantwortungsbewusstsein und Innovationskraft.

Die Cyber Intelligence Embassy unterstützt Unternehmen dabei, maßgeschneiderte Authentifizierungskonzepte zu entwickeln und effizient umzusetzen - mit neuesten Technologien, fundiertem Fachwissen und Blick für Regulatorik und Nutzererlebnis.

Trennen Sie einen zweiten Faktor von der Phishing-Resistenz.

Das NIST weist darauf hin, dass ein manuell eingegebener Einmalcode von einer gefälschten Webseite weitergeleitet werden kann. Daher macht allein sein Vorhandensein eine Anmeldung nicht phishing-resistent. Eine korrekt integrierte WebAuthn-Lösung bindet die Antwort an den authentischen Dienst. Die Kontowiederherstellung muss weiterhin sicher erfolgen.

  • Listen Sie Anwendungen auf, die noch SMS, Codes oder umgehbare Genehmigungen akzeptieren, und priorisieren Sie privilegierte Konten.
  • Testen Sie Registrierung, Geräteverlust und Kontosperrung anhand eines realen Benutzerprozesses.
  • Widerstandsfaktorabdeckung messen und datierte Ausnahmen mit den Eigentümern verwalten.

Primärquelle: NIST SP 800-63B-4. Verwandte Methode: den praktischen Leitfaden lesen.

Passkeys: Domain- und RP-ID-Wechsel vorbereiten

Konto, Web-Origin und RP ID unterscheiden, damit Zugangsdaten nicht stillschweigend neu zugeordnet werden.

  • Notiere alte und neue Origins, RP IDs und zugehörige Konten. Ein gleicher Kontoname macht einen Passkey nicht für eine andere RP ID gültig. Prüfe erlaubte WebAuthn-Kombinationen und verfügbare Zugangswege während des Wechsels.
  • Prüfe in einer autorisierten Testumgebung Challenge, Origin, RP ID und Kontobindung mit einer geeigneten Bibliothek. Teste unerwartete Origins und wiederholte Challenges. Bei neuer RP ID ist eine authentifizierte Neuregistrierung nötig; eine kopierte Datenbankzeile migriert keinen Schlüssel.
  • Teste Nutzer mit nur altem Credential, Wiederherstellung und offene Sitzungen. Lege Öffnung und Stilllegung der Wege mit geprüftem Rückweg fest. Eine erfolgreiche Registrierung auf der neuen Domain beweist nicht den Widerruf aller alten Sitzungen.

Nachvollziehbarer Abnahmefall

Fiktives Beispiel: Diese Daten beschreiben keine Kunden oder beobachteten Ergebnisse.

Falldaten anzeigen
{
    "old_origin": "https://login.old.example",
    "old_rp_id": "old.example",
    "new_origin": "https://login.new.example",
    "new_rp_id": "new.example",
    "same_service_account": true,
    "expected": "authenticated_new_registration"
}

Erwartete Entscheidung

Fiktives Beispiel: Das Konto bleibt gleich, aber old.example wird new.example mit anderer RP ID. Das alte Credential darf nicht still neu zugeordnet werden; die neue Registrierung folgt dem vorgesehenen authentifizierten Ablauf.

W3C — Web Authentication Level 2

Kann eine Datenbankänderung die RP ID eines Passkeys ändern?

Nein. Die RP ID gehört zum geprüften Geltungsbereich des Credentials. Bereite eine gültige Registrierung für den neuen Bereich und eine authentifizierte Kontozuordnung vor.

Primärquelle: W3C — Web Authentication Level 2. Verwandte Methode: den praktischen Leitfaden lesen.

postMessage: Ursprung, Fenster und Befehl prüfen

Einen Nachrichtenvertrag für iframe oder Popup festlegen, der unerwartete Absender und Daten abweist.

  • Erfasse exakte Ursprünge, erwartete Fensterreferenz und Nachrichtentypen. Nutze ein genaues targetOrigin für sensible Daten. Ein Ursprung umfasst Schema, Host und Port; eine Teilzeichenfolgensuche im Domainnamen validiert keinen Teilnehmer.
  • Vergleiche event.origin und für diese Fensterintegration event.source mit der erwarteten Referenz. Prüfe Schema, zulässige Werte und Vorgangszustand. Behandle Inhalt als Daten, ohne eval oder HTML-Einfügung. Ein erlaubter Ursprung ersetzt keine serverseitige Berechtigungsprüfung.
  • Teste ähnliche Domains, andere Ports, ein anderes Fenster desselben Ursprungs, ungültige Felder und Nachrichten nach Abschluss. Entferne unbenötigte Listener und entwerte abgeschlossene Austausche. Antworten verwenden einen zuvor erlaubten Ursprung, auch nach Fensternavigation.

Nachvollziehbarer Abnahmefall

Fiktives Beispiel: Diese Daten beschreiben keine Kunden oder beobachteten Ergebnisse.

Falldaten anzeigen
{
    "allowed_origin": "https://widget.example",
    "observed_origin": "https://widget.example",
    "expected_window": "active_iframe",
    "observed_window": "another_window",
    "payload_schema_valid": true,
    "expected": "reject_without_effect"
}

Erwartete Entscheidung

Fiktives Beispiel: https://widget.example ist erlaubt, aber event.source verweist auf ein anderes Fenster. Der Vertrag verlangt das aktive iframe-Fenster: Nachricht ohne Befehl ablehnen.

MDN — Window.postMessage

Primärquelle: MDN — Window.postMessage. Verwandte Methode: den praktischen Leitfaden lesen.

Identität: Faktoren, Sitzungen und Wiederherstellung

Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.

Two factors: check the protocol beyond the interface

Entered codes, push approvals and WebAuthn responses provide different service binding. Biometrics can activate an authenticator; they do not replace cryptographic response checks by the application.

  • Observe UP and UV separately in the intended journey.
  • Check the sync and non-exportability conditions actually needed.
  • Rehearse loss and binding a new method from an existing session.

Open the authenticator and recovery comparison →

Sources consulted on · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3

Erweiterungen: Berechtigungen und Zugriff

Ausführliche Hinweise stehen in dieser Ausgabe auf Englisch zur Verfügung.

Robust authentication does not describe extension access

Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.

  • Test approved extensions in a profile dedicated to sensitive operations.
  • For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
  • Distinguish session revocation, token revocation, extension disablement and native-component removal.

Read the permission directory and manifest examples →

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent