1
00:00:00,930 --> 00:00:03,210
‫Instruktur: Jadi kami telah menyiapkan model

2
00:00:03,210 --> 00:00:06,440
‫pengguna kami untuk menyelamatkan pengguna dengan kata sandi yang aman.

3
00:00:06,440 --> 00:00:08,850
‫Dan selanjutnya, kita akan

4
00:00:08,850 --> 00:00:11,670
‫benar-benar menerapkan otentikasi dan otorisasi pengguna.

5
00:00:11,670 --> 00:00:14,230
‫Jadi secara sederhana, seluruh alur kerja pengguna

6
00:00:14,230 --> 00:00:16,530
‫yang masuk dan memungkinkan mereka untuk

7
00:00:16,530 --> 00:00:19,360
‫berinteraksi dengan sumber daya tertentu yang dilindungi yang

8
00:00:19,360 --> 00:00:22,163
‫tidak dapat diakses oleh pengguna yang tidak masuk.

9
00:00:23,100 --> 00:00:26,050
‫Sekarang ada banyak metode otentikasi di luar

10
00:00:26,050 --> 00:00:29,360
‫sana, tetapi yang akan kita gunakan adalah pendekatan yang

11
00:00:29,360 --> 00:00:34,360
‫sangat modern, sederhana dan aman yang disebut Json Web Tokens atau disingkat JWT.

12
00:00:35,170 --> 00:00:38,100
‫Jadi Json Web Tokens adalah solusi tanpa

13
00:00:38,100 --> 00:00:39,500
‫kewarganegaraan untuk otentikasi.

14
00:00:39,500 --> 00:00:43,410
‫Jadi tidak perlu menyimpan status sesi apa pun di server

15
00:00:43,410 --> 00:00:47,360
‫yang tentu saja sempurna untuk API yang tenang seperti yang sedang

16
00:00:47,360 --> 00:00:48,580
‫kita bangun.

17
00:00:48,580 --> 00:00:53,080
‫Karena ingat, API yang tenang harus selalu tanpa kewarganegaraan.

18
00:00:53,080 --> 00:00:56,300
‫Dan alternatif yang paling banyak digunakan untuk otentikasi

19
00:00:56,300 --> 00:01:00,240
‫dengan JWT adalah dengan hanya menyimpan status masuk pengguna

20
00:01:00,240 --> 00:01:02,420
‫di server menggunakan sesi.

21
00:01:02,420 --> 00:01:05,150
‫Tapi tentu saja tidak mengikuti prinsip

22
00:01:05,150 --> 00:01:08,700
‫yang mengatakan bahwa API yang tenang harus tanpa

23
00:01:08,700 --> 00:01:12,293
‫kewarganegaraan dan itulah mengapa kami memilih solusi seperti JWT.

24
00:01:13,130 --> 00:01:15,960
‫Jadi sekarang mari kita lihat bagaimana otentikasi

25
00:01:15,960 --> 00:01:18,660
‫benar-benar bekerja dengan Json Web Tokens.

26
00:01:18,660 --> 00:01:21,600
‫Dan dengan asumsi kita sudah memiliki pengguna

27
00:01:21,600 --> 00:01:25,380
‫terdaftar di database kita, beginilah cara pengguna masuk ke aplikasi.

28
00:01:25,380 --> 00:01:28,700
‫Jadi klien pengguna mulai dengan membuat permintaan

29
00:01:28,700 --> 00:01:32,330
‫posting dengan nama pengguna atau email dan kata sandi.

30
00:01:32,330 --> 00:01:35,400
‫Aplikasi kemudian memeriksa apakah pengguna ada dan

31
00:01:35,400 --> 00:01:37,430
‫apakah kata sandinya benar.

32
00:01:37,430 --> 00:01:40,340
‫Dan jika demikian, Token Web Json unik

33
00:01:40,340 --> 00:01:44,010
‫hanya untuk pengguna tersebut dibuat menggunakan string rahasia

