1
00:00:00,930 --> 00:00:03,210
‫Kursleiter: Wir haben also unser

2
00:00:03,210 --> 00:00:06,440
‫Benutzermodell eingerichtet, um Benutzer mit sicheren Passwörtern zu speichern.

3
00:00:06,440 --> 00:00:08,850
‫Als nächstes werden wir

4
00:00:08,850 --> 00:00:11,670
‫die Benutzerauthentifizierung und -autorisierung wirklich implementieren.

5
00:00:11,670 --> 00:00:14,230
‫Einfach ausgedrückt, der gesamte Arbeitsablauf der

6
00:00:14,230 --> 00:00:16,530
‫Anmeldung von Benutzern und

7
00:00:16,530 --> 00:00:19,360
‫der Interaktion mit bestimmten geschützten Ressourcen, auf

8
00:00:19,360 --> 00:00:22,163
‫die nicht angemeldete Benutzer keinen Zugriff haben.

9
00:00:23,100 --> 00:00:26,050
‫Es gibt viele Authentifizierungsmethoden, aber die

10
00:00:26,050 --> 00:00:29,360
‫eine, die wir verwenden werden, ist ein sehr

11
00:00:29,360 --> 00:00:34,360
‫moderner, einfacher und sicherer Ansatz namens Json Web Tokens oder kurz JWT.

12
00:00:35,170 --> 00:00:38,100
‫Json Web Tokens sind also eine zustandslose Lösung

13
00:00:38,100 --> 00:00:39,500
‫für die Authentifizierung.

14
00:00:39,500 --> 00:00:43,410
‫Es ist also nicht erforderlich, einen Sitzungsstatus auf dem Server

15
00:00:43,410 --> 00:00:47,360
‫zu speichern, was natürlich perfekt für ruhige APIs wie diejenige ist,

16
00:00:47,360 --> 00:00:48,580
‫die wir erstellen.

17
00:00:48,580 --> 00:00:53,080
‫Denken Sie daran, dass Restful APIs immer zustandslos sein sollten.

18
00:00:53,080 --> 00:00:56,300
‫Und die am weitesten verbreitete Alternative zur Authentifizierung mit

19
00:00:56,300 --> 00:01:00,240
‫JWTs besteht darin, den Anmeldestatus des Benutzers mithilfe von Sitzungen einfach

20
00:01:00,240 --> 00:01:02,420
‫auf dem Server zu speichern.

21
00:01:02,420 --> 00:01:05,150
‫Aber dann folgt natürlich nicht der

22
00:01:05,150 --> 00:01:08,700
‫Grundsatz, dass Restful APIs zustandslos sein sollten und

23
00:01:08,700 --> 00:01:12,293
‫deshalb entscheiden wir uns für eine Lösung wie JWTs.

24
00:01:13,130 --> 00:01:15,960
‫Schauen wir uns nun an, wie die Authentifizierung

25
00:01:15,960 --> 00:01:18,660
‫mit Json Web Tokens tatsächlich funktioniert.

26
00:01:18,660 --> 00:01:21,600
‫Und vorausgesetzt, wir haben bereits einen registrierten Benutzer

27
00:01:21,600 --> 00:01:25,380
‫in unserer Datenbank, so meldet sich ein Benutzer in der App an.

28
00:01:25,380 --> 00:01:28,700
‫Der Client des Benutzers beginnt also mit einer

29
00:01:28,700 --> 00:01:32,330
‫Postanfrage mit dem Benutzernamen oder der E-Mail und dem Passwort.

30
00:01:32,330 --> 00:01:35,400
‫Die Anwendung prüft dann, ob der Benutzer existiert und

31
00:01:35,400 --> 00:01:37,430
‫ob das Passwort korrekt ist.

32
00:01:37,430 --> 00:01:40,340
‫Und wenn dies der Fall ist, wird ein eindeutiger

33
00:01:40,340 --> 00:01:44,010
‫Json Web Token nur für diesen Benutzer mithilfe einer geheimen Zeichenfolge erstellt,

