Dari pengalaman saya, sampe berbusa kasih tau junior antara encryption dan encoding. Sampe berkali-kali menjelaskan bahwa JWT itu tidak "mengenkripsi" atau menyembunyikan informasi di dalamnya. Tapiiii, JWT itu digunakan untuk "menjaga integritas" informasi nya, untuk mendeteksi ada "tamper" nggak di dalam informasi tersebut. Mantap bro Eko
betul sama buat menjaga resource yg kita restrict sih .... misalnya seperti content yg diupload ama user, itu gk boleh diakses ama selain user itu sendiri. maka kita kasih token jwt. kalo mau aman terenkripsi pake ssl
belajar JWT dari sini juga, benar Pak Eko JWT itu utk mempermudah proses cek otoritas makanya jagan store data penting seperti password di token JWT 👍👍
mantap penjelasanny kang.. trims bagi yg sudah bertanya.. spt kang eko sampaikan, diu JWT tertulis merupakan industry standard RFC 7519 yang diakui, jd pertanyaan aman / tidak, jgn diragukan lagi.
betul intinya jwt emng bsa di decode, tp gk bsa di modifikasi jadi ketika kita menggunakan jwt, data tersebut akan menjadi data yg sesuai saat di kirim. jadi tujuannya emng untuk menjaga integritas, alias data yg dikirim akan selalu valid dan gk akan bisa diubah (jd gk valid).
Model web app fe+be pake jwt menurut saya kurang aman. Selain itu sulit mengamankan aset2 atau halaman fe yang harusnya dapat ketika sudah login. Selain itu rawan beragam jenis serangan. Paling bener pake sesi. Jwt hanya dipakai ketika terpaksa atau cuma sekali pakai (misal SSO) Jwt bisa diproteksi dari serangan2 itu tapi lagi2 pake session cookie. Jadi mending langsung ke session cookie. Jwt bisa digunakan antar servis atau backend, antar aplikasi, untuk authnya mobile app (dg proteksi tambahan)
Kalau JWT kan ada Secret Key nya ya buat validasi. Kalau aman atau nggak aman itu lebih ke tempat naro si JWT itu. Misal kena serangan Man in The Middle dan berhasil di curi itu token gakan diotak atik juga isinya.
ohya pak, mau tanya gmna cara ngamanin dari front end (client side) request ke backend biar aman, otomatis kan orang kalo dari client side bakal tau itu cara request ke backend nya gmna, saya dari dulu bingung, sebenerny saya sudah tau juga, dengan memakai token expired, sama csrf / token 1 kali pakai, tapi adakah cara lain?, soalnya menurut saya mau di kasih expired 5 menit pun kalo masih ada waktu sisa, si hacker bakal bisa akses backend?
request dr frontend ke backend ya ga bisa d apa"in paling pake reverse proxy supaya url backend nya ga keliatan kalau pake rest api cara amanin gimana? ya pake token dan setiap request check apakah token nya valid/ masih berlaku itulah gunanya jwt untuk membawa data yg juga bisa di validasi backend bisa juga pake cors untuk melindungi request dr yg bukan ditujukan ini konteksnya rest api ya
@@ZynthProductions kalau misal si hacker bisa monitoring jaringan kita, trus dapet tuh url api, payload, sama jwt nya gimana bang? jwt kan fungsinya buat ngevalidasi, nah biar transaksi data fe sama be aman nih gimana?
@@fariddarmaji4047 kalau si hacker bisa monitor jaringan walau udah di reverse proxy brarti server fe nya udah ketembus mas karna reverse proxy running nya di server. cmiiw
@@fariddarmaji4047ya kan ttp gak bisa diapa2in sm hacker, kecuali hacker tau secret keynya. Agar bisa bikin payload baru sesuai keinginan hacker ya butuh: header + payload + secret
kalau algonya hanya header dan json jadinya gak aman gak sih? soalnya nanti hacker bisa generate lagi datanya dengan cara yang sama, algo(header, datapalsu). nanti dapet signature yg baru tinggal ganti deh. Mungkin lebih masuk akal kalau algonya butuh secret_key, misal algo(header, json, secret_key). kalo gini harusnya hacker gk bisa generate signaturenya lagi karena butuh secret_key, sedangkan yang tau secret_key hanya client dan server CMIIW
Selagi Secret Codenya / signaturenya gak bocor ya token itu gak bisa dipakek walau ada payloadnya, karena otoriasasi dengan jwt kan butuh token sama secret key, selagi di payload gak menaruh data sensitif seperti password dan property credential lainnya
@@hafiznugraha3063 klo dirasa kurang aman, encrypt aja value emailnya pake public/private key atau secret key yg berbeda. jd yg bisa decrypt cuma fe / be aja
Kayaknya ada yg kelewat deh kang, Aku masih bingung gimana App 2 tau kalo payloaf json nya berubah. Kan payload nya di modifikasi sebelum masuk ke App 2, yg artinya App 2 baru banget dapet jwt yg isi json nya kayak gitu
cara App 2 ngevalidasi token valid apa ngga ya dengan bikin "expected signature" pake secret key yg dia punya tapi dari header + payload yg dikirim. terus dibandingin dah tu "actual signature" yg dikirim match ga sm "expected signaturenya". makanya butuh penting buat mengamakan itu key, jangan sampe bocor
JWT di validasi di APP 2 dengan cara compare antara header payload dengan signaturenya ketika sama berarti benar klo salah berarti ga valid. Yg perlu ditekankan signature kan berisi juga SECRET KEY, nah jangan smpe bocor itu secret key nya
@@capital-craftt secret key ngaruhnya dimana di struktur jwt? terus, apa gabisa didapet dri decode an jwt? gmn caranya app 2 tau kalo jwt nya pake secret key yg sama? apa app 2 ngebandinginnya signature yg udh pake secret key X dengan signature yg dikirim dri app 1? berarti, intinya di secret key dong. pak eko nyebutnya kalo payload berubah doang, kan gbs tuh app 2 ngecek payload itu berubah engga secara gaada payload fix (bs berubah dari valuenya)
Izin bertanya pak eko atau temen-tenan yg sudah tahu boleh bantu jawab yaa, Untuk secret key pada app 1 dan app 2 dua itu didapat dari mana pak? Apakah kita generate sendiri atau bagaimana? Kemudian isi secret key itu bebas atau ada ketentuannya pak?
Ya aman² aja... User gk bisa ganti ke role se enak nya dengan ganti payload... Kalau payload di ganti token jya bakan rusak... Signature nya gk valid kalau gk tau secret key nya
1. bikin long secret key, pake random generator 2. pake SHA-512 3. rotating key tiap beberapa periode sekali bruteforce butuh waktu, ga instan, apalagi klo algoritmanya susah. jadi sebelum si hacker ketemu secret keynya, ya kita ganti duluan, biar dia ngulang ngebruteforce dari 0. so far google yg pake jwt juga aman2 aja sampe sekarang. openid mereka pake RS256 doang padahal
id token untuk menyimpan data dr si user supaya app frontend tau si user valid atau tidak atau menampilkan info dr si user access token untuk validasi request
Pak eko maaf masih ada yg ganjel di saya Di contoh kan payload datanya user pass nih, dan keliatan Nah semisal si hacker cuma ambil datanya ini dan dia input nya ttp dari app 1 soalnya udah tau datanya, berarti valid donk? Apakah login ini biasanya gk kaya gitu sistem nya, mohon penjelasan 🙏
@@radenmaulanarifaiabdullah1992betul, itu pak eko cuma contoh aja. programmer sembrono yang kirim password ke frontend njirr, aku biasanya id sama nama, atau sama username dan email buat isian halaman profile, form dihalaman ganti password biarin ga menampilkan password saat ini, karena emang jangan, biarin kosong nanti tinggal timpa password saat ini dengan password baru di database
salah satu teknik serangan MITM. Maka dari itu agak berbahaya kalau mau melakukan transaksi online bank pakai wifi public takutnya sudah ada yang sniff network activity nya terus di modifikasi
@@belajarjava-f5n karena jwt pada dasarnya muncul di link / url jadi bisa di modifikasi kemudian di encode. Tp klo sudah menerapkan JWT dan secret key tidak bocor, aman
Buat TS yg nanya lu gk perlu ke jwt decode, lu tinggal decode aja dari base64 ke string udah ke decode.. Lu kira jwt itu untuk enkripsi wkwk Lu rubah payload nya lu pake gk bakal bisa cak... Token nya udah rusak
@@danangardianto4717jangan disimpen bang, klo gua caranya simpen di cookies buat accesstoken nya, nanti tiap request yg perlu auth, cek dlu accesstokennya, bener apa ngga, jadi secret key tetep di backend aja, yg dijelasin mas Eko beda kasus
Dari pengalaman saya, sampe berbusa kasih tau junior antara encryption dan encoding. Sampe berkali-kali menjelaskan bahwa JWT itu tidak "mengenkripsi" atau menyembunyikan informasi di dalamnya. Tapiiii, JWT itu digunakan untuk "menjaga integritas" informasi nya, untuk mendeteksi ada "tamper" nggak di dalam informasi tersebut.
Mantap bro Eko
betul sama buat menjaga resource yg kita restrict sih .... misalnya seperti content yg diupload ama user, itu gk boleh diakses ama selain user itu sendiri. maka kita kasih token jwt. kalo mau aman terenkripsi pake ssl
Sekarang bisa gini berarti
"Jadi JWT itu gini bro ....... kalau masih gak paham nonton video pak eko aja"
WKWKWK
tetap aja bisa di ubah. kalau hacker tau itu data jwt. ya tinggal generate ulang signature berdasarkan algo dari header.
@@davidstephen7070 kan harus tau secret key nya dulu baru bisa generate ulang
@@davidstephen7070 makanya ada secret key juga bang.
jadi kalaupun bisa generate ulang, harus tau secret key dari yang request
2 tahun yang lalu, bro setia menunggu jawaban dari kang eko
😂
wkw
😂
bro sabar banget 🥲
pertanyaan 2 tahun lalu anjayy sampe lupa pernah tanya soalnya dah nemu jawabannya, pentingnya mencari tau terlebih dahulu sebelum bertanya 🤣
belajar JWT dari sini juga, benar Pak Eko JWT itu utk mempermudah proses cek otoritas makanya jagan store data penting seperti password di token JWT 👍👍
Kaget suaranya bahasa inggris ternyata ada audio track english😅
pertanyaan 2 tahun lalu anjayy sampe lupa pernah tanya soalnya dah nemu jawabannya, pentingnya mencari tau terlebih dahulu sebelum bertanya 🤣
mantap penjelasanny kang..
trims bagi yg sudah bertanya..
spt kang eko sampaikan, diu JWT tertulis merupakan industry standard RFC 7519 yang diakui,
jd pertanyaan aman / tidak, jgn diragukan lagi.
betul intinya jwt emng bsa di decode, tp gk bsa di modifikasi jadi ketika kita menggunakan jwt, data tersebut akan menjadi data yg sesuai saat di kirim. jadi tujuannya emng untuk menjaga integritas, alias data yg dikirim akan selalu valid dan gk akan bisa diubah (jd gk valid).
jwaban yg saya cari selama ini
Model web app fe+be pake jwt menurut saya kurang aman. Selain itu sulit mengamankan aset2 atau halaman fe yang harusnya dapat ketika sudah login. Selain itu rawan beragam jenis serangan. Paling bener pake sesi. Jwt hanya dipakai ketika terpaksa atau cuma sekali pakai (misal SSO)
Jwt bisa diproteksi dari serangan2 itu tapi lagi2 pake session cookie. Jadi mending langsung ke session cookie. Jwt bisa digunakan antar servis atau backend, antar aplikasi, untuk authnya mobile app (dg proteksi tambahan)
daging parah, menjawab keresahan saya selama ini, mantap pak eko
makasih ilmunya pakkk kerennn buat pemula
JWT tipenya ada JWS, JWE, JWK(s)
yang ke enkripsi itu JWE, yg bisa di decode JWS
Kalau JWT kan ada Secret Key nya ya buat validasi. Kalau aman atau nggak aman itu lebih ke tempat naro si JWT itu. Misal kena serangan Man in The Middle dan berhasil di curi itu token gakan diotak atik juga isinya.
Terimakasihhh
ohya pak, mau tanya gmna cara ngamanin dari front end (client side) request ke backend biar aman, otomatis kan orang kalo dari client side bakal tau itu cara request ke backend nya gmna, saya dari dulu bingung, sebenerny saya sudah tau juga, dengan memakai token expired, sama csrf / token 1 kali pakai, tapi adakah cara lain?,
soalnya menurut saya mau di kasih expired 5 menit pun kalo masih ada waktu sisa, si hacker bakal bisa akses backend?
request dr frontend ke backend ya ga bisa d apa"in
paling pake reverse proxy supaya url backend nya ga keliatan kalau pake rest api
cara amanin gimana? ya pake token dan setiap request check apakah token nya valid/ masih berlaku
itulah gunanya jwt untuk membawa data yg juga bisa di validasi backend
bisa juga pake cors untuk melindungi request dr yg bukan ditujukan
ini konteksnya rest api ya
@@ZynthProductions kalau misal si hacker bisa monitoring jaringan kita, trus dapet tuh url api, payload, sama jwt nya gimana bang?
jwt kan fungsinya buat ngevalidasi, nah biar transaksi data fe sama be aman nih gimana?
@@fariddarmaji4047 kalau si hacker bisa monitor jaringan walau udah di reverse proxy brarti server fe nya udah ketembus mas karna reverse proxy running nya di server. cmiiw
@@fariddarmaji4047 knp ga lo amanin aja tu pake HTTPS?
@@fariddarmaji4047ya kan ttp gak bisa diapa2in sm hacker, kecuali hacker tau secret keynya. Agar bisa bikin payload baru sesuai keinginan hacker ya butuh: header + payload + secret
betul JWT itu bukan untuk encryption, kalau mau payload nya gk di decode ganti pake JWE dan jg data payload isinya data yang di butuhkan saja.
kalau algonya hanya header dan json jadinya gak aman gak sih? soalnya nanti hacker bisa generate lagi datanya dengan cara yang sama, algo(header, datapalsu). nanti dapet signature yg baru tinggal ganti deh.
Mungkin lebih masuk akal kalau algonya butuh secret_key, misal algo(header, json, secret_key). kalo gini harusnya hacker gk bisa generate signaturenya lagi karena butuh secret_key, sedangkan yang tau secret_key hanya client dan server
CMIIW
iya kayaknya mas, saya juga masi kepikiran itu
generate signature JWT emang pake secret key bang. uda ada standardnya
Mmg seperti itu. Tapi kyknya lupa dijelasin sm mas eko
Mantap pak eko
mantap pak eko
pa eko, kira kira boleh ga minta foto kalo ketemu di kantor sebelum intern saya habis
Key agreement atau distribusi kunci antara client dan servernya gimana?
klo pake yg asymmetric key, distribusinya bisa pake JWK. klo symmetric ada banyak metode, salah satunya pake secret manager.
Ini beneran pakai bahasa Inggris atau dubing, Pak?
keget suaranya ingris awkwk
inti nya jwt bisa di intip payload nya tapi ga bisa dimodif ya bang
@@samsul_dev iya di modif bisa tp bakal divalidasi app 2 dan bakal ga valid karena beda antara signature dan payloadnya
Alternativenya bisa pakai Paseto
Selagi Secret Codenya / signaturenya gak bocor ya token itu gak bisa dipakek walau ada payloadnya, karena otoriasasi dengan jwt kan butuh token sama secret key, selagi di payload gak menaruh data sensitif seperti password dan property credential lainnya
kalo email doang aman gak. buat unique identifier user nya
@hafiznugraha3063 biasanya sih user id yang dipakek , kalau emang email-nya perlu harusnya gpp
@@hafiznugraha3063 klo dirasa kurang aman, encrypt aja value emailnya pake public/private key atau secret key yg berbeda. jd yg bisa decrypt cuma fe / be aja
Hmm menarique
alg: none 🗿
🙂
ada yg punya rekomendasi belajar flutter ga dari mana?
soalnya bapak zaman now kayanya ga ada tutor flutter
kuldii project bang, bagus semua contentnya, dari basic
@@jayanpihawiani abis searching, kontennya malah mostly malah flutter dan dart yaa wkwkw
btw thank u sirr
Kayaknya ada yg kelewat deh kang,
Aku masih bingung gimana App 2 tau kalo payloaf json nya berubah.
Kan payload nya di modifikasi sebelum masuk ke App 2, yg artinya App 2 baru banget dapet jwt yg isi json nya kayak gitu
cara App 2 ngevalidasi token valid apa ngga ya dengan bikin "expected signature" pake secret key yg dia punya tapi dari header + payload yg dikirim. terus dibandingin dah tu "actual signature" yg dikirim match ga sm "expected signaturenya". makanya butuh penting buat mengamakan itu key, jangan sampe bocor
JWT di validasi di APP 2 dengan cara compare antara header payload dengan signaturenya ketika sama berarti benar klo salah berarti ga valid. Yg perlu ditekankan signature kan berisi juga SECRET KEY, nah jangan smpe bocor itu secret key nya
@@capital-craftt secret key ngaruhnya dimana di struktur jwt? terus, apa gabisa didapet dri decode an jwt? gmn caranya app 2 tau kalo jwt nya pake secret key yg sama? apa app 2 ngebandinginnya signature yg udh pake secret key X dengan signature yg dikirim dri app 1?
berarti, intinya di secret key dong. pak eko nyebutnya kalo payload berubah doang, kan gbs tuh app 2 ngecek payload itu berubah engga secara gaada payload fix (bs berubah dari valuenya)
@@dittodhime oh ketika generate signature ditambah secret key juga, di video nya ngga soalnya makanya aga bingung
eh setelah buka website jwt nya faham, jadi generate signature itu dengan cara, algo(header.json.my_key) nah my_key ini yang punya cuma app a & app b
pak coba bkin contoh aplikasi penerapan nya donk..
teori nya paham tapi praktek nya kek nya susah ya..
Ini berarti jwt emng tujuannya integritas ya bang eko
Izin bertanya pak eko atau temen-tenan yg sudah tahu boleh bantu jawab yaa,
Untuk secret key pada app 1 dan app 2 dua itu didapat dari mana pak? Apakah kita generate sendiri atau bagaimana? Kemudian isi secret key itu bebas atau ada ketentuannya pak?
kita generate sendiri dan bebas, contohnya "aslkdh*ASiasdn191O!)sifA(S8dh13O(*21i1n2308eedx"
CMIIW
open your terminal and type openssl rand -base64 64
generate sendiri aja kak, ane biasa nya generate secret key nya pakai bcrypt awkwkwkwkwk
@@ezteco4899 oalah paham" Makasih bang
@@kapaksucigalpagor2839 Siap kak, thanks you respon nya
bagaimana ya cara implementsi jwt dan sistem login pada apk yang punya offline mode ?
Emng perlu ya jwt dpakai di offline?
Selama itu offline hrusnya aman sih
@@gunawanmigi2637 maksud nya online dan bisa offline juga, nah ketika offline itu mekanisme login nya gimana ya ?
@@gunawanmigi2637 oh maksud nya utnuk app yang support online dan offline
btw masukin user role / permission di jwt aman ga ?
Ya aman² aja... User gk bisa ganti ke role se enak nya dengan ganti payload...
Kalau payload di ganti token jya bakan rusak... Signature nya gk valid kalau gk tau secret key nya
Berarti app 1 & app 2 harus punya secret key yg sama ya?
iya bang
bagai mana jika screetkeynya ketauan karena misal di bruteforce
1. bikin long secret key, pake random generator
2. pake SHA-512
3. rotating key tiap beberapa periode sekali
bruteforce butuh waktu, ga instan, apalagi klo algoritmanya susah. jadi sebelum si hacker ketemu secret keynya, ya kita ganti duluan, biar dia ngulang ngebruteforce dari 0.
so far google yg pake jwt juga aman2 aja sampe sekarang. openid mereka pake RS256 doang padahal
apakah secret key nya harus sama?
@@khumammm harus dong. Krn utk produce signature itu header + payload + secret
JWT ada ga sih yg ga make secret key? (saking malesnya gitu misal)
Pertanyaan macam apa ini
@@rhrkv harus pake. Klo ga pake gampang sekali dilihat dan untuk memvalidasinya jg g bisa
JWE lah yang mengamankan data (data ter encryption)
Kembali lagi seperti yg di jelaskan pak eko bahwa enkripsi kelemahannya adalah lambat. Jadi disesuaikan kebutuhan
@@dittodhime iyah misal data nya kalau harus comply PCI DSS ya mesti ngikutin standard industri.
bang bahas id token vs access token di oauth dung
id token untuk menyimpan data dr si user supaya app frontend tau si user valid atau tidak atau menampilkan info dr si user
access token untuk validasi request
Pak eko maaf masih ada yg ganjel di saya
Di contoh kan payload datanya user pass nih, dan keliatan
Nah semisal si hacker cuma ambil datanya ini dan dia input nya ttp dari app 1 soalnya udah tau datanya, berarti valid donk?
Apakah login ini biasanya gk kaya gitu sistem nya, mohon penjelasan 🙏
1. payload ngga boleh ada password, data sensitif,
2. semisal terlanjur kasih username password di payload, terus dia login dari app 1, tetep valid
@@radenmaulanarifaiabdullah1992betul, itu pak eko cuma contoh aja. programmer sembrono yang kirim password ke frontend njirr, aku biasanya id sama nama, atau sama username dan email buat isian halaman profile, form dihalaman ganti password biarin ga menampilkan password saat ini, karena emang jangan, biarin kosong nanti tinggal timpa password saat ini dengan password baru di database
ya kalo udah gak guna itu jwt, pasti ud di bubarin itu jwt😂
Cara hackernya ngerubah request nya gimana tuh. Bahas dong pak eko 5:39
salah satu teknik serangan MITM. Maka dari itu agak berbahaya kalau mau melakukan transaksi online bank pakai wifi public takutnya sudah ada yang sniff network activity nya terus di modifikasi
@@belajarjava-f5n karena jwt pada dasarnya muncul di link / url jadi bisa di modifikasi kemudian di encode. Tp klo sudah menerapkan JWT dan secret key tidak bocor, aman
Buat TS yg nanya lu gk perlu ke jwt decode, lu tinggal decode aja dari base64 ke string udah ke decode..
Lu kira jwt itu untuk enkripsi wkwk
Lu rubah payload nya lu pake gk bakal bisa cak... Token nya udah rusak
jwt nama gw
ok
Apakah JWT bisa dipakai untuk aplikasi FE untuk membungkus payload API POST ke BE?
Bisa aja, yg penting jangan data penting yg di kirim melalui JWT. Karena pada dasarnya payloadnya bisa di decode
@dittodhime kalo app FE kayak react / vue / client side framework lainnya gitu nyimpen secret key nya gimana? Apakah aman?
@@danangardianto4717 lebih aman di middleware tp klo pertanyaannya bisa ya bisa, aman atau nggak tergantung developer ngamaninnya gmn
@@danangardianto4717jangan disimpen bang, klo gua caranya simpen di cookies buat accesstoken nya, nanti tiap request yg perlu auth, cek dlu accesstokennya, bener apa ngga, jadi secret key tetep di backend aja,
yg dijelasin mas Eko beda kasus
@@danangardianto4717 yg bisa generate secret key cuman backend. frontend cuman nyimpen doang, udah