Skip to Content

Multi-Faktor-Authentifizierung (MFA)

Multi-Faktor-Authentifizierung erfordert, dass Benutzer eine zweite Form der Verifizierung zusätzlich zu ihren primären Anmeldedaten angeben. Auris unterstützt vier MFA-Mechanismen — TOTP-Authentifizierungs-Apps, SMS-Einmalpasswörter, WebAuthn-Hardware-Keys und Passkeys sowie adaptives risikobasiertes MFA, das zusätzliche Faktoren automatisch basierend auf erkanntem Risiko auslöst —, die gemäß deiner Sicherheitsrichtlinie kombiniert werden können.

TOTP (Authentifizierungs-App)

Time-Based One-Time Password (TOTP) ist der am häufigsten unterstützte MFA-Mechanismus. Benutzer scannen einen QR-Code mit einer Authentifizierungs-App — wie Google Authenticator, Authy, 1Password oder einer RFC 6238-kompatiblen Anwendung — und geben den sechsstelligen Code ein, den sie generiert.

Funktionsweise

TOTP-Codes werden aus einem gemeinsamen Geheimnis und der aktuellen Zeit abgeleitet. Server und Authentifizierungs-App berechnen unabhängig denselben Code für jedes 30-Sekunden-Fenster. Auf dem Gerät des Benutzers ist keine Netzwerkverbindung erforderlich.

Benutzer-Einrichtung

Der TOTP-Einschreibungsablauf:

  1. Der Benutzer navigiert zu Konto → Sicherheit → Zwei-Faktor-Authentifizierung.
  2. Ein QR-Code und ein manueller Eingabeschlüssel werden angezeigt.
  3. Der Benutzer scannt den QR-Code mit seiner Authentifizierungs-App.
  4. Der Benutzer gibt den anfänglichen sechsstelligen Code ein, um die Einrichtung zu bestätigen.
  5. Wiederherstellungscodes werden generiert und angezeigt. Der Benutzer muss diese speichern — sie können später nicht abgerufen werden.

Wiederherstellungscodes

Jede TOTP-Einrichtung generiert 10 Einmal-Wiederherstellungscodes. Wenn ein Benutzer den Zugriff auf sein Authentifizierungsgerät verliert, kann er einen Wiederherstellungscode eingeben, um MFA zu umgehen und sich anzumelden. Nach Verwendung wird ein Wiederherstellungscode ungültig. Benutzer können von ihrer Konto-Sicherheitsseite neue Wiederherstellungscodes generieren — dadurch werden alle vorherigen Codes ungültig.

Admin-Aktionen

Admins können die TOTP-Einschreibung eines Benutzers über die Console zurücksetzen (Benutzer-Detail → Sicherheit → TOTP zurücksetzen). Dadurch wird die vorhandene TOTP-Konfiguration entfernt und der Benutzer gezwungen, sich beim nächsten Login neu einzuschreiben. Verwende dies, wenn ein Benutzer meldet, dass er ein Gerät verloren oder ersetzt hat.

POST/api/user/2fa/totp/enable

Initiiert die TOTP-Einschreibung für den authentifizierten Benutzer. Gibt das TOTP-Secret und den QR-Code-Data-URI zurück.

POST/api/user/2fa/totp/verify

Bestätigt die Einschreibung durch Verifizierung des anfänglichen TOTP-Codes. Generiert und gibt Wiederherstellungscodes zurück.

DELETE/api/user/2fa/totp

Entfernt die TOTP-Einschreibung des Benutzers. Erfordert den aktuellen TOTP-Code oder einen Wiederherstellungscode zur Bestätigung.

SMS-OTP

SMS-Einmalpasswörter übermitteln einen Verifizierungscode an die registrierte Mobiltelefonnummer des Benutzers via SMS. Auris verwendet Twilio als SMS-Provider.

Voraussetzungen

SMS-OTP erfordert:

  • Ein Twilio-Konto mit einer Telefonnummer, die SMS senden kann.
  • TWILIO_ACCOUNT_SID, TWILIO_AUTH_TOKEN und TWILIO_FROM_NUMBER Umgebungsvariablen, die in der Auris-API konfiguriert sind.

Eine vollständige SMS-OTP-Einrichtungsanleitung einschließlich Twilio-Konfiguration findest du unter SMS-OTP-Authentifizierung.

Benutzer-Einrichtung

  1. Der Benutzer navigiert zu Konto → Sicherheit → Telefonnummer.
  2. Der Benutzer gibt seine Mobiltelefonnummer im E.164-Format ein (z.B. +49 89 12345678).
  3. Auris sendet einen Verifizierungscode per SMS.
  4. Der Benutzer gibt den Code ein, um den Telefonbesitz zu bestätigen.
  5. Die Telefonnummer ist verifiziert und kann für SMS-OTP-MFA verwendet werden.