34
00:01:44,010 --> 00:01:46,290
‫die auf einem Server gespeichert ist.

35
00:01:46,290 --> 00:01:49,410
‫Und ein JWT selbst ist eigentlich nur ein String,

36
00:01:49,410 --> 00:01:51,150
‫der ungefähr so aussieht.

37
00:01:51,150 --> 00:01:54,170
‫Aber wir werden auf der nächsten Folie mehr über

38
00:01:54,170 --> 00:01:55,770
‫das JWT selbst sprechen.

39
00:01:55,770 --> 00:02:00,440
‫Wie auch immer, der Server sendet dieses JWT dann zurück an den Client, der

40
00:02:00,440 --> 00:02:04,160
‫es entweder in einem Cookie oder in einem lokalen Speicher speichert.

41
00:02:04,160 --> 00:02:06,930
‫Und so wird der Benutzer authentifiziert und

42
00:02:06,930 --> 00:02:09,570
‫im Grunde in unsere Anwendung eingeloggt,

43
00:02:09,570 --> 00:02:12,720
‫ohne einen Zustand auf dem Server zu verlassen.

44
00:02:12,720 --> 00:02:16,310
‫Der Server weiß also tatsächlich nicht, welche Benutzer

45
00:02:16,310 --> 00:02:17,930
‫tatsächlich angemeldet sind.

46
00:02:17,930 --> 00:02:20,960
‫Aber natürlich weiß der Benutzer, dass er eingeloggt

47
00:02:20,960 --> 00:02:25,040
‫ist, weil er ein gültiges Json Web Token besitzt, das ein

48
00:02:25,040 --> 00:02:29,270
‫bisschen wie ein Reisepass ist, um auf geschützte Teile der Anwendung zuzugreifen.

49
00:02:29,270 --> 00:02:32,470
‫Also noch einmal, nur um sicherzustellen, dass Sie die Idee haben.

50
00:02:32,470 --> 00:02:35,330
‫Ein Benutzer ist eingeloggt, sobald er seinen

51
00:02:35,330 --> 00:02:39,720
‫eindeutigen gültigen Json Web Token zurückerhält, der nirgendwo auf dem Server

52
00:02:39,720 --> 00:02:41,030
‫gespeichert ist.

53
00:02:41,030 --> 00:02:44,840
‫Dieser Prozess ist also völlig zustandslos.

54
00:02:44,840 --> 00:02:49,300
‫Jedes Mal, wenn ein Benutzer dann auf eine geschützte Route zugreifen möchte,

55
00:02:49,300 --> 00:02:51,940
‫wie beispielsweise seine Benutzerprofildaten, sendet er

56
00:02:51,940 --> 00:02:55,360
‫seinen Json Web Token zusammen mit einer Anfrage.

57
00:02:55,360 --> 00:02:58,480
‫Es ist also ein bisschen so, als würde man seinen Pass vorzeigen, um

58
00:02:58,480 --> 00:03:00,450
‫Zugang zu dieser Route zu erhalten, oder?

59
00:03:00,450 --> 00:03:03,870
‫Und das ist wahrscheinlich der beste und einfachste Weg, diese

60
00:03:03,870 --> 00:03:05,320
‫ganze Idee zu verstehen.

61
00:03:05,320 --> 00:03:07,910
‫Sobald die Anfrage den Server erreicht,

62
00:03:07,910 --> 00:03:11,140
‫überprüft unsere App, ob das Json Web Token

63
00:03:11,140 --> 00:03:12,580
‫tatsächlich gültig ist.

64
00:03:12,580 --> 00:03:15,760
‫Wenn der Benutzer also wirklich der ist, für den er sich ausgibt.

65
00:03:15,760 --> 00:03:17,710
‫Und mehr darüber, wie dieser Schritt

66
00:03:17,710 --> 00:03:19,660
‫funktioniert, etwas später in diesem Video.

67
00:03:19,660 --> 00:03:22,710
‫Wenn das Token nun tatsächlich gültig ist,

