Btw, kalau ujung-ujungnya masih mengandalkan database untuk menyimpan state, berarti tujuan JWT untuk mekanisme autentikasi bersifat stateless belum bisa tercapai. Kalau gitu sekalian aja generate JWT payload dengan memasukkan user password (hash) sebagai bagian dari secret key. Kalau terjadi kebocoran JWT, user tinggal reset password. JWT yang bocor otomatis menjadi invalid karena secret key sudah berubah dengan adanya perubahan password.
Cara saya mencegah JWT di curi, pada payload saya simpan IP user pada waktu login. Misal JWT tercuri belum tentu IP pencuri sama dengan IP user. Paling tidak meminimalisir penggunaan JWT oleh orang lain. Expired emang sengaja dibuat singkat 1 jam (aplikasi web base)
Gak bisa om pakai cara ini😊 kalau kita simpan IP nya, misalnya pada kasus 100 orang di satu kantor akses web kita, maka 100 orang tsb IP publiknya akan sama... kl kita validasi 1 IP && 1 session maka org lain dikantor tsb (dimana IP publiknya sama) gak akan bisa login di aplikasi kita....
terima kasih ilmunya. Buat yang bingung: kalau expired date pada jwt di edit pencuri bagaimana? Di dalam pengeditan JWT, kita butuh secret key JWT yang dibuat dengan secret key yang salah, pasti token nya akan ditolak oleh server. Yang ga ada obat itu kalau secret key JWT bisa bocor keluar.
Kalau saya biasanya nerapin metode, ketika login dibuatkan access dan refresh token. Access token simpan di memori db semisal redis dan jg simpan jg di db biasa. Untuk refresh token simpan di db biasa aja. Jadi access token bisa direvoke kpn aja, caranya dgn cek tokennya ada di db atau gak ketika mau revoke, jika ada access token di memori db hapus jg. Untuk memori db hanya digunakan pengecekan tiap request agar tidak terlalu lambat krn latency query ke db biasa
Betull cara saya juga begitu, cuma agak sedikit beda, yg saya simpan di memori itu salt dari body access tokennya, karena kalo full access tokennya di taro memory lumayan gede ukurannya, kalo salt aja paling cuma 16char
@@BukhoriMuslim1453 iya kalau concernnya emg fokus di token yg bisa dicuri2 tradeoffnya begitu bang. Statelessnya bisa tetep berlaku di internal system aja
owh itu gunanya refersh token yaa, Pak saya request pada video rest api pada laravel di update menggunakan access token jwt berserta refresh token, dan perbandingan dengan token sanctum, serta dibuatkan fitur logout other device.
Terimakasih penjelasannya pak, sangat mudah untuk di mengerti. Sekarang saya jadi penaran, gimana cara secure refresh dan access token di client biar aman ya? Apakah cukup jika hanya ditaruh di web storage seperti local storage atau cookie?
pak mau tanya, ada juga yang menjelaskan kalo refreshToken disimpan di http-only-cookie, kira-kira keamanannya seperti apa kalau disimpan dengan cara itu pak? mohon pencerahannya terimakasih🙂
klo saya buat access token itu berubah2 setiap request, jadi di payloadnya saya buat data request semuanya yg dinamic ditambah session di database yg pastinya access tokennya berubah terus setiap saat.
Kalau saya lebih memilih request token baru sebelum token lama expire. Misalnya token expire dalam 3600 detik, maka setelah 3550 detik setelah token lama didapat, saya akan meminta token baru. Ini akan menjamin tidak ada transaksi yang gagal hanya karena masalah sepele.
kalau tokennya disimpan dilocal storage sama aja bang bisa dicuri, jadi solusinya belum mengatasi inti masalahnya. disimpan di http only cookie sih jwtnya
Mas eko,, Misalnya kita punya webservice dan pakai jwt,, dan webservice itu di gunakan pada aplikasi berbasis mobile, nah klo ada orang yg melakukan Reverse Engineering pada APK Android dan dapat link webservice beserta parameter2 nya, ada gag teknik mengamankan akses webservice kita tersebut beserta akses jwt ny mas ??
kalau case cuma "kecuri" tokennya sih simple as wajib kirim deviceId biasanya di header, nanti tinggal dicompare dengan jwt yang telah dibalut dengan payload deviceId bisa stateless gak perlu simpan ini itu
Nah deviceId itu cuma perumpamaan ya, kita bisa samarin nama untuk fieldnya yang susah ditebak bahkan saat di decode tidak akan tau itu deviceId Untuk value juga bisa pake encryption yang valuenya berubah rubah setiap kali dikirim system kita tinggal decode dgn value yang sebenernya sama
@@ProgrammerZamanNow pa untuk informasi yang diinputkan di payload jwt bagus nya apa aja. jika mau ada mekanisme pengecekan role dan is email verified apakah aman jika disimpan di payload atau harus check di database untuk itu ?
kalo di google bukannya kalo hapus session langsung ke logout, sedangkan kallau hanya hapus refresh token kan berarti harus nungggu 1 jam setelah request refresh token terakhir
Kalau kelupaan logout di device lain lalu mau login di device yg baru (selama acces token/refresh token lama masih bisa dipakai) si user dikasi warning, masih login di device xxx, dikasi opsi force logout di device lama lalu acces token dan refresh tokennya digenerate setelah login tentunya. Efektif nga ya? 😅
ada bagusnya dri servernya langsung set the cookie dengan httpOnly setelah itu saat client melakukan rrwuest otomatis kekirim sama access and refrrsh tokennya
@@fauzialdrich9700 iya bang, cara yang lebih aman menyimpan jwt tokennya di http only cookie karena data di http only cookie ga bisa dicuri atau lebih susah mungkin aku belum nemu cara curi data di http only cookie, setting http only cookienya jadi secure biar hanya bisa dikirim lewat https yang artinya akan dienkripsi, terus setting jadi same site juga biar ga bisa di cross site request forgery
ada kelemahannya pak, kalau pas user sedang tidak online, maka ia tidak bisa mengkick device lain tersebut, misal lagi tidur atau sedang ga buka hp, maka akun user keburu diacak-acak pencuri, misal saldonya dihabisin. solusinya adalah konfirmasi dulu ke device utama user, misal dikasih notifikasi real time ke user bahwa ada device lain yang mencoba login apakah ini anda? kalau iya klik tombol izinkan login berikut. jadi kalau user pas sedang tidak online, dia akan tetap aman karena device lain yang mencoba login harus dikonfirmasi dulu dari device utama user, kalau ga dikonfirmasi akan ditolak ga boleh login
Makasih ilmunya Pak Eko, asli ini menjawab kegalauan saya soal JWT wkwkwk Btw Pak saya ada pertanyaan bodoh: kalo saya jadi penyedia aplikasi, bisa ga saya tau ada refresh token yg tercuri tanpa user yg sebenarnya melapor ke saya? Terima kasih sebelumnya Pak
@ProgrammerZamanNow saya kalau sistem login juga suka melibatkan user agent juga, tapi apakah user agent bisa di manipulasi artinya bisa dikirim pake user agent yang di modifikasi seperti fake gps?
@@ProgrammerZamanNow tapi kok banyak website yg tidak implement ini yah, krn saya coba bbrp website besar di indonesia, saya pake cookie dengan beda2 browser itu tetap jalan, saya yakin arsitek developer pasti tau ini, tp saya pengen tau alasan kenapa gak di-implement, pasti ada alasan yg lebih kuat
bisa aja refresh token nya di buat expired, dan biasa nya refresh token gak ter ekspose, gimana jika semua ketahuan, tinggal ganti secret utk build JWT nya, biasa nya ini di simpan di Env. cara ini biasanya membuat semua user auto logout
@@_fuji_studio_ kalau di memory gak dong. tergantung dimana nyimpannya, saya disini gak bahas bagaimana cara menyimpannya. sedangkan access token kenapa terekspose, karena diikutkan di request header
@@RoziPutramemori mana bang? kan itu token lu kirim ke frontend, terus di simpan di frontend sana. nah data apapun yang lu simpan di frontend bisa dicuri
izin bertanya pak, jika kasusnya backend dan frontend dipisah dan frontend menyimpan token jwt yang dilempar dari backend lalu bagaimana cara mengetahui dari sisi frontend bahwa user telah login? Contoh kasusnya saya ingin meproteksi halaman yang hanya boleh diakses ketika user telah login, apakah implementasinya cukup memeriksa ada tidaknya token di local storage atau cookie?
Makasih pak atas penjelasannya, Saya ada pertanyaan pak, misalnya ketika refresh token sudah expired kemudian request refresh token baru apakah baiknya refresh token yg lama (yg sudah expired) di hapus dari database?
Kalau saya biasa bikin task scheduling, nanti pake cron expression dipanggil setiap jam 1 malem buat hapus token yg expired, mau itu refresh, verify, reset token
akses token bisa di trap di jaringan begitupun sebenarnya refresh token, jadi ya sama aja. ketika akses token di curi itu udah + refresh token. betulkah begitu?🙏
@@ProgrammerZamanNow masih belum paham bang, jadi ketika client mengakses resource dengan token yang sudah expire client harus request access token baru dengan refresh token. berarti user nya harus hit resource nya lagi manual dong dengan token baru ? atau ada mekanisme untuk mengakses ulang resource dengan access token baru tapi klo begini harus diterapkan di semua resource dong ?
jwt di reset ketika expired, semisal saya ingin akses url /item ketika server mengembalikan code 410 gone yang berarti expired token maka client memiliki interceptor yang akan memperbarui token dengan mengirim token refresh ke auth server dan kemudian mendapatkan jwt yang baru kemudian di ulang request yang gagal tadi
@@ravetechsolutions Baik terimakasih informasinya om. Untuk periode reset refresh token nya sendiri itu biasanya kapan ya om? karena kalau di video refresh token juga mempunyai masa expired.
di dimensi lain, ada web yang butuh login melulu, cuma perkara tutup web, giliran mau berkunjung lagi minta login lagi, ini salah satu cara kah ? (bukan pake refresh token)
Kalau selama masih menggunakan internet publik yg sama, berarti kan access token dan refresh token masih ttp bisa kecuri terus,, karena masih bisa dipantau oleh yg punya wifi, gmna donk? Soalnya saya klo dduk di cafe bisa berjam² 😂,
Setau saya kalau sudah https itu data yg kita kirim ke server sudah di encrypt pakai public key server nya, sehingga cuman si server yg bisa lihat data nya
bisa aja klo server nya satu jaringan sama usernya, masalahnya klo servernya cloud yg kebaca kan ip publik nya, saran sih validasinya pakai fingerprint di frontend nya
@@bangabudesign7997ga perlu pihak ketiga, tinggal buat dr yang unik dr device itu, kaya useragent, dll yg sifatnya ga berubah, nnti tinggal hash pake md5 aja jadi dah fingerprint
kalau aplikasinya sangat penting lebih baik semua state dikelola di backend, server yang diprogram pakai bahasa ramah memori dan cepat kayaknya udah lebih dari cukup buat handle itu semua kayak golang, kalau backendnya javascript mungkin perlu nambah biaya dengan nyediain hardware yang lebih mumpuni karena js ga efisien bahasanya
"Untuk meminal meminama apaya", lagi serius nyimak, ane tiba - tiba jadi ketawa pak wkwkwk 🤣🤣🤣
saya juga pengen ketawa
Hahaha di beberapa video juga selalu salah ngomong kalau ngomong "meminimalisir"
Yg penting bukan "mesengnyarakan" 😅😂
@@fajarnh merosakkan
di pin dong 🤣
Btw, kalau ujung-ujungnya masih mengandalkan database untuk menyimpan state, berarti tujuan JWT untuk mekanisme autentikasi bersifat stateless belum bisa tercapai. Kalau gitu sekalian aja generate JWT payload dengan memasukkan user password (hash) sebagai bagian dari secret key. Kalau terjadi kebocoran JWT, user tinggal reset password. JWT yang bocor otomatis menjadi invalid karena secret key sudah berubah dengan adanya perubahan password.
Cara saya mencegah JWT di curi, pada payload saya simpan IP user pada waktu login. Misal JWT tercuri belum tentu IP pencuri sama dengan IP user. Paling tidak meminimalisir penggunaan JWT oleh orang lain. Expired emang sengaja dibuat singkat 1 jam (aplikasi web base)
Gak bisa om pakai cara ini😊
kalau kita simpan IP nya, misalnya pada kasus 100 orang di satu kantor akses web kita, maka 100 orang tsb IP publiknya akan sama... kl kita validasi 1 IP && 1 session maka org lain dikantor tsb (dimana IP publiknya sama) gak akan bisa login di aplikasi kita....
Lah kalo yg kebaca ip public gimana om, kenapa ga pakai fingerprint aja di front end nya
@@vlers sekalian pakai validasi retina & biometrik lain gan 😂 plus face recog wkk itu baru aman
@@novianindy887 verifikasinya 1 IP + 1 username / session dong.. kan yg penting jgn sampai ada 2 IP login ke 1 username / session...
@@novianindy887 kenapa ga test DNA aja sekalian bang..
terima kasih ilmunya.
Buat yang bingung: kalau expired date pada jwt di edit pencuri bagaimana?
Di dalam pengeditan JWT, kita butuh secret key
JWT yang dibuat dengan secret key yang salah, pasti token nya akan ditolak oleh server. Yang ga ada obat itu kalau secret key JWT bisa bocor keluar.
kalau di edit ya ketauan signature nya beda
Kalau saya biasanya nerapin metode, ketika login dibuatkan access dan refresh token. Access token simpan di memori db semisal redis dan jg simpan jg di db biasa. Untuk refresh token simpan di db biasa aja.
Jadi access token bisa direvoke kpn aja, caranya dgn cek tokennya ada di db atau gak ketika mau revoke, jika ada access token di memori db hapus jg. Untuk memori db hanya digunakan pengecekan tiap request agar tidak terlalu lambat krn latency query ke db biasa
Betull cara saya juga begitu, cuma agak sedikit beda, yg saya simpan di memori itu salt dari body access tokennya, karena kalo full access tokennya di taro memory lumayan gede ukurannya, kalo salt aja paling cuma 16char
jadi gak stateless lagi dong
@@muhammadfahriansyah3795 betul bisa jg simpan header/signaturenya aja bang
@@BukhoriMuslim1453 iya kalau concernnya emg fokus di token yg bisa dicuri2 tradeoffnya begitu bang. Statelessnya bisa tetep berlaku di internal system aja
owh itu gunanya refersh token yaa,
Pak saya request pada video rest api pada laravel di update menggunakan access token jwt berserta refresh token, dan perbandingan dengan token sanctum, serta dibuatkan fitur logout other device.
terima kasih banyak kak sudah dibuatkan video penjelasannya. sangat bermanfaat.
Untuk menyimpan Token baiknya di Cookies, Local Storage, atau Session Storage ?
trima kasih atas ilmunya pa🙏😊
Terimakasih penjelasannya pak, sangat mudah untuk di mengerti. Sekarang saya jadi penaran, gimana cara secure refresh dan access token di client biar aman ya? Apakah cukup jika hanya ditaruh di web storage seperti local storage atau cookie?
boleh donk dijelasin mengenai PKCE
up
pak mau tanya, ada juga yang menjelaskan kalo refreshToken disimpan di http-only-cookie, kira-kira keamanannya seperti apa kalau disimpan dengan cara itu pak? mohon pencerahannya terimakasih🙂
thanks suhu pencerahannya
ooowh... oke pa, makasih ilmunya 🙏🙏
gua dah make sistem refresh token dan access token dah lama dan sangat enak dan securitynya mantap selama frontendnya terstruktur calling tokennya
klo saya buat access token itu berubah2 setiap request, jadi di payloadnya saya buat data request semuanya yg dinamic ditambah session di database yg pastinya access tokennya berubah terus setiap saat.
Kalau saya lebih memilih request token baru sebelum token lama expire. Misalnya token expire dalam 3600 detik, maka setelah 3550 detik setelah token lama didapat, saya akan meminta token baru. Ini akan menjamin tidak ada transaksi yang gagal hanya karena masalah sepele.
kalau tokennya disimpan dilocal storage sama aja bang bisa dicuri, jadi solusinya belum mengatasi inti masalahnya. disimpan di http only cookie sih jwtnya
Best practice manage jwtToken di frontend dimana ya? Localstorage, cookies atau apa? Khususnya kalo cuma pake plain react tanpa next/remix
Kalo urgent dan fatal, tinggal ganti secret key nya, otomatis semua token akan invalid, memaksa semua user untuk login ulang. Opsi terakhir.
mudah2an gak ada yang di SP devops nya #eh
Mas eko,, Misalnya kita punya webservice dan pakai jwt,, dan webservice itu di gunakan pada aplikasi berbasis mobile, nah klo ada orang yg melakukan Reverse Engineering pada APK Android dan dapat link webservice beserta parameter2 nya, ada gag teknik mengamankan akses webservice kita tersebut beserta akses jwt ny mas ??
kalau case cuma "kecuri" tokennya sih simple as wajib kirim deviceId biasanya di header, nanti tinggal dicompare dengan jwt yang telah dibalut dengan payload deviceId
bisa stateless gak perlu simpan ini itu
ga bisa gitu bang, pas tokennya udah jatuh ke pencurinya bisa memalsukan deviceid di header requestnya
Nah deviceId itu cuma perumpamaan ya, kita bisa samarin nama untuk fieldnya yang susah ditebak bahkan saat di decode tidak akan tau itu deviceId
Untuk value juga bisa pake encryption yang valuenya berubah rubah setiap kali dikirim system kita tinggal decode dgn value yang sebenernya sama
@@_fuji_studio_ jika ingin edit value, kan butuh secret key bang?
pak request penjelasan CSRF token
noted
@@ProgrammerZamanNow pa untuk informasi yang diinputkan di payload jwt bagus nya apa aja. jika mau ada mekanisme pengecekan role dan is email verified apakah aman jika disimpan di payload atau harus check di database untuk itu ?
bahas mekanisme auto extend pak, jadi kalo user masih tetep login, expired time nambah lagi, kecuali emang gak pernah login baru expired
kalo di google bukannya kalo hapus session langsung ke logout, sedangkan kallau hanya hapus refresh token kan berarti harus nungggu 1 jam setelah request refresh token terakhir
Pak kalo refresh token di web kan disimpen nya di cookie client pake httpOnly, kalo di mobile gitu disimpen dimana ya?
pengen tanya bisa ngk tokennya itu di bungkus dengan TLS ? biar ngk bisa di pakai sama sembarang orang
Kalau kelupaan logout di device lain lalu mau login di device yg baru (selama acces token/refresh token lama masih bisa dipakai) si user dikasi warning, masih login di device xxx, dikasi opsi force logout di device lama lalu acces token dan refresh tokennya digenerate setelah login tentunya. Efektif nga ya? 😅
bisa, cuma berarti hanya bisa login di 1 tempat
refresh token yg di client sebaiknya di simpan dimana ya pak ? apakah session storage atau local storage ? atau gimana ya bagusnya
ada bagusnya dri servernya langsung set the cookie dengan httpOnly setelah itu saat client melakukan rrwuest otomatis kekirim sama access and refrrsh tokennya
di local storage nya biasanya
@@ProgrammerZamanNow berarti refresh token itu juga bisa di curi ya mas? access token & refresh token kan sama2 kelihatan di local storage
@@fauzialdrich9700 iya bang, cara yang lebih aman menyimpan jwt tokennya di http only cookie karena data di http only cookie ga bisa dicuri atau lebih susah mungkin aku belum nemu cara curi data di http only cookie, setting http only cookienya jadi secure biar hanya bisa dikirim lewat https yang artinya akan dienkripsi, terus setting jadi same site juga biar ga bisa di cross site request forgery
@@fauzialdrich9700saran aja kalau web mending disimpan di cookie lebih aman
tambah sedikit lagi om, bahas invalidate/kick JWT jika ada atau triknya
pak dilanjut dengna penerapan CSRF tokennya🙏🙏
menarik
ada kelemahannya pak, kalau pas user sedang tidak online, maka ia tidak bisa mengkick device lain tersebut, misal lagi tidur atau sedang ga buka hp, maka akun user keburu diacak-acak pencuri, misal saldonya dihabisin. solusinya adalah konfirmasi dulu ke device utama user, misal dikasih notifikasi real time ke user bahwa ada device lain yang mencoba login apakah ini anda? kalau iya klik tombol izinkan login berikut. jadi kalau user pas sedang tidak online, dia akan tetap aman karena device lain yang mencoba login harus dikonfirmasi dulu dari device utama user, kalau ga dikonfirmasi akan ditolak ga boleh login
bahas mengenai authorization nya kang, gmana cara kita tau kalo token jwt ini punya role access ini
up
Mungkin dibody jwtnya ditambahin aja value role usernya
Kan bisa di decode tuh tinggal tambah aja datanya sebelum ke encode
di body payload jwt masukin role access nya
tambahin aja di payload
Pak Eko tools diagram yang Bapak pakai itu apa ya ?
kalo sudah pake https, apakah masih blm aman internetnya pak?
harus bikin laporan kehilangan dulu gak sih mestinya ?
Makasih ilmunya Pak Eko, asli ini menjawab kegalauan saya soal JWT wkwkwk
Btw Pak saya ada pertanyaan bodoh: kalo saya jadi penyedia aplikasi, bisa ga saya tau ada refresh token yg tercuri tanpa user yg sebenarnya melapor ke saya? Terima kasih sebelumnya Pak
bisa aja, misal di record User Agent nya di database, jadi kalo dia akses pake User Agent berbeda, langsung blokir
@ProgrammerZamanNow saya kalau sistem login juga suka melibatkan user agent juga, tapi apakah user agent bisa di manipulasi artinya bisa dikirim pake user agent yang di modifikasi seperti fake gps?
@@ProgrammerZamanNow tapi kok banyak website yg tidak implement ini yah, krn saya coba bbrp website besar di indonesia, saya pake cookie dengan beda2 browser itu tetap jalan, saya yakin arsitek developer pasti tau ini, tp saya pengen tau alasan kenapa gak di-implement, pasti ada alasan yg lebih kuat
bisa aja refresh token nya di buat expired,
dan biasa nya refresh token gak ter ekspose,
gimana jika semua ketahuan, tinggal ganti secret utk build JWT nya, biasa nya ini di simpan di Env. cara ini biasanya membuat semua user auto logout
nyimpannya di localstorage tetap terekspose bang semua yang disimpan di localstorage bisa dicuri
@@_fuji_studio_ kalau di memory gak dong.
tergantung dimana nyimpannya, saya disini gak bahas bagaimana cara menyimpannya.
sedangkan access token kenapa terekspose, karena diikutkan di request header
@@RoziPutramemori mana bang? kan itu token lu kirim ke frontend, terus di simpan di frontend sana. nah data apapun yang lu simpan di frontend bisa dicuri
Buat case pakai Laravel Passport cocok kayanya kang
lanjut implement pakai nodejs dong bang
izin bertanya pak, jika kasusnya backend dan frontend dipisah dan frontend menyimpan token jwt yang dilempar dari backend lalu bagaimana cara mengetahui dari sisi frontend bahwa user telah login? Contoh kasusnya saya ingin meproteksi halaman yang hanya boleh diakses ketika user telah login, apakah implementasinya cukup memeriksa ada tidaknya token di local storage atau cookie?
mungkin bisa pake metode aplikasi bank, jadi nyatet session yang login pada device tertentu..
waktu call ke BE nya, kalo dapat unauthorized, tinggal tampilkan halaman belum login
Makasih pak atas penjelasannya,
Saya ada pertanyaan pak, misalnya ketika refresh token sudah expired kemudian request refresh token baru apakah baiknya refresh token yg lama (yg sudah expired) di hapus dari database?
refresh token biasanya gak bisa diperbaharui, dia harus login ulang
Kalau saya biasa bikin task scheduling, nanti pake cron expression dipanggil setiap jam 1 malem buat hapus token yg expired, mau itu refresh, verify, reset token
menyengsengsarkan vs meminal meminama. haha
akses token bisa di trap di jaringan begitupun sebenarnya refresh token, jadi ya sama aja. ketika akses token di curi itu udah + refresh token. betulkah begitu?🙏
Belum tentu, kan bisa aja di waktu kejadian itu, refresh token nya gak dipake
@@ProgrammerZamanNow masih belum paham bang, jadi ketika client mengakses resource dengan token yang sudah expire client harus request access token baru dengan refresh token. berarti user nya harus hit resource nya lagi manual dong dengan token baru ? atau ada mekanisme untuk mengakses ulang resource dengan access token baru tapi klo begini harus diterapkan di semua resource dong ?
Good tutor ny pak
Berarti kalo pengen bisa logout secara paksa user realtime access token harus di simpan di db ya?
iya, cuma jadi gak terllau berguna pake JWT
Refresh token itu biasanya akan di refresh ketika expired juga kah? atau ketika mendekati expired saat user meminta Access Token baru?
jwt di reset ketika expired, semisal saya ingin akses url /item ketika server mengembalikan code 410 gone yang berarti expired token maka client memiliki interceptor yang akan memperbarui token dengan mengirim token refresh ke auth server dan kemudian mendapatkan jwt yang baru kemudian di ulang request yang gagal tadi
@@ravetechsolutions Baik terimakasih informasinya om. Untuk periode reset refresh token nya sendiri itu biasanya kapan ya om? karena kalau di video refresh token juga mempunyai masa expired.
@@renbangbprd7236 tergantung jenis aplikasi, semakin rentan semakin pendek waktunya, isExpired pakai timestamp biasanya
saya masih ngarep course spring security nih pak :D
gak perlu pake spring security, terlalu bloated
@@ProgrammerZamanNow bloated tapi clientnya minta pak, hahaha
@@ProgrammerZamanNow blh pak eko bikin konten knp g perlu pke spring security 😁
boleh donk bahas Cookie Consent, di youtube belum ada bahasa indonesia neh
noted
di dimensi lain, ada web yang butuh login melulu, cuma perkara tutup web, giliran mau berkunjung lagi minta login lagi, ini salah satu cara kah ? (bukan pake refresh token)
aplikasi dapodik bukan om? itu rese juga, tutup tab aja harus login lagi 😂
pasti aplikasi negara wakanda
@@bagiteknologi sekarang bahkan remember me sudah ilang sudah ganti jadi always auto remember me,
Masih menunggu course javascript lanjutan
kyknya udh abis deh
coba lanjut ke kelas
1. node js
2. vue
Kalau selama masih menggunakan internet publik yg sama, berarti kan access token dan refresh token masih ttp bisa kecuri terus,, karena masih bisa dipantau oleh yg punya wifi, gmna donk?
Soalnya saya klo dduk di cafe bisa berjam² 😂,
Berdoa yg punya cafe gak jahat, hahaha
@@ProgrammerZamanNow ini mah jawaban yg bisa masuk ke semua pertanyaan kang 🤣,
Setau saya kalau sudah https itu data yg kita kirim ke server sudah di encrypt pakai public key server nya, sehingga cuman si server yg bisa lihat data nya
kalau semisal websitenya udah make https dan implemen HSTS seharusnya sih udah relatif aman dari mitm karena lalu lintas data udah terenkripsi
klo pake HTTPS harusnya aman, klo data sangat sensitif sekalian aja sediain VPN😂😂
ngebahas security terus nih kang belakangan, hehe, ada apa kira2 ya
lanjutin vlog yang kemaren2, ternyata banyak yang request untuk dilanjut
tambahi pin, agar fitur edit/action unlocked
Kang kapan buat algoritma dan struktur data😢
doakan biar cepet dibuat, hehe
@@ProgrammerZamanNow semoga di mudahkan kang
sy salfok sm tools yg buat ngejelasin itu, namanya ap y kang?
Excalidraw bang 🙌🏻🔥🙌🏻
@@Ariprw tq bang, 👍
@@puguhhastagunawan8421 sama-sama
jika refresh tokennya expired apakah artinya user harus login lagi?
biasanya seperti itu
Bisa gk ya kalau validasinya + IP Adress
Jadi misal JWT nya di curi dan yg akses tidak sama dengan IP Adress yg awal maka tidak bisa akses
bisa aja klo server nya satu jaringan sama usernya, masalahnya klo servernya cloud yg kebaca kan ip publik nya, saran sih validasinya pakai fingerprint di frontend nya
@@vlers harus pake pihak ketiga ya kalau mau dapatkan fingerprintnya?
@@bangabudesign7997ga perlu pihak ketiga, tinggal buat dr yang unik dr device itu, kaya useragent, dll yg sifatnya ga berubah, nnti tinggal hash pake md5 aja jadi dah fingerprint
bahas siopv2 bang
Still waiting Elysia JS
no bro, no js in backend. golang, .net, or java
bahas csrf pak
minggu depan
Jwt token = json web token token ya kang
wkwkwk
sa ae
bagaimana jika 22 nya di curi wakakakak
kalau aplikasinya sangat penting lebih baik semua state dikelola di backend, server yang diprogram pakai bahasa ramah memori dan cepat kayaknya udah lebih dari cukup buat handle itu semua kayak golang, kalau backendnya javascript mungkin perlu nambah biaya dengan nyediain hardware yang lebih mumpuni karena js ga efisien bahasanya
Pada akhirnya paling aman ngasih tau device mana aja yang aktif session nya😅
biar user yang kick sendiri