Rate Limits

Um Missbrauch zu verhindern, setzt Auris Rate Limits für SMS-OTP-Codes durch:

  • Maximal 5 Codes pro Telefonnummer pro Stunde.
  • 30 Sekunden Abkühlzeit zwischen Sendeanfragen.
  • Maximal 5 Verifizierungsversuche pro Code, bevor er ungültig wird.
POST/api/user/phone

Setzt die Telefonnummer des Benutzers und sendet einen Verifizierungscode.

POST/api/user/phone/verify

Verifiziert die Telefonnummer mit dem per SMS empfangenen Code.

POST/api/user/2fa/sms/enable

Aktiviert SMS-OTP als zweiten Faktor, nachdem die Telefonnummer verifiziert ist.

POST/api/user/2fa/sms/send

Sendet einen neuen SMS-OTP-Code während einer MFA-Challenge.

WebAuthn / Passkeys

WebAuthn (Web Authentication, FIDO2) ermöglicht es Benutzern, sich mit Hardware-Security-Keys (YubiKey, Titan Key) oder Plattform-Authentifikatoren (Touch ID, Face ID, Windows Hello) zu authentifizieren. Wenn als zweiter Faktor verwendet, tippt der Benutzer auf seinen Hardware-Key oder verwendet Biometrie, um die MFA-Challenge abzuschließen.

WebAuthn-Anmeldedaten sind von Natur aus Phishing-resistent: Die Anmeldedaten sind an den spezifischen Ursprung (Domain) gebunden und können nicht auf einer anderen Website wiedergegeben werden.

Eine vollständige WebAuthn-Einrichtungsanleitung findest du unter WebAuthn / Passkeys.

Benutzer-Einrichtung

  1. Der Benutzer navigiert zu Konto → Sicherheit → Passkeys.
  2. Der Benutzer klickt auf “Passkey registrieren” und gibt einen Namen für die Anmeldedaten an.
  3. Der Browser zeigt eine Plattform-Authentifizierungs-Aufforderung (Touch ID, Windows Hello oder einen Hardware-Key).
  4. Die Anmeldedaten werden registriert. Der Benutzer kann mehrere Passkeys für verschiedene Geräte registrieren.

Während der MFA-Challenge

Wenn WebAuthn-MFA erforderlich ist, zeigt die Hosted-Login-Seite eine WebAuthn-Challenge an. Der registrierte Authentifikator des Benutzers verarbeitet die kryptografische Antwort — keine Codeeingabe ist erforderlich.

POST/api/user/2fa/webauthn/enable

Initiiert die WebAuthn-Registrierung als zweiten Faktor. Gibt die Registrierungs-Challenge zurück.

POST/api/user/2fa/webauthn/challenge

Generiert eine Authentifizierungs-Challenge für eine laufende MFA-Verifizierung.

DELETE/api/user/2fa/webauthn

Entfernt registrierte WebAuthn-Anmeldedaten anhand der Credential-ID.

Adaptives MFA (Risikobasiert)

Adaptives MFA bewertet bei jedem Login einen Risikoscore und eskaliert die Authentifizierungsanforderung automatisch, wenn das Risiko erhöht ist. Anstatt immer MFA zu verlangen oder nie, reagiert Auris proportional zum tatsächlichen Risiko jedes Login-Versuchs.

Risikofaktoren

Auris berechnet einen Risikoscore aus fünf gewichteten Faktoren:

FaktorBeschreibungBeispiel-Trigger
IP-ReputationIP-Adresse mit bekannt bösartiger Aktivität, VPN, Proxy oder Rechenzentrum verbundenLogin von einem Tor-Ausgangsknoten
GerätevertrauenUnbekannter Geräte-Fingerabdruck (kein früherer erfolgreicher Login von diesem Gerät)Erster Login von einem neuen Laptop
Geografische AnomalieUnmögliche Reise — die Entfernung zwischen dem vorherigen Login-Ort und dem aktuellen impliziert eine schnellere als mögliche BewegungLogin aus Italien gefolgt 30 Minuten später von einem Login aus Japan
VerhaltensweisenLogin-Zeit, Anfrage-Takt und andere Verhaltenssignale, die von der Basislinie des Benutzers abweichenLogin um 3:00 Uhr morgens, wenn der Benutzer sich immer während der Geschäftszeiten anmeldet
Aktions-SensitivitätHöher-sensitive Operationen (z.B. E-Mail ändern, API-Schlüssel generieren) werden strenger bewertet als Nur-Lese-ZugriffBenutzer versucht, sein Passwort unmittelbar nach dem Login zu ändern

