1
00:00:00,000 --> 00:00:04,869
[MUSIK]

2
00:00:04,869 --> 00:00:06,266
In den vorangegangenen Lektionen

3
00:00:06,266 --> 00:00:10,110
haben wir verschiedene Arten von Authentifizierungsschemata gesehen.

4
00:00:10,110 --> 00:00:14,910
Wir begannen mit der grundlegenden Authentifizierung, dann schauten wir uns an, wie wir Cookies für die

5
00:00:14,910 --> 00:00:18,290
Authentifizierung verwenden können, und sogar signierte Cookies, und

6
00:00:18,290 --> 00:00:22,090
danach haben wir uns die sitzungsbasierte Authentifizierung angesehen.

7
00:00:22,090 --> 00:00:27,070
Wo der Server verfolgt Informationen über jeden Client, und

8
00:00:27,070 --> 00:00:30,680
dann wird das Cookie als eine Möglichkeit der Indizierung in die serverseitige

9
00:00:30,680 --> 00:00:35,720
Datenbank verwendet werden, um zusätzliche Informationen zu extrahieren, um den Benutzer zu validieren.

10
00:00:35,720 --> 00:00:41,160
Jetzt sind die Cookie- und sitzungsbasierten Authentifizierungen nicht skalierbar,

11
00:00:41,160 --> 00:00:47,300
da der Server alle verschiedenen Benutzer verfolgen muss.

12
00:00:48,820 --> 00:00:53,120
Obwohl dies außerhalb des HTTP-Protokolls selbst geschieht,

13
00:00:53,120 --> 00:00:56,160
aber die Tatsache, dass Sie

14
00:00:56,160 --> 00:01:00,660
alle Abschnittinformationen der Server-Site verfolgen müssen, macht es nicht sehr skalierbar.

15
00:01:00,660 --> 00:01:04,510
Hier hat sich die tokenbasierte Authentifizierung als

16
00:01:04,510 --> 00:01:06,570
sehr nützlich erwiesen.

17
00:01:06,570 --> 00:01:11,260
werden wir uns die Token-Basis-Authentifizierung in dieser Vorlesung und

18
00:01:11,260 --> 00:01:12,830
Übung, die folgt, ein wenig detaillierter ansehen.

19
00:01:14,680 --> 00:01:18,880
Wiederum schnell überprüfen Cookies und sitzungsbasierte Authentifizierung.

20
00:01:18,880 --> 00:01:20,580
Bei der Cookie-basierten Authentifizierung

21
00:01:20,580 --> 00:01:25,240
stellen wir fest, dass Cookies auf der Clientseite gespeichert werden und die Cookies

22
00:01:25,240 --> 00:01:29,510
in jeder ausgehenden Anfrage Nachricht enthalten sind, wobei der Server

23
00:01:29,510 --> 00:01:35,050
durch Extrahieren von Informationen aus dem Cookie an diesen bestimmten Client erinnert wird.

24
00:01:35,050 --> 00:01:40,550
Cookie kann zusammen mit Sitzungen verwendet werden, wobei die Cookies die Sitzungs-ID speichern.

25
00:01:40,550 --> 00:01:44,650
Wenn der Server die eingehende Anfrage vom Cookie erhält,

26
00:01:44,650 --> 00:01:49,770
extrahiert er die Session-ID und verwendet diese als Index in den serverseitigen

27
00:01:49,770 --> 00:01:55,210
Sitzungsspeicher, um die Sitzungsinformationen für die bestimmten Kunden.

28
00:01:55,210 --> 00:01:56,840
Nun, dieser Ansatz, wie gesagt,

29
00:01:56,840 --> 00:02:01,234
ist nicht sehr skalierbar, denn wenn Sie Tausende von Sitzungen haben, muss der Server

30
00:02:01,234 --> 00:02:04,980
all diese Tausenden von Sitzungen auf der Serverseite verfolgen.

31
00:02:04,980 --> 00:02:10,820
Obwohl es unabhängig von HTTP in einem Speicher durchgeführt wird,

32
00:02:10,820 --> 00:02:14,610
entweder in einem Dateispeicher oder einer Datenbank.

