Anmelden mit Benutzername und Passwort ist 2026 ein Auslaufmodell. Phishing, Passwort-Wiederverwendung und schlechte Passwörter machen jedes klassische Login-System unsicher – egal wie streng die Regeln sind. Moderne Authentifizierung sieht anders aus: Passkeys statt Passwörter, OAuth statt eigener User-Datenbank, OIDC statt selbst gebauter Token-Logik. Diese Konzepte sind nicht nur sicherer, sie sind oft auch einfacher für Anwender. Aber sie wollen verstanden sein, bevor man sie einsetzt. In diesem Artikel erklären wir die drei wichtigsten modernen Authentifizierungs-Konzepte und zeigen, wann welches passt.
Warum klassische Passwörter ein Auslaufmodell sind
Passwörter haben fundamentale Schwächen, die sich nicht durch noch strengere Regeln beheben lassen:
- Anwender wählen schwache Passwörter, weil starke schwer zu merken sind
- Phishing-Seiten klauen Passwörter, ohne dass der Anwender es merkt
- Passwörter werden zwischen Diensten wiederverwendet – ein Leak betrifft viele Konten
- Datenbank-Leaks bei Drittanbietern legen Millionen Hashes offen
- Key-Logger und Malware fangen Eingaben am Endgerät ab
- Brute-Force- und Dictionary-Angriffe sind dank GPU-Power schneller als je zuvor
- Passwort-Resets per Mail sind selbst ein Sicherheitsrisiko
Die FIDO Alliance, Google, Apple, Microsoft und Mozilla haben gemeinsam Passkeys als standardisiertes Nachfolge-Verfahren für Passwörter etabliert. In allen großen Plattformen ist Passkey-Support seit 2024/2025 verfügbar – die Adaptation in KMU-Anwendungen kommt jetzt.
Passkeys – das neue Login
Ein Passkey ist ein kryptografisches Schlüsselpaar, das auf dem Endgerät (Smartphone, Notebook, Hardware-Token) gespeichert wird. Beim Login generiert das Gerät eine Signatur, die der Server prüft. Es wird kein Geheimnis übertragen, das geklaut werden könnte.
Phishing-resistent
Ein Passkey funktioniert nur für die echte Domain, für die er erstellt wurde. Eine Phishing-Site bekommt keinen gültigen Login-Versuch.
Kein Passwort zu merken
Anwender bestätigt das Login nur per Touch-ID, Face-ID, Windows-Hello oder PIN. Das war's.
Gerätegebunden, aber synchronisierbar
Passkeys können zwischen Geräten synchronisiert werden (Apple iCloud Keychain, Google Password Manager, Bitwarden). So ist man auf mehreren Geräten arbeitsfähig.
Funktioniert offline
Die Authentifizierung läuft lokal, der Server prüft nur die Signatur. Kein zusätzliches Mail- oder SMS-Token nötig.
Kein Reset-Aufwand bei Datenbank-Leak
Auch wenn die Anwendung gehackt wird – die öffentlichen Schlüssel auf dem Server sind nutzlos ohne den privaten Schlüssel auf dem Anwender-Gerät.
Wie Passkeys technisch funktionieren
Auf Code-Ebene werden Passkeys über die WebAuthn-API implementiert. Sie ist seit 2019 W3C-Standard und in allen modernen Browsern verfügbar.
Registrierung
Anwender legt im Anwendungs-Backend ein Passkey-Eintrag an. Das Backend gibt eine Challenge aus, der Browser/das Gerät generiert ein Schlüsselpaar und schickt den öffentlichen Schlüssel zurück. Der private Schlüssel bleibt am Gerät.
Login
Backend gibt eine neue Challenge aus. Anwender bestätigt am Gerät (Biometrie/PIN). Das Gerät signiert die Challenge mit dem privaten Schlüssel und schickt die Signatur ans Backend. Backend prüft die Signatur gegen den gespeicherten öffentlichen Schlüssel.
Falls Gerät verloren
Anwender kann sich mit einem anderen Gerät anmelden (vorausgesetzt, der Passkey ist dort synchronisiert) oder per Fallback-Methode (alter Passwort-Account, E-Mail-Recovery) reaktivieren.
Account-Recovery
Sollte zwingend mit eingeplant werden – Passkey-Verlust ohne Recovery ist Account-Verlust.
Wer Passkeys einführt, sollte Passwörter als Fallback noch eine Weile aktiv lassen. Sonst sind Anwender ausgesperrt, wenn sie ihr Gerät verlieren und keine Backup-Methode haben. Stufenweise migrieren ist sicherer als Big-Bang.
OAuth 2.0 – Anmelden mit Konten von Drittanbietern
OAuth 2.0 ist das Protokoll, das es ermöglicht, sich bei einer Anwendung mit einem Konto eines anderen Dienstes anzumelden – also "Mit Google anmelden", "Mit Microsoft anmelden", "Mit Apple anmelden". OAuth kümmert sich um die Autorisierung – nicht direkt um die Identität.
OAuth 2.0 ist ein Autorisierungs-Protokoll, kein Authentifizierungs-Protokoll. Es regelt, welche Daten ein Drittsystem im Namen eines Anwenders abfragen darf – nicht direkt, wer der Anwender ist. Für reine Authentifizierung kommt OIDC ins Spiel (dazu gleich).
Wann OAuth Sinn macht
- Anwendung greift im Namen des Anwenders auf Drittdienst zu (z.B. Kalender, Mail, Cloud-Speicher)
- Anwender soll Daten zwischen Diensten freigeben können
- Integration mit externen APIs (Google Calendar, Microsoft Graph, Dropbox)
- Mobile App, die im Namen des Anwenders Aktionen in der Web-App ausführen will
Wann OAuth nicht passt
- Reine Anmeldung – dafür ist OIDC zuständig
- Ohne Drittsystem – wenn nichts geteilt werden soll, ist OAuth Overkill
- Wenn Anwender keinen Account beim Drittsystem haben
OpenID Connect (OIDC) – moderne Anmeldung mit Identitätsprovidern
OIDC ist eine Erweiterung von OAuth 2.0, die explizit die Anmeldung abdeckt. Es ist heute der De-facto-Standard für moderne Authentifizierung in Webanwendungen, die Identity-Provider nutzen wollen (Google, Microsoft Entra ID, Auth0, Keycloak).
Single Sign-On
Anwender meldet sich einmal beim Identity Provider an und kann mehrere Anwendungen nutzen, ohne sich erneut anzumelden.
Keine Passwort-Verwaltung in der eigenen App
Anwender-Passwörter liegen beim Identity Provider. Ihre Anwendung sieht nur ein bestätigtes Token.
Multi-Faktor-Authentifizierung zentral
Wenn der Identity Provider MFA verlangt, gilt das für alle angebundenen Anwendungen.
Großer Standard
Keine eigene Auth-Logik, kein eigenes User-Management – die Identity-Provider haben Spezialisten und Audits.
Flexibel
OIDC kann mit firmenweitem Microsoft Entra, mit Google-Konten, mit eigenem Keycloak oder einer Mischung arbeiten.
Wie OIDC praktisch aussieht
Anwender klickt auf "Mit Microsoft anmelden"
Browser wird auf den Identity Provider weitergeleitet (z.B. login.microsoftonline.com).
Anwender meldet sich beim Identity Provider an
Mit seinem üblichen M365-Login, ggf. mit MFA. Ihre Anwendung sieht das nicht.
Identity Provider stellt Token aus
Ein ID Token (mit Identitätsinformationen) und ein Access Token (für API-Zugriffe) werden an Ihre Anwendung zurückgegeben.
Ihre Anwendung prüft das Token
Signatur, Ablauf, Aussteller. Token gültig? Dann ist der Anwender angemeldet.
Session in Ihrer Anwendung
Anwender hat eine normale Session, die nach Konfiguration abläuft (idealerweise mit Refresh-Token-Verlängerung).
Nutzen Sie eine erprobte OIDC-Bibliothek statt eigener Implementierung. Auth-Protokolle haben subtile Sicherheitsfallen – einer von vielen Bibliotheken-Maintainern wird sie wahrscheinlich besser umsetzen als Sie. Beispiele: panva/jose für PHP, oidc-client-ts für JavaScript, Microsoft.AspNetCore.Authentication für .NET.
Eigene Identity Provider – wann sich Keycloak lohnt
Wer nicht von Microsoft, Google oder Auth0 abhängig sein will, kann einen eigenen Identity Provider betreiben. Die populärste Open-Source-Lösung dafür ist Keycloak.
| Kriterium | Eigener Keycloak | Cloud Provider (Auth0, Microsoft Entra) |
|---|---|---|
| Kosten | Hosting + Wartung selbst | Lizenzmodell, ab Anzahl Anwender |
| Datenhoheit | komplett bei Ihnen | beim Anbieter |
| Betriebsaufwand | Sie betreiben den Server | Anbieter |
| Features | sehr viele, aber muss selbst aktiviert werden | sehr viele, oft schon enthalten |
| Geeignet für | KMU mit eigener IT, Branchen mit hohen Datenanforderungen | KMU ohne eigene Hosting-Affinität |
Viele KMU nutzen Microsoft Entra ID als Identity Provider, weil sie ohnehin Microsoft 365 einsetzen. Das ist oft die einfachste Lösung: Single Sign-On für alle Mitarbeitenden, MFA zentral konfigurierbar, kein zusätzlicher Server nötig.
Multi-Faktor-Authentifizierung – immer und überall
Egal welches Auth-Verfahren Sie wählen: Multi-Faktor-Authentifizierung ist 2026 Standard. Selbst Passkeys können um eine zweite Faktor-Stufe ergänzt werden, wenn besonders sensible Operationen geschützt werden sollen.
| Methode | Sicherheit | Anwender-Komfort | Empfehlung |
|---|---|---|---|
| SMS-Code | niedrig (SIM-Swapping möglich) | mittel | nur als Notfall-Backup |
| Mail-Code | niedrig-mittel | mittel | nur als Notfall-Backup |
| TOTP-App (Google Authenticator, Aegis) | hoch | mittel | Standard für klassisches MFA |
| WebAuthn / Passkey | sehr hoch | hoch | Beste Option, wenn Geräteunterstützung vorhanden |
| Hardware-Token (YubiKey) | sehr hoch | mittel | für besonders kritische Accounts (Admin, Finance) |
⚠️ Wichtig: Bei Admin-Konten ist MFA nicht verhandelbar. SMS ist hier keine ausreichende zweite Stufe – TOTP-App oder Hardware-Token sind das Minimum.
Was bei einer Auth-Migration zu beachten ist
Wer eine bestehende Anwendung von Passwort-Login auf modernere Verfahren umstellt, sollte mit Bedacht vorgehen:
Bei jedem Auth-Wechsel
- Mehrere Methoden parallel anbieten, mindestens 6-12 Monate
- Alte Passwort-Hashes nicht löschen, bis alle aktiven Anwender migriert sind
- Anwender-Kommunikation früh und klar (was ändert sich, warum, wie nutze ich es)
- Recovery-Prozesse vor dem Go-Live testen
- Log-Stream über Auth-Events einrichten (verdächtige Logins, fehlgeschlagene Versuche)
- Dokumentation für Helpdesk – Anrufe wegen Auth werden zunehmen
- Fallback-Plan, falls der Identity Provider ausfällt
- DSGVO-Bewertung – welche Daten gehen wohin?
5 typische Auth-Fehler in KMU-Anwendungen
Eigene Auth-Logik
Login-System selbst gebaut, Passwörter mit MD5 oder SHA-1 gehasht. Lösung: bewährte Bibliotheken / Identity Provider nutzen.
Kein Brute-Force-Schutz
Login lässt unbegrenzte Versuche zu. Lösung: Rate-Limiting, Account-Lockout nach n Fehlversuchen.
Logout existiert nur nominell
Logout löscht das Cookie, aber das JWT bleibt gültig bis Ablauf. Lösung: Token-Revocation oder kurze Token-Laufzeit mit Refresh.
Keine MFA für Admins
Standard-Login auch für Administratoren. Lösung: MFA verpflichtend für privilegierte Accounts.
Passwort-Reset über unverschlüsselten Link
Reset-Mail enthält Link, der dauerhaft gültig ist. Lösung: einmalige Token mit kurzer Laufzeit (15-60 Minuten).
Empfehlung für KMU-Anwendungen 2026
- Neue Anwendungen: OIDC mit Microsoft Entra (wenn M365 vorhanden) oder Keycloak (sonst), Passkeys als bevorzugte Methode für Anwender, Passwort als Fallback
- Bestehende Anwendungen: schrittweise Migration zu OIDC, MFA für alle Anwender, mittelfristig Passkeys
- Interne Tools / Admin-Backends: MFA verpflichtend, Hardware-Token für hochprivilegierte Accounts
- Kundenportale: SSO über OIDC + Passkey-Option für hohen Komfort
Fazit: Moderne Auth ist sicherer UND einfacher
2026 ist Authentifizierung kein Kompromiss mehr zwischen Sicherheit und Komfort. Passkeys sind sicherer als Passwörter und gleichzeitig einfacher zu nutzen. OAuth/OIDC machen eigene Anwender-Verwaltung überflüssig. Multi-Faktor-Authentifizierung ist Standard. Wer als KMU heute eine Webanwendung baut oder eine bestehende modernisiert, sollte diese Konzepte verstehen und gezielt einsetzen – sonst ist die Anwendung in 2-3 Jahren technisch und sicherheitstechnisch veraltet.
Wenn Sie für Ihre bestehende Anwendung eine Auth-Modernisierung planen oder bei einer Neuentwicklung von Anfang an auf zeitgemäße Authentifizierung setzen wollen – melden Sie sich. Wir entwerfen und implementieren OIDC-Integrationen, Passkey-Logins und MFA-Strategien für KMU in Freiburg und der Region.