34
00:01:44,010 --> 00:01:46,290
‫yang disimpan di server.

35
00:01:46,290 --> 00:01:49,410
‫Dan JWT itu sendiri sebenarnya hanyalah sebuah string

36
00:01:49,410 --> 00:01:51,150
‫yang terlihat seperti ini.

37
00:01:51,150 --> 00:01:54,170
‫Tapi kita akan berbicara lebih banyak tentang JWT itu

38
00:01:54,170 --> 00:01:55,770
‫sendiri di slide berikutnya.

39
00:01:55,770 --> 00:02:00,440
‫Bagaimanapun, server kemudian mengirimkan JWT itu kembali ke klien yang akan

40
00:02:00,440 --> 00:02:04,160
‫menyimpannya di cookie atau di penyimpanan lokal.

41
00:02:04,160 --> 00:02:06,930
‫Dan seperti ini, pengguna diautentikasi dan pada

42
00:02:06,930 --> 00:02:09,570
‫dasarnya masuk ke aplikasi kami

43
00:02:09,570 --> 00:02:12,720
‫tanpa meninggalkan status apa pun di server.

44
00:02:12,720 --> 00:02:16,310
‫Jadi server sebenarnya tidak tahu pengguna mana

45
00:02:16,310 --> 00:02:17,930
‫yang sebenarnya login.

46
00:02:17,930 --> 00:02:20,960
‫Tapi tentu saja, pengguna tahu bahwa

47
00:02:20,960 --> 00:02:25,040
‫dia masuk karena dia memiliki Token Web Json yang valid

48
00:02:25,040 --> 00:02:29,270
‫yang agak mirip paspor untuk mengakses bagian aplikasi yang dilindungi.

49
00:02:29,270 --> 00:02:32,470
‫Jadi sekali lagi, hanya untuk memastikan Anda mendapatkan ide.

50
00:02:32,470 --> 00:02:35,330
‫Seorang pengguna masuk segera setelah dia mendapatkan

51
00:02:35,330 --> 00:02:39,720
‫kembali Token Web Json uniknya yang valid yang tidak disimpan di mana

52
00:02:39,720 --> 00:02:41,030
‫pun di server.

53
00:02:41,030 --> 00:02:44,840
‫Dan karena itu proses ini sama sekali tanpa kewarganegaraan.

54
00:02:44,840 --> 00:02:49,300
‫Kemudian, setiap kali pengguna ingin mengakses rute yang dilindungi, seperti

55
00:02:49,300 --> 00:02:51,940
‫data profil pengguna, misalnya, ia

56
00:02:51,940 --> 00:02:55,360
‫mengirimkan Token Web Json-nya bersama dengan permintaan.

57
00:02:55,360 --> 00:02:58,480
‫Jadi itu seperti menunjukkan paspornya untuk mendapatkan akses

58
00:02:58,480 --> 00:03:00,450
‫ke rute itu, bukan?

59
00:03:00,450 --> 00:03:03,870
‫Dan itu mungkin cara terbaik dan termudah untuk memahami

60
00:03:03,870 --> 00:03:05,320
‫seluruh gagasan ini.

61
00:03:05,320 --> 00:03:07,910
‫Sekarang setelah permintaan mengenai server, aplikasi

62
00:03:07,910 --> 00:03:11,140
‫kami kemudian akan memverifikasi apakah Token Web Json

63
00:03:11,140 --> 00:03:12,580
‫benar-benar valid.

64
00:03:12,580 --> 00:03:15,760
‫Jadi jika pengguna benar-benar seperti yang dia katakan.

65
00:03:15,760 --> 00:03:17,710
‫Dan lebih lanjut tentang cara kerja

66
00:03:17,710 --> 00:03:19,660
‫langkah ini nanti di video ini.

67
00:03:19,660 --> 00:03:22,710
‫Nah jika token tersebut benar-benar valid, maka

68
00:03:22,710 --> 00:03:26,210
‫data yang diminta akan dikirim ke client dan jika

