Wie gestaltet man einen Authentifizierungsflow?

[Raphael_]

Hallo,

ich arbeite derzeit an der Entwicklung einer Website, die ein Frontend und ein Backend umfasst. Die Website soll es Benutzern ermöglichen, Konten zu erstellen, um persönliche Informationen zu speichern. Für das Authentifizierungs- und Autorisierungsverfahren habe ich Keycloak als Lösung gewählt. Keycloak verwaltet die Benutzer, sodass ich nicht alles von Grund auf neu entwickeln muss. Diese Lösung basiert auf JWT (JSON Web Tokens).

Nun habe ich folgende Frage: Wenn Benutzer Daten über sich selbst speichern sollen, benötige ich eine Datenbank (die Auswahl der Datenbank ist noch nicht final). Wie gehe ich am besten vor, wenn sich ein neuer Benutzer registriert? Wenn sich jemand in Keycloak registriert, müsste ich in meiner Datenbank eigentlich eine eindeutige Benutzer-ID generieren, um den Benutzer später identifizieren zu können.

Meine Idee war, eine ID basierend auf dem "sub"-Wert zu generieren, der Teil des JWTs ist, indem ich ein Hash-Verfahren verwende. Diese generierte "ID" würde ich dann in meiner Datenbank speichern. Auf diese Weise könnte ich bei der Anmeldung eines Benutzers einfach den "sub"-Wert extrahieren und mithilfe des Hash-Verfahrens die zugehörige ID in meiner Datenbank abrufen.

Da ich in diesem Bereich noch keine Erfahrung habe, bin ich mir unsicher, ob meine Idee sinnvoll ist. Deshalb frage ich nach bewährten Methoden und wie so etwas normalerweise umgesetzt wird.

Vielen Dank im Voraus!

 

[KonradN]

Deine Idee ist schon richtig und genau das solltest Du machen.

Wenn Du einen Request mit JWT bekommst, dann wertest Du das JWT aus. Im sub Feld hast Du die eindeutige ID des Users und dann kannst Du schauen, ob es den User schon gibt oder nicht. Und dann kannst Du ggf. den User anlegen wenn er noch nicht existiert.

(Das wäre die Idee, wenn KeyCloak der Master ist und alle User entsprechend berechtigt sind!)

Ggf. bekommst Du auch noch weitere Informationen wie Email Adresse, Name, .... In so einem Fall kann es Sinn machen, auch diese Werte zu prüfen und ggf. bei Dir zu ändern (So Du die Werte auch gespeichert hast. Evtl. ist das aber unnötig, da Du nichts redundant speicherst.)

Aber da ist kein Hashing notwendig. Die Id des Users würde ich direkt speichern.

 

[Raphael_]

Deine Idee ist schon richtig und genau das solltest Du machen.

Wenn Du einen Request mit JWT bekommst, dann wertest Du das JWT aus. Im sub Feld hast Du die eindeutige ID des Users und dann kannst Du schauen, ob es den User schon gibt oder nicht. Und dann kannst Du ggf. den User anlegen wenn er noch nicht existiert.

(Das wäre die Idee, wenn KeyCloak der Master ist und alle User entsprechend berechtigt sind!)

Ggf. bekommst Du auch noch weitere Informationen wie Email Adresse, Name, .... In so einem Fall kann es Sinn machen, auch diese Werte zu prüfen und ggf. bei Dir zu ändern (So Du die Werte auch gespeichert hast. Evtl. ist das aber unnötig, da Du nichts redundant speicherst.)

Aber da ist kein Hashing notwendig. Die Id des Users würde ich direkt speichern.

Danke erstmal für deine Antwort.

Mir kamen jetzt 2 Fragen.

1. Das bedeutet, dass der Datenflow dann so ist, dass jemand im Frontend was eingibt, diese Infos dann ans Backend gesendet werden und das Backend dann die Informationen an Keycloak sendet, um die Registrierung durchführt, ist das richtig? Weil wenn ich das mit der id speichern nicht machen müsste, dann könnte ich ja direkt vom Frontend die Anmeldedaten ans Keycloak senden, oder?

2. Was mache ich, wenn sich ein Nutzer registriert, meine Datenbank aber aus irgendwelchen Gründen nicht erreichbar ist? In diesem Fall hätte Keycloak ja einen Nutzer registriert aber ich könnte die id nicht in der Datenbank speichern.

Danke für deine Hilfe!

 

[KonradN]

Nein, Der Ablauf sieht anders aus.

Der Nutzer greift auf das Frontend zu. Wenn er nicht angemeldet ist, dann ist kein Token vorhanden.
Nun will der Nutzer sich anmelden. Das macht Keycloak, d.h. der Webbrowser wechselt zu einer Seite von Keycloak.
Dort meldet der Nutzer sich an. Wenn er angemeldet ist, erzeugt Keycloak ein Token und leitet dann den Browser an eine URL weiter (Diese ist entweder fest konfiguriert oder diese wurde im Request, die den Login angefordert hat, mitgegeben. In der Regel ist es so, dass ein Pattern verpflichtend ist, also es muss myapp.com als Domain sein. Aber der Login kann von vielen Seiten kommen, die public sind und am Ende möchte an ja wieder auf der Seite sein - nur eben angemeldet)
Bei der Weiterleitung ist im Browser aber nun das Token mit hinterlegt. Das kann das Frontend nun auswerten und erhält dadurch dann gewisse Informationen wie Name, Email Adresse und all sowas....

Wenn das Frontend auf das Backend zugreift, dann wird dieses Token vom Nutzer einfach mitgegeben.