68
00:03:22,710 --> 00:03:26,210
‫werden die angeforderten Daten an den Client gesendet und

69
00:03:26,210 --> 00:03:29,400
‫wenn nicht, wird dem Benutzer eine Fehlermeldung angezeigt,

70
00:03:29,400 --> 00:03:32,600
‫dass er nicht auf diese Ressource zugreifen darf.

71
00:03:32,600 --> 00:03:34,880
‫Und solange der Benutzer eingeloggt ist,

72
00:03:34,880 --> 00:03:38,230
‫funktioniert es jedes Mal, wenn er Daten von einer

73
00:03:38,230 --> 00:03:39,843
‫beliebigen geschützten Route anfordert.

74
00:03:40,840 --> 00:03:43,000
‫Nun ist es sehr

75
00:03:43,000 --> 00:03:47,570
‫wichtig zu beachten, dass all diese Kommunikation über https erfolgen muss.

76
00:03:47,570 --> 00:03:51,510
‫Also sicheres verschlüsseltes http, um zu verhindern, dass

77
00:03:51,510 --> 00:03:55,840
‫jeder auf Passwörter oder Json Web Tokens zugreifen kann.

78
00:03:55,840 --> 00:03:59,090
‫Nur dann haben wir ein wirklich sicheres System.

79
00:03:59,090 --> 00:04:02,430
‫Aber darüber werden wir später in diesem Abschnitt sprechen, okay.

80
00:04:02,430 --> 00:04:05,120
‫Ich weiß also, dass das am Anfang ziemlich

81
00:04:05,120 --> 00:04:06,900
‫verwirrend aussehen kann, wenn

82
00:04:06,900 --> 00:04:09,120
‫man sich das erste Mal darum

83
00:04:09,120 --> 00:04:13,490
‫bemüht, aber eigentlich ist das Prinzip an sich eigentlich ganz einfach, oder?

84
00:04:13,490 --> 00:04:15,830
‫Und das ist wirklich alles,

85
00:04:15,830 --> 00:04:20,370
‫was Sie wissen müssen, um die Authentifizierung mit JWT implementieren zu können.

86
00:04:20,370 --> 00:04:22,740
‫Aber lassen Sie uns nun etwas

87
00:04:22,740 --> 00:04:25,880
‫tiefer in die Funktionsweise des JWT selbst eintauchen.

88
00:04:25,880 --> 00:04:30,310
‫Ein Json Web Token sieht also aus wie der linke Teil dieses Screenshots,

89
00:04:30,310 --> 00:04:35,310
‫der aus dem JWT-Debugger bei jwt stammt. io.

90
00:04:35,940 --> 00:04:38,650
‫Im Wesentlichen handelt es sich also um eine Codierungszeichenfolge,

91
00:04:38,650 --> 00:04:40,430
‫die aus drei Teilen besteht.

92
00:04:40,430 --> 00:04:44,140
‫Der Header, die Payload und die Signatur.

93
00:04:44,140 --> 00:04:47,910
‫Jetzt sind der Header nur einige Metadaten über das Token selbst

94
00:04:47,910 --> 00:04:50,910
‫und die Nutzlast sind die Daten, die wir

95
00:04:50,910 --> 00:04:54,470
‫in das Token codieren können, alle Daten, die wir wirklich wollen.

96
00:04:54,470 --> 00:04:56,690
‫Je mehr Daten wir hier kodieren möchten,

97
00:04:56,690 --> 00:04:58,890
‫desto größer ist das JWT.

98
00:04:58,890 --> 00:05:01,750
‫Wie auch immer, diese beiden Teile sind

99
00:05:01,750 --> 00:05:04,860
‫nur einfacher Text, der verschlüsselt, aber nicht verschlüsselt wird.

100
00:05:04,860 --> 00:05:08,790
‫So kann jeder sie entschlüsseln und lesen.

101
00:05:08,790 --> 00:05:11,730
‫Daher können wir hier keine sensiblen Daten speichern.

102
00:05:11,730 --> 00:05:13,460
‫Aber das ist überhaupt