69
00:03:26,210 --> 00:03:29,400
‫tidak, maka akan ada error yang memberitahu user

70
00:03:29,400 --> 00:03:32,600
‫bahwa dia tidak diperbolehkan untuk mengakses resource tersebut.

71
00:03:32,600 --> 00:03:34,880
‫Dan selama pengguna masuk, beginilah

72
00:03:34,880 --> 00:03:38,230
‫cara kerjanya setiap kali dia meminta data dari

73
00:03:38,230 --> 00:03:39,843
‫rute yang dilindungi.

74
00:03:40,840 --> 00:03:43,000
‫Sekarang yang sangat penting untuk

75
00:03:43,000 --> 00:03:47,570
‫diperhatikan di sini adalah bahwa semua komunikasi ini harus terjadi melalui https.

76
00:03:47,570 --> 00:03:51,510
‫Jadi amankan http terenkripsi untuk mencegah siapa pun

77
00:03:51,510 --> 00:03:55,840
‫bisa mendapatkan akses ke kata sandi atau Token Web Json.

78
00:03:55,840 --> 00:03:59,090
‫Hanya dengan begitu kita memiliki sistem yang benar-benar aman.

79
00:03:59,090 --> 00:04:02,430
‫Tapi kita akan membicarakannya nanti di bagian ini, oke.

80
00:04:02,430 --> 00:04:05,120
‫Jadi saya tahu bahwa ini bisa terlihat

81
00:04:05,120 --> 00:04:06,900
‫cukup membingungkan pada awalnya

82
00:04:06,900 --> 00:04:09,120
‫ketika Anda pertama kali mencoba

83
00:04:09,120 --> 00:04:13,490
‫untuk membungkus kepala Anda, tetapi sebenarnya prinsipnya sendiri sebenarnya cukup sederhana, oke?

84
00:04:13,490 --> 00:04:15,830
‫Dan hanya ini yang

85
00:04:15,830 --> 00:04:20,370
‫perlu Anda ketahui agar dapat menerapkan otentikasi menggunakan JWT.

86
00:04:20,370 --> 00:04:22,740
‫Tapi sekarang mari selami sedikit

87
00:04:22,740 --> 00:04:25,880
‫lebih dalam tentang bagaimana sebenarnya JWT itu bekerja.

88
00:04:25,880 --> 00:04:30,310
‫Jadi Token Web Json terlihat seperti bagian kiri dari tangkapan layar ini yang

89
00:04:30,310 --> 00:04:35,310
‫diambil dari debugger JWT di jwt. saya

90
00:04:35,940 --> 00:04:38,650
‫Jadi pada dasarnya, ini adalah string penyandian yang

91
00:04:38,650 --> 00:04:40,430
‫terdiri dari tiga bagian.

92
00:04:40,430 --> 00:04:44,140
‫Header, payload, dan tanda tangan.

93
00:04:44,140 --> 00:04:47,910
‫Sekarang header hanyalah beberapa metadata tentang token itu sendiri dan

94
00:04:47,910 --> 00:04:50,910
‫payload adalah data yang dapat kita encode

95
00:04:50,910 --> 00:04:54,470
‫ke dalam token, data apa pun yang benar-benar kita inginkan.

96
00:04:54,470 --> 00:04:56,690
‫Jadi semakin banyak data yang ingin kita

97
00:04:56,690 --> 00:04:58,890
‫encode di sini, semakin besar JWT.

98
00:04:58,890 --> 00:05:01,750
‫Bagaimanapun, kedua bagian ini hanyalah teks

99
00:05:01,750 --> 00:05:04,860
‫biasa yang akan dikodekan, tetapi tidak dienkripsi.

100
00:05:04,860 --> 00:05:08,790
‫Jadi siapa pun akan dapat memecahkan kode dan membacanya.

101
00:05:08,790 --> 00:05:11,730
‫Jadi kami tidak dapat menyimpan data sensitif apa pun di sini.

102
00:05:11,730 --> 00:05:13,460
‫Tapi itu tidak masalah

