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
@bagas14715Ай бұрын
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
@RevansahDragunovАй бұрын
Sekarang bisa gini berarti "Jadi JWT itu gini bro ....... kalau masih gak paham nonton video pak eko aja" WKWKWK
@davidstephen7070Ай бұрын
tetap aja bisa di ubah. kalau hacker tau itu data jwt. ya tinggal generate ulang signature berdasarkan algo dari header.
@henrybs1550Ай бұрын
@@davidstephen7070 kan harus tau secret key nya dulu baru bisa generate ulang
@Tom-ft3doАй бұрын
@@davidstephen7070 makanya ada secret key juga bang. jadi kalaupun bisa generate ulang, harus tau secret key dari yang request
@itsmee3372Ай бұрын
2 tahun yang lalu, bro setia menunggu jawaban dari kang eko
@flashnao4360Ай бұрын
😂
@yogithesymbianАй бұрын
wkw
@NIKXPhreakerАй бұрын
😂
@agungsenjaya874Ай бұрын
bro sabar banget 🥲
@ghalmasshandityaaaАй бұрын
pertanyaan 2 tahun lalu anjayy sampe lupa pernah tanya soalnya dah nemu jawabannya, pentingnya mencari tau terlebih dahulu sebelum bertanya 🤣
@kaizen1835Ай бұрын
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 👍👍
@ghalmasshandityaaaАй бұрын
pertanyaan 2 tahun lalu anjayy sampe lupa pernah tanya soalnya dah nemu jawabannya, pentingnya mencari tau terlebih dahulu sebelum bertanya 🤣
@ELghazАй бұрын
Kaget suaranya bahasa inggris ternyata ada audio track english😅
@bboydarkneszАй бұрын
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.
@vianazisАй бұрын
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).
@123mrfaridАй бұрын
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)
@yuyunpurniawan6294Ай бұрын
JWT tipenya ada JWS, JWE, JWK(s) yang ke enkripsi itu JWE, yg bisa di decode JWS
@raincodemyidАй бұрын
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.
@AnggaHodeАй бұрын
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?
@ZynthProductionsАй бұрын
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
@fariddarmaji4047Ай бұрын
@@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?
@ZynthProductionsАй бұрын
@@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
@capital-crafttАй бұрын
@@fariddarmaji4047 knp ga lo amanin aja tu pake HTTPS?
@Faaaklu0210Ай бұрын
@@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
@alvierrrАй бұрын
daging parah, menjawab keresahan saya selama ini, mantap pak eko
@longcat666Ай бұрын
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.
@khumammmАй бұрын
jwaban yg saya cari selama ini
@daffarafi3362Ай бұрын
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
Mmg seperti itu. Tapi kyknya lupa dijelasin sm mas eko
@afrizalokyАй бұрын
Key agreement atau distribusi kunci antara client dan servernya gimana?
@capital-crafttАй бұрын
klo pake yg asymmetric key, distribusinya bisa pake JWK. klo symmetric ada banyak metode, salah satunya pake secret manager.
@daverussell4052Ай бұрын
pa eko, kira kira boleh ga minta foto kalo ketemu di kantor sebelum intern saya habis
@fariddarmaji4047Ай бұрын
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
@capital-crafttАй бұрын
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
@dittodhimeАй бұрын
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
@caskkaАй бұрын
@@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)
@naufalshoeria1926Ай бұрын
@@dittodhime oh ketika generate signature ditambah secret key juga, di video nya ngga soalnya makanya aga bingung
@naufalshoeria1926Ай бұрын
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
@AdiGunawan1Ай бұрын
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Ай бұрын
kalo email doang aman gak. buat unique identifier user nya
@AdiGunawan1Ай бұрын
@hafiznugraha3063 biasanya sih user id yang dipakek , kalau emang email-nya perlu harusnya gpp
@IbrahimAkbarАй бұрын
@@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
@kelas.kreatifАй бұрын
makasih ilmunya pakkk kerennn buat pemula
@samsul_devАй бұрын
inti nya jwt bisa di intip payload nya tapi ga bisa dimodif ya bang
@dittodhimeАй бұрын
@@samsul_dev iya di modif bisa tp bakal divalidasi app 2 dan bakal ga valid karena beda antara signature dan payloadnya
@masedinetАй бұрын
Ini beneran pakai bahasa Inggris atau dubing, Pak?
@prima123456Ай бұрын
pak coba bkin contoh aplikasi penerapan nya donk.. teori nya paham tapi praktek nya kek nya susah ya..
@teknolovedigitalАй бұрын
Alternativenya bisa pakai Paseto
@allgarry7719Ай бұрын
ada yg punya rekomendasi belajar flutter ga dari mana? soalnya bapak zaman now kayanya ga ada tutor flutter
@jayanpihawianiАй бұрын
kuldii project bang, bagus semua contentnya, dari basic
@allgarry7719Ай бұрын
@@jayanpihawiani abis searching, kontennya malah mostly malah flutter dan dart yaa wkwkw btw thank u sirr
@AlexanderzulАй бұрын
keget suaranya ingris awkwk
@uyosuryo629Ай бұрын
bagai mana jika screetkeynya ketauan karena misal di bruteforce
@capital-crafttАй бұрын
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
@iqbalrivaldi2856Ай бұрын
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?
@ezteco4899Ай бұрын
kita generate sendiri dan bebas, contohnya "aslkdh*ASiasdn191O!)sifA(S8dh13O(*21i1n2308eedx" CMIIW
@RezaPrayoga236Ай бұрын
open your terminal and type openssl rand -base64 64
@kapaksucigalpagor2839Ай бұрын
generate sendiri aja kak, ane biasa nya generate secret key nya pakai bcrypt awkwkwkwkwk
@iqbalrivaldi2856Ай бұрын
@@ezteco4899 oalah paham" Makasih bang
@iqbalrivaldi2856Ай бұрын
@@kapaksucigalpagor2839 Siap kak, thanks you respon nya
@lgarin2115Ай бұрын
Terimakasihhh
@thefiredguyАй бұрын
Ini berarti jwt emng tujuannya integritas ya bang eko
@samsul_devАй бұрын
bagaimana ya cara implementsi jwt dan sistem login pada apk yang punya offline mode ?
@gunawanmigi2637Ай бұрын
Emng perlu ya jwt dpakai di offline? Selama itu offline hrusnya aman sih
@samsul_devАй бұрын
@@gunawanmigi2637 maksud nya online dan bisa offline juga, nah ketika offline itu mekanisme login nya gimana ya ?
@samsul_devАй бұрын
@@gunawanmigi2637 oh maksud nya utnuk app yang support online dan offline
@adrianabdillah6857Ай бұрын
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 🙏
@radenmaulanarifaiabdullah1992Ай бұрын
1. payload ngga boleh ada password, data sensitif, 2. semisal terlanjur kasih username password di payload, terus dia login dari app 1, tetep valid
@Naruto-oc6miАй бұрын
@@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
@rhrkvАй бұрын
JWT ada ga sih yg ga make secret key? (saking malesnya gitu misal)
@umardev500Ай бұрын
Pertanyaan macam apa ini
@dittodhimeАй бұрын
@@rhrkv harus pake. Klo ga pake gampang sekali dilihat dan untuk memvalidasinya jg g bisa
@belajarjava-f5nАй бұрын
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
@dittodhimeАй бұрын
@@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
@edhoparisudha4012Ай бұрын
Berarti app 1 & app 2 harus punya secret key yg sama ya?
@Jin_zАй бұрын
iya bang
@samsul_devАй бұрын
btw masukin user role / permission di jwt aman ga ?
@umardev500Ай бұрын
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
@bukangariiАй бұрын
bang bahas id token vs access token di oauth dung
@ZynthProductionsАй бұрын
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
@khumammmАй бұрын
apakah secret key nya harus sama?
@Faaaklu0210Ай бұрын
@@khumammm harus dong. Krn utk produce signature itu header + payload + secret
@demostraneАй бұрын
JWE lah yang mengamankan data (data ter encryption)
@dittodhimeАй бұрын
Kembali lagi seperti yg di jelaskan pak eko bahwa enkripsi kelemahannya adalah lambat. Jadi disesuaikan kebutuhan
@demostraneАй бұрын
@@dittodhime iyah misal data nya kalau harus comply PCI DSS ya mesti ngikutin standard industri.
@LukmandstАй бұрын
mantap pak eko
@Anwar-x4jАй бұрын
Mantap pak eko
@m.ramadhanur.h7824Ай бұрын
Hmm menarique
@henrybs1550Ай бұрын
alg: none 🗿
@afdhaliapreto7703Ай бұрын
ya kalo udah gak guna itu jwt, pasti ud di bubarin itu jwt😂
@justkoding25Ай бұрын
🙂
@umardev500Ай бұрын
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
@jiwatomoАй бұрын
jwt nama gw
@pakheri1554Ай бұрын
ok
@danangardianto4717Ай бұрын
Apakah JWT bisa dipakai untuk aplikasi FE untuk membungkus payload API POST ke BE?
@dittodhimeАй бұрын
Bisa aja, yg penting jangan data penting yg di kirim melalui JWT. Karena pada dasarnya payloadnya bisa di decode
@danangardianto4717Ай бұрын
@dittodhime kalo app FE kayak react / vue / client side framework lainnya gitu nyimpen secret key nya gimana? Apakah aman?
@dittodhimeАй бұрын
@@danangardianto4717 lebih aman di middleware tp klo pertanyaannya bisa ya bisa, aman atau nggak tergantung developer ngamaninnya gmn
@radenmaulanarifaiabdullah1992Ай бұрын
@@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