33
00:02:14,610 --> 00:02:19,520
Die Tatsache, dass Sie alle diese Informationen verfolgen müssen, macht sie jedoch nicht skalierbar.

34
00:02:19,520 --> 00:02:23,960
Um Sie noch einmal daran zu erinnern,

35
00:02:23,960 --> 00:02:27,201
warum sprechen wir über tokenbasierte Authentifizierung? Die

36
00:02:27,201 --> 00:02:32,260
sitzungsbasierte Authentifizierung funktioniert, wie wir bereits gesehen haben, perfekt für

37
00:02:32,260 --> 00:02:39,910
Webanwendungen und kann sich leicht um die Benutzerauthentifizierung kümmern.

38
00:02:39,910 --> 00:02:43,660
Aber dann, sitzungsbasierte Authentifizierung, während es das Prinzip der

39
00:02:43,660 --> 00:02:48,280
zustandslosen Server und führt auch zu Skalierbarkeitsproblemen.

40
00:02:48,280 --> 00:02:52,727
Das zweite Problem ist, dass mobile Anwendungen

41
00:02:52,727 --> 00:02:58,090
sitzungsbasierte Authentifizierungen nicht sehr gut verarbeiten.

42
00:02:58,090 --> 00:03:01,742
In ähnlicher Weise haben mobile Anwendungen es schwer, mit Cookies umzugehen.

43
00:03:01,742 --> 00:03:08,048
In solchen Fällen, in denen Ihr Server Daten

44
00:03:08,048 --> 00:03:13,610
sowohl für eine Webanwendung als auch für eine mobile App bereitstellt.

45
00:03:13,610 --> 00:03:19,275
Dann wird die sitzungsbasierte Authentifizierung nicht sehr nützlich sein, und

46
00:03:19,275 --> 00:03:25,139
hier wird die tokenbasierte Authentifizierung viel einfacher zu verwenden.

47
00:03:25,139 --> 00:03:29,369
Bei einer tokenbasierten Authentifizierung als bestehender Name

48
00:03:29,369 --> 00:03:34,589
wird der Server ein Token an einen validierten Benutzer ausgeben, und alle nachfolgenden

49
00:03:34,589 --> 00:03:40,803
Anfragen, die von der Clientseite kommen, tragen das Token in der Anforderung selbst.

50
00:03:40,803 --> 00:03:48,992
Entweder in Form eines Request-Headers oder im Text der Request-Nachricht.

51
00:03:48,992 --> 00:03:53,410
Darüber hinaus hilft uns die tokenbasierte Authentifizierung auch bei der

52
00:03:53,410 --> 00:03:57,965
Bewältigung der sogenannten CORS- oder CSRF-Probleme.

53
00:03:57,965 --> 00:04:00,480
Cross-Origin Resource Sharing Probleme und so

54
00:04:00,480 --> 00:04:04,360
weiter, ich werde kurz über die Kosten im nächsten Modul sprechen.

55
00:04:04,360 --> 00:04:07,540
Aber im Moment behebt die tokenbasierte Authentifizierung einige der

56
00:04:07,540 --> 00:04:13,430
Probleme, die mit Autos und Cross-Site-Anfragen Fälschung im Zusammenhang mit Fragen.

57
00:04:13,430 --> 00:04:17,680
Nicht nur das, die tokenbasierte Authentifizierung ist für eine

58
00:04:17,680 --> 00:04:21,700
Anwendung viel einfacher, ihre Authentifizierung mit einer anderen Anwendung zu teilen.

59
00:04:21,700 --> 00:04:24,610
Natürlich geschieht dies alles auf sichere Weise.

60
00:04:24,610 --> 00:04:28,867
Aber mit sitzungsbasierter Authentifizierung ist das nicht einfach.

61
00:04:28,867 --> 00:04:32,272
Wie funktioniert die tokenbasierte Authentifizierung?

62
00:04:32,272 --> 00:04:34,260
Bei der tokenbasierten Authentifizierung

63
00:04:34,260 --> 00:04:40,020
muss sich der Benutzer zunächst selbst auf der Serverseite validieren.

64
00:04:40,020 --> 00:04:44,040
Nun könnte diese Validierung die Formen annehmen, die wir zuvor gesehen haben.