Für die Nutzerdaten selbst ist Keycloak verantwortlich. Das kannst Du soweit konfigurieren. Du kannst also für Login und so eigene Seiten hinterlegen, damit es so aussieht, wie Du willst. Und Du kannst in Keycloak für ein Realm "Enable User Registration" aktivieren.

Wichtig ist, dass die Verantwortung wirklich bei Keycloak liegt. Du solltest da also keine Vertraulichen Informationen in Deiner App verwalten oder pflegen. Du bekommst also nie das Passwort zu sehen. Der User muss sich auch nicht mit Passwort anmelden. Evtl. meldet er sich mit einem Zertifikat an oder mit irgend etwas anderem... Evtl. mit einem anderen Identity Provider wie Microsoft, Google, Facebook, Github, ....

Das ist nicht die Verantwortung Deiner App. Das ist der Verantwortungsbereich von Keycloak. Und das kann man da alles konfigurieren.
Deine Anwendung (Frontend wie Backend) vertrauen der Keycloak Instanz und damit dem Token.

 

[KonradN]

Ach ja - wenn eine Ressource nicht da ist (z.B. eine Datenbank) - dann funktioniert alles natürlich nicht. Das ist aber doch etwas ganz normales. Wenn die Datenbank Deiner App nicht funktioniert, dann funktioniert das Backend nicht und da das Frontend das Backend braucht, wird das auch nicht gehen. Bei irgendwelchen Anfragen wird dann vermutlich im Backend eine Exception kommen was dann zu einem 5xx http Status Code führen dürfte. Und das wird dann im Frontend hoffentlich irgendwie angezeigt.

 

[Raphael_]

Nein, Der Ablauf sieht anders aus.

Der Nutzer greift auf das Frontend zu. Wenn er nicht angemeldet ist, dann ist kein Token vorhanden.
Nun will der Nutzer sich anmelden. Das macht Keycloak, d.h. der Webbrowser wechselt zu einer Seite von Keycloak.
Dort meldet der Nutzer sich an. Wenn er angemeldet ist, erzeugt Keycloak ein Token und leitet dann den Browser an eine URL weiter (Diese ist entweder fest konfiguriert oder diese wurde im Request, die den Login angefordert hat, mitgegeben. In der Regel ist es so, dass ein Pattern verpflichtend ist, also es muss myapp.com als Domain sein. Aber der Login kann von vielen Seiten kommen, die public sind und am Ende möchte an ja wieder auf der Seite sein - nur eben angemeldet)
Bei der Weiterleitung ist im Browser aber nun das Token mit hinterlegt. Das kann das Frontend nun auswerten und erhält dadurch dann gewisse Informationen wie Name, Email Adresse und all sowas....

Wenn das Frontend auf das Backend zugreift, dann wird dieses Token vom Nutzer einfach mitgegeben.

Für die Nutzerdaten selbst ist Keycloak verantwortlich. Das kannst Du soweit konfigurieren. Du kannst also für Login und so eigene Seiten hinterlegen, damit es so aussieht, wie Du willst. Und Du kannst in Keycloak für ein Realm "Enable User Registration" aktivieren.

Wichtig ist, dass die Verantwortung wirklich bei Keycloak liegt. Du solltest da also keine Vertraulichen Informationen in Deiner App verwalten oder pflegen. Du bekommst also nie das Passwort zu sehen. Der User muss sich auch nicht mit Passwort anmelden. Evtl. meldet er sich mit einem Zertifikat an oder mit irgend etwas anderem... Evtl. mit einem anderen Identity Provider wie Microsoft, Google, Facebook, Github, ....

Das ist nicht die Verantwortung Deiner App. Das ist der Verantwortungsbereich von Keycloak. Und das kann man da alles konfigurieren.
Deine Anwendung (Frontend wie Backend) vertrauen der Keycloak Instanz und damit dem Token.

Vielen Dank, das war mir garnicht so klar und ist wirklich hilfreich.

Was meinst du denn aber bitte mit "Der User muss sich auch nicht mit Passwort anmelden. Evtl. meldet er sich mit einem Zertifikat an oder mit irgend etwas anderem"? Weil ich meine der User hat sich doch registriert, dann muss er doch auch das Passwort für seinen Account eingeben, oder habe ich dich da falsch verstanden?

Und setzt Keycloak den Token im Browser dann automatisch? Also ist das dann im local storage gespeichert?

Vielen Dank!

 

[KonradN]

Du hast viele Möglichkeiten, wie sich ein User anmelden kann. Username / Passwort oder Email/Passwort sind nur zwei Möglichkeiten.

Unternehmen haben teilweise eine eigene PKI Infrastruktur und nutzen diese, um sich z.B. dann mit einem Zertifikat auf einer Smartcard anzumelden. Das geht auch mit Keycloak: Server Administration Guide (keycloak.org)

Was alles mit Keycloak geht kann Dir aber als Entwickler egal sein. Du musst die einzelnen Möglichkeiten nicht kennen. Das ist aus meiner Sicht der große Vorteil. Die Userverwaltung ist separat und Du hast damit nichts am Hut. Für Tests kannst Du da irgendwas haben. Die typischen User user/user und admin/admin oder so ... (Also jeweils username/passwort angegeben). Und wenn die Anwendung dann deployed wird, dann kann da genutzt werden, was immer da gewünscht wird.

Damit hast Du eine kritische Komponente ausgelagert. Du musst Dir keine Gedanken machen, was für Features da evtl. benötigt werden. Sicherheitsanforderungen können separat von Deiner Anwendung frei umgesetzt werden.