103
00:05:13,460 --> 00:05:16,580
‫kein Problem, denn im dritten Teil, also in

104
00:05:16,580 --> 00:05:19,370
‫der Signatur, wird es erst richtig spannend.

105
00:05:19,370 --> 00:05:22,990
‫Die Signatur wird aus dem Header, den Payloads und

106
00:05:22,990 --> 00:05:26,020
‫dem auf dem Server gespeicherten Secret erstellt.

107
00:05:26,020 --> 00:05:27,080
‫Erinnere dich daran?

108
00:05:27,080 --> 00:05:28,760
‫Und dieser ganze Prozess wird

109
00:05:28,760 --> 00:05:30,883
‫dann als Signieren des Json Web Token bezeichnet.

110
00:05:31,900 --> 00:05:35,590
‫Auch hier verwendet der Signaturalgorithmus den Header,

111
00:05:35,590 --> 00:05:40,590
‫die Nutzlast und das Geheimnis, um eine eindeutige Signatur zu erstellen.

112
00:05:40,650 --> 00:05:43,200
‫Also nur diese Daten plus das

113
00:05:43,200 --> 00:05:46,160
‫Geheimnis können diese Signatur erstellen, in Ordnung?

114
00:05:46,160 --> 00:05:49,200
‫Diese Signatur bildet dann zusammen mit dem

115
00:05:49,200 --> 00:05:52,310
‫Header und den Payloads das JWT, das

116
00:05:52,310 --> 00:05:55,190
‫dann an den Client gesendet wird.

117
00:05:55,190 --> 00:05:58,320
‫Wie ich bereits auf der ersten Folie kurz erwähnt

118
00:05:58,320 --> 00:06:02,000
‫habe, muss der Server, sobald er ein JWT erhält, um Zugriff

119
00:06:02,000 --> 00:06:05,010
‫auf eine geschützte Route zu gewähren, es überprüfen, um

120
00:06:05,010 --> 00:06:07,730
‫festzustellen, ob der Benutzer wirklich der ist,

121
00:06:07,730 --> 00:06:10,120
‫für den er sich ausgibt, oder?

122
00:06:10,120 --> 00:06:13,890
‫Mit anderen Worten, es wird überprüft, ob niemand den Header

123
00:06:13,890 --> 00:06:16,580
‫und die Nutzdaten des Tokens geändert hat.

124
00:06:16,580 --> 00:06:20,030
‫Auch in diesem Überprüfungsschritt wird überprüft, ob kein

125
00:06:20,030 --> 00:06:23,350
‫Dritter tatsächlich den Header oder die Nutzlast

126
00:06:23,350 --> 00:06:26,280
‫des Json Web Token geändert hat.

127
00:06:26,280 --> 00:06:29,650
‫Wie funktioniert diese Überprüfung eigentlich?

128
00:06:29,650 --> 00:06:32,560
‫Nun, es ist eigentlich ganz einfach.

129
00:06:32,560 --> 00:06:35,410
‫Sobald das JWT empfangen wurde, nimmt die

130
00:06:35,410 --> 00:06:38,920
‫Verifizierung seinen Header und seine Nutzlast und erstellt

131
00:06:38,920 --> 00:06:41,540
‫zusammen mit dem Geheimnis, das

132
00:06:41,540 --> 00:06:45,440
‫noch auf dem Server gespeichert ist, im Grunde eine Testsignatur.

133
00:06:45,440 --> 00:06:48,390
‫Aber die Originalsignatur, die beim

134
00:06:48,390 --> 00:06:53,390
‫Erstellen des JWT generiert wurde, befindet sich noch im Token, oder?

135
00:06:53,930 --> 00:06:56,550
‫Und das ist der Schlüssel für diese Überprüfung.

136
00:06:56,550 --> 00:06:59,180
‫Denn jetzt müssen wir nur

137
00:06:59,180 --> 00:07:02,590
‫noch die Testunterschrift mit der Originalunterschrift vergleichen.