103
00:05:13,460 --> 00:05:16,580
‫sama sekali karena di bagian ketiga, jadi di

104
00:05:16,580 --> 00:05:19,370
‫tanda tangan, adalah tempat yang benar-benar menarik.

105
00:05:19,370 --> 00:05:22,990
‫Tanda tangan dibuat menggunakan header, payload, dan

106
00:05:22,990 --> 00:05:26,020
‫rahasia yang disimpan di server.

107
00:05:26,020 --> 00:05:27,080
‫Ingat bahwa?

108
00:05:27,080 --> 00:05:28,760
‫Dan seluruh proses ini

109
00:05:28,760 --> 00:05:30,883
‫kemudian disebut menandatangani Json Web Token.

110
00:05:31,900 --> 00:05:35,590
‫Jadi sekali lagi, algoritma penandatanganan mengambil

111
00:05:35,590 --> 00:05:40,590
‫header, payload, dan rahasia untuk membuat tanda tangan yang unik.

112
00:05:40,650 --> 00:05:43,200
‫Jadi hanya data ini plus rahasia

113
00:05:43,200 --> 00:05:46,160
‫yang bisa membuat tanda tangan ini, oke?

114
00:05:46,160 --> 00:05:49,200
‫Kemudian bersama dengan header dan payload,

115
00:05:49,200 --> 00:05:52,310
‫tanda tangan ini membentuk JWT, yang

116
00:05:52,310 --> 00:05:55,190
‫kemudian dikirim ke klien.

117
00:05:55,190 --> 00:05:58,320
‫Sekarang seperti yang saya sebutkan secara singkat, tepat

118
00:05:58,320 --> 00:06:02,000
‫di slide pertama, setelah server menerima JWT untuk memberikan

119
00:06:02,000 --> 00:06:05,010
‫akses ke rute yang dilindungi, itu perlu

120
00:06:05,010 --> 00:06:07,730
‫memverifikasinya untuk menentukan apakah pengguna benar-benar

121
00:06:07,730 --> 00:06:10,120
‫seperti yang dia klaim, bukan?

122
00:06:10,120 --> 00:06:13,890
‫Dengan kata lain, ini akan memverifikasi jika tidak ada yang

123
00:06:13,890 --> 00:06:16,580
‫mengubah header dan data payload token.

124
00:06:16,580 --> 00:06:20,030
‫Jadi sekali lagi, langkah verifikasi ini akan memeriksa

125
00:06:20,030 --> 00:06:23,350
‫apakah tidak ada pihak ketiga yang benar-benar mengubah

126
00:06:23,350 --> 00:06:26,280
‫header atau muatan Json Web Token.

127
00:06:26,280 --> 00:06:29,650
‫Jadi, bagaimana sebenarnya verifikasi ini bekerja?

128
00:06:29,650 --> 00:06:32,560
‫Yah itu sebenarnya cukup mudah.

129
00:06:32,560 --> 00:06:35,410
‫Jadi begitu JWT diterima, verifikasi akan

130
00:06:35,410 --> 00:06:38,920
‫mengambil header dan payloadnya dan bersama dengan

131
00:06:38,920 --> 00:06:41,540
‫rahasia yang masih tersimpan

132
00:06:41,540 --> 00:06:45,440
‫di server, pada dasarnya membuat tanda tangan uji.

133
00:06:45,440 --> 00:06:48,390
‫Tapi tanda tangan asli yang

134
00:06:48,390 --> 00:06:53,390
‫dihasilkan saat JWT pertama kali dibuat masih dalam token, kan?

135
00:06:53,930 --> 00:06:56,550
‫Dan itulah kunci untuk verifikasi ini.

136
00:06:56,550 --> 00:06:59,180
‫Karena sekarang yang harus kita lakukan

137
00:06:59,180 --> 00:07:02,590
‫adalah membandingkan tanda tangan uji dengan tanda tangan asli.

138
00:07:02,590 --> 00:07:05,050
‫Dan jika tanda tangan

