‫Kursleiter: Wir haben also unser
‫Benutzermodell eingerichtet, um Benutzer mit sicheren Passwörtern zu speichern.
‫Als nächstes werden wir
‫die Benutzerauthentifizierung und -autorisierung wirklich implementieren.
‫Einfach ausgedrückt, der gesamte Arbeitsablauf der
‫Anmeldung von Benutzern und
‫der Interaktion mit bestimmten geschützten Ressourcen, auf
‫die nicht angemeldete Benutzer keinen Zugriff haben.
‫Es gibt viele Authentifizierungsmethoden, aber die
‫eine, die wir verwenden werden, ist ein sehr
‫moderner, einfacher und sicherer Ansatz namens Json Web Tokens oder kurz JWT.
‫Json Web Tokens sind also eine zustandslose Lösung
‫für die Authentifizierung.
‫Es ist also nicht erforderlich, einen Sitzungsstatus auf dem Server
‫zu speichern, was natürlich perfekt für ruhige APIs wie diejenige ist,
‫die wir erstellen.
‫Denken Sie daran, dass Restful APIs immer zustandslos sein sollten.
‫Und die am weitesten verbreitete Alternative zur Authentifizierung mit
‫JWTs besteht darin, den Anmeldestatus des Benutzers mithilfe von Sitzungen einfach
‫auf dem Server zu speichern.
‫Aber dann folgt natürlich nicht der
‫Grundsatz, dass Restful APIs zustandslos sein sollten und
‫deshalb entscheiden wir uns für eine Lösung wie JWTs.
‫Schauen wir uns nun an, wie die Authentifizierung
‫mit Json Web Tokens tatsächlich funktioniert.
‫Und vorausgesetzt, wir haben bereits einen registrierten Benutzer
‫in unserer Datenbank, so meldet sich ein Benutzer in der App an.
‫Der Client des Benutzers beginnt also mit einer
‫Postanfrage mit dem Benutzernamen oder der E-Mail und dem Passwort.
‫Die Anwendung prüft dann, ob der Benutzer existiert und
‫ob das Passwort korrekt ist.
‫Und wenn dies der Fall ist, wird ein eindeutiger
‫Json Web Token nur für diesen Benutzer mithilfe einer geheimen Zeichenfolge erstellt,
‫die auf einem Server gespeichert ist.
‫Und ein JWT selbst ist eigentlich nur ein String,
‫der ungefähr so aussieht.
‫Aber wir werden auf der nächsten Folie mehr über
‫das JWT selbst sprechen.
‫Wie auch immer, der Server sendet dieses JWT dann zurück an den Client, der
‫es entweder in einem Cookie oder in einem lokalen Speicher speichert.
‫Und so wird der Benutzer authentifiziert und
‫im Grunde in unsere Anwendung eingeloggt,
‫ohne einen Zustand auf dem Server zu verlassen.
‫Der Server weiß also tatsächlich nicht, welche Benutzer
‫tatsächlich angemeldet sind.
‫Aber natürlich weiß der Benutzer, dass er eingeloggt
‫ist, weil er ein gültiges Json Web Token besitzt, das ein
‫bisschen wie ein Reisepass ist, um auf geschützte Teile der Anwendung zuzugreifen.
‫Also noch einmal, nur um sicherzustellen, dass Sie die Idee haben.
‫Ein Benutzer ist eingeloggt, sobald er seinen
‫eindeutigen gültigen Json Web Token zurückerhält, der nirgendwo auf dem Server
‫gespeichert ist.
‫Dieser Prozess ist also völlig zustandslos.
‫Jedes Mal, wenn ein Benutzer dann auf eine geschützte Route zugreifen möchte,
‫wie beispielsweise seine Benutzerprofildaten, sendet er
‫seinen Json Web Token zusammen mit einer Anfrage.
‫Es ist also ein bisschen so, als würde man seinen Pass vorzeigen, um
‫Zugang zu dieser Route zu erhalten, oder?
‫Und das ist wahrscheinlich der beste und einfachste Weg, diese
‫ganze Idee zu verstehen.
‫Sobald die Anfrage den Server erreicht,
‫überprüft unsere App, ob das Json Web Token
‫tatsächlich gültig ist.
‫Wenn der Benutzer also wirklich der ist, für den er sich ausgibt.
‫Und mehr darüber, wie dieser Schritt
‫funktioniert, etwas später in diesem Video.
‫Wenn das Token nun tatsächlich gültig ist,
‫werden die angeforderten Daten an den Client gesendet und
‫wenn nicht, wird dem Benutzer eine Fehlermeldung angezeigt,
‫dass er nicht auf diese Ressource zugreifen darf.
‫Und solange der Benutzer eingeloggt ist,
‫funktioniert es jedes Mal, wenn er Daten von einer
‫beliebigen geschützten Route anfordert.
‫Nun ist es sehr
‫wichtig zu beachten, dass all diese Kommunikation über https erfolgen muss.
‫Also sicheres verschlüsseltes http, um zu verhindern, dass
‫jeder auf Passwörter oder Json Web Tokens zugreifen kann.
‫Nur dann haben wir ein wirklich sicheres System.
‫Aber darüber werden wir später in diesem Abschnitt sprechen, okay.
‫Ich weiß also, dass das am Anfang ziemlich
‫verwirrend aussehen kann, wenn
‫man sich das erste Mal darum
‫bemüht, aber eigentlich ist das Prinzip an sich eigentlich ganz einfach, oder?
‫Und das ist wirklich alles,
‫was Sie wissen müssen, um die Authentifizierung mit JWT implementieren zu können.
‫Aber lassen Sie uns nun etwas
‫tiefer in die Funktionsweise des JWT selbst eintauchen.
‫Ein Json Web Token sieht also aus wie der linke Teil dieses Screenshots,
‫der aus dem JWT-Debugger bei jwt stammt. io.
‫Im Wesentlichen handelt es sich also um eine Codierungszeichenfolge,
‫die aus drei Teilen besteht.
‫Der Header, die Payload und die Signatur.
‫Jetzt sind der Header nur einige Metadaten über das Token selbst
‫und die Nutzlast sind die Daten, die wir
‫in das Token codieren können, alle Daten, die wir wirklich wollen.
‫Je mehr Daten wir hier kodieren möchten,
‫desto größer ist das JWT.
‫Wie auch immer, diese beiden Teile sind
‫nur einfacher Text, der verschlüsselt, aber nicht verschlüsselt wird.
‫So kann jeder sie entschlüsseln und lesen.
‫Daher können wir hier keine sensiblen Daten speichern.
‫Aber das ist überhaupt
‫kein Problem, denn im dritten Teil, also in
‫der Signatur, wird es erst richtig spannend.
‫Die Signatur wird aus dem Header, den Payloads und
‫dem auf dem Server gespeicherten Secret erstellt.
‫Erinnere dich daran?
‫Und dieser ganze Prozess wird
‫dann als Signieren des Json Web Token bezeichnet.
‫Auch hier verwendet der Signaturalgorithmus den Header,
‫die Nutzlast und das Geheimnis, um eine eindeutige Signatur zu erstellen.
‫Also nur diese Daten plus das
‫Geheimnis können diese Signatur erstellen, in Ordnung?
‫Diese Signatur bildet dann zusammen mit dem
‫Header und den Payloads das JWT, das
‫dann an den Client gesendet wird.
‫Wie ich bereits auf der ersten Folie kurz erwähnt
‫habe, muss der Server, sobald er ein JWT erhält, um Zugriff
‫auf eine geschützte Route zu gewähren, es überprüfen, um
‫festzustellen, ob der Benutzer wirklich der ist,
‫für den er sich ausgibt, oder?
‫Mit anderen Worten, es wird überprüft, ob niemand den Header
‫und die Nutzdaten des Tokens geändert hat.
‫Auch in diesem Überprüfungsschritt wird überprüft, ob kein
‫Dritter tatsächlich den Header oder die Nutzlast
‫des Json Web Token geändert hat.
‫Wie funktioniert diese Überprüfung eigentlich?
‫Nun, es ist eigentlich ganz einfach.
‫Sobald das JWT empfangen wurde, nimmt die
‫Verifizierung seinen Header und seine Nutzlast und erstellt
‫zusammen mit dem Geheimnis, das
‫noch auf dem Server gespeichert ist, im Grunde eine Testsignatur.
‫Aber die Originalsignatur, die beim
‫Erstellen des JWT generiert wurde, befindet sich noch im Token, oder?
‫Und das ist der Schlüssel für diese Überprüfung.
‫Denn jetzt müssen wir nur
‫noch die Testunterschrift mit der Originalunterschrift vergleichen.
‫Und wenn die Testsignatur mit
‫der Originalsignatur übereinstimmt, bedeutet dies, dass die Nutzdaten
‫und der Header nicht geändert wurden, oder?
‫Denn wenn sie modifiziert
‫worden wären, müsste die Testsignatur anders sein.
‫Daher können wir in diesem Fall, in
‫dem die Daten nicht geändert wurden, den Benutzer authentifizieren.
‫Und wenn sich die
‫beiden Signaturen tatsächlich unterscheiden, bedeutet dies
‫natürlich, dass die Daten manipuliert wurden.
‫Normalerweise durch den Versuch, die Nutzlast zu ändern.
‫Aber dieser Dritte, der die Nutzlast manipuliert,
‫hat natürlich keinen Zugriff auf das Geheimnis, sodass er
‫das JWT nicht signieren kann.
‫Die Originalsignatur wird also niemals den
‫manipulierten Daten entsprechen.
‫Daher wird die Überprüfung in diesem Fall
‫immer fehlschlagen.
‫Und das ist der Schlüssel zum Funktionieren dieses ganzen Systems.
‫Es ist die Magie, die JWT so einfach,
‫aber auch extrem mächtig macht.
‫Lassen Sie mich es also noch einmal zusammenfassen.
‫Ohne das Geheimnis kann niemand die JWT-Daten
‫manipulieren, da er keine gültige Signatur für
‫die neuen Daten erstellen kann.
‫Ich meine, sie könnten die Daten
‫natürlich manipulieren, aber der Überprüfungsschritt wird immer fehlschlagen.
‫Keine Sorge, wir werden diese
‫JWT-Algorithmen nicht selbst implementieren.
‫Sie sind sehr komplex und wir werden
‫hier das Rad nicht neu erfinden, in Ordnung?
‫Aber es ist immer noch sehr wichtig zu verstehen, wie
‫dieser ganze Prozess hinter den Kulissen abläuft.
‫Und ich hoffe, dass dieser Vortrag genau das für Sie getan hat.
‫Aber jetzt gehen wir zur nächsten Vorlesung über, um
‫all dies tatsächlich zu nutzen.