65
00:04:44,040 --> 00:04:48,519
So können wir eine lokale Validierung mit Benutzername und Passwort verwenden.

66
00:04:48,519 --> 00:04:53,111
Oder wir können sogar die Validierung von Drittanbietern mit

67
00:04:53,111 --> 00:04:58,267
Technologien wie oauth oder oauth 2.0 oder open ID verwenden.

68
00:04:58,267 --> 00:05:03,700
Wir werden kurz über oauth und oauth 2.0 im nächsten Modul sprechen.

69
00:05:03,700 --> 00:05:08,790
Aber egal auf welche Weise

70
00:05:08,790 --> 00:05:14,370
sich der Benutzer authentifiziert, sobald der Benutzer authentifiziert wurde, kann Ihr Server dem Benutzer einfach ein Token ausgeben.

71
00:05:14,370 --> 00:05:18,790
Und die gesamte nachfolgende Kommunikation zwischen

72
00:05:18,790 --> 00:05:23,658
dem Benutzer und dem Server kann einfach mit diesem Token erfolgen.

73
00:05:23,658 --> 00:05:29,240
JSON Web Token, über das wir sprechen werden, ist ein solches tokenbasiertes

74
00:05:29,240 --> 00:05:35,465
Authentifizierungsschema, und dort Server, wenn es dieses Token erstellt, wird es ein signiertes Token erstellen.

75
00:05:35,465 --> 00:05:40,315
Verwenden eines Geheimnisses auf der Server-Site, das nur der Server kennt.

76
00:05:40,315 --> 00:05:43,965
Selbst wenn ein Dritter in Richtung und zwischen und

77
00:05:43,965 --> 00:05:49,185
versucht, das Token zu manipulieren, selbst wenn er das Token erfasst und

78
00:05:49,185 --> 00:05:53,045
versucht, das Token zu manipulieren, wird das Token ungültig.

79
00:05:53,045 --> 00:05:57,201
Und so ist diese Art, den Benutzer zu schützen,

80
00:05:57,201 --> 00:06:02,250
leicht machbar, alle nachfolgenden Anfragen

81
00:06:02,250 --> 00:06:07,430
von der Client-Seite sollten das Token in der Anfrage tragen,

82
00:06:07,430 --> 00:06:11,870
entweder, wie gesagt, in der Kopfzeile oder im Hauptteil der Anforderungsnachricht.

83
00:06:11,870 --> 00:06:16,120
Wenn der Server dieses Token empfängt, überprüft der Server das Token,

84
00:06:16,120 --> 00:06:20,810
um sicherzustellen, dass es sich um ein gültiges Token handelt. Wenn es sich um ein gültiges Token handelt,

85
00:06:20,810 --> 00:06:25,430
antwortet der Server dann auf die eingehende Anforderung.

86
00:06:25,430 --> 00:06:31,210
Wie ich bereits erwähnt habe, ist JSON Web Tokens ein solches tokenbasiertes Authentifizierungsschema.

87
00:06:31,210 --> 00:06:35,838
JSON Web Token, ist eine sehr einfache Möglichkeit,

88
00:06:35,838 --> 00:06:41,174
Informationen in einem Token zu codieren und sie dann an die Client-Site zu übergeben.

89
00:06:41,174 --> 00:06:45,702
JSON Web Token selbst basiert auf Standards,

90
00:06:45,702 --> 00:06:49,670
dies basiert auf dem IETF RFC 7519.

91
00:06:49,670 --> 00:06:53,499
IETF steht hier für die Internet Engineering Task Force.

92
00:06:53,499 --> 00:07:00,011
Die Organisation, die alles über die Funktionsweise des Internets vorschreibt

93
00:07:00,011 --> 00:07:06,427
und sich mit den Protokollen und den Richtlinien befasst, die mit dem Internet zusammenhängen.

94
00:07:06,427 --> 00:07:10,391
Der RFC steht für das Normendokument,

95
00:07:10,391 --> 00:07:15,270
in IETF Begriffen steht RFC für Request for Comments.

96
00:07:15,270 --> 00:07:18,650
Und jedes solche Normendokument trägt eine Zahl.

97
00:07:18,650 --> 00:07:23,560
7519 bezieht sich in diesem Fall auf das Dokument,

