Keycloak & Passkeys: Was ist das, was geht und was nicht

Überblick & Begriffe

Kurz gesagt wollen Passkeys nicht weniger als Passwörter obsolet machen. Und den Benutzernamen möglicherweise gleich mit. Ursprung dieser Lösung sind allerlei Probleme, die von der klassischen Kombination von Benutzernamen und Passwörtern, die üblicherweise bei jeder Benutzerauthentifizierung via Loginformular in eine geschützte Anwendung abgefragt werden, ausgehen.

Passwörter können beispielsweise zu wenig komplex sein und sind so einfach zu erraten. Genauso muss sich der Anwender an Benutzernamen und Passwort erinnern, was dem ein oder anderen nicht leichtfällt. Passwörter können via Brute-Force erraten oder durch Datenlecks aufgedeckt werden. Gleichzeitig verwenden Benutzer gleiche Passwörter oft mehrfach bei verschiedenen Diensten und machen so direkt mehrere Dienste angreifbar, wenn das Passwort bekannt wird.

Viele dieser Probleme lassen sich durch die Verwendung von Passwortmanagern lösen, da komplexe und individuelle Passwörter sicher und unvergesslich gespeichert werden. Für andere Probleme kommen Passkeys ins Spiel. Sie sind vor allem sicherer, benutzerfreundlicher und bieten einen Phishing-Schutz.

Recherchiert man zum Thema Passkeys, stolpert man oft ebenfalls über die Begriffe WebAuthN und FIDO2. Einfach gesprochen:

• WebAuthN ist ein Webstandard der W3C, der eine API zur Authentication im Web festlegt, die über JavaScript angesprochen wird. Dadurch können Websites Benutzer mit Hilfe kryptografischer Schlüsselpaare authentifizieren.
• FIDO2 ist ein konkreter Standard, wie Authentifizierung im Web mit kryptografischen Schlüsselpaaren ablaufen sollte und umfasst auch eine Möglichkeit WebAuthN umzusetzen.
• Passkeys sind eine Implementierung von FIDO2. Für jeden zu nutzenden Dienst wird ein Schlüsselpaar erzeugt.

Passkeys aus technischer Sicht

Technisch handelt es sich bei einem Passkey um ein asymmetrisch Schlüsselpaar – also einen öffentlichen und einen privaten Schlüssel. Soll der Login via Passkey bei einem Dienst ermöglicht werden, geschieht das über eine Credential Creation in 3 Schritten:

1. Der Benutzer erzeugt lokal ein neues Schlüsselpaar.
2. Der private Schlüssel wird sicher auf dem Gerät des Benutzers gespeichert und verlässt dieses im Bestfall nie.
3. Der öffentliche Schlüssel wird an den Dienst übertragen und dort als Credential des Benutzers hinterlegt.

Wie bei asymmetrischen Schlüsseln üblich, lässt sich aus dem öffentlichen Schlüssel der private nicht ableiten. Daher eignet sich der private Schlüssel als sicherer Passwortersatz, da dieser das Gerät des Benutzers nicht verlässt. Der Login erfolgt dann so:

1. Der Benutzer ruft bei dem Server, bei dem er sich einloggen möchte, eine Challenge ab, die bei jedem Loginversuch anders ist.
2. Der Benutzer nutzt seinen privaten Schlüssel, um die Challenge zu signieren und sendet nur die Signatur an den Server zurück.
3. Der Server prüft mithilfe des ihm bekannten öffentlichen Schlüssel des Benutzers die Signatur auf Gültigkeit.

Durch diesen Ablauf kann der Benutzer nachweisen, dass er im Besitz des privaten Schlüssels ist, ohne diesen aus der Hand geben zu müssen. Durch die Signatur ist der Nachweis erbracht und der Server kann den Login zulassen.

Passkeys in Keycloak

Beim Login in einen Benutzeraccount kann man grob zwischen drei Scenarios unterscheiden, wie Keycloak hier unterstützen kann.

1. Login mit Benutzername und Passwort, zweiter Faktor via Passkey
2. Login mit Benutzername und Passkey statt Passwort
3. Login nur mit Passkey ohne Benutzernamen

Möglichkeit 1 – Zweiter Faktor via Passkey

Um einen Passkey als zweiten Faktor beim Login nutzen zu können, müssen wir am Browser Flow eine kleine Änderung vornehmen. Standardmäßig will Keycloak als zweiten Faktor ein OTP Form zeigen. Dieses können wir jedoch einfach durch den WebAuthn Authenticator ergänzen:

Da der WebAuthn Authenticator teil eines Conditional Subflows ist, wird er nur angezeigt, wenn der Benutzer, der sich einloggen will, auch einen Passkey als zweiten Faktor in seiner Account Console hinterlegt hat:

Möchte man als Admin benutzer zwingen einen Passkey zu hinterlegen, geht dies über die Required Action „Webauthn Register“.

Möglichkeit 2 – Passkey statt Passwort

Auch hierfür ist eine Änderung am Login Flow notwendig – schließlich wollen wir jetzt nichtmehr nach Benutzernamen und Passwort, sondern nach Benutzernamen und Passkey fragen beim Login. Daher muss das UsernamePasswordForm gegen ein Username Form und einen WebAuthn Passwordless Authenticator getauscht werden:

Dann hat ein User auch die Möglichkeit über die Account Console im Bereich Passwordless einen Passkey zu hinterlegen:

Da der Benutzer sich allerdings nicht mehr einloggen kann, sollte nur ein Login via Passkey erlaubt sein, dieser allerdings noch keinen konfiguriert haben, sollte der Passkey entweder schon bei der Registrierung hinterlegt werden, oder nur alternativ zum Passwort genutzt werden.

Möglichkeit 3 – Login ohne Benutzernamen nur mit Passkey

Diese Möglichkeit wird ebenfalls frisch von Keycloak ab Version 26.4 unterstützt. Dazu muss unter Authentication -> Policies -> Webauthn Passwordless Policy die Option "Enable Passkeys" anschaltet werden.

Fazit

• Keycloak unterstützt bereits von Haus aus Basisfunktionalität zu Passkeys
• Passkeys können als Passwort-Ersatz, zweiter Faktor oder als Ersatz für Benutzername und Passwort genutzt werden.