1
00:00:02,200 --> 00:00:08,050
Sekarang penting untuk memahami bagaimana otentikasi bekerja karena jika Anda memiliki latar belakang pengembangan web,

2
00:00:08,050 --> 00:00:12,100
Anda mungkin terbiasa dengan otentikasi yang bekerja sedikit berbeda.

3
00:00:12,100 --> 00:00:17,910
Jadi kami memiliki server, Firebase dalam kasus kami, tetapi itu bisa berupa server apa pun yang kami

4
00:00:17,920 --> 00:00:19,570
ajak bicara dari aplikasi

5
00:00:19,570 --> 00:00:25,330
seluler React Native kami dan ini adalah server yang biasanya juga mengautentikasi kami, sehingga kami dapat mengirim

6
00:00:25,330 --> 00:00:30,030
email dan kata sandi yang dimasukkan pengguna untuk membuat pengguna baru atau untuk

7
00:00:30,040 --> 00:00:32,940
login, jadi kami mengirim data auth ke server.

8
00:00:32,940 --> 00:00:39,880
Sekarang server merespons dengan sesuatu, misalnya dengan kesalahan jika kredensial salah atau dengan respons sukses

9
00:00:39,880 --> 00:00:46,870
jika mereka benar dan dalam aplikasi web tradisional, server kemudian juga akan menyimpan apa yang

10
00:00:46,870 --> 00:00:53,550
disebut sesi di server dan mengembalikannya. kunci sesi ke front-end, jadi untuk browser misalnya

11
00:00:53,560 --> 00:00:59,620
yang pada dasarnya memungkinkan browser untuk mengetahui bahwa pengguna yang menggunakan aplikasi

12
00:00:59,620 --> 00:01:02,580
ini di browser ini dikonfirmasi.

13
00:01:02,590 --> 00:01:08,820
Sekarang ini bekerja sedikit berbeda untuk aplikasi seluler karena di sana, Anda berkomunikasi dengan server yang

14
00:01:08,840 --> 00:01:13,640
tidak memiliki kewarganegaraan, misalnya RESTful APIs atau GraphQL APIs dan di sana Anda

15
00:01:13,930 --> 00:01:19,360
tidak benar-benar memiliki sesi karena server tidak peduli dengan masing-masing klien, itu tidak menyimpan

16
00:01:19,420 --> 00:01:23,680
data apa pun tentang apakah Anda diautentikasi atau tidak, Anda malah

17
00:01:24,280 --> 00:01:27,010
bekerja dengan apa yang disebut token.

18
00:01:27,010 --> 00:01:30,780
Idenya tidak terlalu jauh dari ide sesi.

19
00:01:31,030 --> 00:01:36,250
Ketika Anda masuk dan server memeriksa email dan kata sandi dan menentukan bahwa keduanya benar, server membuat

20
00:01:36,850 --> 00:01:38,680
token, menggunakan algoritma tertentu untuk

21
00:01:38,680 --> 00:01:45,430
itu dan menggunakan kunci, kunci pribadi yang hanya diketahui oleh server. Token ini kemudian dikembalikan kepada Anda, jadi ke

22
00:01:45,430 --> 00:01:47,530
aplikasi Anda, misalnya ke

23
00:01:47,530 --> 00:01:53,470
React Native mobile app dan di sana Anda dapat menyimpan token di beberapa penyimpanan,

24
00:01:53,860 --> 00:01:56,010
misalnya di penyimpanan Redux, jadi

25
00:01:56,020 --> 00:02:00,700
dalam memori, kelola dengan Redux di memori sementara Anda aplikasi sedang berjalan.

26
00:02:00,910 --> 00:02:08,260
Sekarang mengapa kita membutuhkan token itu? Untuk satu, selama kami memiliki token itu, kami dapat menentukan di

27
00:02:08,290 --> 00:02:13,780
aplikasi seluler bahwa pengguna mungkin masuk dan karenanya meneruskan pengguna dari layar otentikasi ke layar aplikasi utama

28
00:02:13,780 --> 00:02:19,450
kami dan seterusnya dan ketika pengguna mengklik logout, kami hanya akan menghapus token itu tetapi kita juga

29
00:02:20,110 --> 00:02:25,630
membutuhkan token itu untuk sesuatu yang lain. Di server, seperti yang saya sebutkan,

30
00:02:25,690 --> 00:02:31,600
kami biasanya memiliki sumber daya tertentu, URL tertentu yang hanya terkena pengguna yang masuk, jadi misalnya

31
00:02:31,690 --> 00:02:37,860
di aplikasi kami, membuat produk mungkin bukan sesuatu yang harus dapat dilakukan setiap pengguna dan oleh

32
00:02:37,910 --> 00:02:43,720
karena itu jika Anda ingin mengirim permintaan ke sumber daya yang dilindungi, Anda harus melampirkan

33
00:02:43,720 --> 00:02:50,500
token itu ke permintaan sehingga server yang membuat token dan yang karenanya dapat memeriksa dengan kunci pribadi apakah

34
00:02:50,500 --> 00:02:55,580
token itu valid, sehingga server dapat menentukan apakah Anda memiliki akses atau tidak.

35
00:02:55,660 --> 00:03:02,620
Jika Anda mengirim token yang salah atau token yang tidak valid atau tidak ada token sama sekali, akses akan ditolak dan Anda

36
00:03:02,620 --> 00:03:05,090
mendapatkan kembali kesalahan. Jika Anda memiliki

37
00:03:05,110 --> 00:03:11,050
token yang valid dan lagi server dapat memeriksa apakah token itu valid atau tidak, Anda akan diberikan akses

38
00:03:11,050 --> 00:03:14,970
dan karenanya Anda dapat mengakses sumber daya, menulis data, apa pun itu.

39
00:03:15,070 --> 00:03:17,430
Ini adalah bagaimana otentikasi bekerja dan ini adalah

40
00:03:17,560 --> 00:03:19,560
bagaimana kami akan mengimplementasikannya di sini.

41
00:03:19,570 --> 00:03:25,390
Sekarang hal baiknya adalah Firebase yang kami gunakan sebagai dend backend sudah memiliki semua hal manajemen pengguna pembuatan

42
00:03:25,390 --> 00:03:29,460
token bawaan, jadi kami tidak perlu khawatir tentang itu, kami hanya perlu

43
00:03:29,560 --> 00:03:34,210
mengirim permintaan yang tepat dan kemudian mengelola token itu dan kami baik untuk pergi.