98
00:07:23,560 --> 00:07:27,250
das Standarddokument im Zusammenhang mit JSON Web Token.

99
00:07:27,250 --> 00:07:31,420
Das JSON Web Token selbst ist ein eigenständiges Token, es trägt alle

100
00:07:31,420 --> 00:07:37,250
Informationen in sich selbst, die notwendig sind, um den Benutzer zu identifizieren.

101
00:07:37,250 --> 00:07:43,080
Nicht nur das, ein JSON-Web-Token kann zwischen zwei Anwendungen gemeinsam genutzt werden.

102
00:07:43,080 --> 00:07:46,930
So

103
00:07:46,930 --> 00:07:51,760
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,

104
00:07:51,760 --> 00:07:56,950
das sie bereit ist, für den Zugriff auf den Server in ihrem Namen zu autorisieren.

105
00:07:56,950 --> 00:08:00,200
Diese Freigabe des Token erfolgt auf eine sehr sichere Weise,

106
00:08:00,200 --> 00:08:03,460
also machen Sie sich keine Sorgen um die Sicherheit dort.

107
00:08:03,460 --> 00:08:04,990
Dies ist nicht auf eine sichere Weise,

108
00:08:04,990 --> 00:08:09,090
wobei durch die gemeinsame Nutzung des Tokens zwischen einer Anwendung zu einer anderen.

109
00:08:09,090 --> 00:08:13,250
Dabei wird die Autorisierung auf eine zweite Anwendung übertragen, und

110
00:08:13,250 --> 00:08:17,740
die zweite Anwendung kann im Auftrag der ersten Anwendung die

111
00:08:17,740 --> 00:08:18,990
Kommunikation mit dem Server autorisieren.

112
00:08:20,200 --> 00:08:24,200
Dies ist mit Token möglich.

113
00:08:24,200 --> 00:08:28,710
Jetzt wird sich der Ingenieur in Ihnen offensichtlich fragen, was genau

114
00:08:28,710 --> 00:08:32,690
in einem JSON Web Token ist und wie ist es nützlich?

115
00:08:32,690 --> 00:08:39,120
Ein JSON-Web-Token ist, wie gesagt, in eine lange Zeichenfolge codiert und

116
00:08:39,120 --> 00:08:43,530
diese Zeichenfolge selbst kann als bestehend aus drei Teilen interpretiert werden.

117
00:08:43,530 --> 00:08:49,470
Die Zeichenfolge selbst kann, oder die codierte Zeichenfolge selbst enthält drei Teile,

118
00:08:49,470 --> 00:08:52,896
den Header, die Payload und die Signatur.

119
00:08:52,896 --> 00:08:59,070
Das enthält genügend Informationen darüber, wie dieses Token codiert ist.

120
00:08:59,070 --> 00:09:03,780
Der Header selbst enthält den spezifischen Algorithmus, der zum

121
00:09:03,780 --> 00:09:08,460
Codieren dieses JSON-Web-Token verwendet wird, und den Typ des Tokens selbst.

122
00:09:08,460 --> 00:09:16,280
Der Algorithmus in diesem Fall wäre HS256, das ein 256-Bit-Codierungsschema

123
00:09:16,280 --> 00:09:21,140
ist, das zum Hashing der Informationen innerhalb des Tokens verwendet wird.

124
00:09:21,140 --> 00:09:24,350
Und in diesem Fall ist dies das JSON Web Token, und so

125
00:09:24,350 --> 00:09:27,870
wird das Typfeld auf JWT gesetzt.

126
00:09:27,870 --> 00:09:33,210
Und das sind die Informationen, die im Header von JSON Web Token gespeichert sind.

127
00:09:33,210 --> 00:09:38,800
Die Payload selbst, enthält Informationen, die Ihnen helfen, den Benutzer zu identifizieren.

128
00:09:38,800 --> 00:09:41,440
In der Übung, die wir tun werden,

129
00:09:41,440 --> 00:09:46,730
trägt die Stundennutzlast nur die ID des Benutzers innerhalb der Nutzlast.

130
00:09:46,730 --> 00:09:48,720
Es sind keine weiteren Informationen erforderlich.

