MFA & SSO
MFA & SSO
Multi-Faktor-Authentifizierung und Single Sign-On – die modernen Standards für sichere Identitätsverwaltung im Enterprise-Umfeld. Von TOTP über SAML bis zu Zero Trust. Mit interaktivem Login-Flow-Simulator.
Inhaltsverzeichnis
Schnellübersicht
Auf dieser Seite lernst du alles über moderne Authentifizierungsmethoden:
- Grundlagen: Was sind MFA und SSO und warum sind sie wichtig?
- 3 Faktoren: Wissen, Besitz, Biometrie – die Basis von MFA
- MFA-Methoden: TOTP, SMS, Push, Hardware-Tokens, Biometrie
- SSO-Architektur: Wie funktioniert Single Sign-On?
- Protokolle: SAML, OAuth 2.0, OpenID Connect, Kerberos
- Login-Flow-Simulator: Interaktiv SSO-Flow testen
- Best Practices: Implementierung und Sicherheit
- FAQ: Häufige Fragen und Mythen
1. Was sind MFA und SSO?
Definition
MFA (Multi-Faktor-Authentifizierung) ist ein Sicherheitsverfahren, bei dem Benutzer zwei oder mehr unabhängige Authentifizierungsfaktoren vorlegen müssen, um Zugriff auf eine Ressource zu erhalten. Dies erhöht die Sicherheit erheblich, da ein Angreifer mehrere Faktoren gleichzeitig kompromittieren müsste.
SSO (Single Sign-On) ermöglicht Benutzern, sich mit einer einzigen Anmeldung bei mehreren verbundenen Anwendungen oder Diensten zu authentifizieren, ohne für jede Anwendung separate Anmeldedaten eingeben zu müssen.
Warum sind MFA und SSO wichtig?
- Passwörter allein reichen nicht: 80% aller Datenverletzungen nutzen gestohlene oder schwache Passwörter (Verizon DBIR 2024)
- Benutzerfreundlichkeit: SSO reduziert Passwort-Müdigkeit und verbessert die User Experience
- Compliance: Viele Standards (ISO 27001, DSGVO, NIST, BSI) fordern MFA für kritische Systeme
- Zero Trust: MFA ist eine Grundvoraussetzung für Zero-Trust-Architekturen
- Produktivität: SSO spart Zeit und reduziert Helpdesk-Tickets für Passwort-Resets um bis zu 50%
- Kosten: Ein Passwort-Reset kostet Unternehmen durchschnittlich 70 € (Forrester)
2. Die 3 Faktoren der Authentifizierung
MFA basiert auf der Kombination von mindestens zwei der drei folgenden Faktoren. Jeder Faktor repräsentiert eine andere Art von Nachweis:
Wissen
Informationen, die nur der Benutzer weiß. Der älteste und am weitesten verbreitete Faktor.
- Passwörter & PINs
- Sicherheitsfragen
- Muster-Sperren
- Passphrasen
Besitz
Physische Objekte, die der Benutzer besitzt. Deutlich sicherer als reines Wissen.
- Smartphones (TOTP/Push)
- Hardware-Tokens (YubiKey)
- Smartcards
- SMS-Codes
Biometrie
Eindeutige biologische Merkmale des Benutzers. Sehr benutzerfreundlich, aber Datenschutzbedenken.
- Fingerabdruck
- Gesichtserkennung
- Iris-Scan
- Stimmerkennung
Wichtig: Faktoren müssen unabhängig sein!
Zwei Passwörter sind kein MFA, da beide zum Faktor "Wissen" gehören. Echtes MFA kombiniert mindestens zwei verschiedene Faktoren (z.B. Passwort + Fingerabdruck oder Passwort + TOTP-Code).
Beispiele für echtes MFA:
- Passwort (Wissen) + TOTP-Code (Besitz)
- Passwort (Wissen) + Fingerabdruck (Biometrie)
- PIN (Wissen) + YubiKey (Besitz)
3. MFA-Methoden im Detail
Es gibt verschiedene Methoden zur Implementierung von MFA, jede mit unterschiedlichen Sicherheitsniveaus, Benutzerfreundlichkeit und Kosten.
TOTP (Time-based One-Time Password)
Zeitbasierte Einmalpasswörter, die alle 30 Sekunden neu generiert werden. Apps wie Google Authenticator, Microsoft Authenticator oder Authy.
SMS-Codes
Einmalpasswörter werden per SMS an das registrierte Smartphone gesendet. Einfach, aber anfällig für SIM-Swapping-Angriffe.
Push-Benachrichtigungen
Benutzer erhalten eine Push-Nachricht auf ihr Smartphone und müssen die Anmeldung bestätigen. Einfach und benutzerfreundlich.
Hardware-Tokens (FIDO2/WebAuthn)
Physische Security Keys wie YubiKey oder Google Titan. Höchste Sicherheit, phishing-resistent, aber zusätzliche Kosten.
Biometrische Authentifizierung
Fingerabdruck, Gesichtserkennung oder Iris-Scan. Schnell und benutzerfreundlich, aber Datenschutzbedenken möglich.
E-Mail-Codes
Einmalpasswörter werden per E-Mail gesendet. Einfach zu implementieren, aber abhängig von E-Mail-Sicherheit und Verfügbarkeit.
Vergleich der MFA-Methoden
| Methode | Sicherheit | Benutzerfreundlichkeit | Kosten | Phishing-Resistenz |
|---|---|---|---|---|
| Hardware-Token (FIDO2) | Sehr hoch | Mittel | Hoch (einmalig) | Ja |
| TOTP (Authenticator App) | Hoch | Hoch | Niedrig | Nein |
| Push-Benachrichtigung | Mittel-Hoch | Sehr hoch | Niedrig | Begrenzt |
| Biometrie | Hoch | Sehr hoch | Mittel | Nein |
| SMS-Codes | Niedrig | Hoch | Niedrig | Nein |
| E-Mail-Codes | Mittel | Mittel | Niedrig | Nein |
Empfehlung für Enterprise-Umfeld
- Administratoren & privilegierte Accounts: Hardware-Tokens (FIDO2/WebAuthn) – höchste Sicherheit
- Alle Mitarbeiter: TOTP + Push-Backup – guter Kompromiss aus Sicherheit und UX
- Externe Partner: TOTP oder E-Mail – einfach zu verteilen
- Niemals SMS allein: NIST rät seit 2016 von SMS-basiertem MFA ab
4. SSO-Architektur – Wie funktioniert Single Sign-On?
SSO basiert auf einem zentralen Identity Provider (IdP), der die Authentifizierung für mehrere Anwendungen (Service Provider, SP) übernimmt. Der Benutzer muss sich nur einmal beim IdP anmelden.
SSO-Authentifizierungsfluss
Benutzer ruft Anwendung auf
Der Benutzer möchte auf eine geschützte Anwendung (Service Provider) zugreifen
Anwendung leitet zum IdP weiter
Die Anwendung erkennt, dass der Benutzer nicht authentifiziert ist, und leitet zum Identity Provider weiter
Authentifizierung beim IdP
Der Benutzer meldet sich beim IdP an (z.B. mit Passwort + MFA)
IdP stellt Token aus
Nach erfolgreicher Authentifizierung stellt der IdP ein SAML-Assertion oder OAuth-Token aus
Zugriff gewährt
Die Anwendung validiert das Token und gewährt Zugriff – ohne erneute Anmeldung
Vorteile von SSO
- Einmalige Anmeldung: Benutzer müssen sich nur einmal authentifizieren
- Reduzierte Passwort-Müdigkeit: Weniger Passwörter zu merken (durchschnittlich 100+ pro Mitarbeiter)
- Zentrale Verwaltung: Konten können zentral deaktiviert werden (z.B. bei Mitarbeiteraustritt)
- Bessere Compliance: Einheitliche Passwortrichtlinien und MFA-Pflicht
- Weniger Helpdesk-Tickets: Bis zu 50% weniger Passwort-Reset-Anfragen
- Bessere Security: Zentralisiertes Logging und Monitoring aller Logins
5. SSO-Protokolle im Detail
Verschiedene Protokolle ermöglichen SSO-Implementierungen. Hier die vier wichtigsten Standards:
SAML 2.0
XML-basiertes Protokoll für SSO, hauptsächlich im Enterprise-Umfeld eingesetzt. Der älteste und am weitesten verbreitete Standard.
- XML-basierte Assertions
- Browser-Redirect-Flow
- Ideal für Enterprise-Apps
- Reifer Standard (seit 2005)
- Unterstützt Single Logout
OAuth 2.0
Delegierungs-Framework für Autorisierung (nicht Authentifizierung!). Ermöglicht Drittanbieter-Zugriff ohne Passwort-Weitergabe.
- Token-basiert (Access Token)
- Mehrere Flows (Authorization Code, Implicit, etc.)
- Ideal für APIs und Mobile Apps
- Scope-basierte Berechtigungen
- Kein Authentifizierungsprotokoll!
OpenID Connect (OIDC)
Authentifizierungs-Erweiterung von OAuth 2.0. JSON-basiert und daher moderner als SAML. Der heutige Standard für Web-SSO.
- JSON Web Tokens (JWT)
- ID-Token + Access-Token
- Ideal für moderne Web-Apps
- UserInfo-Endpoint
- Von Google, Microsoft, Auth0 genutzt
Kerberos
Netzwerk-Authentifizierungsprotokoll, entwickelt am MIT. Basis von Active Directory und Windows-Domänen.
- Ticket Granting Ticket (TGT)
- Key Distribution Center (KDC)
- Mutual Authentication
- Ideal für On-Premise-Umfeld
- Keine Passwörter im Netzwerk
Protokoll-Vergleich
| Feature | SAML 2.0 | OAuth 2.0 | OpenID Connect | Kerberos |
|---|---|---|---|---|
| Hauptzweck | SSO / Federation | Autorisierung | Authentifizierung | Netzwerk-Auth |
| Datenformat | XML | JSON / Form | JSON (JWT) | Binär (Tickets) |
| Transport | HTTP Redirect/POST | HTTP | HTTP | UDP/TCP |
| Mobile-freundlich | Schwerfällig | Ja | Ja | Nein |
| Cloud-freundlich | Ja | Ja | Ja | On-Premise |
| Enterprise-Standard | Ja | Ja | Ja (modern) | Ja (AD) |
| Typischer Einsatz | Unternehmens-Apps | APIs, Social Login | Web-SSO, Mobile | Windows Domänen |
6. Interaktiver Login-Flow-Simulator
Teste, wie ein SSO-Login mit verschiedenen Protokollen und MFA-Methoden abläuft. Wähle die Parameter aus und beobachte den Authentifizierungsfluss in Echtzeit.
SSO & MFA Flow Simulator
Wähle das Szenario aus und sieh, wie der Authentifizierungsfluss abläuft. Der Simulator zeigt die beteiligten Komponenten, exchanged Nachrichten und die finale Entscheidung.
Szenario-Konfiguration
Authentifizierungsfluss
7. Best Practices für MFA & SSO
Sicherheit
- MFA für alle privilegierten Accounts
- FIDO2 für Admin-Accounts bevorzugen
- SMS-MFA vermeiden (SIM-Swapping)
- Conditional Access Policies nutzen
- Phishing-resistente Methoden einsetzen
Benutzerfreundlichkeit
- SSO für alle Unternehmens-Apps
- Remember-Device für vertrauenswürdige Geräte
- Step-up Authentication nur bei Bedarf
- Klare Fehlermeldungen bei MFA-Problemen
- Self-Service für MFA-Reset
Auditing & Monitoring
- Alle Login-Events protokollieren
- Anomale Login-Muster erkennen
- Failed-Login-Alerts konfigurieren
- Integration mit SIEM-Systemen
- Regelmäßige Access-Reviews
Recovery & Backup
- Mehrere MFA-Methoden pro User
- Backup-Codes sicher aufbewahren
- Break-Glass-Accounts für Notfälle
- Admin-Recovery-Prozesse dokumentieren
- Regelmäßige Recovery-Tests
Policies & Governance
- Klare MFA-Pflichten definieren
- Rollenbasierte MFA-Anforderungen
- Compliance mit DSGVO, ISO 27001
- Regelmäßige Policy-Reviews
- Dokumentierte Entscheidungsprozesse
Training & Awareness
- MFA-Onboarding für neue Mitarbeiter
- Security Awareness Trainings
- Phishing-Simulationen regelmäßig
- Helpdesk-Schulung für MFA-Support
- Dokumentation und FAQs bereitstellen
8. FAQ – Häufige Fragen
Häufige Fragen zu MFA & SSO
SMS-MFA ist aus mehreren Gründen unsicher:
- SIM-Swapping: Angreifer können die SIM-Karte des Opfers auf eine eigene Karte übertragen
- SS7-Schwachstellen: Das Telefonie-Protokoll SS7 hat bekannte Sicherheitslücken
- Keine Ende-zu-Ende-Verschlüsselung: SMS können abgefangen werden
- Verzögerungen: SMS können Minuten brauchen – Nutzer geben frustriert auf
Das NIST (National Institute of Standards and Technology) rät seit 2016 von SMS-MFA ab.
OAuth 2.0 ist ein Autorisierungs-Framework. Es beantwortet die Frage: "Was darf diese App tun?" (z.B. "Auf meine Fotos zugreifen"). Es ist kein Authentifizierungsprotokoll!
OpenID Connect (OIDC) ist eine Authentifizierungs-Erweiterung von OAuth 2.0. Es fügt ein ID-Token (JWT) hinzu, das die Identität des Benutzers bestätigt. OIDC beantwortet: "Wer ist dieser Benutzer?"
Merkregel: OAuth 2.0 = Autorisierung, OIDC = Authentifizierung + Autorisierung.
FIDO2 (Fast IDentity Online 2) ist ein Standard der FIDO Alliance für passwortlose Authentifizierung. WebAuthn ist die Web-API dafür.
Warum es so sicher ist:
- Phishing-resistent: Der private Schlüssel verlässt niemals das Gerät
- Public-Key-Kryptographie: Nur eine Signatur wird gesendet, nie das Passwort
- Domain-Bindung: Credentials sind an die Domain gebunden
- Biometrie oder PIN: Lokale Verifizierung auf dem Gerät
Beispiele: YubiKey, Google Titan, Windows Hello, Apple Touch ID/Face ID.
Conditional Access (bedingter Zugriff) ist ein Sicherheitskonzept, bei dem Zugriffsentscheidungen auf Basis mehrerer Faktoren getroffen werden:
- Benutzer: Wer meldet sich an? (Rolle, Risikoprofil)
- Standort: Von wo? (Corporate Network, Ausland)
- Gerät: Mit welchem Gerät? (Managed, compliant)
- Anwendung: Auf welche Ressource? (kritisch, öffentlich)
- Risiko: Wie hoch ist das Risiko? (unmögliche Reise, leaked credentials)
Beispiel: "Wenn User von außerhalb des Firmennetzwerks auf SAP zugreift, verlange MFA + Compliance-Check."
Empfohlene Vorgehensweise:
- IdP auswählen: Azure AD, Okta, Auth0, OneLogin, Keycloak (Open Source)
- Anwendungen inventarisieren: Welche Apps sollen angebunden werden?
- Protokoll wählen: SAML für Enterprise-Apps, OIDC für moderne Web-Apps
- Pilot-Phase: Mit 5-10 Apps und einer Benutzergruppe starten
- MFA einführen: Parallel zu SSO MFA für alle User aktivieren
- Rollout: Schrittweise alle Anwendungen anbinden
- Legacy-Apps migrieren: Alte Systeme mit Password-Sync oder modernen Alternativen ersetzen
Best Practice: Mehrere Recovery-Optionen vorbereiten:
- Backup-Codes: 10 einmalige Codes, die der User sicher aufbewahrt
- Zweite MFA-Methode: Z.B. TOTP + Push als Fallback
- Self-Service-Reset: Über verifizierte E-Mail oder alternative Methode
- Helpdesk-Prozess: Identitätsprüfung (z.B. über Manager) und manuelles Reset
- Break-Glass-Accounts: Admin-Accounts ohne MFA für Notfälle (streng überwacht)
Wichtig: Recovery-Prozesse müssen dokumentiert und regelmäßig getestet werden!
SSO (Single Sign-On): Benutzer melden sich einmal an und haben Zugriff auf mehrere Anwendungen innerhalb derselben Organisation/Domäne.
Federation: Benutzer können sich mit Credentials einer anderen Organisation bei Anwendungen anmelden. Beispiel: "Login mit Google" oder "Login mit Microsoft" auf einer fremden Website.
Zusammenhang: Federation ist die technische Grundlage, die SSO über Organisationsgrenzen hinweg ermöglicht. SAML und OIDC sind beides Federation-Protokolle.
Viele Standards und Regulierungen fordern MFA:
- DSGVO (EU): Angemessene Sicherheitsmaßnahmen, MFA für kritische Systeme empfohlen
- ISO 27001: Zugriffskontrolle, starke Authentifizierung gefordert
- BSI IT-Grundschutz: MFA für administrative Zugriffe Pflicht
- NIST SP 800-63B: MFA für alle authentifizierten Zugriffe empfohlen
- PCI DSS: MFA für alle Admin-Zugriffe auf Cardholder-Data-Umfeld
- PSD2 (EU): Starke Kundenauthentifizierung (SCA) für Zahlungen
- HIPAA (USA): Zugriffskontrolle auf Gesundheitsdaten
Zusammenfassung
Die wichtigsten Punkte
- MFA: Kombination von 2+ Faktoren (Wissen, Besitz, Biometrie) für erhöhte Sicherheit
- SSO: Eine Anmeldung für mehrere Anwendungen über einen Identity Provider
- 3 Faktoren: Wissen (Passwort), Besitz (Token/Smartphone), Biometrie (Fingerabdruck)
- Sicherste Methode: FIDO2/WebAuthn (Hardware-Tokens) – phishing-resistent
- Unsicherste Methode: SMS-Codes – SIM-Swapping möglich, NIST rät ab
- Protokolle: SAML (Enterprise), OIDC (modern), OAuth 2.0 (Autorisierung), Kerberos (AD)
- Best Practices: Default MFA, Conditional Access, Recovery-Optionen, Awareness-Training
- Compliance: MFA von ISO 27001, DSGVO, BSI, PCI DSS gefordert
- Zero Trust: MFA ist Grundvoraussetzung für Zero-Trust-Architekturen
- SSO-Vorteile: Weniger Passwort-Müdigkeit, bessere Security, weniger Helpdesk-Tickets
Weiterführende Themen
IAM-Systeme, Rollen, Berechtigungen und Lifecycle-Management im Detail.
Zu IAMAD DS, Domänen, Forests, Trusts und Kerberos-Authentifizierung.
Zu Active DirectoryPAM, Just-in-Time-Access und Verwaltung privilegierter Accounts.
Zu PAM"Never trust, always verify" – Das moderne Sicherheitsparadigma.
Zu Zero Trust