138
00:07:02,590 --> 00:07:05,050
‫Und wenn die Testsignatur mit

139
00:07:05,050 --> 00:07:08,460
‫der Originalsignatur übereinstimmt, bedeutet dies, dass die Nutzdaten

140
00:07:08,460 --> 00:07:11,760
‫und der Header nicht geändert wurden, oder?

141
00:07:11,760 --> 00:07:13,690
‫Denn wenn sie modifiziert

142
00:07:13,690 --> 00:07:16,720
‫worden wären, müsste die Testsignatur anders sein.

143
00:07:16,720 --> 00:07:19,600
‫Daher können wir in diesem Fall, in

144
00:07:19,600 --> 00:07:22,990
‫dem die Daten nicht geändert wurden, den Benutzer authentifizieren.

145
00:07:22,990 --> 00:07:24,940
‫Und wenn sich die

146
00:07:24,940 --> 00:07:27,520
‫beiden Signaturen tatsächlich unterscheiden, bedeutet dies

147
00:07:27,520 --> 00:07:29,870
‫natürlich, dass die Daten manipuliert wurden.

148
00:07:29,870 --> 00:07:32,780
‫Normalerweise durch den Versuch, die Nutzlast zu ändern.

149
00:07:32,780 --> 00:07:35,470
‫Aber dieser Dritte, der die Nutzlast manipuliert,

150
00:07:35,470 --> 00:07:38,750
‫hat natürlich keinen Zugriff auf das Geheimnis, sodass er

151
00:07:38,750 --> 00:07:41,370
‫das JWT nicht signieren kann.

152
00:07:41,370 --> 00:07:44,320
‫Die Originalsignatur wird also niemals den

153
00:07:44,320 --> 00:07:46,050
‫manipulierten Daten entsprechen.

154
00:07:46,050 --> 00:07:49,160
‫Daher wird die Überprüfung in diesem Fall

155
00:07:49,160 --> 00:07:50,700
‫immer fehlschlagen.

156
00:07:50,700 --> 00:07:53,850
‫Und das ist der Schlüssel zum Funktionieren dieses ganzen Systems.

157
00:07:53,850 --> 00:07:57,190
‫Es ist die Magie, die JWT so einfach,

158
00:07:57,190 --> 00:07:59,790
‫aber auch extrem mächtig macht.

159
00:07:59,790 --> 00:08:01,560
‫Lassen Sie mich es also noch einmal zusammenfassen.

160
00:08:01,560 --> 00:08:04,830
‫Ohne das Geheimnis kann niemand die JWT-Daten

161
00:08:04,830 --> 00:08:07,920
‫manipulieren, da er keine gültige Signatur für

162
00:08:07,920 --> 00:08:10,960
‫die neuen Daten erstellen kann.

163
00:08:10,960 --> 00:08:13,570
‫Ich meine, sie könnten die Daten

164
00:08:13,570 --> 00:08:16,870
‫natürlich manipulieren, aber der Überprüfungsschritt wird immer fehlschlagen.

165
00:08:16,870 --> 00:08:19,900
‫Keine Sorge, wir werden diese

166
00:08:19,900 --> 00:08:22,660
‫JWT-Algorithmen nicht selbst implementieren.

167
00:08:22,660 --> 00:08:24,830
‫Sie sind sehr komplex und wir werden

168
00:08:24,830 --> 00:08:27,060
‫hier das Rad nicht neu erfinden, in Ordnung?

169
00:08:27,060 --> 00:08:29,910
‫Aber es ist immer noch sehr wichtig zu verstehen, wie

170
00:08:29,910 --> 00:08:32,110
‫dieser ganze Prozess hinter den Kulissen abläuft.

171
00:08:32,110 --> 00:08:35,570
‫Und ich hoffe, dass dieser Vortrag genau das für Sie getan hat.

172
00:08:35,570 --> 00:08:38,370
‫Aber jetzt gehen wir zur nächsten Vorlesung über, um

173
00:08:38,370 --> 00:08:40,433
‫all dies tatsächlich zu nutzen.