131
00:09:48,720 --> 00:09:51,690
Diese ID kann serverseitig verwendet werden,

132
00:09:51,690 --> 00:09:58,350
um in die Mongo DB zu indizieren, um bei Bedarf die vollständigen Benutzerinformationen abzurufen.

133
00:09:58,350 --> 00:10:02,050
Sie werden also sehen, dass wir die ID codieren und

134
00:10:02,050 --> 00:10:05,020
sie dann in der Nutzlast dieser Nachricht speichern. Bei

135
00:10:05,020 --> 00:10:09,470
Bedarf können Sie zusätzliche Informationen in der Nutzlast der Nachricht speichern.

136
00:10:09,470 --> 00:10:11,410
Aber je mehr Informationen Sie dort gespeichert haben,

137
00:10:11,410 --> 00:10:15,720
desto größer wird das entsprechende JSON Web Token zu mir.

138
00:10:15,720 --> 00:10:20,010
Versuchen Sie also, die Menge an Informationen zu begrenzen, die Sie in der Nutzlast

139
00:10:20,010 --> 00:10:22,155
des JSON Web Token gespeichert haben.

140
00:10:22,155 --> 00:10:27,545
Wie wir in der Übung sehen werden, haben wir ein Knotenmodul, das es uns ermöglicht,

141
00:10:27,545 --> 00:10:30,875
ein JSON-Web-Token zu codieren und

142
00:10:30,875 --> 00:10:34,395
zu erstellen, basierend auf den Informationen, die wir in die Nutzlast einfügen möchten.

143
00:10:34,395 --> 00:10:38,735
Wenn Sie nun ein JSON-Web-Token erstellen, geben Sie auch eine Signatur an.

144
00:10:38,735 --> 00:10:44,929
Ein geheimer Schlüssel auf der Serverseite, der für die Codierung dieses JSON-Web-Token verwendet wird,

145
00:10:44,929 --> 00:10:51,044
und dieses Geheimnis ist auch im Signaturteil des JSON-Web-Token enthalten.

146
00:10:51,044 --> 00:10:55,232
Die Signatur selbst ist so enthalten, dass

147
00:10:55,232 --> 00:10:58,797
vor codiertem Header und Payload Grundlagen vorhanden sind,

148
00:10:58,797 --> 00:11:04,750
die dann mit dem spezifischen Geheimnis codiert wird, das vom Server verwendet wird.

149
00:11:04,750 --> 00:11:08,644
Und dies codierte, wie ich sagte, die HMAC,

150
00:11:08,644 --> 00:11:14,144
dass wir in einer der vorherigen Lektionen und

151
00:11:14,144 --> 00:11:20,922
mit dem 256 Bit Hashing bezeichnet haben, und das ist in der Signatur enthalten.

152
00:11:20,922 --> 00:11:25,118
Wenn also dieses JSON-Web-Token auf der Serverseite empfangen wird und

153
00:11:25,118 --> 00:11:30,094
der Server dieses Token dekodiert, kann der Server eine Kreuzprüfung durchführen, um

154
00:11:30,094 --> 00:11:34,525
sicherzustellen, dass dieses JSON-Web-Token von niemandem manipuliert wurde,

155
00:11:34,525 --> 00:11:39,460
während das Token zwischen dem Client und der Server-Site übergeben wird.

156
00:11:39,460 --> 00:11:43,020
Wenn Sie also etwas über Sicherheit und Eindringlinge

157
00:11:43,020 --> 00:11:47,670
usw. wissen, verstehen Sie, warum es wichtig ist, das Token zu codieren und die

158
00:11:47,670 --> 00:11:53,250
Authentizität des Tokens auf der Serversite zu überprüfen.

159
00:11:53,250 --> 00:11:58,640
Wie bereits erwähnt, wenn Sie sich mit JSON Web Token in Ihrer Knotenanwendung beschäftigen müssen.

160
00:11:58,640 --> 00:12:02,810
Es gibt ein spezifisches Knotenmodul namens jsonwebtoken Node Module.

161
00:12:02,810 --> 00:12:07,830
Dieses Knotenmodul implementiert die JSON Web Token bezogenen Standards und

162
00:12:07,830 --> 00:12:10,640
kann in Ihre Knotenanwendung aufgenommen werden.