Faktoren werden zu einem endgültigen Risikoscore von 0 bis 100 kombiniert.

Risikoschwellenwerte

Schwellenwerte in Console → Sicherheit → Adaptives MFA konfigurieren:

SchwellenwertVerhalten
Niedrig (0–30)Keine zusätzliche Authentifizierung erforderlich. Standard-Login fährt fort.
Mittel (31–70)Aufforderung zu einer konfigurierten MFA-Methode (TOTP, SMS oder WebAuthn).
Hoch (71–100)Stärkere MFA-Methode erforderlich. Nur TOTP ist unzureichend — Hardware-WebAuthn wird bevorzugt.

Diese Schwellenwerte sind konfigurierbar. Du kannst auch adaptives MFA vollständig deaktivieren und eine feste Richtlinie verwenden.

ACR und AMR in Tokens

Wenn Step-up-Authentifizierung erfolgt, schließt Auris Standard-Claims in den Access Token ein:

  • ACR (Authentication Context Class Reference): Das erreichte Vertrauensniveau. Zum Beispiel urn:mace:incommon:iap:silver für MFA-verifizierte Sitzungen.
  • AMR (Authentication Methods References): Die verwendeten Authentifizierungsmethoden. Zum Beispiel ["pwd", "totp"] für Passwort + TOTP oder ["pwd", "hwk"] für Passwort + Hardware-Key.

Dein Anwendungsserver kann diese Claims inspizieren, um sitzungsbasierte Zugriffskontrolle durchzusetzen.

Step-up-Authentifizierung

Step-up-Authentifizierung ermöglicht es deiner Anwendung, für bestimmte Operationen innerhalb einer bestehenden Sitzung eine zusätzliche Verifizierung zu verlangen, ohne eine vollständige Neu-Anmeldung zu erzwingen.

Ein Benutzer ist beispielsweise angemeldet und navigiert zu “Konto löschen”. Deine Anwendung kann eine Step-up-Challenge auslösen, die den Benutzer auffordert, sich erneut zu authentifizieren (Passwort eingeben) oder einen MFA-Faktor abzuschließen, bevor die destruktive Aktion fortfährt.

Auris implementiert Step-up über ACR in der Autorisierungsanfrage. Wenn deine Anwendung einen Autorisierungscode mit acr_values=2fa anfordert, prüft Auris das ACR-Level der aktuellen Sitzung und fordert nur dann eine zusätzliche Authentifizierung an, wenn die Sitzung die Anforderung noch nicht erfüllt.

Step-up-Authentifizierung basiert auf den AMR-Claims der Sitzung. Eine Sitzung, die mit TOTP authentifiziert wurde (amr: ["pwd", "totp"]), wird während der Gültigkeitsdauer derselben Sitzung nicht erneut nach TOTP gefragt, es sei denn, die ACR-Anforderung gibt eine Methode an, die noch nicht vorhanden ist.

Console-Konfiguration

MFA-Einstellungen sind in Console → Authentifizierung → MFA-Einstellungen verfügbar.

Methoden-Umschalter:

MethodeUmschalterHinweise
TOTPAktivieren/DeaktivierenAktivieren, damit Benutzer Authentifizierungs-Apps einschreiben können
SMS-OTPAktivieren/DeaktivierenErfordert Twilio-Konfiguration in Umgebungsvariablen
WebAuthnAktivieren/DeaktivierenErfordert HTTPS (Passkeys funktionieren nicht über einfaches HTTP)
Adaptives MFAAktivieren/DeaktivierenBei Deaktivierung gilt die statische Richtlinie für alle Benutzer

Durchsetzungsrichtlinien:

RichtlinieBedeutung
optionalBenutzer können MFA einrichten, sind aber nicht dazu verpflichtet
requiredAlle Benutzer müssen mindestens eine MFA-Methode einschreiben, um den Login abzuschließen
adaptiveMFA ist nur erforderlich, wenn der Risikoscore den konfigurierten Schwellenwert überschreitet

Risikoschwellenwerte: Konfigurierbare Schieberegler für die Nieder/Mittel/Hoch-Grenzen und Pro-Faktor-Gewichtungen.

Erforderliche Berechtigungen

Alle MFA-Verwaltungsendpunkte arbeiten auf dem eigenen Konto des authentifizierten Benutzers und erfordern keine besonderen Berechtigungen außer der Authentifizierung. Admin-Level-Operationen (TOTP eines anderen Benutzers zurücksetzen, MFA-Status anzeigen) erfordern manage:users.

Verwandte Seiten

Architektur