[MUSIK]
In den vorangegangenen Lektionen
haben wir verschiedene Arten von Authentifizierungsschemata gesehen.
Wir begannen mit der grundlegenden Authentifizierung, dann schauten wir uns an, wie wir Cookies für die
Authentifizierung verwenden können, und sogar signierte Cookies, und
danach haben wir uns die sitzungsbasierte Authentifizierung angesehen.
Wo der Server verfolgt Informationen über jeden Client, und
dann wird das Cookie als eine Möglichkeit der Indizierung in die serverseitige
Datenbank verwendet werden, um zusätzliche Informationen zu extrahieren, um den Benutzer zu validieren.
Jetzt sind die Cookie- und sitzungsbasierten Authentifizierungen nicht skalierbar,
da der Server alle verschiedenen Benutzer verfolgen muss.
Obwohl dies außerhalb des HTTP-Protokolls selbst geschieht,
aber die Tatsache, dass Sie
alle Abschnittinformationen der Server-Site verfolgen müssen, macht es nicht sehr skalierbar.
Hier hat sich die tokenbasierte Authentifizierung als
sehr nützlich erwiesen.
werden wir uns die Token-Basis-Authentifizierung in dieser Vorlesung und
Übung, die folgt, ein wenig detaillierter ansehen.
Wiederum schnell überprüfen Cookies und sitzungsbasierte Authentifizierung.
Bei der Cookie-basierten Authentifizierung
stellen wir fest, dass Cookies auf der Clientseite gespeichert werden und die Cookies
in jeder ausgehenden Anfrage Nachricht enthalten sind, wobei der Server
durch Extrahieren von Informationen aus dem Cookie an diesen bestimmten Client erinnert wird.
Cookie kann zusammen mit Sitzungen verwendet werden, wobei die Cookies die Sitzungs-ID speichern.
Wenn der Server die eingehende Anfrage vom Cookie erhält,
extrahiert er die Session-ID und verwendet diese als Index in den serverseitigen
Sitzungsspeicher, um die Sitzungsinformationen für die bestimmten Kunden.
Nun, dieser Ansatz, wie gesagt,
ist nicht sehr skalierbar, denn wenn Sie Tausende von Sitzungen haben, muss der Server
all diese Tausenden von Sitzungen auf der Serverseite verfolgen.
Obwohl es unabhängig von HTTP in einem Speicher durchgeführt wird,
entweder in einem Dateispeicher oder einer Datenbank.
Die Tatsache, dass Sie alle diese Informationen verfolgen müssen, macht sie jedoch nicht skalierbar.
Um Sie noch einmal daran zu erinnern,
warum sprechen wir über tokenbasierte Authentifizierung? Die
sitzungsbasierte Authentifizierung funktioniert, wie wir bereits gesehen haben, perfekt für
Webanwendungen und kann sich leicht um die Benutzerauthentifizierung kümmern.
Aber dann, sitzungsbasierte Authentifizierung, während es das Prinzip der
zustandslosen Server und führt auch zu Skalierbarkeitsproblemen.
Das zweite Problem ist, dass mobile Anwendungen
sitzungsbasierte Authentifizierungen nicht sehr gut verarbeiten.
In ähnlicher Weise haben mobile Anwendungen es schwer, mit Cookies umzugehen.
In solchen Fällen, in denen Ihr Server Daten
sowohl für eine Webanwendung als auch für eine mobile App bereitstellt.
Dann wird die sitzungsbasierte Authentifizierung nicht sehr nützlich sein, und
hier wird die tokenbasierte Authentifizierung viel einfacher zu verwenden.
Bei einer tokenbasierten Authentifizierung als bestehender Name
wird der Server ein Token an einen validierten Benutzer ausgeben, und alle nachfolgenden
Anfragen, die von der Clientseite kommen, tragen das Token in der Anforderung selbst.
Entweder in Form eines Request-Headers oder im Text der Request-Nachricht.
Darüber hinaus hilft uns die tokenbasierte Authentifizierung auch bei der
Bewältigung der sogenannten CORS- oder CSRF-Probleme.
Cross-Origin Resource Sharing Probleme und so
weiter, ich werde kurz über die Kosten im nächsten Modul sprechen.
Aber im Moment behebt die tokenbasierte Authentifizierung einige der
Probleme, die mit Autos und Cross-Site-Anfragen Fälschung im Zusammenhang mit Fragen.
Nicht nur das, die tokenbasierte Authentifizierung ist für eine
Anwendung viel einfacher, ihre Authentifizierung mit einer anderen Anwendung zu teilen.
Natürlich geschieht dies alles auf sichere Weise.
Aber mit sitzungsbasierter Authentifizierung ist das nicht einfach.
Wie funktioniert die tokenbasierte Authentifizierung?
Bei der tokenbasierten Authentifizierung
muss sich der Benutzer zunächst selbst auf der Serverseite validieren.
Nun könnte diese Validierung die Formen annehmen, die wir zuvor gesehen haben.
So können wir eine lokale Validierung mit Benutzername und Passwort verwenden.
Oder wir können sogar die Validierung von Drittanbietern mit
Technologien wie oauth oder oauth 2.0 oder open ID verwenden.
Wir werden kurz über oauth und oauth 2.0 im nächsten Modul sprechen.
Aber egal auf welche Weise
sich der Benutzer authentifiziert, sobald der Benutzer authentifiziert wurde, kann Ihr Server dem Benutzer einfach ein Token ausgeben.
Und die gesamte nachfolgende Kommunikation zwischen
dem Benutzer und dem Server kann einfach mit diesem Token erfolgen.
JSON Web Token, über das wir sprechen werden, ist ein solches tokenbasiertes
Authentifizierungsschema, und dort Server, wenn es dieses Token erstellt, wird es ein signiertes Token erstellen.
Verwenden eines Geheimnisses auf der Server-Site, das nur der Server kennt.
Selbst wenn ein Dritter in Richtung und zwischen und
versucht, das Token zu manipulieren, selbst wenn er das Token erfasst und
versucht, das Token zu manipulieren, wird das Token ungültig.
Und so ist diese Art, den Benutzer zu schützen,
leicht machbar, alle nachfolgenden Anfragen
von der Client-Seite sollten das Token in der Anfrage tragen,
entweder, wie gesagt, in der Kopfzeile oder im Hauptteil der Anforderungsnachricht.
Wenn der Server dieses Token empfängt, überprüft der Server das Token,
um sicherzustellen, dass es sich um ein gültiges Token handelt. Wenn es sich um ein gültiges Token handelt,
antwortet der Server dann auf die eingehende Anforderung.
Wie ich bereits erwähnt habe, ist JSON Web Tokens ein solches tokenbasiertes Authentifizierungsschema.
JSON Web Token, ist eine sehr einfache Möglichkeit,
Informationen in einem Token zu codieren und sie dann an die Client-Site zu übergeben.
JSON Web Token selbst basiert auf Standards,
dies basiert auf dem IETF RFC 7519.
IETF steht hier für die Internet Engineering Task Force.
Die Organisation, die alles über die Funktionsweise des Internets vorschreibt
und sich mit den Protokollen und den Richtlinien befasst, die mit dem Internet zusammenhängen.
Der RFC steht für das Normendokument,
in IETF Begriffen steht RFC für Request for Comments.
Und jedes solche Normendokument trägt eine Zahl.
7519 bezieht sich in diesem Fall auf das Dokument,
das Standarddokument im Zusammenhang mit JSON Web Token.
Das JSON Web Token selbst ist ein eigenständiges Token, es trägt alle
Informationen in sich selbst, die notwendig sind, um den Benutzer zu identifizieren.
Nicht nur das, ein JSON-Web-Token kann zwischen zwei Anwendungen gemeinsam genutzt werden.
So
kann beispielsweise eine Anwendung, wenn sie authentifiziert und dann ein JSON-Web-Token erhält, dieses JSON-Web-Token an und in dieser Anwendung übergeben,
das sie bereit ist, für den Zugriff auf den Server in ihrem Namen zu autorisieren.
Diese Freigabe des Token erfolgt auf eine sehr sichere Weise,
also machen Sie sich keine Sorgen um die Sicherheit dort.
Dies ist nicht auf eine sichere Weise,
wobei durch die gemeinsame Nutzung des Tokens zwischen einer Anwendung zu einer anderen.
Dabei wird die Autorisierung auf eine zweite Anwendung übertragen, und
die zweite Anwendung kann im Auftrag der ersten Anwendung die
Kommunikation mit dem Server autorisieren.
Dies ist mit Token möglich.
Jetzt wird sich der Ingenieur in Ihnen offensichtlich fragen, was genau
in einem JSON Web Token ist und wie ist es nützlich?
Ein JSON-Web-Token ist, wie gesagt, in eine lange Zeichenfolge codiert und
diese Zeichenfolge selbst kann als bestehend aus drei Teilen interpretiert werden.
Die Zeichenfolge selbst kann, oder die codierte Zeichenfolge selbst enthält drei Teile,
den Header, die Payload und die Signatur.
Das enthält genügend Informationen darüber, wie dieses Token codiert ist.
Der Header selbst enthält den spezifischen Algorithmus, der zum
Codieren dieses JSON-Web-Token verwendet wird, und den Typ des Tokens selbst.
Der Algorithmus in diesem Fall wäre HS256, das ein 256-Bit-Codierungsschema
ist, das zum Hashing der Informationen innerhalb des Tokens verwendet wird.
Und in diesem Fall ist dies das JSON Web Token, und so
wird das Typfeld auf JWT gesetzt.
Und das sind die Informationen, die im Header von JSON Web Token gespeichert sind.
Die Payload selbst, enthält Informationen, die Ihnen helfen, den Benutzer zu identifizieren.
In der Übung, die wir tun werden,
trägt die Stundennutzlast nur die ID des Benutzers innerhalb der Nutzlast.
Es sind keine weiteren Informationen erforderlich.
Diese ID kann serverseitig verwendet werden,
um in die Mongo DB zu indizieren, um bei Bedarf die vollständigen Benutzerinformationen abzurufen.
Sie werden also sehen, dass wir die ID codieren und
sie dann in der Nutzlast dieser Nachricht speichern. Bei
Bedarf können Sie zusätzliche Informationen in der Nutzlast der Nachricht speichern.
Aber je mehr Informationen Sie dort gespeichert haben,
desto größer wird das entsprechende JSON Web Token zu mir.
Versuchen Sie also, die Menge an Informationen zu begrenzen, die Sie in der Nutzlast
des JSON Web Token gespeichert haben.
Wie wir in der Übung sehen werden, haben wir ein Knotenmodul, das es uns ermöglicht,
ein JSON-Web-Token zu codieren und
zu erstellen, basierend auf den Informationen, die wir in die Nutzlast einfügen möchten.
Wenn Sie nun ein JSON-Web-Token erstellen, geben Sie auch eine Signatur an.
Ein geheimer Schlüssel auf der Serverseite, der für die Codierung dieses JSON-Web-Token verwendet wird,
und dieses Geheimnis ist auch im Signaturteil des JSON-Web-Token enthalten.
Die Signatur selbst ist so enthalten, dass
vor codiertem Header und Payload Grundlagen vorhanden sind,
die dann mit dem spezifischen Geheimnis codiert wird, das vom Server verwendet wird.
Und dies codierte, wie ich sagte, die HMAC,
dass wir in einer der vorherigen Lektionen und
mit dem 256 Bit Hashing bezeichnet haben, und das ist in der Signatur enthalten.
Wenn also dieses JSON-Web-Token auf der Serverseite empfangen wird und
der Server dieses Token dekodiert, kann der Server eine Kreuzprüfung durchführen, um
sicherzustellen, dass dieses JSON-Web-Token von niemandem manipuliert wurde,
während das Token zwischen dem Client und der Server-Site übergeben wird.
Wenn Sie also etwas über Sicherheit und Eindringlinge
usw. wissen, verstehen Sie, warum es wichtig ist, das Token zu codieren und die
Authentizität des Tokens auf der Serversite zu überprüfen.
Wie bereits erwähnt, wenn Sie sich mit JSON Web Token in Ihrer Knotenanwendung beschäftigen müssen.
Es gibt ein spezifisches Knotenmodul namens jsonwebtoken Node Module.
Dieses Knotenmodul implementiert die JSON Web Token bezogenen Standards und
kann in Ihre Knotenanwendung aufgenommen werden.
Dieses Modul selbst bietet eine Methode namens sign, mit der Sie das
Token von der Serverseite an den Client signieren und ausgeben können.
Es enthält auch eine Verifizierungsmethode.
Welche verwendet werden kann, um die Authentizität zu überprüfen oder
um die Authentizität des eingehenden JSON-Web-Token zu gewährleisten,
so dass wir in unserer Übung das JSON-Web-Token-Modul verwenden.
Zusammen mit dem JSON Web Token Modul
haben wir auch das Passport-JWT Modul Knotenmodul verwendet.
Das bietet die jwt-basierten Strategien für unser Pass-Authentifizierungsmodul.
Dies bietet also eine Passstrategie für die Authentifizierung mit JSON Web Token.
Dies ermöglicht es Ihnen, RESTful-Endpunkt mit dem JWT als Methode für
die Überprüfung zu authentifizieren, ohne dass der Server Sitzungen verwenden muss.
Jetzt
unterstützt das JWT Passport-Modul eine Methode, das sogar das JWT-Token aus
der eingehenden Anforderungsnachricht zu extrahieren und dann sogar das Token in Ihrem Namen zu verifizieren.
Das Passport-JWT-Modul intern, verwendet das JSON Web Token Modul
für die Überprüfung dieses JSON Web Token.
Das Token selbst kann im Header der eingehenden Anfrage,
im Header, sogar im Authentifizierungskopf der eingehenden Anfrage, getragen
werden, was wir in der Übung tun werden.
Das Token kann auch im Körper der eingehenden Anfrage getragen werden. In diesem Fall
müssen wir das Token aus dem Körper der eingehenden Anfrage extrahieren und
es dann verwenden.
Das Passport-JWT-Modul unterstützt dies auch, wenn Sie dies
als Methode verwenden, um das Token vom Client an die Server-Site zurückzugeben.
Das JSON Web Token, kann auch in den URL-Abfrageparametern enthalten sein, wenn Sie so
wählen, und kann von dort b Passport-JWT extrahiert und
für die Authentifizierung verwendet werden.
Nun, mit diesem schnellen Verständnis von JSON Web Tokens und
wie sie nützlich sind, werden wir zu der Übung übergehen, in der wir
das Passport-JWT-Modul zusammen mit dem JSON Web Token-Modul verwenden
und unseren Express Rest API-Server für die Verwendung von JSON Web Tokens konfigurieren.
( MUSIK)