139
00:07:05,050 --> 00:07:08,460
‫uji sama dengan tanda tangan asli, berarti

140
00:07:08,460 --> 00:07:11,760
‫payload dan header belum dimodifikasi, bukan?

141
00:07:11,760 --> 00:07:13,690
‫Karena jika sudah

142
00:07:13,690 --> 00:07:16,720
‫dimodifikasi, maka tanda tangan uji harus berbeda.

143
00:07:16,720 --> 00:07:19,600
‫Oleh karena itu dalam hal ini di

144
00:07:19,600 --> 00:07:22,990
‫mana tidak ada perubahan data, kami kemudian dapat mengautentikasi pengguna.

145
00:07:22,990 --> 00:07:24,940
‫Dan tentu saja, jika

146
00:07:24,940 --> 00:07:27,520
‫kedua tanda tangan itu benar-benar berbeda, ya

147
00:07:27,520 --> 00:07:29,870
‫berarti ada orang yang merusak datanya.

148
00:07:29,870 --> 00:07:32,780
‫Biasanya dengan mencoba mengubah payload.

149
00:07:32,780 --> 00:07:35,470
‫Tetapi pihak ketiga yang memanipulasi muatan tersebut

150
00:07:35,470 --> 00:07:38,750
‫tentu saja tidak memiliki akses ke rahasia tersebut, sehingga

151
00:07:38,750 --> 00:07:41,370
‫mereka tidak dapat menandatangani JWT.

152
00:07:41,370 --> 00:07:44,320
‫Jadi tanda tangan asli tidak akan pernah sesuai

153
00:07:44,320 --> 00:07:46,050
‫dengan data yang dimanipulasi.

154
00:07:46,050 --> 00:07:49,160
‫Dan karena itu, verifikasi akan selalu gagal

155
00:07:49,160 --> 00:07:50,700
‫dalam kasus ini.

156
00:07:50,700 --> 00:07:53,850
‫Dan itulah kunci untuk membuat seluruh sistem ini bekerja.

157
00:07:53,850 --> 00:07:57,190
‫Keajaiban itulah yang membuat JWT begitu sederhana,

158
00:07:57,190 --> 00:07:59,790
‫tetapi juga sangat kuat.

159
00:07:59,790 --> 00:08:01,560
‫Jadi izinkan saya merangkumnya lagi.

160
00:08:01,560 --> 00:08:04,830
‫Tanpa rahasia, tidak ada yang dapat memanipulasi data

161
00:08:04,830 --> 00:08:07,920
‫JWT karena mereka tidak dapat membuat tanda

162
00:08:07,920 --> 00:08:10,960
‫tangan yang valid untuk data baru.

163
00:08:10,960 --> 00:08:13,570
‫Maksud saya mereka tentu saja dapat memanipulasi

164
00:08:13,570 --> 00:08:16,870
‫data, tetapi itu akan selalu gagal dalam langkah verifikasi.

165
00:08:16,870 --> 00:08:19,900
‫Sekarang, jangan khawatir, kami tidak akan benar-benar

166
00:08:19,900 --> 00:08:22,660
‫mengimplementasikan algoritma JWT ini sendiri.

167
00:08:22,660 --> 00:08:24,830
‫Mereka sangat kompleks dan kita tidak

168
00:08:24,830 --> 00:08:27,060
‫akan menemukan kembali roda di sini, oke?

169
00:08:27,060 --> 00:08:29,910
‫Tetapi tetap sangat penting untuk benar-benar memahami bagaimana seluruh

170
00:08:29,910 --> 00:08:32,110
‫proses ini bekerja di belakang layar.

171
00:08:32,110 --> 00:08:35,570
‫Dan saya berharap bahwa kuliah ini melakukan hal itu untuk Anda.

172
00:08:35,570 --> 00:08:38,370
‫Tapi sekarang, mari kita beralih ke kuliah berikutnya untuk

173
00:08:38,370 --> 00:08:40,433
‫benar-benar mulai menggunakan semua ini.