163
00:12:10,640 --> 00:12:15,190
Dieses Modul selbst bietet eine Methode namens sign, mit der Sie das

164
00:12:15,190 --> 00:12:18,910
Token von der Serverseite an den Client signieren und ausgeben können.

165
00:12:18,910 --> 00:12:21,820
Es enthält auch eine Verifizierungsmethode.

166
00:12:21,820 --> 00:12:27,040
Welche verwendet werden kann, um die Authentizität zu überprüfen oder

167
00:12:27,040 --> 00:12:33,380
um die Authentizität des eingehenden JSON-Web-Token zu gewährleisten,

168
00:12:33,380 --> 00:12:38,620
so dass wir in unserer Übung das JSON-Web-Token-Modul verwenden.

169
00:12:38,620 --> 00:12:42,010
Zusammen mit dem JSON Web Token Modul

170
00:12:42,010 --> 00:12:47,450
haben wir auch das Passport-JWT Modul Knotenmodul verwendet.

171
00:12:47,450 --> 00:12:54,547
Das bietet die jwt-basierten Strategien für unser Pass-Authentifizierungsmodul.

172
00:12:54,547 --> 00:12:59,441
Dies bietet also eine Passstrategie für die Authentifizierung mit JSON Web Token.

173
00:12:59,441 --> 00:13:06,153
Dies ermöglicht es Ihnen, RESTful-Endpunkt mit dem JWT als Methode für

174
00:13:06,153 --> 00:13:12,240
die Überprüfung zu authentifizieren, ohne dass der Server Sitzungen verwenden muss.

175
00:13:12,240 --> 00:13:17,300
Jetzt

176
00:13:17,300 --> 00:13:21,710
unterstützt das JWT Passport-Modul eine Methode, das sogar das JWT-Token aus

177
00:13:21,710 --> 00:13:26,970
der eingehenden Anforderungsnachricht zu extrahieren und dann sogar das Token in Ihrem Namen zu verifizieren.

178
00:13:26,970 --> 00:13:31,470
Das Passport-JWT-Modul intern, verwendet das JSON Web Token Modul

179
00:13:31,470 --> 00:13:34,550
für die Überprüfung dieses JSON Web Token.

180
00:13:34,550 --> 00:13:40,300
Das Token selbst kann im Header der eingehenden Anfrage,

181
00:13:40,300 --> 00:13:44,350
im Header, sogar im Authentifizierungskopf der eingehenden Anfrage, getragen

182
00:13:44,350 --> 00:13:46,940
werden, was wir in der Übung tun werden.

183
00:13:46,940 --> 00:13:51,420
Das Token kann auch im Körper der eingehenden Anfrage getragen werden. In diesem Fall

184
00:13:51,420 --> 00:13:54,610
müssen wir das Token aus dem Körper der eingehenden Anfrage extrahieren und

185
00:13:54,610 --> 00:13:56,352
es dann verwenden.

186
00:13:56,352 --> 00:14:01,170
Das Passport-JWT-Modul unterstützt dies auch, wenn Sie dies

187
00:14:01,170 --> 00:14:06,580
als Methode verwenden, um das Token vom Client an die Server-Site zurückzugeben.

188
00:14:06,580 --> 00:14:11,600
Das JSON Web Token, kann auch in den URL-Abfrageparametern enthalten sein, wenn Sie so

189
00:14:11,600 --> 00:14:16,440
wählen, und kann von dort b Passport-JWT extrahiert und

190
00:14:16,440 --> 00:14:18,370
für die Authentifizierung verwendet werden.

191
00:14:18,370 --> 00:14:22,783
Nun, mit diesem schnellen Verständnis von JSON Web Tokens und

192
00:14:22,783 --> 00:14:27,915
wie sie nützlich sind, werden wir zu der Übung übergehen, in der wir

193
00:14:27,915 --> 00:14:33,230
das Passport-JWT-Modul zusammen mit dem JSON Web Token-Modul verwenden

194
00:14:33,230 --> 00:14:38,211
und unseren Express Rest API-Server für die Verwendung von JSON Web Tokens konfigurieren.

195
00:14:38,211 --> 00:14:41,589
( MUSIK)