Ngobrolin Otentikasi
Ringkasan Episode
Bantu KoreksiOtentikasi dibedakan tegas dari otorisasi lewat analogi bandara: mencocokkan wajah dengan paspor dan tiket itu otentikasi — memastikan orangnya memang dia; sementara boleh masuk gerbang yang mana dan boleh melakukan apa itu otorisasi. Seorang pilot dan seorang penumpang sama-sama terverifikasi identitasnya, tapi izin yang mereka punya berbeda. Kebutuhannya sendiri muncul karena HTTP itu stateless: server tidak tahu siapa yang datang kalau tidak diberitahu, dan hanya sebagian sumber daya yang boleh diakses semua orang. Empat pendekatan dibahas. API key membedakan kunci publik yang boleh tertanam di sisi klien dan kunci privat yang haram keluar dari server — inilah alasan layanan seperti payment gateway mengharuskan kita punya server, dan mengapa meta framework atau serverless function jadi jalan keluar bagi yang sebelumnya hanya punya aplikasi sisi klien. Skema dasar HTTP juga dibandingkan: basic sekadar mengirim nama pengguna dan kata sandi dalam bentuk base64, sedangkan bearer mengirim token yang bisa dibatalkan dan punya masa berlaku. OAuth dijelaskan lewat alur single sign-on: ada server otentikasi tersendiri, dan setiap domain lain mengalihkan pengguna ke sana lalu menerima token sebagai jawaban — sehingga satu kali masuk cukup untuk banyak layanan. Diakui pula bahwa OAuth mudah bagi pengguna tapi merepotkan bagi yang mengimplementasikannya. Terakhir JWT, dengan satu penekanan penting: bagian payload-nya bisa dibaca siapa saja, yang menjaga keamanan adalah tanda tangannya.
Poin-poin Utama
- •Otentikasi memastikan siapa kita, otorisasi menentukan apa yang boleh kita lakukan — pilot dan penumpang sama-sama terverifikasi tapi izinnya berbeda
- •Kunci privat tidak boleh ada di sisi klien karena bisa dilihat lewat view source; inilah alasan payment gateway mengharuskan kita punya server
- •Meta framework dan serverless function menjadi jalan keluar bagi aplikasi yang tadinya murni sisi klien tapi butuh operasi yang harus terjadi di server
- •Bearer lebih aman daripada basic karena yang dikirim berulang kali adalah token yang bisa dibatalkan dan punya masa berlaku, bukan nama pengguna dan kata sandi asli
- •Single sign-on bekerja lewat server otentikasi tersendiri: domain lain mengalihkan pengguna ke sana, lalu menerima token untuk diverifikasi antar server
- •OAuth mengembalikan access token berumur pendek beserta refresh token berumur panjang, dan izin yang lebih sensitif harus diminta lewat scope terpisah
- •Payload JWT bisa dibaca siapa saja — yang menjaga keamanannya adalah tanda tangan, jadi server harus menolak permintaan yang signature-nya tidak terverifikasi
2. Halo, halo, halo. Halo, selamat malam, selamat malam 2.
Ketemu lagi kita bersama trio ngobrol in web malam hari ini.
Seperti biasa di hari Sulasa malam. Waktunya apa teman-teman? Waktunya ngobrol in web.
Malam hari ini tidak ada tanda live karena kita kembali lagi terpaksa harus rekaman.
Kita rekamannya ini di miw malam. Jadi nggak terlalu jauh ya bedanya ya.
Kita rekaman karena ada kesibukan. Jadi nggak bisa hari Sulasa.
Mudah-mudahan tidak mengurangi keseruan kita malam hari ini yang membahas topik autentikasi.
Apa itu autentikasi? Kenapa butuh? Dan beberapa hal yang berhubungan dengan autentikasi.
Masih bersama kita bertiga. Masih ada Ivan, masih ada Eka, masih ada saya Riza.
Dan buat pengingat aja, cara ini ya ngobrolan kita bertiga sebenarnya.
Dan harapannya sih ngobrolan, diskusinya juga bisa mengalir ke teman-teman.
Kalo misalkan teman-teman yang bekerja dengan web. Iya, kalo misalkan teman-teman ada topik atau ada topik diskusi yang menarik gitu ya,
bisa kita diskusikan juga. Atau jika teman ingin bisa bergabung, juga bisa sampaikan ke kita, kita ajak kita ngobrol-ngobrol juga.
Iya. Nah, kalau tidak di luar live video, teman-teman punya pertanyaan atau topik diskusi,
bisa langsung aja ditulis di bit.ly/ngobrolinweb. Kita pasti baca dan kita sangat mengapresiasi saran dari teman-teman yang bagus-bagus ya.
Kita juga banyak ambil ide-ide dari topik-topik yang disarankan oleh teman-teman semua.
Ini juga keliatannya topik malam ini salah satu yang udah lama diusulin di Slido itu.
Jadi kita umpulin, terus kita keluarkan di saat yang pas lah ya. Kalo lagi penasaran.
Yes. Oke, jadi malam hari ini seperti yang udah saya sebutkan tadi, kita akan membahas tentang
berbagai cara untuk kodentikasi di web ya atau di platform atau di protokol HTTP lah gitu secara umum ya.
Jadi bukan hanya client dan servernya, clientnya udah belum tentu juga browser ya.
Bisa aja mobile, bisa mungkin embedded device, bisa macem-macem, tapi dia berjalan di protokol HTTP atau...
- Protokol HTTP. - Iya. Atau yang biasa kita gunakan untuk ini ya,
menampilkan halaman web gitu. Protokol standarnya web lah gitu ya.
Oke, mungkin kita bisa mulai dari apa itu otentikasi? Ada yang bisa menjelaskan secara singkat gitu?
Otentikasi itu proses memastikan bahwa seorang user atau suatu akun itu memang betul dia.
Misalnya ada user datang mengaku saya adalah A. Nah, otentikasi itu proses memastikan bahwa itu memang A.
Kurang, kalau pendeknya gitu kali ya. Coba perjalanannya.
Seperti yang kita pernah pelajari sebelumnya tentang cookies atau yang sebelum-sebelumnya storage ya,
server itu sebenarnya tidak tahu atau istilahnya stateless. Tidak tahu siapa yang datang kalau enggak.
Lihat transkrip lengkap (536 segmen lagi)
Kalau enggak dikasih tahu. Kalau dia enggak memberitahukan, "Ey, saya itu Ivan loh."
Saya kita kunjungi sebuah situs, apapun lah ya situs, dan kita si server itu enggak tahu siapa kita kalau kita enggak kasih tahu.
Nah, setelah kita memberitahu server, "Hei, saya itu Ivan." Server itu harus bisa melakukan proses verifikasi.
Nah, itulah proses verifikasi itulah bagaimana si server bisa mengautentikasi saya itu adalah Ivan,
dan saya boleh diberi masuk, dan saya bisa diberikan datanya si Ivan.
Kalau enggak ya enggak bisa gitu. Itulah umumnya.
Nah, terus ini kalau bahas kan tadi request adalah stateless, berarti kan implikasinya ini kenapa sampai ada keperluan buat autentikasi.
Nah, karena ada resource yang boleh diakses semua orang, dan ada resource yang belum tentu boleh diakses atau dilakukan semua orang, ya kan.
Jadi untuk public resource, itu kan kalau public resource semua boleh baca.
Misalnya gampangnya kalau situs berita semua orang kan boleh nge-request blog post atau artikel terakhir.
Ya, enggak ada keperluan, enggak perlu mastiin apakah kamu Ivan, apakah kamu Eka, kan enggak perlu.
Ibaratnya kalau analogi tempat, kita di tempat umum nih kita ke taman atau kita ke jalanan, ya kan enggak ada yang menghentikan kita,
enggak ada yang menghentikan kita, ya udah kita mau lewat suatu jalan, kita jalan aja.
Tapi kalau kita mau masuk misalnya stasiun kereta api atau bandara masuk ke gedungnya, itu lain kasus kan.
Kita harus buktikan identitas kita. Nah, tiket itu kan ada tiket, ada KTP, nah ini bakal nyambung ke icon selanjutnya.
Yang jelas kita enggak boleh se-enaknya masuk karena itu hal yang resource yang tidak boleh diakses semua orang.
Ya, jadi kalau misalkan ada hal yang misalkan tadi apa situs berita atau blog lah.
Blog mungkin orang, mungkin blog saya, Ivan, dan Eka bisa baca gitu ya.
Tapi yang bisa entry artikelnya, yang bisa memasukkan artikelnya ya cuma bisa saya gitu.
Bagaimana caranya ya mungkin nanti ada apa lizafahmi.com/admin gitu kan.
Terus ada masukan, biasanya masukan password. Nah, itu adalah cara mengetahui apakah saya punya apa bisa masuk atau enggak gitu.
- Nah, jadi kalau emang resource-nya publik semua, ya udah enggak perlu sama sekali.
Authentikasi itu emang enggak perlu. Ini akan perlu kalau itu tadi ada misalnya kalau blog post,
ada dashboard admin-nya yang harus bisa diakses orang tertentu aja.
Atau mungkin ada private post yang masih status-nya draft, mungkin bisa dibaca oleh editor atau apa,
cuma tetap enggak boleh diakses oleh user lain. Nah, itu skopnya autentikasi.
- Ya, ada juga apa namanya kalau misalkan tadi blog-nya kan, blog pribadi.
Kalau misalkan blog-nya yang umum misalkan kayak medium gitu kan.
Medium itu bisa memastikan bahwa artikel yang kita tulis atas nama kita, misalkan atas nama Riza,
ya hanya saya, begitu. Begitu Ivan login dengan akonnya, maka di halaman dashboard-nya atau di halaman admin-nya,
itu artikelnya artikel Ivan, bukan artikel saya. - Hanya gabar saya aja.
- Iya, jadi kalau multi-user, ya berarti dia memastikan bahwa data-data yang diakses,
itu hanya data milik kita yang login. - Berarti kita bisa pisahkan antara autentikasi dan otorisasi.
- Nah, ini poin selanjutnya. - Otorisasi gimana tuh?
- Ya itu tadi seperti yang Mas Riza, kalau misalnya di sebuah ruangan VIP,
hanya boleh orang VIP yang punya kartu VIP-nya yang boleh masuk, itu namanya otorisasi.
Kalau tadi yang selalu saya login ke Medium, hanya saya bisa melihat artikel yang saya tulis,
saya tidak bisa lihat artikel yang Mas Riza tulis, itu kan otorisasi.
- Oh itu masuknya otorisasi ya? - Iya.
- Nah, analogi lagi nih, kalau tempat tadi kan kalau yang publik tuh jalanan atau taman atau ruang publik lainnya,
kita jalan mah lewat-lewat aja, nggak bakal di-stop kan. Kalau kita masuk bandara, kan kita ada 2 hal.
Hal pertama, ya maksudnya kita punya misalnya sebagai penumpang, kita punya tiket, flight tertentu,
kita berada di gate yang benar, misalnya kalau tiket, kalau penerbangan kita domestik gitu,
ya kita nggak bakal boleh masuk ke gate-nya internasional kan, karena itu hal yang kita lakukan adalah mau masuk gate untuk terbang sebagai penumpang.
Itu otorisasi hal apa yang bisa kita lakukan, sedangkan otentikasinya adalah ngecek,
nyamain nama di paspor atau KTP dengan nama di tiket, sama biasanya kalau di gate kan kita seru buka masker,
buka masker nunjukin muka tuh. Kan sih orangnya, si tugas bandara kecek apakah identitas, tiket, dan orangnya itu sama,
nah itu otentikasi, sedangkan otorisasi itu kita boleh masuk gate mana dan boleh ngapain.
Nah kalau misalnya pilot ini bukan penumpang, kan pasti otorisasi hal yang boleh dilakukan si pilot atau pramugari itu kan beda kan,
dia boleh masuk mungkin pintu-pintu lain yang kita sebagai penumpang nggak bisa, walaupun kita sebagai penumpang punya tiket,
punya KTP, udah nunjukin, ya tetap aja kita nggak boleh masuk kan, kita nggak boleh mengakses tempat tertentu atau melakukan hal tertentu
yang boleh dilakukan oleh pilot atau staf atau tugas.
- Hmm, iya, iya, iya. Oke, jadi malam ini kita... - Otorisasi itu siapa kita sama otentikasi siapa kita,
otorisasi itu hal apa saja yang boleh dilakukan.
Apa yang boleh kita lakukan, ya. Dan malam ini kita akan membahas tentang otentikasi dan mudah-mudahan di episode-episode mendatang
kita akan bahas tentang otorisasi juga ya. Oke, nah berkaitan dengan otentikasi, salah satu referensi yang menarik ini ada dari MDN,
tentang otentikasi melalui protokol HTTP, ini ternyata si HTTP sudah memberikan istilahnya framework ya untuk kita melakukan otoritas.
Ya, melakukan otentikasi melalui HTTP yang disebut sebagai basic schema.
Di sini ada apa ya, spesifikasinya lah ya, tata caranya, prosedurnya, gimana caranya flow dari orang yang meminta identitas,
meminta validasi identitas atau otentikasi, kemudian akan dijawab oleh si server ya.
Kira-kira gambarnya seperti ini ya, ilustrasinya. Jadi, client ini bukan hanya web browser.
Biasanya kita menyebut client browser ya, tapi di sini bukan. Siapapun interface yang ingin mengakses, yang ingin melakukan otentikasi.
Jadi itu bisa berupa suatu aplikasi web. Ya, aplikasi web kan bisa terdiri dari client side, server side, itu sepenuh satu aplikasi, atau aplikasi mobile, atau aplikasi apapun itu.
Yang penting, protokolnya HTTP. Jadi, request-nya belum terjadi dari browser, atau mau terjadi dari comment line, atau mau terjadi dari HTTP client seperti postman.
Ataupun library-library yang digunakan di mobile juga bisa ya. Semuanya, pokoknya selama HTTP client, kita menggunakan HTTP client itu bisa dianggap sebagai clientnya dari server.
Server di sini adalah tempat di mana data user dan berbagai proses validasinya terjadi di server ya.
Jadi, proses checking-nya ada di server. Jadi, semacam service API, atau service yang menghandle logic, business logic, sama database, dan lain-lain.
Ya, jadi kita pertama kan si client ini melakukan request, "Eh, saya mau login dong," gitu kan. Habis itu dianggapin, atau di response 401, karena kita tidak terlalu...
Ini tempat terkunci. Ya, misalkan kita mau /admin atau /dashboard, gitu. Oh, nggak boleh, kan. Jadi, biasanya itu di redirect, ya. Di redirect, akhirnya masuk ke halaman login, gitu kan.
Kalau di sini, ini kan yang basic out ya. Basic out itu yang kayak pop-up itu aja. Pop-up dari browser, tahu nggak? Pop-up dari browser yang kayak...
Oh, kayak FTP ya, kalau buka FTP dari browser, gitu kan. Oh, iya, iya. Kalau jangan dulu kita buka FTP, gitu, ada username password, gitu.
Iya, iya. Terus minta username sama password. Dan ini tidak spesifik terhadap user. Hanya basic out biasa.
Ya. Terus habis itu dikirimkan, ya mungkin, ini metodenya banyak ya. Nanti kita juga mungkin akan bahas sedikit ya. Ada yang basic, ada yang macem-macem gitu. Ada yang ngirimin token, ada yang ngirimin username password, dan lain-lain, habis itu dicek.
Kevalidasinya dicek di sini, usernya benar nggak sih? Username ini atau token ini punya kapabilitas untuk memasuki area tertentu. Kalau iya, maka kembalinya adalah status 200 dan oke.
Atau kalau gagal, ya kembali lagi ke 401. Gagal 401 seperti awal. Gitu. Itu ini sederhananya ya. Ada banyak lagi turunan-turunannya yang sangat bermacam-macam, gitu.
Semakin secure, semakin sulit lah kita. Ada yang harus pakai handphone lah, harus pakai auto-tiketer lah, macem-macem ya. Nanti kita juga akan bahas sedikit. Tapi yang mau kita bahas selanjutnya adalah tentang skema.
Skema yang paling umum sebenarnya basic sama bearer. Dan itu masing-masing, nah yang lain itu nggak tahu. Mungkin teman-teman ada yang pernah punya pengalaman pakai yang lain-lain itu bisa di-post di komen. Karena kita belum pernah.
Iya, yang paling sering kita gunakan adalah yang basic sama bearer. Yang basic seperti tadi. Iya, yang basic ini seperti ini. Jadi kita kirimin token yang kita dapatkan, gitu ya.
Mungkin dari login juga atau dari mana gitu ya. Dan satu lagi adalah bearer. Bearer token juga hampir sama ya modelnya ya. Kalau teman-teman familiar dengan OAuth.
Iya, kita kirimnya, selalu kita kirim. Kalau yang basic itu, basic itu simple, yang paling simple itu cuma base number 4 dari username titik 2 password.
Jadi sebuah string di base 64. Jadi itu isinya. Kalau bearer itu. Token, yang di encode tokennya ya. Akses token.
API key, ada API key untuk nge-generate token. Jadi ada hash key. Jadi lah tokennya. Nah tokennya itu nanti, kalau tadi kan tulisannya authenticate, titik 2 basic, spasi, base 64.
Kalau bearer authenticate, bearer langsung hasil hashnya tadi, tokennya itu.
Jadi kalau bearer itu kelebihan nya lebih secure mungkin ya. Karena yang dikirim, jadi setiap request atau apapun yang dikirim adalah tokennya bukan username sama password langsung kan.
Jadi kalau ada apa-apa, bisa di-invalidate tokennya. Atau ya biasanya kan akses token itu ada masa hidupnya, setiap bakal valid berapa lama, bisa di-refresh.
Biasanya begini, kalau sebuah aplikasi, bayangkan sebuah aplikasi, anggapnya aja WordPress deh.
Pasti simple, ada username login. Kalau basic authentication itu kan, nggak mungkin kita, kalau kita ada client API, contohnya client-side JavaScript.
Kalau yang kita kirimkan itu adalah username password kita, itu kan bahaya ya. Orang bisa akses langsung.
Sedangkan kita bisa set dari aplikasi, kita bikin namanya application password. Jadi hanya password aja yang mengidentifikasi kalau itu punya saya.
Dan kalau misalnya itu pun bocor, itu nggak akan bisa dipakai untuk mengakses account secara admin. Karena hanya bisa akses mungkin API-APA tertentu aja ya kan.
Barrel token itu lebih aman daripada yang basic out. - Menarik. Ada apa lagi sih tipe-tipe selanjutnya?
Mungkin kita bisa lihat di artikel yang kedua ini ya. Walaupun judulnya tentang REST API, tapi ini juga bisa berlaku untuk non-REST API.
Yang grafql, gRPC, macam-macam ya. Jadi ada beberapa cara. - Mungkin detailnya bakal sedikit berbeda,
tapi kita di sini lebih lihat ke pola-polanya ya, workflow-nya secara umum. Nah, ini yang barusan dibahas, Evan, yang baru banget.
Gimana caranya kita melakukan mengamankan API kita yang mungkin tidak boleh diakses oleh publik?
Bisa menggunakan yang pertama tadi API key, yang barusan dibahas Evan ya. API key, gimana caranya ini ada ini?
- Biasanya ada public key sama private key. Jadi private key-nya nggak boleh disimpan di mana-mana, termasuk di client, nggak boleh ada.
Private key itu hanya ada di server, jadi public key-nya yang dipakai oleh komunikasi antar.
Kalau misalnya punya client-side JavaScript, kita bisa embed public key-nya di JavaScript application kita
yang kita pakai untuk generate token tadi. Nanti token-nya dikirimkan, diauthenticate pakai private key.
- Private key itu harus di server-side ya, di sisi server ya. Nggak boleh disimpan di sisi client karena bisa dilihat.
Namanya private itu kan nggak boleh dibagikan, gitu ya. Kalau ada di sisi client, kita bisa view source,
terus kita bisa lihat kuncinya. Nah, makanya, ini ada beberapa pertanyaan juga yang muncul ya, cukup sering muncul.
Makanya beberapa service seperti Payment Gateway itu mengharuskan kita punya server, nggak boleh langsung dari client.
Karena dia harus menggenerasi entah itu token ataupun punya private key, harus disimpan di server, tidak boleh di client.
- Untungnya sih kalau disambungin ke implementasi, ya ini framework.
Maksudnya kalau kita cuma pakai yang mentahan React, swell, itu kan masih client-side web browser ya.
Jadi mungkin agak sulit kalau harus server-side. Nah, di sini perannya meta framework.
Jadi sekarang udah lumayan banyak ya, meta framework. Kalau kita pakai React, ya bisa pakai Next atau Gatsby atau Remix.
Kalau pakai Swell, bisa pakai Swell Kit. Terus semua bisa pakai Astro. Jadi ada banyak meta framework
yang bisa berfungsi secara full-stack itu jadi satu solusi. Jadi kalau dulu mungkin kita harus bikin satu aplikasi lagi,
misalnya Express atau KoA, kita harus punya aplikasi Node.js. Terus dari aplikasi React kita,
manggil ke server itu, sekarang bisa ada alternatif lain pakai meta framework yang di satu aplikasi udah full-stack.
Ada sisi browser-nya, client-side-nya, ada sisi yang cuma bisa dibaca di server untuk melakukan operasi seperti ini.
- Ya, alternatif yang lain yang pernah saya kerjakan adalah dengan menggunakan itu serverless lambda.
Jadi kalau misalkan kayak Netlify, Netlify kan hanya client-side ya.
Nah, kita semudah membuat sebuah folder dengan nama functions, didalamnya kita bisa punya server dalam tanda kutip gitu.
Jadi hal-hal yang seperti ini bisa kita tangani di sana. Jadi mungkin kalau nggak mau full-blown langsung ke meta framework,
bisa coba lambda server ada di Netlify, ada di versel juga kalau nggak salah ya. Jadi ada di mana-mana.
Kalau lebih sederhana. Tapi kalau misalkan, wah kayaknya ribet nih, harus pakai AWSK atau pakai GCPK atau yang lain gitu kan.
Nah, mungkin opsi untuk menggunakan meta framework lebih cocok gitu ya.
- Nah, cuma Netlify sama Versel juga sekarang udah bisa ngehosting server-side. Jadi maksudnya itu tergantung complex-side.
Iya, bisa. Jadi misalkan kita punya Next.js, bisa dihosting di Netlify atau Versel.
Node server-nya, jadi mereka sebenarnya under the hood itu pakai AWS.
- Iya, iya. Masih gratis ya? - Ada free tier. Free tiernya gratis.
Iya, gratis ada sekian menit, sekian ratus menit batasnya running compute time.
- Nah, ini ada pro dan cons-nya ya. Kenapa kita perlu menggunakan? Karena mudah dan ya gampang lah ya, cepat juga ya.
Dan lebih fleksibel. Nah, disadvantage-nya adalah security. Security-nya lemah ya.
- Paling gampangnya, ini si GitHub token. Bayangkan aja GitHub token. - Oh iya, token.
- Iya, GitHub token. Kita bisa bikin GitHub personal access token, seperti API key.
Jadi kita bisa access GitHub API dengan menggunakan personal access token untuk mengakses data-data yang kita punya di GitHub.
Bisa bikin repo, bisa search repo, bisa macem-macem, lihat PR gitu ya, full request.
Bisa destroy repo juga kalau memang dikasih aksesnya.
- Ya, kalau sempat bocor ya. Oke, kita lanjut ke yang kedua ya. Ini option kedua adalah yang juga mau, apa, yang sekarang ini lagi hype ya, OAuth ya.
Yang versi 2 itu apa namanya, sekarang lumayan banyak yang menggunakan ya.
Jadi kalau teman-teman menggunakan service tuh misalkan kayak Twitter login, atau apa lagi, oh, GitHub login juga termasuk.
- Ya, Facebook login. - Oh, Facebook login, ada macem-macem service yang menyediakan service untuk login
sehingga user tidak perlu register. Memudahkan ya, terutama kalau teman-teman yang bikin produk baru.
- Menggunakan akun user. - Akun yang sudah ada, akun social media biasanya ya.
Jadi daripada kita harus suruh user register, masukin username, masukin password, email, apa segala macem gitu, hobby gitu ya.
Lebih baik kan kita misalkan menggunakan Google atau Facebook atau Twitter, kita bisa ambil data public ya, data public atau data private di sana.
Kemudian kita login dengan menggunakan salah satu akun social media kita.
- Nah, keunggulannya, bukan keunggulan sih, cuma OAuth 2.0 ini adalah standar.
Jadi sebenarnya bukan library, OAuth-nya sendiri bukan library, cuma ada beberapa library yang mengimplementasi ini.
Nah, ini adalah kayak semacam standar spesifikasi. Jadi kan Facebook, Google itu kan perusahaan yang beda-beda, codebase-nya beda-beda.
Jadi OAuth ini men-streamline bentuk workflow-nya. Jadi minta token, minta token dibalikinya seperti apa,
terus item-itemnya, field-nya apa aja, itu kurang lebih di-streamline biar mudah. Misalnya nanti ada sosmed baru atau layanan baru yang mau menyediakan login juga, OAuth juga bisa dengan lebih mudah.
- Oke, jarak kerjanya gimana sih kalau OAuth ini? - Ada itu di link-nya saya kasih.
- Ini ya? - Ini nyambung.
- Nah, OAuth 0 itu salah satu library yang paling major ya, yang mengimplementasi OAuth.
- OAuth 0 itu bukan library, dia service. - Oh, layanan.
- Service, ya, layanan. - Tapi dia punya SDK, kan?
- Ya. Turun dikit, turun dikit. Ada bagannya. Ini yang non-single-sign-on, ini non-single-sign-on.
- Oh, non-single-sign-on. - Kalau login biasa kan kita login, set cookies, kita kembali sedikit deh biar kita bisa lihat kebedaannya.
Jadi kalau non-sso, kalau kita login ke domain 1 ya kan, kita browse ke domain 1, kita login, kita set cookie-nya, selanjutnya kita sudah terautentikasi.
Namun kalau kita ke domain yang berbeda, domain 2. - Cookie-nya nggak ada.
- Kalau kita, cookie-nya kan nggak bisa diases, cookie yang tadi kita sudah login. Meskipun mungkin layanannya sama ya.
Mungkin ya, mungkin. Anggap aja sama-sama blog kita sendiri gitu ya. Tetapi kita nggak bisa akses domain 2 langsung tanpa kita harus login ulang.
Ya kan? Jadi akibatnya apa di sini? Kita harus punya username password di domain 1 dan username password di domain 2.
- Oke. - Kalau itu ada 1000, kita punya 1000, ya kan?
Nah selanjutnya biasanya ini terjadi di sebuah company-company yang enterprise.
Bayangkan aja company enterprise itu punya multiple site, ratusan mungkin.
Kalau satu site harus login kan, repot ya. Dan berbeda. Nah makanya ada disebut single sign-on.
Kalau di Microsoft atau Azure apa itu namanya ya? SSO-nya mereka itu pakai SAML gitu. Saya lupa ininya.
Ah, udahlah. Lalu kalau bisa itu SAML. Nah selanjutnya kalau kita pakai SSO itu cara kerja seperti ini.
Itu yang central authentication domain, turun dulu. Jadi kalau bayangkan sebuah company yang enterprise. Ini jaman sebelum Anda pakai login dengan Facebook, login dengan Google ya.
Sebelum jaman itu ya. Itu sudah ada. Itu pakai kembali lagi protokolnya namanya SAML. Saya lupa nama ini. Dan itu produknya dari Microsoft.
Domain satu kita login, dan ternyata kita di redirect ke authentication server. Nah sebesarnya namanya mawar.com.
Domain tiga.
Kita itu login-nya ke domain tiga. Kita cuma login di domain tiga. Lalu kita akan direct ke kembali ke domain satu dengan akses token yang dikirimkan dari si authentication server untuk menyatakan
"Hey, user ini sudah benar orangnya, dan ini tokennya lu bisa pakai untuk nanti tanya gue."
Jadi ibaratnya, Mas Rizze itu domain satu. Ba Eka itu domain tiga. Contoh, saya datang ke Ba Eka. "Hey, saya mau login Ba Eka. Ini username password."
"Oke, saya mau login ke domain satu." "Oke." Terus Ba Eka langsung kabarin ke Mas Rizze, "Si Ivan sudah terauthentikasi. Ini tokennya."
Terus nanti Mas Rizze tanya lagi, "Benarkah token ini punya Ivan?" "Oh benar." Saya jawab, "Benar." Nanti Mas Rizze balik dan set cookie-nya ke domain satu.
Sehingga saat saya akses domain satu sudah dalam keadaan login. Demikian juga kalau saya akses domain dua.
Saya akan ke redirect lagi ke authentication server, namun saat ini karena saya sudah pernah login, saya nggak perlu login lagi karena sudah ada cookie-nya.
- Itu cookie-nya? - Cookie-nya nempel ke domain tiga. Cookie yang saya sudah pernah login ke domain tiga.
Ada proses redirect. Tetap saya redirect dulu ke domain tiga. Ternyata saya sudah login dan saya akan redirect lagi ke domain dua.
Domain dua akan tanya, "Ini orang sudah benar nggak?" "Oh benar. Tokennya ini ya?" "Ya, balik." Maka saya login ke domain dua.
- Itulah proses SSO. - Single Sign-On.
- Kalau lebih detailnya, lebih detailnya seperti ini. - Oke.
Jadi, key-nya itu adalah ada domain authentication server sendiri yang mengautotikasi semua.
Kalau kita saat ini pakenya login dengan Google, login dengan GitHub, GitHub-nya yang menjadi authentication server.
- Ya, domain tiga ini ya? - Iya.
Jadi, ini memanfaatkan service external yang sudah ada ya?
Ya, ini biasanya cukup sering digunakan kalau kita sudah menggunakan microservice dan service-nya banyak.
Salah satu service yang berdiri sendiri adalah authentication server atau authentication service.
Dan setiap kali kita mau login ke service A, service B, service C, kita harus consult dulu dengan si authentication service ini.
- Gitu ya? - Ya. Jadi, lewat ada komunikasi dari back-end. Server-to-server.
- Server-to-server. - Untuk nanya, "Ini orang benar nggak?"
Tapi kalau misalnya lebih enterprise lagi, nanti ada lagi key-nya.
Key-nya yang di server satu, sekey-nya di server dua hanya bisa pakai key itu baru bisa ngomong.
Karena kalau ada main-in-the-middle yang intercept, nggak kebaca ternyata.
Itu beda lagi itu ceritanya. Tapi tetap sama, prosesnya sama.
Kita lanjut ke pembahasan tentang empat cara melakukan pengamanan API, termasuk juga autentikasi.
Nanti kita sudah bahas tentang OAuth ini, cara kerjanya tadi sudah kita bahas.
Dan kenapa menggunakan OAuth? Karena industri standar, salah satunya.
Keunggulannya di sini disebutkan untuk improve security, user experience, dan scalability.
Yang seperti yang kita sebutkan tadi, dia sudah service terpisah.
Kalau teman-teman punya banyak service, nggak perlu bikin login satu per satu di setiap service.
Itu juga membuat user jadi malas tiap mengases domain satu login.
"Ah, mau coba domain dua?" Login juga. Padahal kita sudah login sebelumnya.
Jadi itu juga membuat user experience jadi lebih bagus.
Terus tentu ada kekurangan. Di sini kekurangannya adalah complexity.
Semakin sekur, semakin kompleks sistem kita. Jadi ini seperti yang tadi dijelaskan,
setiap kali kita mologin, sebenarnya kita redirect ke service authentication.
Kita bawa kode yang pertama kita bawa. Terus habis itu di redirect.
Habis itu setelah login berhasil di approve dengan domain 3 itu...
yang pertama kali itu akan dibawa request token dan redirect URI.
Di domain 3 kita pakai request token itu, kita login plus name dan passwordnya kita.
Lalu waktu kembali itu adalah access token dan refresh token.
Jadi access tokennya itu ada time to live-nya biasanya 30 hari.
Jadi refresh token itu 6 bulan.
Kalau misalnya access tokennya expired, hanya bisa di refresh pakai refresh token
untuk meminta kembali access token supaya kita bisa pakai.
Selanjutnya kalau bisa refresh tokennya habis, maka kita serius harus login ulang.
Nah bahas token-token ini jadi inget nih, salah satu ini contoh implementasi sih
dari layanan yang menyediakan single sign on kayak gini, itu Spotify.
-Dokumentasinya bagus deh, coba buka. -Oh iya, jadi private chat ya.
Itu contoh untuk layanan mereka, tapi sebetulnya kita pakai website lain juga kurang lebih alurnya mirip seperti ini.
Ini ada beberapa opsi.
Ini application, ada account service dan ada user ya, modelnya mirip juga kayak tadi.
Itu kayak tadi dibahas sama Ivan sih sebetulnya, cuma jadi inget aja sih ini dulu sempat lama
kayak gue nggak paham-paham sulit ngerti OAuth itu kayak gimana.
Akhirnya baru klik, itu pas lihat ini soalnya bagannya bagus, bagannya gampang dipahamin.
Memang OAuth ini implementasinya yang sulit.
Bagi kita, bagi developer sulit, tapi bagi user mudah sebenarnya.
Karena tinggal klik, login, balik. Apalagi kalau dia login dengan account yang sudah sering dia pakai,
misalnya dalam hal ini Google atau Microsoft account, Microsoft T60 ya misalnya,
tinggal login, balik lagi udah selesai. Jadi nggak terjadi apa-apa,
tapi kita yang implementasi itu harus belajar betul ini semua.
- Kita yang pakai aja kadang-kadang, ya pakai dalam artian ini ya, kita menggunakan library
untuk misalkan koneksi antara website kita dengan Spotify misalkan atau dengan GitHub atau dengan apa,
itu lumayan tricky juga kalau kita nggak tahu cara kerjanya kan.
Jadi kita ngirim apa, kita expect dikasih dibalikin apa. Itu tuh harus paham dulu.
- Eka putus-putus ya? - Iya, boleh diulang beberapa kali terakhir.
- Apa tadi jadi lupa? Apanya mental modelnya adalah kita harus tahu apa aja yang harus kita kirim di masing-masing langkah,
habis itu apa yang akan kita terima, habis itu langkah selanjutnya apa.
Jadi yang penting menguasai itu. - Terutama kalau misalkan teman-teman
mau pakai service atau mau menggunakan API yang sifatnya private, misalkan Twitter gitu ya.
Kita mau ngambil data Twitter, bisa, tapi kita harus menggunakan OAuth dulu.
Jadi kita lakukan otentikasi dulu, otentikasinya sudah berhasil, baru kita bisa request data.
Dan request datanya pun... - Nah, itu biasanya ada di parameter,
kan ada parameter scope tuh di Spotify juga ada tuh di langkah pertama scope.
Jadi ada hal-hal yang publik, kayak misalnya biasanya display name atau apa ya, entah itu Spotify atau Twitter.
Tapi kan ada hal-hal yang perlu, apa, harus di grantor sendiri.
Misalnya bikin tweet atau kalau di Spotify misalnya membuat playlist atau menghapus playlist,
itu harus ada scope grantor sendiri. - Oke, mantap.
Kita lanjut ke bagian ketiga. Ini yang udah kita bahas tadi ya, basic dan beerer ya.
Jadi kita lewatin aja ya. - Iya.
- Dan yang keempat adalah UAT. - Ya, dia lihat sekilas aja.
- Oke, lihat sekilas ya. Ini method yang paling luas digunakan, paling banyak digunakan.
Kemudian cara gunanya... - Pakai HTTP header ya.
- Pakai HTTP header... - Dikirim di header, header-nya namanya authorization, basic spasi,
apa tadi, username dan password, atau beerer, spasi, token.
- Ya, dan beberapa keunggulannya ya tentu lebih sederhana ya, paling sederhana.
Tapi kekurangannya adalah... - Nggak ada akses role, scope, scope nggak ada.
- Skop. Terus kemudian kalau... - Ya, dia beresik aja ya.
- Nggak bisa expiry, nggak bisa. - Oke.
- Jadi biasanya udah orang pakai itu ya pakai aja.
Kalau misalnya ada developer-nya udah bolak-balik, ada yang resign, segala macam,
ya bayangin aja kalau kita harus ngereset itu semua, kan susah.
- Setiap ada yang ngereset, direset.
- Terus, jadi apa namanya?
Simple implementasinya, tetapi less secure aja untuk maintenance.
- Oke, dan terakhir di sini kita masuk ke bagian keempat ya itu JWT atau JSON Web Token.
Walaupun di sini menggunakan JSON, tapi seperti yang teman-teman tahu bahwa JSON ini udah dipakai umum ya,
di semua platform, di semua bahasa juga pakainya kebanyakan JSON ya.
Walaupun ini asalnya dari JavaScript kan.
- Bukan JSON Momoa kan ya? - JSON Power Rangers.
- Udah rip. - Nah, gimana cara kerja ini?
Nah, JSON ini lumayan baru ya.
Dan sekarang itu lumayan banyak yang pakai dan framework-nya juga udah lengkap ya.
Jadi cara kerjanya adalah dengan?
- Dan ini sebenarnya mirip dengan kombinasi cara-cara sebelumnya kan.
Jadi sebetulnya ada access token, ada data yang mengidentifikasi user.
Yang paling sering sih ya user ID sama user name ya misalnya. Jadi ada user ID, user name,
access token, terus data internal kayak generated datetime issue-nya kapan,
lalu di-encrypt dengan format tertentu JWT itu kan sebetulnya lagi-lagi dia adalah semacam spesifikasi standar.
Jadi bukan library tapi spesifikasi untuk pola algoritma encryption-nya.
- Nah, yang dikirim adalah? - Ada 3 bagian.
Nah, coba sambil buka itu deh. Sambil buka jwt.io.
Ada header, ada payload, ya header, payload dan signature.
Nah, jadi data yang dikirimkan ke server itu di fetch URL kita atau apapun, pokoknya mau dikirim lewat post
atau lewat pay, apapun, dikirim itu encoded ini.
- Yang ini ya? - Kita cuma kirim encoded aja gitu ya.
Yang kita kirim, yang dikiri itu kalau udah di-code kayak di kanan itu.
Nanti hasilnya itu, header-nya apa? Header-nya itu dia kasih tahu algoritma untuk nge-generate-nya pakai HS256.
- Sorry, HS256 beda, bukan SHA256. - Bukan SHA ya, lainnya?
Bukan, tipe-nya jwt. Terus payload-nya itu semua orang bisa baca, payload-nya itu isinya.
Itu lah isi post data yang kita itu, payload itu adalah isi post data.
Itu nggak sensitif juga sih, biasanya paling user name, user ID, issue type, biasanya standarnya, coba cover di IAT deh.
- Issue Add. - Issue Add. Itu isinya bisa macam-macam.
Itu intinya apapun data yang mau kita kirimkan.
Dan setelah payload itu kita kirimkan apa? Kita sign pakai HMX SHA256.
Isinya itu nanti base64 url, header-nya, code payload-nya, sama secret-nya kita.
Itu lah nanti di client-side secret-nya apa, nanti di server-side secret-nya apa.
Dicocokin sama yang di service-nya.
Jadi dia akan dikirimkan dalam bentuk bahasa Sandi, yang hanya bisa dibuka oleh secret-nya ini ya, kuncinya.
Kalau kuncinya sama, maka dia bisa buka.
Sebenarnya bisa dibuka siapa saja. Payload itu sebenarnya bisa dibuka siapa saja.
Tetapi server hanya mau menerima jika signature verified.
Itu contoh centang tadi itu. Jadi di sisi server, saat kita lakukan decode dan kita harus cek,
ini signature-nya benar tidak? Kalau tidak benar, jangan diproses.
Tapi payload-nya semua bisa baca.
Anggap di sini payload ini bukan sesuatu yang rahasia, karena orangnya sudah login.
Makanya bisa terjadi, ini kan untuk mencegur REST API connection kan ya.
Jadi orangnya itu sebenarnya sudah login, sudah punya access key.
Dan ini hanya untuk mengirimkan data ke REST API.
- Request selanjutnya ya? - Iya.
Untuk mengirimkan data apapun itu.
Dan datanya itu supaya si server tahu kalau itu datanya benar dari orang yang terautentikasi dan terautorisasi.
Pakai ini.
Pertanyaan, encoded ini bagaimana cara kita bikin ya?
Kalau itu, kalau mau simpelnya, itu, itu, itu, dari bawah.
Jadi caranya itu gini, caranya, bentar, kecepatan.
- Oh kecepatan? Ini? - Iya.
- Ini? - Iya.
Yes, stop.
Nah, cara, cara memencode itu sebenarnya itu cuma Base64 encode header-nya.
Header itu JSON kan.
Oh ini, ini datanya kita nih.
Iya, itu Base64.
- Terus sama ini, Base64. - Oh iya ini ya, berarti.
Terus yang signature-nya, Base64 ini, tambah Base64 ini, tambah, tambah secret-nya.
Terus di kassisha 26, 256.
Itulah jadi verified-nya.
- Biasanya di... - Terus dipisahkan titik ya itu.
Bagi dia pake titik ya ini ya.
- Ya ini kan dia? - Iya.
Oke.
Kalau di browser client-side kan ada A to B, B to A kan.
Kalau untuk Base, apa Base64.
Tapi hati-hati jangan lupa di note gak ada itu.
- Itu kan feature browser. - Jadi?
A to B dan B to A itu feature-nya web browser.
Kalau kita pakai JavaScript di server-side,
Pakainya buffer, buffer from, kan ada tuh buffer.from untuk Base64. Cuma exactly gimana ya gak apal sih.
Oke.
Pokoknya pakainya API buffer.
Ya, ya, ya.
Nah, next-nya kita bahas apa nih?
Yang sisa apa ya? Oh ini, apa?
WebAuthent. Nah, ini WebAuthent ini apa nih? Barang baru kayaknya ya.
Nah dia, ini ya. Identity bukan.
WebAuthent.io deh.
Bukan. Bukan web.dev/identity.
Bukan. Nah, itu dia.
WebAuthent itu spesifikasi.
Jadi spesifikasi untuk men-strainline atau menstandarisasi proses autentikasi di web.
Yang sebelumnya kan standarisasi ya misalnya tadi tuh apa?
Authorization scheme yang basic, better.
Tapi sekarang kan makin lama autentikasi makin canggih.
Terus belum teknologi masing-masing device.
Misalnya kan udah ada ya semacam fingerprint atau biometrics fingerprint.
Terus ada juga misalnya perantara Iris ya.
Terus ada Retina.
Mungkin ada perantara atau aplikasi untuk 2 factor authentication juga.
Jadi kan intinya makin sekarang autentikasi makin rumit dan makin bermacam-macam.
Nah, ini adalah spesifikasi yang berusaha men-strainline workflow autentikasi itu.
- Nah, bagusnya Nisa. - Simple-nya begini.
Ada yang pernah punya akun BCA nggak?
Ya, punya.
Pernah nggak dulu dikasih token?
- Oh, yang biru itu. - Iya, yang biru.
Jaman dulu sebelum ada standarisasi autentikasi ini,
kan masing-masing aplikasi punya caranya sendiri untuk nge-generate.
- Belum ada standar ya? - Itu sama aja.
Sebenarnya yang key BCA atau key mendiri itu kan sebenarnya 2 factor authentication.
Sebenarnya, jadi untuk mengautorisasi.
Jadi kita sudah masukin login, mau transfer.
Habis mau transfer, tanya lagi nih, masukin aplikasi 1 di key BCA-nya.
Aplikasi 1, aplikasi 2, gitu kan.
Di lama banget nggak pakai, gila.
Nah, itu kan setelah dia muncul angkanya, di-generate di sini, terus balik sana.
Itu kan standar yang dibikin bank itu sendiri.
Kita nggak tahu standar itu apa.
Itu punya mereka sendiri, algoritmanya nggak ada yang tahu.
Mungkin cuma mereka yang tahu.
Sedangkan web autentikasi ini adalah standarisasi dari sisi web
jika kita ingin punya autentikasi yang seperti itu.
Misalnya pakai 2 factor authentication, pakai uBKey.
Jadi, men standarisasi semua cara meng-generate autentikasi, 2 factor authentication seperti itu.
Oke, ini adalah spesifikasi implementasinya.
Teman-teman bisa cek di sini.
Ada yang pakai Python, Go, pakai TypeScript.
TypeScript ada 2 malah ya.
Ada Ruby, Java, Java juga ada 3.
Bahkan bisa akses itu ya, kayak fingerprint ya.
Kalau di device yang memang support.
Dan kalau buat gue sih, ini yang menarik nih biasanya vendor itu kan agak sulit buat compact ya.
Apalagi buat ala yang major seperti ini.
Nah, tumben banget ini web autentikasi itu udah, walaupun mungkin implementasinya,
maksudnya mungkin nggak semua API di support ya.
Tapi ini Chrome, Firefox, Edge, sama kalau WebKit belum mungkin ya.
Chrome, Firefox, Chromium, dan Firefox udah bisa compact.
WebKit nggak ada ya malah ya.
Oh, WebKit belum.
Gak ada di sini sama sekali.
Iya aja ada walaupun semua nggak bisa gitu.
Safari, safari ada gitu.
Safari, safari.
Cuma emang nggak semua, cuma sebagian.
Tapi kan udah lumayan banget ini.
Maksudnya ini pertanda yang bagus ke depannya.
Iya, bener, bener.
Hampir 2 dari 5 ya.
1, 2, 3, 4, 5.
Karena desktop Linux juga nggak ada safari di sana kan.
Desktop Linux nggak ada yang bisa.
Wah, suara robot lagi nih.
Halo?
Sorry, sorry.
Boleh diulang lagi?
Ya, masing-masing vendor udah mulai mengadopsi ini.
Hmm, oke.
Ini roaming authentication.
Apa ini roaming authentication?
Spread Hardware Authenticator.
Oh, ini ya, YubiKey gitu-gitu ya?
Itu tadi key.
Ya, oke.
Ini juga udah hampir semua support ya.
Ada yang punya YubiKey nggak?
Dulu sempat dapat dari Chrome Dev Summit, tapi hilang.
Waduh.
Hilang.
Oh, masih ada.
Yang iru itu kan?
Iya.
Yang kita cuma kayak ditaruh di atas meja, ambil-ambil aja gitu.
Ternyata mahal, Bo.
Mahal ya.
Belum jamannya di Chrome Dev Summit.
50 dolar.
50 dolar?
Oh.
Iya.
Padahal itu cuma ditaruh di atas meja, mau ngambil berapa aja terserah.
Iya.
Kalau mental maling, ambil di jual lagi.
Nah, ini kan, coba kalau si web autent ini lumayan rumit dan lumayan banyak scope-nya.
Tapi yang direkomendasikan sih kalau cuma pengen tahu.
Ini kan belum kebayang kan.
Pasti kalau yang belum pernah pakai, baca ini nggak kebayang, abstrak.
Solusinya itu tuh ada code web-nya.
Ada code web yang cukup bagus.
Ya, kalau mau coba.
Kalau mau coba ya.
Eka jadi robot.
Eka jadi robot.
Lagi, ulang, ulang, ulang.
Iya.
Tuh.
Apa?
Masih, halo, halo, halo.
Halo.
Halo.
Ini direkomendasikan untuk belajar langkah-langkahnya sama bagian-bagiannya.
Kita sendiri belum coba.
Jadi kalau mungkin nanti kita ada kesempatan untuk implementasi,
kita bisa bahas di episode yang terpisah kali ya, lebih detail.
Karena ini lagi hot-hot-nya nih.
Lagi banyak dibahas juga ya.
Lagi menarik.
Webaltern.
Mudah-mudahan nanti dibahas lagi di I/O.
Mudah-mudahan.
Nah, kalau ada pembahasan di I/O atau di conference-conference, nanti mungkin kita bisa bahas.
Kita bahas lebih detail kali ya.
Lebih detail lagi ya.
Jadi mungkin ini agak diluar scope dari topik kita malam hari ini.
Karena kita juga belum ada kesempatan buat nyoba ya.
Buat implementasi ini karena juga cukup baru.
Walaupun secara support kayaknya udah lumayan optimis ya.
Bakal disupport penuh karena ya sekarang aja baru muncul udah disupport banyak browser ya.
Ya.
Oke.
Ada lagi?
Ada lagi.
Sepertinya.
Habis.
Oke, kalau gitu berhubung mata di kita sudah habis.
Kenapa?
Siapa tahu nanti hari Selasa ada yang nonton dan mereka mengikuti WorldCamp Asia di Bangkok.
Oh iya, boleh.
Ya, say hi aja ke saya.
Kenapa saya nggak bisa ikut live karena saya lagi ada di Bangkok.
Lagi organize WorldCamp Asia 2023.
Jadi kalau ada temen-temen, temen-temen ada yang ke Bangkok ikut acara nanti say hi.
Ya.
Atau ada di live stream juga ya?
Live stream, live stream.
Oh, say hi online bisa juga.
Asia.WorldCamp.org 2023.
Oke.
Bagi temen-temen yang nggak bisa datang, ada live streamnya silahkan.
Banyak topik-topik yang menarik tentang WordPress.
Ya.
17 sampai 19.
Suruh sekali.
Mana nih? Agendanya mana agenda?
Schedule, conference day.
Itu 17 itu contributor day.
18 itu acara utamanya.
Jadi evolution segala macam.
SIPI, development, ada security, ada design, ada full-site editing juga tuh, full-site editing.
Menarik ya.
Ya.
Seru, seru, seru.
Ini hari ke-2-nya, hari ke-3-nya tanggal 19.
Masih conference juga ya berarti ya?
Conference juga, ada multilingual, ada automatic QA, visual education testing, progressive web app, and so on.
Ya.
Mungkin nanti kita bisa bahas review-nya juga, pengalamannya di sana.
Oh iya, buat minggu depan ya.
Gimana pengalamannya buat minggu depan mungkin?
Saya organizer, jadi kalau pengalaman ikut session mungkin nggak banyak.
Gak apa-apa, pengalaman menjalankan sebagai organizer.
Karena kan kita juga pengen nih, ada conference-conference di Indonesia kan, mulai bisa dijalankan lagi kan.
Conference development.
Ayo ngobrolin web conference.
Isinya ngobrol-ngobrol.
Jangan terlalu muluk-muluk lah.
Kalau bisa kita live dulu di satu conference, kita numpang.
Oh iya, bisa-bisa.
Yang nonton jumlah nggak sampai 100, mau bikin conference.
Oke kalau gitu, mungkin untuk malam ini kita udahan dulu.
Terima kasih buat teman-teman yang udah nonton.
Jangan lupa, kalau ada kritik, saran, ada topik, diskusi, bisa ke bit.ly/ngobrolinweb.
Malam ini kita pamit.
Saya Riza, bisa kalau ada mo sehai bisa di Twitter, Rizafami22.
Ada Eka juga, di Eka.fi, dan ada Ivan di IvanKris.com.
Oke, sekian dulu.
Selamat malam, selamat istirahat, sampai jumpa minggu depan.
Dadah.
Deskripsi asli dari YouTube
Malam ini kita akan ngobrolin tentang berbagai cara melakukan otentikasi di protokol yang digunakan oleh web yaitu HTTP. Topik pembahasan: - otentikasi - otentikasi vs otorisasi - HTTP Authentication (https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication) - 4 Auth method (https://blog.hubspot.com/website/api-authentication) - Single-sign on (https://auth0.com/blog/what-is-and-how-does-single-sign-on-work/) - JSON Web Token (https://jwt.io) - Webauthn (https://webauthn.io/) --------- 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...
24 Mei 2023
Ngobrolin Google IO Lebih Dalam
Melanjutkan rangkuman umum minggu sebelumnya, episode ini memilih beberapa topik dari Google I/O untuk dibedah lebih dal...
5 Des 2022
Ngobrolin i18n
Episode ini membahas Intl, Web API untuk internationalization yang membuat pemformatan tanggal, angka, dan mata uang ses...
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 .