Sekarang penting untuk memahami bagaimana otentikasi bekerja karena jika Anda memiliki latar belakang pengembangan web,
Anda mungkin terbiasa dengan otentikasi yang bekerja sedikit berbeda.
Jadi kami memiliki server, Firebase dalam kasus kami, tetapi itu bisa berupa server apa pun yang kami
ajak bicara dari aplikasi
seluler React Native kami dan ini adalah server yang biasanya juga mengautentikasi kami, sehingga kami dapat mengirim
email dan kata sandi yang dimasukkan pengguna untuk membuat pengguna baru atau untuk
login, jadi kami mengirim data auth ke server.
Sekarang server merespons dengan sesuatu, misalnya dengan kesalahan jika kredensial salah atau dengan respons sukses
jika mereka benar dan dalam aplikasi web tradisional, server kemudian juga akan menyimpan apa yang
disebut sesi di server dan mengembalikannya. kunci sesi ke front-end, jadi untuk browser misalnya
yang pada dasarnya memungkinkan browser untuk mengetahui bahwa pengguna yang menggunakan aplikasi
ini di browser ini dikonfirmasi.
Sekarang ini bekerja sedikit berbeda untuk aplikasi seluler karena di sana, Anda berkomunikasi dengan server yang
tidak memiliki kewarganegaraan, misalnya RESTful APIs atau GraphQL APIs dan di sana Anda
tidak benar-benar memiliki sesi karena server tidak peduli dengan masing-masing klien, itu tidak menyimpan
data apa pun tentang apakah Anda diautentikasi atau tidak, Anda malah
bekerja dengan apa yang disebut token.
Idenya tidak terlalu jauh dari ide sesi.
Ketika Anda masuk dan server memeriksa email dan kata sandi dan menentukan bahwa keduanya benar, server membuat
token, menggunakan algoritma tertentu untuk
itu dan menggunakan kunci, kunci pribadi yang hanya diketahui oleh server. Token ini kemudian dikembalikan kepada Anda, jadi ke
aplikasi Anda, misalnya ke
React Native mobile app dan di sana Anda dapat menyimpan token di beberapa penyimpanan,
misalnya di penyimpanan Redux, jadi
dalam memori, kelola dengan Redux di memori sementara Anda aplikasi sedang berjalan.
Sekarang mengapa kita membutuhkan token itu? Untuk satu, selama kami memiliki token itu, kami dapat menentukan di
aplikasi seluler bahwa pengguna mungkin masuk dan karenanya meneruskan pengguna dari layar otentikasi ke layar aplikasi utama
kami dan seterusnya dan ketika pengguna mengklik logout, kami hanya akan menghapus token itu tetapi kita juga
membutuhkan token itu untuk sesuatu yang lain. Di server, seperti yang saya sebutkan,
kami biasanya memiliki sumber daya tertentu, URL tertentu yang hanya terkena pengguna yang masuk, jadi misalnya
di aplikasi kami, membuat produk mungkin bukan sesuatu yang harus dapat dilakukan setiap pengguna dan oleh
karena itu jika Anda ingin mengirim permintaan ke sumber daya yang dilindungi, Anda harus melampirkan
token itu ke permintaan sehingga server yang membuat token dan yang karenanya dapat memeriksa dengan kunci pribadi apakah
token itu valid, sehingga server dapat menentukan apakah Anda memiliki akses atau tidak.
Jika Anda mengirim token yang salah atau token yang tidak valid atau tidak ada token sama sekali, akses akan ditolak dan Anda
mendapatkan kembali kesalahan. Jika Anda memiliki
token yang valid dan lagi server dapat memeriksa apakah token itu valid atau tidak, Anda akan diberikan akses
dan karenanya Anda dapat mengakses sumber daya, menulis data, apa pun itu.
Ini adalah bagaimana otentikasi bekerja dan ini adalah
bagaimana kami akan mengimplementasikannya di sini.
Sekarang hal baiknya adalah Firebase yang kami gunakan sebagai dend backend sudah memiliki semua hal manajemen pengguna pembuatan
token bawaan, jadi kami tidak perlu khawatir tentang itu, kami hanya perlu
mengirim permintaan yang tepat dan kemudian mengelola token itu dan kami baik untuk pergi.