Ngobrolin JWT
Ringkasan Episode
Bantu KoreksiEpisode ini membahas secara mendalam tentang JWT (JSON Web Token), mulai dari cara pengucapan yang benar menurut spesifikasi resmi yaitu "jot", hingga struktur dan cara kerjanya. Para host menjelaskan komponen JWT yang terdiri dari header (hijau), payload (putih), dan signature (biru/ungu), serta bagaimana data di dalamnya hanya di-encode dengan Base64, bukan di-encrypt. Diskusi juga menyentuh pentingnya membaca RFC dan spesifikasi teknis, dengan contoh kasus menarik tentang perbedaan perilaku redirect 301 di berbagai browser yang ternyata dijelaskan di RFC. Selain itu, dibahas juga penggunaan JWT dalam autentikasi, perbedaan dengan session-based authentication, serta best practices dalam implementasinya.
Poin-poin Utama
- •JWT secara resmi diucapkan "jot" menurut spesifikasi di papernya, bukan "jay-double-u-tee"
- •JWT terdiri dari 3 bagian: header (algoritma), payload (data/claims), dan signature (untuk verifikasi)
- •Data di JWT hanya di-encode dengan Base64, bukan di-encrypt, sehingga bisa dibaca siapa saja
- •Membaca RFC dan spesifikasi teknis penting untuk memahami behavior yang tidak dijelaskan di tutorial biasa
- •Contoh kasus: redirect 301 di-cache permanent oleh browser sesuai RFC, yang bisa menyebabkan masalah jika tidak dipahami
- •JWT debugger di jwt.io dapat digunakan untuk melihat dan memverifikasi isi token
- •Pentingnya memahami kapan menggunakan JWT vs session-based authentication sesuai kebutuhan aplikasi
[Musik]
[Music]
Halo, halo, halo, selamat malam.
Selamat malam.
- Halo semuanya. - Mana suara soundboard-nya?
Mana, pelo let, om?
[Music]
- Oh bukan ya? - Oh apaan ya?
[Music]
[Gelak]
Apa kabar, apa kabar?
Selasa malam, mudah-mudahan.
Waktunya ngobrolin web nih.
Waktunya ngobrolin web.
Apaan, nggak nungguin gitu langsung?
Selasa malam waktunya ngobrolin web.
Nggak berengan.
Kita udah lama ya, nggak berengan gitu.
Nggak berusaha berengan.
Nggak berusaha berengan, udah capek.
Soalnya waktu itu kan sempat ada sponsor,
jadi sponsor duluan.
Waktu Sasa malam.
Ya tetap aja, sebenarnya bisa aja.
Abis kelar sponsor kan bisa.
- Iya, iya, iya. - Bisa langsung aja.
Apa kabar, apa kabar?
Coba chat, itu dulu.
Apa, absent dulu.
Di kanan bawah itu nanti muncul
Lihat transkrip lengkap (2300 segmen lagi)
chat-nya.
Pengen nyobain.
Ada overlay-nya.
Fitur baru dari Streamyard.
Automatis gitu.
Coba di chat.
Halo, coba ya, halo.
Kalau gitu bahaya dong.
Nah, muncul kan?
- Kelihatan nggak? - Keren sih.
Oh iya, muncul.
Jadi kalau teman-teman...
Kok Imbre itu bahaya?
Imbre itu
teranjur image-nya.
Image-nya bahaya gitu.
Konotasinya, Imbre itu
konotasinya negatif gitu maksudnya.
Bukan, kan bahaya
bukan bahaya negatif.
Bahaya negatif lah.
Bahaya negatif, cuman kadang-kadang...
Walaupun yang ngomong
sembarangan orang lain, tetap aja
Imbre yang kena.
Padahal image-nya nggak ada.
Saya kehilangan konteks ini kayaknya
inside jokes-nya
waktu di Shanghai ya.
Enggak kok.
Dari sebelumnya.
Dari sebelumnya.
- Halo teman-teman. - Malem ini bahasa apa kita?
Yang di YouTube
yang juga di link-in.
Yang di link-in kita nggak bisa...
Comment bisa, comment bisa.
Nggak tahu masuk apa nggak.
Masuk nggak kalau di link-in?
Yang 6 ton di link-in
masuk harusnya.
Coba dulu, coba dulu.
Kalau teman-teman yang di link-in, boleh jangan komentar kayak maksa gitu.
Itu juga enak.
Jadi malam ini kita akan
bahas tentang JWT.
Tapi sebelum kita bahas tentang
apa itu JWT?
Cara penggunanya gimana?
Kenapa pakai JWT? Dan lain-lain.
Pertanyaan terbesar
yang harus dijawab sebelum kita bahas
tentang JWT adalah bagaimana
cara melafalkannya.
Nah, ya JWT.
Bahasa Indonesia.
Itu kan bahasa Indonesia.
JWT.
JWT.
Kalau bisa bahasa Inggris,
JWT.
Emang gimana?
JWT.
Kan ada kalau SQL
kan ada yang bilang SQL.
Ada yang bilang SQL.
Ada yang bilang
apa lagi? Cuma itu sih ya?
Cuma itu doang sih. Biasa yang debat kan
cuma GIF lawan
GIF doang kan.
Ada perdebatannya.
Sama itu.
Itu bukanya, pisang itu
bukanya dari mana? Dari atas apa dari bawah?
Itu juga ada perdebatan ya, Marin.
Itu bukan...
Itu doangnya itu yang gimana?
Bisa bayangin pisang ga?
Bisa.
Lu buka pisang itu dari mana?
Dari atas apa dari bawah?
Atas itu yang dekat.
Nanti ada Jusan jawab.
Nah, itu lebih kecil.
Bebas, bebas.
Itu kan ASHAB ya.
Mau yang mana, pilih. Bebaskan.
Sama kayak bubur diaduk atau tidak diaduk.
Diaduk atau engga.
Diaduk dong.
Ga diaduk itu salah.
Dan seset.
Jadi jawaban temen-temen
ternyata keliru.
Jadi JWT itu
ada pronunciasi
di papernya.
Jadi kalau buka
papernya.
Ada pronunciasi segala.
Di bagian introduction.
Di sini ada jod.
Jod.
Ga pernah sih gue pake jod.
Selalu JWT.
JWT gitu.
Terus sampe
ada spesifikasi teknisnya gitu.
Di paper lo buat apa ya?
Menarik juga ya?
Oke. Ini sering banget.
Itu dia island ya.
Jadi JWT itu
disarankan
oleh papernya atau
open standard.
Untuk ngomongin
apa? Pronunciasi atau
penyebutannya adalah jod.
Iseng banget sih.
Pasti ga disikir gitu loh.
Ga maksudnya
ya aduh.
Kayak masih ga kebayang.
Komprehensif.
Papernya komprehensif.
Sampai pronunciasi segala dibahas.
Ini bacanya
biar cepet jod aja.
Itu kan kayak.
Halo mas
Ferdy.
Ferdy Kruger.
Pedri, oh Pedri.
Sorry, salah.
Pedri.
Sudah jawabnya.
Pedri Kruger.
Tuh kan.
Salah semua kan kita selama ini
ngomongnya kan.
Ya JWT jod.
Kalo kita ngomong jod ga ada yang tau karena ga ada yang
baca papernya.
Malas juga.
Atau kita aja yang ga pernah baca papernya.
Iya.
Orang lain disekitar kita yang kerja sama
kita baca papernya atau ga?
Pasalanya kan itu.
Coba temen-temen yang ada disini
ada 9 atau 10
orang yang katanya
menonton.
Ada yang baca paper
jod ga? JWT ga?
Ga, dan itu
juga bisa ditarik lagi.
Kalau kita belajar sesuatu, baca
paper spesifikasi teknisnya
atau ga? Karena gue juga ga.
Engga.
Baca MDN ya.
Tidak pernah.
Tidak pernah.
Spesifikasi
apa lagi ya?
Kadang ga ngerti. Maksudnya kadang ga paham
cari artikel yang
ngin, tapi kayak nyampeinnya dengan bahasa
lebih ramah manusia, ada gambarnya.
Gampangnya aja deh JavaScript.
Kita berkuarkor ngomong
event loop contohnya.
Ada yang pernah ga baca spesifikasi event loop-nya?
Ya dong.
Nah kan harusnya baik ya, karena itu spesifikasi
teknis ya. Tapi kan itu
lebih baik buat yang bikin browser kan?
Bangga gitu ya, ga baca itu bangga.
Yang bikin runtime.
Yang bikin runtime JavaScript.
Iya.
Memang jarang sih ya.
Biasanya kan kita cari tutorial ya.
GraphQL saya juga ga baca
spesifikasinya.
Contoh atau demo.
Karena kan praktikal.
Ingin langsung di praktekkan
pada saat bikin produk
atau bikin tutorial atau bikin
aplikasi.
Sebagai salah satu
contohnya yang
membuat saya
2 hari lalu
memenangkan sebuah
perdebatan.
Jadi ada ceritanya gini.
Menang heketong atau menang ombak ya?
Perdebatan.
Perdebatannya lumayan ini.
Karena perdebatan
soal redirect 301.
Oke.
Karena keputusannya
sangat besar.
Permanen atau ga?
Jadi
kita lagi
memutuskan
apakah perlu memakai 301
atau 302.
Ada case di user yang
tadinya
butuh URL itu
maksudnya URL itu tadinya
ga ada
dan harus di redirect.
Tapi kemudian akan
ada.
URL itu akan dipakai.
Slug itu akan dipakai.
Tadinya ga ada.
Jadi daripada 404
mau dilarikan ke tempat lain
dulu.
Tapi kemudian user membuat URL itu menjadi ada.
Nah.
Terus kemudian
dari sisi user
dia bilang
ini gua sudah bikin URL
page itu sudah ada.
Namun tetap redirect.
Nah.
Datang lah kita
mungkin case di browser.
Kalau dipakai incognito case.
Tapi dia kembali ke kita.
Berarti user-user yang di luar sana
yang publik sudah mengunjungi
URL itu sebelumnya.
Gimana kita bisa
nge-clear case mereka?
Gak bisa kan?
Gak bisa.
Berarti kan bahaya itu kan.
Dan itu kebetulan compliance.
Jadi URL itu khusus compliance.
Jadi ga bisa ada apa-apain.
Kalau ga, kacau.
Secara compliance-nya.
Oke.
Kita telusuri. Kita sampai
telusuri sampai ke
sisi CDN.
Provider.
Dari sisi CDN provider mengatakan
engga kita ga ngasih
cash header
di 301.
Ga ngasih
cash header blablabla.
Akhirnya ditelusuri. Memang ga ada cash header.
Gak ada.
Terus kenapa si browser nge-cash?
Barulah dipahami
di pelajarisannya.
Ternyata ada di RFC
kalau 301 itu
si browser
akan nge-cash
forever.
Dan itu sesuai implementasi
si browser.
Make sense ya.
Jadi meskipun kita kirim
cash header untuk 301
ada browser yang akan mengignore.
Jadi secara implementasi
ga
sama browser satu
dengan browser lain.
Jadi dari situ juga baru belajar.
Dan setelah belajar itu
menelusurinya dengan menggunakan
Jemenai dan panjang lewati
tanya Jemenai. Akhirnya Jemenai
menunjukin ke sebuah dokumentasi
di RFC.
Barulah saya baca RFC-nya.
Oh, today I learn.
Ternyata perlu
baca RFC.
-Itulah gunanya ya. Gunanya membaca
RFC, paper,
spesifikasi, dan lain-lain ya.
Kalau udah detail.
-Nggak mendeskripsikan implementasinya.
Tapi dia ngasih inspektif
behavior-nya, ya kan?
Browser menerapinnya gimana terserah.
Nah, ya itu berarti
RFC-nya bilang
move permanently.
301 kan udah pindah nih
permanently. Ting! Yang bikin
browser, oh, permanent. Ya udah.
Dibuat permanent. Maksudnya itu understandable
banget sih ya, kalau dari
perspektif itu.
Cuma kita kan nggak baca
RFC sehari-hari.
-Buru-buru baca
RFC. Kita
developer high-level.
Maksudnya
sebuah teknologi
itu kan kita pake banyak
banget teknologi sepotong-sepotong
ya kita ambil, ya misalnya kita
pake HTTP lah ya. Kita pake
apapun itu, ECMAScript,
segala macem apalah, misalnya
event listener juga kan pasti ada
spesifikasinya. Masa kita
mau baca satu persatu?
Agak sulit juga ya.
-RFC.
RFC kepanilannya apa ya?
Disini ada nih. RFC.
-RFC.
Ya dibuka aja.
-Request for comment.
-Bukan. Request for comment.
Apa panjangannya? Request for comment.
-Oh, request for comment.
Iya.
Spesifikasi teknisnya
suatu teknologi.
-Yes. Mas Gayu itu
benar. Request for comment.
Saya baru tahu
Jot dan Oout
itu beda tapi saling melengkapi. Betul.
Kita
perlu ngomong jot atau jeli?
-Jot.
-Ngemain level dulu ya.
-Jot dong. Biar kita
bisa nge-flexing, bisa pamer bahwa
kita udah baca spesifikasinya.
-Oh iya. Soalala kita udah
baca ya.
-Ya udah baca bagian itu tepatnya.
-Request
for comment itu apa? Request
for comment itu jadi misalkan
kita bikin sebuah dokumen teknis.
Baik itu
secara publik atau internal perusahaan.
Terus mau
di review sama teman-teman
kita, itu biasanya kita
minta RFC dong. Request for comment
gitu. Benar gak sih?
-Ya, tapi kalau konteks
teknologi web kan ya
itu hampir semua
teknologi web itu kan bukan
milik siapapun ya.
Maksudnya gak, bukan punya satu perusahaan
atau apapun. Jadi
apa yang nentuin adalah
konsorsium yang
anggotanya juga banyak
dari berbagai
pihak. Ya itu buat
buat meloloskan
atau mempublish suatu
standar, standar teknis
yang berarti
mereka yang bikin, yang mempropos
bakal bikin semacam
spesifikasi teknis.
Nah itu overview-nya sih
kayak yang dibeskripsikan itu
behavior-nya seperti apa, kegunaan
seperti apa, cara pakenya seperti apa.
Nah semua pihak-pihak lain
yang konsorsium kayak W3C
atau semacamnya, ya pihak-pihak
lain bakal pada ngasih input
sampai nanti
voting atau, ya voting ya
kelihatannya voting, kalau semua
udah oke, ya they publish.
-Yuntinya ini ya,
apa namanya?
Publikasi atau sebuah
tulisan
yang dipublikasi dan kemudian
diminta untuk
mereview ya, orang lain diminta untuk
mereview. -Oleh semua
stakeholder atau pihak-pihak ya?
-Oleh semua stakeholder, ya.
Kalau ada yang tahu
misalkan untuk acara
apa namanya?
CHP, oh beda lagi ya.
Call for Paper.
-Tidak, kalau itu mah paper
buat jadi
bicara di acara itu. -Jadi gue bicara
buat teknologi yang dirilis
dipake buat ya semua
maksudnya apapun kita mau pakai
library atau framework atau
kita bikin aplikasi jenis apapun
kan tetap pakai teknologi yang
sama, behavior-nya harus sama.
-Ya, kadang-kadang
di kantor juga ada
proses seperti ini, jadi misalkan
kita punya
ide untuk implementasi
sebuah teknologi baru.
Misalkan waktu itu Ivan pernah propose apa ya?
-Denu
atau Bun, gitu ya.
Mengandikan OJS.
Sudah pakai ya? -Denu.
-Itu ada proses RFC-nya dulu nggak?
Bikin dokumen alasannya
atau langsung POC?
-POC aja, terus
kutik-kutik sama
teman sebelah.
"Ayo dong kita pakai Denu, ayo dong."
"Ya sudah, cobalah."
-Oh, ini ternyata
ada penjelasannya
RFC itu kalau buat
di IETF
ada kayak
format-nya.
Ada kayak standar-standar diskusinya.
Yang apa?
Ya, consortium yang
memproduksi standar-standar
teknologi internet, macam-macam sih.
-Ada RFC editor.
-Wuh, keren amat.
-Oh, IETF, internet
engineering task force,
ternyata ada gugus kerjanya.
-Internet
engineering task force.
-Internet engineering ya.
Oh, ada strukturnya
udah diatur ya?
-Pokoknya udah ada struktur
format-nya yang
terstandarisasi.
Format-nya bisa
ATML, bisa PlantX, atau
ATML Live.
Dari PlantX jadi ATML,
bisa PDN, bisa
SML ya.
-Yang lebih menarik, ini status
jadi bisa informasional
dulu.
Kalau baru di Godok, Pier tahu aja.
Maksudnya, menginformasikan
semua stakeholder bahwa
ada ini nih.
Iya, statusnya paling
bahkan sebelum experimental
itu ada informasional.
-Ada draft standar,
internet standar,
based current practice,
historic,
sudah jadi masa lalu ya,
sejarah. -Kalau udah pre-created.
-Kalau udah pre-created ya.
Oke, menarik-menarik.
-Jadi semua kayak udah ada
workflow-nya gitu ternyata.
-Ya, oke.
Sekarang kita masuk apa itu?
JSON Web Token.
-Jod itu harus pakai
JSON gak sih? Bisa gak sih pakai?
-SML? Namanya
udah JSON. -Namanya
Sock nanti, Sock.
-Gak bisa.
-Jadi XWT.
-XWT.
JSON Web Token
ini berarti
salah satu
apa ya, kan
awalnya kan format
pengiriman
interchangeable itu apa ya, format
bertukar data itu kan
formatnya awalnya SML ya.
Sebelum SML ada lagi gak sih?
Ya, mungkin text biasa ya.
alien text, habis itu jadi
SML,
habis itu sekarang yang terkenal ya
JSON kan, formatnya JSON kan.
Kalau kita hit
REST API apa, returnnya JSON.
Mungkin masih ada yang returnnya
SML, mungkin masih ada, tapi
bagian besar JSON.
Terus habis itu
munculah teknik-technik,
beberapa teknik autentikasi kan, salah satu
tadi dari KSA bilang ada
out-out, ada macem-macem,
jadi populer juga nih
si GWT-nya ya,
bertukar token,
bertukar token antar client dan server ya.
-Cuma sebenarnya
dari namanya, ini kayak kurang deskriptif
gak sih? Sebenarnya, apa?
Ini kan
GWT itu ada karena
kebutuhannya yaitu ada
securely transmitting, jadi kayak
justru kalau kita lihat
penggunaannya, fokusnya di secure
sama signing,
kan ini yang, signing
ini yang gak ada di
pokoknya sistem-system
pertukaran informasi sebelumnya,
jadi ada faktor yang pentingnya adalah
secure, signing, sama
yaitu bisa encrypt, decrypt, bisa
pilih jenis algoritmanya.
-Oh iya, ada lagi
kalau yang baru-baru ada yaml ya,
bener ya, ada yaml.
-Json5 itu
supaya bisa commenting. -Json juga ada banyak ya.
Json juga ada banyak, ada Bson.
-Ada JsonC, JsonC
yang bisa ada comment-nya.
Tapi terlalu json5
supaya bisa commenting kan.
-Oh json5 ya, bukan
jsonS ya, keren.
Oh iya, jsonK ya, harusnya comment ya.
Json5.
Apa namanya,
kalau,
kita kembali ke Jot ini dulu ya.
Jot ini awalnya itu
kayak, di desain itu sebenarnya
untuk komunikasi sih,
transmitting information.
-Ya, transmisi data kan,
pertukaran data.
-Authenticasi itu
adalah salah satu
implementasi karena ada
pertukaran data di sana aja.
Cuman bukan, json5 itu
bukan khusus untuk autentikasi.
-Ia dijual terpisah gitu.
-Oh, khusus autentikasi.
Json web token.
-Memunakan json web token.
-Nah, si sebenarnya
data yang
dibawa sama json web token
saat di-transmit itu sebenarnya
hanya di-encoding
base64 aja sebenarnya.
Jadi, sebenarnya
kalau kita ada json web token,
kita decode,
ada sih sebenarnya
data-nya bisa kelihatan,
json-nya itu kelihatan.
Namun,
yang terpenting di sini ya,
menurut pengalaman,
yaitu signing,
digital signing-nya itu loh,
signing token-nya itu yang antara di,
nanti di-echornya sih,
kalau di-headernya kan ngasih tahu
dia pakai,
algoritma apa,
terus kemudian body,
terus kemudian ditutup sama
sign key-nya.
Nah, kita di sisi server
punya private key-nya
untuk
memvalidasi
si sign token-nya itu.
Kalau sign token-nya itu
tidak valid,
kita tidak perlu process
dah tuh body-nya.
Berarti ya itu sudah ada campur tangan
something di tengah-tengah.
Itu scenario.
Authorization itu cuma salah satu scenario
yang dipakai, yang menggunakan
teknik.
Di dunia nyata,
umumnya developer ketemu,
pertama kali ketemu JWT,
ketemu Jod, ya pas karena
penggunaan authorization kan.
Walaupun penggunaan lain juga bisa.
Cuma yang paling umum adalah
authorization.
Karena
kalau di web itu biasanya untuk
information exchange itu
terbuka, jadi datanya
dilihat nggak apa-apa kan, kayak recipe I
gitu kan.
Meskipun tidak semua.
Kalau misalkan kita mau kirim sesuatu
yang rahasia, gunakanlah
JWT.
Tapi sebenarnya
rahasia seperti apa?
Nggak bisa juga sih, Mas.
Kalau rahasia misalnya sangat
penting, nggak bisa juga pakai JWT.
Karena body-nya itu
bisa di decrypt tetap.
Tetap bisa ya, walaupun
kita nggak punya private key-nya.
Coba aja cari contoh.
Ada kan debuggernya? Cari contoh
JSON Web Token deh.
Dibuggernya
token.io
Eh, salah.
Oh iya.
Ini.
Oh iya, ini
yang ijo itu apa?
Ini ada 3 kan, ijo, putih,
sama biru.
Yang
itu generate example coba
pencet dulu, generate example.
HS
HS aja, HS 256.
Udah.
Contohnya kan
sudah ya, sudah.
Kalau ganti mungkin baru panjang.
Oke.
Payload-nya itu kan sebenarnya cuma
itu kan, sub, name, sama
admin kan, itu yang di tengah
yang warna putih.
Iya, putih isinya. Ijo
atas, putih tengah, yang
ungu atau apa itu.
Yang ungu itu
adalah
sign token-nya.
Nah, kalau misalnya mau kita lihat ya
coba di-copy aja yang putihnya.
Copy.
Copy yang putihnya aja.
Nah, cari
Base64 decoder
di online.
Base.
Decode.
Jadi sebenarnya bisa gitu.
Panjang, jadi cuma Base64 decode
aja, encoding Base64
aja, gak ada yang di-encrypted
disitu. Cuma
ekornya tadi
yang si warna
biru ini
adalah
yang mengatakan
saya menandatangani
message ini.
Si klien, si klien menandatangani
message ini. Nanti di server
yang si penerima
memvalidasi, oke
surat ini
valid nih
message-nya dari si klien A.
Itu misalnya.
Jadi baru bisa diproses.
Jadi, yang
utamanya adalah
standarisasi disini adalah cara
melakukan signing-nya
dan cara melakukan
validasinya. Isi itu standarnya.
Nah, ini di debugger
coba aja. Itu kan kursornya
30 tuh di paling
bawah. Dihapus aja 1 karakter
coba. Nanti
jadi merah. Scroll kebawah.
Scroll kebawah.
Nah, signature verification
failed karena
secret-nya yang buat matching adalah
string secret blablabla itu. Nah,
sekarang balikin lagi tuh. Nah,
valid. Jadi, masih biar
gak bisa diutak-atik pihak
yang tidak
berenang. Ini
Base64 juga, bukan? Base64
juga. Oh, enggak, itu
dipake HS256 itu
algoritma itu.
Itu, itu, itu. Yang HS
algoritma-nya itu
dia mengambil
hash. Menjenerate
data itu.
Banyak sih yang dijenerate pakai
pakai
ini, si hash
dari body.
Terus kemudian
si key-nya
tadi, yang pakai key-nya
tadi, terus ada
beberapa pakai algoritma
HS256 itu.
Oh, jadi ini
secret-nya. Gak bisa
apa? Kalau tadi kan tinggal dikopas
aja tuh yang karakter yang dikolom
kiri tuh, terus di decode
Base64. Nah, kalau
yang bawah itu gak bisa.
Kalau mau ganti key-nya, generate
ulang. Ini udah
generate tadi. Oh, harus pilih dulu.
Sekarang ganti
badan. Oh,
harus di generate ulang.
Karena example
Oh, gak bisa ya?
Bisa sih, harus ya.
Tapi...
Bisa.
None.
Kalau none,
gak itu ya, gak ada secret-nya ya.
Oh, ini udah nggak.
Tapi gimana cara
nge-gerate ulang ya?
Gak ada di sini.
Ya, begitulah.
Oke.
Saya cuma tahu pakai,
tapi gak tahu standar ini-nya.
Saya gak tahu seluk beluk.
Nah, ini ada nih, strucure
dan teknisnya. Ya, sama-sama.
Sebagai pengguna, cuma tahu sejauh ini aja sih.
Nah, untuk validasinya sih
sudah pakai library yang sudah
exist. Pakai aplikasi.
Di atas kan ada tuh link-nya.
Ya, selama ini juga gitu.
Kalau
yang PHP ada di Firebase,
punya Firebase JWT.
Ada library-nya.
Sudah ready-made.
Jadi sebenarnya gak tahu banget.
Cuma ya udah, sambil dibaca tuh.
Ya, kalau header itu berarti kita kasih
tahu bahwa algoritma yang digunakan apa.
Tipenya adalah
JWT tadi.
Kemudian kalau payload-nya sendiri,
itu base 64.
Terus, apa nih?
Claims are statement about the entity.
Atau data ya.
Registered public
and private claim.
Public claim itu
this can be defined at will
by those using JWT.
But to avoid collision,
they should define in
IANA JSON Web Token
registry or be defined as
URI
that contain a collision resistant namespace.
Kalau yang private, custom
claim created by share information
between parties. Biasanya ini ya.
Yang umum ini ya. Kita pakai ini ya.
Contohnya, ya
macam-macam ya. Bisa ID,
bisa email, dan lain-lain.
Admin true.
Apakah saya
ganti admin false jadi true?
Ya itu, kalau gak design,
kalau algoritma-nya not,
ya bisa diganti kan.
Nah, ini kan yang tengah bisa diganti
tinggal pakai
base 64 encoder
aja kan.
Kalau misalnya, kalau gak
designing algoritma-nya,
misalnya di header tadi, out
titik 2 non, gitu. Ya bisa
tengahnya diganti sesukanya kan.
Adminnya jadi false atau adminnya
jadi true.
Bisa jelasin ini gak
proses
apa namanya
flow-nya dari
mulai request, kemudian
sampai kita balik lagi ke
kliennya untuk
JWT-nya sendiri.
Sejujurnya, cuma pakai library
selama ini.
Atau sampai bawah aja dulu.
Baca artikelnya sampai bawah
dulu gimana?
Itu ada pertanyaan bagus tuh.
Apa tuh?
Secara keamanan
lebih baik PHP session
atau PHP session?
Hah?
Secara keamanan lebih baik PHP session.
Dibandingkan sama
JWT maksudnya.
Ya.
Sebenarnya JWT
Oke.
Kita bandingkan aja.
Kalau kita menggunakan
authentication, ini khusus
authentication ya. Jadi si user A, si user B,
user C, login lah.
Simple-nya.
Kalau pakai JWT
dia
gak state, gak nyimpan
state di server.
Ya.
Unstateful ya bahasanya ya.
Atau kalau session itu stateful,
JWT itu non-stateful.
Stateless, stateless.
Stateless. Nah.
Mas Riza bahasanya lebih baik. Stateless.
Nah.
Akibatnya apa?
Kalau JWT itu,
scalability-nya lebih bagus.
Karena kita gak perlu simpan session tadi,
gak perlu simpan state di server.
Sedangkan kalau misalnya
stateful, secara
scalable, lebih sulit.
Karena contohnya kalau ada
container-base.
Yang bisa kembang-kempis nih.
Kembang-kempis web container-nya.
EM-nya lebih dari satu ya.
Ya. Akibatnya.
Session yang tadinya kita
kunjungi di mesin A sama
mesin B gimana? Akhirnya harus nambah
lagi namanya Redis
atau third party.
Key value store lah. Harus kita simpan key value.
Jadi session itu
bisa disimpan. Session management ya.
Ya. Mau di database kek.
Atau mau di key value
kayak Redis.
Atau Memcash. Pokoknya yang bisa cluster deh.
Gitu ya. Sendiri gitu.
Berarti kan nambah biaya.
Sedangkan kalau si
JWT stateless,
kita mengenali si klien
berdasarkan dia punya
signing token.
Oh dari signing token, ini si X. Tahu.
Dah. Gitu ya.
Namun secara keamanan
saya nggak bisa bilang banyak
karena JWT ini sudah
industry standard juga ya.
Kalau
PHP session apalagi
lebih aman atau tidak
tergantung konfigurasi.
Jadi sebenarnya secara keamanan,
dua-duanya sudah standard yang sama.
Secara industry standard dipakai.
Tinggal mau pakai yang mana.
Ya.
Ini pertanyaannya untuk satu VM.
Kalau nggak,
nggak banyak,
kalau nggak,
nggak banyak,
mesin?
Nggak banyak mesin.
Dan cuma
user-nya sedikit, ya mungkin
nggak perlu pakai yang rib.
Kalau JWT lebih banyak setup-nya.
Awalnya. Oh berarti ini ya.
Ada flow autentikasi kan.
Ya.
Secara keamanan mungkin sama-sama
aman, tapi
secara simpliciti, kemudahan
mungkin lebih mudah via PHP session ya.
Kalau untuk satu VM. Yes.
Kalau misalnya request-response
aja yang
server-side rendering, standard
pakai traditional.
Tapi kalau sudah SPA,
SPA,
lainnya terpisah,
lebih mudah
menggunakan JWT untuk komunikasinya.
Mungkin itu
jebedanya.
Dua-duanya kalau dikonfigurasi
dengan benar, aman kok.
Ya. Secara keamanan sama,
cuma
tergantung kebutuhannya pada
saat VM-nya apa, mesinnya
satu atau lebih, itu
atau
dipisah antara apa, monolitik
sama ya, bukan monolitik ya, apa ya,
yang front-end sama back-end-nya
terpisah atau yang jadi satu-semua.
Itu
pemilihannya disitu.
JWT ribet.
Iya benar. Ribet.
Lanjut itu dong.
Kita lanjut ya. Lanjut ya.
Ini payload ya, payload kan
teman-teman data yang mau dikirim ya.
Dan terakhir,
nah, yang bawahnya itu, baru
tersanggannya, signature.
Itu tuh, header tambah payload,
tambah secret.
Eh, salah, header tambah payload,
di-encode
pakai secret.
Ya, encode pakai secret dengan
algoritma apa?
Biasanya in practice, ini tuh udah ada
library-nya, jadi sebetulnya sampai sekarang
buat gue dan mungkin banyak
developer lain.
Maksudnya, ini dia apain?
Ini cara kerjanya gimana? Sebenernya
jujur nggak tahu sih, karena ini
umumnya sih pakai library
yang udah jadi ya.
Tinggal encrypt
kita masuk-masukin itu aja, itu kayak
yang dilihat itu.
Mending, masih pakai
library. Jaman sekarang
udah pada pakai autentikasi
library, eh bukan library
lagi, ya library, autentikasi
kayak out-zero, terus apa lagi banyak
ya sekarang. Firebase out atau apa?
Firebase,
Cognito, apalagi itu yang sekarang
banyak loh.
Itu lebih-lebih abstrak lagi ya.
Semakin abstrak.
Oke, kalau digabungnya jadi seperti ini,
ini header, ini content,
ini sitnya, Ca.
Nah, itu
wording-nya, phrasing-nya
menarik sih itu tadi,
kejawab yang tadi
kita bahas di awal banget,
katak sedikit deh.
Output-nya cukup
kayak Base64 URL string
dipisah oleh titik,
jadi kayak gampang ngirinya,
jadi salah satu keumulannya adalah
mudah dikirim
di HTML dan HTTP
lebih compact dibanding
XML-based standard.
Nah, tadi kan kita bahas tuh.
Itu saya paling
pusing dengan
baca XML.
Kalau sudah SSO,
SSO kan pakai,
kalau SSO kan pakenya XML,
XML-based.
Single sign-on?
Iya.
Yang ini ya, maksudnya ya, pakai
yang dari Azur itu
apa namanya?
Active Directory.
Active Directory.
Itu masih pakai XML.
Nah, ini yang tadi saya mau
tanya bagaimana
proses flow-nya.
Jadi kan dari
browser, atau dari
JavaScript, pokoknya
kita mau akses
sebuah res API
yang dilindungi
oleh akses scheme.
Ya, kita pakai
header authorization,
terus pakai bearer,
ditambah tokennya kan.
Nanti dari server,
ngeliat header itu,
dia cek si tokennya
valid atau nggak.
Kalau valid, lanjut.
Kalau valid, maka
dibuka frank access-nya,
dikirimkan datanya.
Dan ada timenya juga,
ada time frame juga loh.
Ada timenya.
Bisa expired juga.
Ini kan protected routes ya.
Akan ngecek apakah JWT-nya valid
atau nggak.
Kalau valid, maka
datanya atau
dibukakan aksesnya,
jika JWT contains
the necessary data, the need to query
for the data.
Oh ya, kita bisa juga kirimin data kan.
Jadi header-nya bearer, token,
kemudian kita post. Datanya kita
kirimkan untuk disimpan ke database,
misalkan, bisa
si apa,
si server-nya akan melakukan query
atau mengeksekusi query
untuk insert data. Ya, dicek.
Ya, ada maksimalnya.
Ya, itu standar lah.
Limitasi jatah yang dikirim di header ya.
Yang berusaha.
Ya, jangan semua data user
ditaruh di tengah itu ya, jangan.
Ya, bisa kepotong soalnya.
Masih penasaran kenapa
tidak token
langsung, tapi harus pakai bearer.
Sama asli, kenapa ya?
Terima kasih.
Sama asli, kenapa ya?
state ini, pengalaman pribadi pernah
gara-gara. Oh, skema-nya.
Ya, bearer, skema.
Emang ada selain bearer?
Selain bearer, berarti ada
ada kayak keyboard lain.
Saya cuma menerima nasib
aja kalau dokumentasi mengatakan
pakai bearer, pakai bearer.
Coba kita lihat. Apa sih bearer, skema?
Selain bearer, skema.
Kayaknya ada ini deh.
Ada itu lain ya? Ada kayak keyboard.
Ada penanda lain.
Ada kayaknya.
Ardy selamat datang menujuin.
GWT bisa di decode, bisa.
Senahnya ya.
Ya, harus.
Karena ini tujuannya kan
saling ngirim
informasi ya.
Nah, ini dia flow-nya.
Jadi dari klien
kirimin
token
ke server, dari
server, kirimin balik.
Kemudian,
kalau valid ya, kalau valid
kirimin balik, kemudian kita bisa
apa namanya?
Token yang valid
apa ya?
Token yang dinyatakan valid oleh server
kita bawa ke
server yang ada datanya.
Ya.
Membuka akses
terhadap resource yang sedang kita lindungi.
Oh, dikasih
kunci lah ya ceritanya ya.
Eh, saya mau akses ini nih.
Karena kita ngecek tanda-tanganya.
Betul nggak ya tanda-tanganya?
Kalau cocok.
Ya, silahkan masuk.
Ya, jadi
kalau kita mau minta sesuatu
ke data ini
kita harus lewat dia dulu, dicek apakah
permintaan
atau request kita itu
dilegalisir atau nggak ya?
Dilegalisir.
Kayak sertifikat
kayak ijazah, harus
setempel basah.
Wah, setempel basah.
Tangan basah.
Basah beneran.
Sekarang sudah
sertifikat loh.
Karena tangan juga digital, masa-masa
dilegalisir ya.
Sama
digital signing key.
Digital
signing key.
Maka jadi
ada istilahnya
akses token ya. Berarti dari
server, authorization server
ngirimin akses token ke
client atau ke browser.
Dari client ini, mau
request API
atau resource, mau ngambil data
itu harus menggunakan akses token ya.
Yang valid.
Sekarang juga memberi tahu
siapa dia.
Si identifikasi.
Identifikasi.
Siapa?
Kan itu penting itu. Dia hanya
boleh akses berdasarkan permisinnya
dia. Nanti kan di J-wait itu ada
permisinya, ada user ID-nya.
Oh iya.
Itu bebas kan. Kita mau
gimana kan. Kalau misalkan semuanya user
yang dianggap sama juga boleh-boleh aja.
Terus ada
aplikasi.
Oh ternyata ada
sort. Ini bacanya sort ya.
Jot dan sort.
Simple web token.
Baru tahu nih, simple web token ada ya.
Apakah dia...
Belum pernah pake dan belum pernah liat.
Nah dan
sama security assumption
language.
Simmetically signed by a shared
secret using the
HMAC algorithm.
Kalau Jot sama-sama
pakai public-private key.
JSON is less
verbose than
XML. Yes.
It's encoded, it's size is also
smaller. Yes. Karena kan
kalau XML ada
buka penutup.
Ada persistnya.
Ada banyak ya.
Ada logo.
Ada GDG.
GDG.
Ada ini yang XML kan?
Benar.
XML.
XML nggak ada.
SVT nggak dibahas SVT.
Karena ini kan situs
JWT.
Secure wise, security wise.
Cuma bilang bahwa
apa, mungkin
signing optionnya terbatas kali ya.
Nggak bisa milih.
Kalau SVT can only be symmetrically
signed
by a shared secret.
Jadi secret yang nge-signed sama
secret yang nge-validasi
sama.
Artinya kurang
secure gitu. Kurang secure.
Kalau JWT
bisa
asymmetric, bisa
private key sama public key.
Ya.
Oh itu sebabnya jadi nggak dipake ya.
Tuh, bedanya tuh.
Panjang sekali.
Antara yang ini sampe ini.
Jauh ya.
Karena datanya besar.
Ini samil soalnya itu.
Iya ini.
Dari opening
closing aja udah banyak dia.
Kalau
JWT, kalau Jason kan cuman
kurung kerawal atau kurung Siku kan.
Iya.
Saya berkutat dengan samil selama
hidup saya dan saya capek dengan
itu.
Ini barulah screenshot satu aja.
Udah capek kok.
The difference between validating and
verifying.
Apa ini? Validation.
Validation.
Pemastikan tokennya itu
formatnya betul.
Tokennya betul dan
contains enforceable claims.
Bisa diproses kali ya
berarti. Nah verifikasi
baru memastikan tokennya
genuine, asli, dan
tidak diutakkan.
Coba kita lihat.
JWT validation.
Oh coba. Nah JWT validation
tadi berarti sebetas bentuknya
aja ya.
Ada header payload signature
dipisah oleh titik formatnya
betul. Base 64
beneran bisa di decode, bisa di encode.
Claim content apa tuh.
Oh ada kayak expire.
Expire-nya, issue-nya.
IAT dan
lain-lain. Udah expire atau belum.
Berarti dia belum nge-check
isinya apa? Legitimate
atau kayak.
Ya sama kayak kita subdued dokumen lah.
Ini duit tangan ini belum. Kalau belum ya
di-check-in gitu. Mungkin gitu ya.
Salah satunya. Jadi
di-check port strukturnya.
Udah ada header content dan
signature atau belum.
Formatnya base 64 bisa di decode
atau enggak. Sama isinya itu
mengandung
beberapa data seperti
expire date, issue
ad dan lain-lain.
Berarti kan kayak field-field-nya itu key-nya betul.
Field-field-nya dibutuhkan ya.
Kalau verification
itu di-check signature-nya
valid atau enggak.
Terus issuer
verification.
Issuer claim matches
unexpected issuer.
Issuer ini orang yang
request ya?
Iya.
Bukan.
Issuer itu yang
nge-generate si token.
Oke.
Ya kalau tadi kayaknya si out-zero.
Out-zero.
Ya yang provider-nya ya.
Yang buat token.
Issuer itu yang buat token.
Iya.
Iya.
Yang generate token di awal ya.
Oke.
Audience check.
Ensuring the audience claim
matches the expected audience.
Oh yang tadi akan sebutin ya?
Apakah dia punya...
Bukan ya? Beda ya?
Ya ini
step-by-step untuk
verifikasi si token-nya
kan ya?
Iya. Verifikasi.
Ya panjang sih ya.
Saya enggak mengerti 100%
di sini.
Tapi kita harus mengerti ini sekarang hari ini.
Validate GVT makes a token makes
sense.
Terus...
Intinya adalah kalau validasi itu
memastikan token-nya
sesuai dengan format
yang di setujui.
Kalau verifikasi
itu isinya benar.
Kalau ini formatnya benar,
ini isinya benar.
Nah cara meng...
Kita kan pengen, ini kan kita mau belajar
bagaimana cara memverifikasi
supaya tahu isinya benar itu tadi yang di atas kan.
Nah signature verifikasi.
Berarti kan
di-decode lagi.
Tunggu ya.
Signature doesn't match what
expected the token might have temple.
Dia kan di-encrypt
pakai kayak
algoritmonnya tadi.
HMAC misalnya.
Terus...
Tadi yang
kalau nggak salah base 64 header
titik
sama base 64 payload
sama secret.
Ya kan? Itulah jadi token.
Jadi
di sisi server, itu juga akan
dicoba, di...
di generate ulang seperti itu
dan dilihat hasilnya sama nggak.
Gitu ya.
Kalau sudah
lolos ini,
issuer verifikasi ini, dan audience check ini
saya nggak mengerti malah.
Bagaimana caranya?
In practical terms.
Nah, dia ngasih practical terms.
You validate.
Kita mau validasi JOD
untuk memastikan
tokennya make sense.
Oh, itu kan jadi validate ya.
Verify. Nah, kalau verify berarti intinya
tokennya belum
diputak-atik, belum
dimodifikasi.
Dan datang dari
sumber yang kita percaya.
Nah, itu berarti kayak issuer
verifikasi.
Issuer verifikasi berarti issuer
yang buat token, kalau audience
itu yang pakai.
Kayaknya benar.
Yang pakai tokennya.
Audience yang pakai token.
Cek GPT dulu.
In many systems,
kedua langkah ini di
combined, disebutnya
GWT JOD verifikasi.
Yang terdiri
dari validation dan verification.
Sejujurnya sih
selama ini pakai, coba deh, bukan
di private chat.
Ini tuh salah satu library yang
paling umum ya, JSON Web Token.
Nah, itu tuh kayak udah ada
metode-metode-nya sih kayak verify.
Nah, jbt.sign,
jbt.verify.
Verify.
Terus apa lagi?
Ya udah banyak, ya scroll aja ke bawah
liat contoh-contohnya metode-nya.
Ya intinya sih kayak jbt.sign,
jbt.verify.
Verify.
Gimana-gimana?
Ini buat authorization.
Gimana?
Ini buat authorization
si jbt.
Untuk, sorry,
untuk process login ya,
ceritanya ya.
Menggunakan jbt.sign untuk process login.
Sekarang kita, ya intinya
dulu.
Tadi abis nanya chat jbt.sign,
ini sama-sama belajar aja ya.
Kelihatan nggak sih?
Belum, belum.
Ulang lagi, ulang lagi. Remove dulu.
Remove dulu.
Ya, tunggu-tunggu.
Terus, dah.
Eh, gimana sih?
Udah tadi, udah tadi.
Ilang.
Tunggu, belum di-share.
Sudah?
Loading, loading, udah.
Nah, udah.
Oke.
Zoom in, zoom in.
Oke. Jbt.
Ya, sudah. Kita tadi ada header, payload,
sama signature.
Di payload tadi,
di payload-nya itu ada ISS,
ada sub, ada, ada,
ini kayak issuer, sama audience,
sama expired date.
Sub itu saya nggak tahu apa.
Oh, iya, iya, iya.
Jadi, sebenarnya token
untuk memastikan si,
itu adalah si user x,
kita selalu ngebawa ISS,
audience, sama expirednya itu.
Itu kan tadi yang register
claims, itu kan yang claims,
kan tadi, inget nggak, di atas, pas bahas body,
kan ada kayak public claim,
blablabla, claim lah pokoknya.
Nah, itu kan yang register claims-nya kan.
Ya, lanjut.
Oke, oke.
Claim meaning,
ISS identifies
the token issuer,
usually identity provider,
OIDP,
or authorization server.
Ya, ini berarti isinya adalah
provider-nya. Auth0 misalnya,
atau Firebase,
atau nama server-nya deh,
ada identity-nya biasanya.
Terus, kemudian,
the extract,
terus,
compare to
pre-configured trusted
issuer, yorai, open,
and sdtps yorai.
Oke, berarti misalnya kalau pakai Auth0,
ISS-nya itu
adalah HTTPS, Auth0,
blablabla. Seperti itu ya, sebagai
identity provider-nya ya.
Make sense, make sense.
Ya, kita matching aja kan,
harus matching apa yang
pre-defined yang kita tahu, yang kita pakai kan
servicenya.
Sandanya, ini diroba,
berarti kan hashing-nya semuanya berubah.
Karena jika salah satu dari sini berubah,
semua hashing-nya kan,
signature-nya kan berubah.
Makanya, nggak bisa dibata datanya,
nggak valid kalau misalnya ISS-nya itu
salah.
Terus, kemudian,
claim,
meaning audience
specifies the intended
recipient of the token. It can be
a single string or an array.
Sebenarnya nggak dijelasin
siapa sih misalnya.
Isinya apa, berarti suka-suka ya, bebas.
Kalau saya,
pembuat aplikasinya
yang server lah,
beratnya server yang nentuin,
yang penting kan matching kan.
Jadi dari siapa untuk siapa,
kalau bahasa begonya, berarti kan
dari siapa untuk siapa itu
dari jodnya
sama servernya, harus
paket, harus sama kan.
Kalau dari siapa
berbeda, berarti itu
udah kayak, udah itu nggak bisa dipercaya,
stop.
Oke.
"Please make an example of
jod when it comes from
Auth0 and..."
Oke.
Iya, kita tanya aja.
CWT,
saya nggak tahu apa kit.
YOTenant, Auth0,
audience-nya,
oh, hanya boleh,
audience-nya itu hanya boleh, mungkin situsnya
kita kan... -Course tadi ada,
ini ada isu course kan tadi ya?
Kalau nggak salah. -Iya kan bisa
API, apa?
URL,
REST API kita, apa mungkin
mau kita limit by endpoint kan bisa.
Itu kan ya mesti free, isinya
suka-suka kita, yang penting harus sama.
Itu aja kan.
Nah.
Yang verifikasinya tadi ya, kit
kita skip aja kan, dan mungkin
spesifik ya. Ada lagi
bahasanya kit, nggak tahu itu apa.
Berarti kan kita cek isuurnya,
berarti
hal ini kan kita bisa simpan
di server, karena ini static ya,
kita tahu pakai Auth0 kita punya
konfigurasinya
sebagai tenant.
Dan kita bisa cek juga
identifernya,
kalau, ini kan datanya
kan didapat dari saat
kembali dari Auth0, dan
si token ini hanya bisa
dipakai jika kita mengakses
URL tertentu.
Yang kita
define di sini.
Jadi waktu JSON web
token yang dikirimkan ke URL
hanya bisa dipakai di URL yang kita.
Yang kita
daftarkan di sini juga.
Oke.
Jelas, jelas, jelas.
Ngerti, mengerti.
Berguna juga.
Berguna juga AI
untuk belajar.
Teman-teman, ada yang masih pusing?
Atau makin pusing?
Jadi intinya misalkan kita
pakai...
Ini benar nih kata mas Kaisa,
JWT ribet aja.
Sebetulnya kalau tidak
peduli-peduli kayak tadi kan tinggal
masuk-masukin aja, nah cuma
apa yang terjadi ya, sekarang kita jadi tahu.
Itu tadi TIL.
Tapi kan
berarti jadi lebih make sense sih. Sebenarnya kalau
pakenya kan tinggal pakai library yang
udah ada, pakai metodnya, verify.
Nah berarti kalau isunya
ISS atau apa claim-claimnya
tadi ada yang nggak cocok ya, bakal direject
juga kan.
Iya.
Dan kayaknya dari library-nya udah
dimasukin secara
otomatis ya, ISS dan
audiensenya tadi ya.
Atau kalau kita mau
menambahin juga bisa ya.
Ya, pokoknya server dan
client harus kumpak lah.
Nah, pas kita nunggu skodinya ya kita harus
apa?
Masuk-masukin argumen yang
expected.
Hmm.
Oke.
"Bisakah OA
selain JWT?"
Mana dia?
Belum disiap. Ini pertanyaan menarik sih.
Ini pertanyaan menarik, tapi
kalau nggak pakai JWT, pakai apa dong?
Berarti kan harus ada cara buat
kayak kirim
memastikan animasi user yang
itu atau bukan.
Samel tadi, ya kan? Samel.
SWT.
Asal tahu cara pakenya berarti.
Asal tahu cara pakenya.
Samel bisa dipakai untuk autentikasi kan?
OAuth 2 bisa
tanpa JWT.
Pakai apa?
OPEC token.
Apa itu?
Maksudnya, ya kan
OAuth 2 kan
hanya token begitu saja ya.
Kita tadinya mau mengirimkan
OAuth 2 tokennya itu sebagai
part dari
autentikasi dan saat kita
mengirimkan data ke server kita
menggunakan token itu.
Jadi sebenarnya OAuth 2 token itu bukan
bukan bagian dari
JWT
atau JWT.
Sebentar, baca lagi ya.
Namanya OPEC tokens.
Share screen aja, share screen.
Oke. Kita share screen lagi.
Coba belajar bersama.
Pertanyaan lagi juga menarik, tapi
kita jawab abis ini ya.
OPEC berarti
step full.
Gue tanya, OAuth
without JWT, yes OAuth bisa bekerja
pakai OPEC token sama
self-contained
tokens often JWT. Ya, udah ini salah sih.
OAuth 2
without JWT
atau JWT, client flow
as unchanged token format resource OK.
The response include
whether active or not.
Jadi data yang dikirimkan
example into
response seperti ini.
Ya, gak jelas.
Katanya kenapa?
Kita pilih OPEC token,
simplicity, confidentiality,
and legacy. Bisa,
tapi sudah legacy.
Oh, kata Mas Kesa tadi
bener tuh. Berarti kalau misalnya
dia tampak JWT
jadinya token
OOP2-nya itu disimpan di server
jadinya step full.
Itu bedanya ya.
Step full dan step plus.
Karena
tokennya itu kan
kunci untuk mengakses banyak hal
sebenarnya.
Yang OAuth 2 token ya, maksudnya.
Bukan JSON Web Token.
Jadi sisi user, setiap
request di header-nya, kirim apa?
Gak kirim apa-apa? Gak ada. Mungkin
pakai cookies saja. Jadi session.
Jadi si server
jadi proxy
untuk ke API.
Misalnya kita pakai
Google API.
Google API kan pakai
OAuth tuh untuk
komunikasinya.
Anggap aja
Google Analytics API.
Kita kan sebagai user autentikasi
dulu, masuk ke Google,
login, habis sudah kita
kasih permission, kembali
dapat OAuth 2 token.
Kita simpan OAuth
2 tokennya di server kita.
Di sisi client, misalnya kita bikin
aplikasi yang mau minta data
analytics.
Mungkin hari ini
gitu ya. Atau page view hari ini
berapa gitu. Si JavaScript
akan request ke
API ya kita.
Terus server kita tahu
kan, ini si user
yang sudah login, mau request
analytics. Dari server
kita jadi proxy menggunakan
token OAuth token tadi ke
Google Analytics API.
Ambil datanya, balikin.
Jadi kan jadi proxy aja.
Tapi itu kan stateful, karena tokennya
disimpan di server.
Jadi butuh server ya.
Apakah perlu pakai
access dan refresh token menerapkan
best practice atau cukup pakai access
token saja?
Best practice-nya tuh
adalah sebetulnya bukan refresh
tokennya sendiri, tapi access tokennya
nggak boleh terlalu
long live. Kayak nggak boleh. Makin
jadi apa? Itu kayak manajemen
Resiko sih. Makin lama
expiry-nya si access token,
makin besar risiko.
Lake atau kecolong atau
apa ilang. Nah, berarti kan
solusinya kayak access tokennya
durasinya harus dibatasi.
Nah, itu kan retop-nya sama UX.
Mungkin tidak tergantung
industri sih. Kalau kayak banking gitu kan
malah nggak ada refresh token kan.
Kita misalnya website
bank, ya
5 menit atau 3 menit ke lockout
ya udah login lagi. User harus
take username sama password di mana.
Maksudnya itu ada
jenis website yang
ya emang standard
practice-nya begitu. Cuma kalau kayak
yang email atau sosmed
dan lain-lain, ya user marah-marah
pasti kalau setiap
sejam sekali atau setiap berapa jam
sekali harus login ulang kan.
Jadi, nah,
refresh token kan solusinya kan
buat menyembatani
kebutuhan security sama
kebutuhan UX.
Iya, iya, iya. Benar, benar, iya.
Cara lockout JWT gimana?
Blacklist kan? Blacklist.
Ini aja di clear.
Clear.
Clear apa? Reforge. Reforge.
Reforge. Reforge.
Bisa request ke server, Reforge,
jadi session token yang, apa,
sorry, token yang tadi ada. Tidak valid lagi.
Iya ya, kita request
ke server,
minta tolong sama server untuk
membuat si
public key atau ya
public key-nya tidak valid gitu ya.
Atau signature-nya tidak valid.
Bukan signature kan.
Key-nya lah ya.
Key-nya tidak valid ya.
Kalau di sisi user kan tinggal hapus
aja cookie-nya. Nah,
kalau dari server, apa ya, di invalidate ya.
Nanti kan nabis sendiri juga
kan, apa, expire sendiri.
Iya, akan expire juga
memang, betul, betul.
Nah, invalidate-nya gimana ya?
Yang mau,
apa, mau tahu
lebih lanjut, di sini ada
link ke bukunya ya.
Buku apa?
Buku JWT.
Handbook for free
dari OutZero.
Harus
belajar banyak sih.
OutZero itu punya ebook gratis
banyak itu,
scroll aja ke bawah.
Jadi ada paski juga
introduction. Sebenernya nggak
mendalam banget sih, cuma kalau pengen tahu cara kerjanya
ya, baca ebook-nya itu.
Jadi ada delapan
chapter ya.
Tapi jujur
kok baca segila skimming?
Nggak ngerti.
Nggak ngerti.
Kalau bacanya diniatin
tuh, bawahnya.
Tuh, bawah. Nah, itu.
Ah, blur.
Apa?
Ini?
Bukan.
Coba ke atas aja, scroll ke
paling atas. Ya, salah satunya itu ya.
Cuma kalau mau lihat semua, ebooks.
Ngerjain breadcrumbnya.
Oh, out.
Nah, itu dia.
Ada
apa lagi ini? Ada paski sih.
Cuma, ya, sebagian ada yang
tentang produknya mereka. Cuma ada yang
general
tentang security juga.
Make your UX dance with
Siam. Apa ini Siam?
Samel.
Nah, paski Siam Hanbu.
CSP itu.
For dummies.
Authentication after password.
Menarik ya.
Kita share lah ya.
Resource ebooks.
Oke, tadi untuk bahas yang tadi
yang pertanyaan Mas Kaisa yang
yang cara
nge-invalidate
token itu, memang
ada salah satunya deny list
atau blacklist tokennya.
Bisa juga di sisi server.
Atau bisa pakai short TTL
untuk akses tokennya.
Jadi
5-5 menit aja.
Ya, expire sendiri.
Cuma, tetap harus
ada cara destroy-nya kan ya.
Harusnya server-side.
Harus di-rotate.
Ya, kalau itu kan berarti kayak TTL
aja kan tadi, expire sendiri.
Rotate itu.
Signing key-nya, rotate ini.
Oh, private key-nya.
Private key-nya.
Private key-nya di-rotate.
Begitu di-rotate, semuanya kan
invalidate.
Semua token yang sudah
desain pakai
semua client, jadi
force lockout ceritanya.
Karena lagi-lagi
karakternya dia stateless ya
sebetulnya.
Jadi kayak nggak bisa di
baru baca lagi.
Itu kan.
Kita
pakai, tetapi sebenarnya nggak tahu.
Ini lah salah satu contoh
nyajot.
Belum tahu lebih
dalam. Taunya cuma kulitnya
doang. Yang penting bisa
menyelesaikan. Ya, tahu cara pakai.
Tapi belum tahu dalam cara kerjanya.
Tapi senang sih karena ada
episode ini kita jadi tahu.
Karena
apa ceran topiknya
ini juga kan di chat?
Siapa?
Ceran ini siapa kemarin?
Kaisa bukannya?
Gak tahu.
Saya kan dari
GitHub di session.
Gak, dari chat kemarin.
Gara-ganti keybase practice gimana
biar tidak lockout semua user-nya kasihan.
Kasihan, biar sih.
Cara blacklist itu.
Blacklist itu.
Caranya blacklist
kalau bahasanya issue tokens.
Ya, blacklist yang
si...
kalau bahasanya JTI. JTI itu apa sih?
JTI.
Cara kick semua user.
Ini yang bawah malah chaos gini mau
kick semua user.
Yang tadi kan cara kick semua user yang tadi.
Ya, tadi udah komen bawahnya.
Nah, komen yang atasnya.
peduli user.
Yang paling simpel ya. Berarti emang
TTL-nya. Maksudnya expire-nya dibuat
cepet aja kan.
Itu lumayan bikin masalah sih.
Walaupun gak ngejawab pertanyaan yang tadi ya.
JWT ID-nya
kan tetap ada di server.
Nah, itu di
di
di destroy atau di blacklist.
Dihapus dari database.
Oh, iya.
Waktu itu pernah ini apa?
Saya pernah ngalamin waktu pakai
Vertex AI.
API-nya Google Cloud.
Itu
TTL-nya cepet.
Jadi harus
degenerate terus-menerus
setiap kali request, hampir
setiap request.
Oh, mau tahu
ide, dapet ide
random lagi, kalau user lockout.
Jadi kita handle separately dari
jangan mikir JWT-nya.
Cuma kalau user lockout, dari sisi user
ya selain cookies-nya dihapus
either kasih cookies
baru, kayak lockout add
atau semacamnya.
atau restore aja di database
database data user lockout pada
jam sekian.
Nah, kalau misalnya masuk.
Jadi dibikin satu cek lagi.
Apakah user barusan lockout?
Ya bisa juga.
Jadi misalnya TTL kita berapa?
Satu jam.
Kalau misalnya user lockout
sebelum, kan kita
cuma perlu ngantisipasi untuk
keperluan keamanan, ngantisipasi
waktu antara setelah user
lockout sampai
issue-nya
TTL-nya expire.
Ya dicek aja dihitung.
Kalau misalnya setelah user
lockout, masih
tiba-tiba ada request
dari user itu, berarti kan
itu pansu, itu bohong.
Belum pakai sih
ini cuma
random idea
aja.
Ada lagi yang mau dibahas?
Best practice-nya itu tadi
bikin sort TTL aja.
Ya, cuma maksudnya
ini ngantisipasi
setelah user lockout sampai TTL-nya
expire. Kan kita nggak tahu user-nya
lockout-nya short-nya misalnya satu jam.
Tapi misalnya
expire-nya baru nanti
user lockout-nya sekarang.
Kalau farno
banget soal security,
dicek aja user
terakhir lockout kapan.
Habis user lockout
rupanya ada network glitch.
Ada request ghost.
Itu beda lagi
kasusnya. Kalian berapa lama
waktu access token dan refresh token?
Biasanya umumnya.
Standard 3600 ya?
Eh berapa satunya?
Ini ya, dari
Auth0 atau Faribas itu
kayaknya sudah nggak ngatur
begituan.
Itu nggak luah
ngubah konfigurasi ya?
Nggak, nggak ngubah
konfigurasi, kecuali
diminta. Sudah dimanjakan dengan tools, tapi good
question sih sebenarnya.
Kalau
access token, yang
pernah saya kerjakan,
authentication-nya itu pakai
30 menit.
Dan refresh token-nya
itu bisa. Refresh token-nya 1
bulan gitu. 1 bulan.
Ya, nggak tahu lah.
2 minggu atau 1 bulan
atau 3 bulan. Tapi kalau Google API
Google API saya tahu itu refresh token-nya
6 bulan.
Refresh token-nya. Sampai apa?
Terlalu sering dulu.
Tapi kalau yang
yang access token sendiri
itu sejam sama
Access token kayaknya standard 1 jam ya?
Ya, antara 30 menit sampai 1 jam
pokoknya scope-nya
begitu.
Kemarin pakai Vertex AI
setiap kali kita ngirimin
apa? Request
itu bikin
token baru.
Oh.
Oh ya?
Iya. Karena yang saya lakukan
pertama adalah, saya jalanin ini
kan. Google
Google Cloud. Oh, kalau kopas dari yang sebelumnya
nggak mau lagi. Gak bisa kan statif kan?
Iya.
Jadi secara dinamis dia langsung
jalanin setiap kali
request.
Nah itu solusi kayak yang tadi kita bahas
cuma versi extreme ya sih?
Berarti kan tiap request
baru lagi
ya, token baru.
Waktu itu
masalahnya di sini. Saya udah
apa? Abis kopas, kok masih kena
red-linie? Itu iya.
Kadang sama.
Kadang sama. Jadi dia
prosesnya itu di G-Cloud-nya ini
dia
TTL-nya. Dia ngecek TTL-nya masih
hidup atau nggak, masih valid
atau nggak. Kalau masih valid, dia pakai yang lama.
Kayaknya gitu sih.
Tiap request berpanjang expired date.
Bisa juga.
Bisa, bisa. Kan si JWT itu ada expired-nya.
Expired date-nya.
Tapi itu
signing token-nya berbeda-beda tuntut terus.
Bisa nggak ya?
Kayaknya nggak bisa deh.
Nanti
signing token-nya jadi beda.
Nggak bisa.
Expired-nya nggak bisa diubah.
Nggak bisa ya?
Iya. Jadi
udah berubah intinya ya.
S-nya berubah.
Waktu di decode.
Eh, di encode.
Oke.
Gimana? Cukup?
Cukup.
Cukup. Kalau cukup, berarti saatnya
kita memilih topik untuk
minggu depan.
Punya topik lagi? Kayak kemarin?
Minggu lalu? Yang bahas
yang minta bahas JWT? Kayak saya ya?
Kalau nggak salah ya? Langsung dari chat ya.
Jadi teman-teman yang live, yang hadir
live sekarang itu punya privilege.
Bisa suggest topik
langsung.
Kalau kita bisa. Atau kita belajar
kalau kita mau.
Kalau menarik.
Kalau kita nggak mau ya tetap bisa
diposting di
discussion juga kan?
Ya, betul.
Buku lagi dong.
Buku lagi? Oke.
Buku apa?
Growing Algorithm.
Growing Algorithm?
Udah baca belum?
Belum.
Udah beli. Baca beberapa halaman pertama.
Makanya
makanya pengen bahas
biar maksa buat baca.
Ada intinya nggak?
Tuh.
Save 45%.
Mending kalau mau buku 2 minggu lagi deh.
Karena kalau beli takutnya telat nggak
nyampe jadi nggak bisa tahu deh.
Kurang mendalam ya
bahasanya ya.
Iya, bebas sih ya.
Aditya
kok namanya kayak nama Indonesia ya?
Ya, kita lock aja
2 minggu lagi kita
Growing Algorithm.
Oke, 2 minggu lagi Growing Algorithm.
Oke, saya cekati dia.
Cari bukunya dulu.
Episode
sekarang 147 berarti 149.
Kalau
boleh bagi saya.
Episode
minggu depan berarti 148.
Ada yang membahas
CSS.
Aduh, CSS PDF.
CSS PDF.
Apa ya?
Bahas toolkit boleh nggak?
Toolkit, toolkit.
Nggak.
Toolkit kayaknya
menarik.
Yang mana ini? Toolkit?
Biar upgrade ya?
Iya.
Buat ganti-ganti
yang... Sekalian pengen belajar aja juga
webpack sama turbo pack.
Oke, mau ini?
Ya boleh. Toolkit modern nih.
Perlu di-vote? Nggak perlu?
Kita Veto aja.
Veto aja ya.
Maaf ya.
Void Zero. Mana Void Zero?
Void Zero.
Void Zero itu perusahaan
yang mengembangkan VT.
Bukan?
Kita kayaknya pernah bahas ya. Cuma lupa.
Void Zero itu kan
yang ini kan?
EFANU kan?
Yang dia bikin semua
kayak apa? Kayak ngerombak
ekosistem JavaScript Tooling
itu kan?
Yang di-announce
di VT Conf
apa gitu.
Ini kan?
Iya, yang di-announce.
Timnya adalah
benar, EFANU.
Dia bikin modern Toolkit.
EFANU.
VT, VT,
Scrolldown, OXC itu.
Sebagian besar yang kita pilih disini.
Kita pernah bahas ini kan?
Ya, kita pernah bahas.
Website-nya ini.
Betul.
Oke, deal ya. Berarti
kita bahas modern.
Oke.
Sambil kita belajar...
Groknya di mana?
Di Amazon, Kindle.
Amazon, Amazon.
Oh, cari yang fisik.
Kalau fisik ya Amazon, bisa
cuma nunggu mirimnya lama sih.
Gatau kalau Kindle
di Amazon.
Kalau di Toko Ijo
tata-tata pangsu.
Ya, bacakan pasti.
Kapan lagi? Minggu depan.
Selasa malam.
Ingat, selasa malam waktunya ngobrolin web.
Ngobrolin web.
Supaya gampang ingat. Senin, harga naik.
Selasa, waktunya ngobrolin web.
Itu
ide-nya Eka itu.
Iya, benar.
Cuma gue juga
nggak ngulang catchphrase
itu lagi sih.
Buat t-shirt bagus sih. Buat t-shirt
bagus. Jangan, jangan, jangan.
Eh udah liat pisanya kita
belum sih.
Waret tuh yang punya
duluan tuh.
Intinya apa namanya
sampelnya dikasih satu.
Langsung kasih warat.
Ilham baru ya, baru join ya.
Kita live setiap
Selasa jam 8.
Tungguin aja minggu depan.
Topiknya kita minggu depan bahas
toolkit modern
yang mungkin bisa menggantikan
beberapa
alat bantu yang biasa kita pakai
jadi lebih panjang.
Biasanya ditulis dengan RAS.
Biasanya pakai RAS.
Biasanya pakai RAS atau yang
lain yang lebih modern gitu ya.
Misalkan kayak webpack ya.
Kan konfigurasinya yang jelimet
tuh. Nah sekarang udah ada
banget kan. Mungkin temen-temen
ada yang sudah tahu, ada beberapa
yang juga belum tahu.
Kita akan bahas minggu depan. Oke.
Untuk malam ini kita udahan dulu.
Kenapa?
Pakai roll up.
Roll up, roll down ya. Banyak ya.
Ada roll up, ada roll down.
Iya.
Jadi kita tunggu minggu depan untuk
pembahasan tentang JavaScript toolkit
modern. Kita ketemu lagi
minggu depan.
Jangan lupa Selasa malam waktunya
ya. Bye bye.
Bye bye.
Deskripsi asli dari YouTube
🗣️🕸️ Selasa malam waktunya #ngobrolinWEB! Malam ini akan membahas tentang JWT, auth, acess token, refresh token dll. Tentu saja bersama Ivan dan Eka. 🔔 Akan mulai mengudara pukul 20:00WIB ya. Yuk mari diramaikan! Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
9 Agu 2023
Ngobrolin URL
Episode ini bagian dari niat baru mereka: menyelipkan topik yang benar-benar mendasar setidaknya sebulan sekali, alih-al...
26 Mar 2025
Ngobrolin Design Pattern
Episode ini membahas tentang Design Pattern dalam pengembangan software, sebuah topik permintaan dari Mas Azam Aziz. Dis...
10 Jan 2024
Ngobrolin CORS
Episode ini membahas tentang CORS (Cross-Origin Resource Sharing), salah satu topik yang sering membingungkan developer ...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .