Ngobrolin Otentikasi - Ngobrolin WEB ep20

3:41Kalau enggak dikasih tahu. Kalau dia enggak memberitahukan, "Ey, saya itu Ivan loh."

3:47Saya kita kunjungi sebuah situs, apapun lah ya situs, dan kita si server itu enggak tahu siapa kita kalau kita enggak kasih tahu.

3:58Nah, setelah kita memberitahu server, "Hei, saya itu Ivan." Server itu harus bisa melakukan proses verifikasi.

4:08Nah, itulah proses verifikasi itulah bagaimana si server bisa mengautentikasi saya itu adalah Ivan,

4:18dan saya boleh diberi masuk, dan saya bisa diberikan datanya si Ivan.

4:22Kalau enggak ya enggak bisa gitu. Itulah umumnya.

4:28Nah, terus ini kalau bahas kan tadi request adalah stateless, berarti kan implikasinya ini kenapa sampai ada keperluan buat autentikasi.

4:40Nah, karena ada resource yang boleh diakses semua orang, dan ada resource yang belum tentu boleh diakses atau dilakukan semua orang, ya kan.

4:52Jadi untuk public resource, itu kan kalau public resource semua boleh baca.

4:57Misalnya gampangnya kalau situs berita semua orang kan boleh nge-request blog post atau artikel terakhir.

5:02Ya, enggak ada keperluan, enggak perlu mastiin apakah kamu Ivan, apakah kamu Eka, kan enggak perlu.

5:09Ibaratnya kalau analogi tempat, kita di tempat umum nih kita ke taman atau kita ke jalanan, ya kan enggak ada yang menghentikan kita,

5:19enggak ada yang menghentikan kita, ya udah kita mau lewat suatu jalan, kita jalan aja.

5:23Tapi kalau kita mau masuk misalnya stasiun kereta api atau bandara masuk ke gedungnya, itu lain kasus kan.

5:30Kita harus buktikan identitas kita. Nah, tiket itu kan ada tiket, ada KTP, nah ini bakal nyambung ke icon selanjutnya.

5:41Yang jelas kita enggak boleh se-enaknya masuk karena itu hal yang resource yang tidak boleh diakses semua orang.

5:49Ya, jadi kalau misalkan ada hal yang misalkan tadi apa situs berita atau blog lah.

5:55Blog mungkin orang, mungkin blog saya, Ivan, dan Eka bisa baca gitu ya.

6:00Tapi yang bisa entry artikelnya, yang bisa memasukkan artikelnya ya cuma bisa saya gitu.

6:07Bagaimana caranya ya mungkin nanti ada apa lizafahmi.com/admin gitu kan.

6:12Terus ada masukan, biasanya masukan password. Nah, itu adalah cara mengetahui apakah saya punya apa bisa masuk atau enggak gitu.

6:21- Nah, jadi kalau emang resource-nya publik semua, ya udah enggak perlu sama sekali.

6:26Authentikasi itu emang enggak perlu. Ini akan perlu kalau itu tadi ada misalnya kalau blog post,

6:32ada dashboard admin-nya yang harus bisa diakses orang tertentu aja.

6:37Atau mungkin ada private post yang masih status-nya draft, mungkin bisa dibaca oleh editor atau apa,

6:43cuma tetap enggak boleh diakses oleh user lain. Nah, itu skopnya autentikasi.

6:51- Ya, ada juga apa namanya kalau misalkan tadi blog-nya kan, blog pribadi.

6:56Kalau misalkan blog-nya yang umum misalkan kayak medium gitu kan.

6:59Medium itu bisa memastikan bahwa artikel yang kita tulis atas nama kita, misalkan atas nama Riza,

7:07ya hanya saya, begitu. Begitu Ivan login dengan akonnya, maka di halaman dashboard-nya atau di halaman admin-nya,

7:16itu artikelnya artikel Ivan, bukan artikel saya. - Hanya gabar saya aja.

7:20- Iya, jadi kalau multi-user, ya berarti dia memastikan bahwa data-data yang diakses,

7:26itu hanya data milik kita yang login. - Berarti kita bisa pisahkan antara autentikasi dan otorisasi.

7:34- Nah, ini poin selanjutnya. - Otorisasi gimana tuh?

7:37- Ya itu tadi seperti yang Mas Riza, kalau misalnya di sebuah ruangan VIP,

7:44hanya boleh orang VIP yang punya kartu VIP-nya yang boleh masuk, itu namanya otorisasi.

7:50Kalau tadi yang selalu saya login ke Medium, hanya saya bisa melihat artikel yang saya tulis,

7:57saya tidak bisa lihat artikel yang Mas Riza tulis, itu kan otorisasi.

8:01- Oh itu masuknya otorisasi ya? - Iya.

8:03- Nah, analogi lagi nih, kalau tempat tadi kan kalau yang publik tuh jalanan atau taman atau ruang publik lainnya,

8:10kita jalan mah lewat-lewat aja, nggak bakal di-stop kan. Kalau kita masuk bandara, kan kita ada 2 hal.

8:17Hal pertama, ya maksudnya kita punya misalnya sebagai penumpang, kita punya tiket, flight tertentu,

8:23kita berada di gate yang benar, misalnya kalau tiket, kalau penerbangan kita domestik gitu,

8:28ya kita nggak bakal boleh masuk ke gate-nya internasional kan, karena itu hal yang kita lakukan adalah mau masuk gate untuk terbang sebagai penumpang.

8:39Itu otorisasi hal apa yang bisa kita lakukan, sedangkan otentikasinya adalah ngecek,

8:49nyamain nama di paspor atau KTP dengan nama di tiket, sama biasanya kalau di gate kan kita seru buka masker,

8:55buka masker nunjukin muka tuh. Kan sih orangnya, si tugas bandara kecek apakah identitas, tiket, dan orangnya itu sama,

9:06nah itu otentikasi, sedangkan otorisasi itu kita boleh masuk gate mana dan boleh ngapain.

9:13Nah kalau misalnya pilot ini bukan penumpang, kan pasti otorisasi hal yang boleh dilakukan si pilot atau pramugari itu kan beda kan,

9:22dia boleh masuk mungkin pintu-pintu lain yang kita sebagai penumpang nggak bisa, walaupun kita sebagai penumpang punya tiket,

9:29punya KTP, udah nunjukin, ya tetap aja kita nggak boleh masuk kan, kita nggak boleh mengakses tempat tertentu atau melakukan hal tertentu

9:37yang boleh dilakukan oleh pilot atau staf atau tugas.

9:43- Hmm, iya, iya, iya. Oke, jadi malam ini kita... - Otorisasi itu siapa kita sama otentikasi siapa kita,

9:51otorisasi itu hal apa saja yang boleh dilakukan.

9:55Apa yang boleh kita lakukan, ya. Dan malam ini kita akan membahas tentang otentikasi dan mudah-mudahan di episode-episode mendatang

10:02kita akan bahas tentang otorisasi juga ya. Oke, nah berkaitan dengan otentikasi, salah satu referensi yang menarik ini ada dari MDN,

10:13tentang otentikasi melalui protokol HTTP, ini ternyata si HTTP sudah memberikan istilahnya framework ya untuk kita melakukan otoritas.

10:24Ya, melakukan otentikasi melalui HTTP yang disebut sebagai basic schema.

10:30Di sini ada apa ya, spesifikasinya lah ya, tata caranya, prosedurnya, gimana caranya flow dari orang yang meminta identitas,

10:43meminta validasi identitas atau otentikasi, kemudian akan dijawab oleh si server ya.

10:50Kira-kira gambarnya seperti ini ya, ilustrasinya. Jadi, client ini bukan hanya web browser.

11:00Biasanya kita menyebut client browser ya, tapi di sini bukan. Siapapun interface yang ingin mengakses, yang ingin melakukan otentikasi.

11:10Jadi 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.

11:22Yang penting, protokolnya HTTP. Jadi, request-nya belum terjadi dari browser, atau mau terjadi dari comment line, atau mau terjadi dari HTTP client seperti postman.

11:38Ataupun 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.

11:56Server di sini adalah tempat di mana data user dan berbagai proses validasinya terjadi di server ya.

12:07Jadi, proses checking-nya ada di server. Jadi, semacam service API, atau service yang menghandle logic, business logic, sama database, dan lain-lain.

12:18Ya, 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...

12:32Ini 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.

12:45Kalau 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...

12:59Oh, kayak FTP ya, kalau buka FTP dari browser, gitu kan. Oh, iya, iya. Kalau jangan dulu kita buka FTP, gitu, ada username password, gitu.

13:08Iya, iya. Terus minta username sama password. Dan ini tidak spesifik terhadap user. Hanya basic out biasa.

13:18Ya. 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.

13:33Kevalidasinya 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.

13:53Atau 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.

14:07Semakin 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.

14:19Skema 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.

14:39Iya, 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.

14:53Mungkin 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.

15:03Iya, 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.

15:19Jadi sebuah string di base 64. Jadi itu isinya. Kalau bearer itu. Token, yang di encode tokennya ya. Akses token.

15:35API 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.

15:57Kalau bearer authenticate, bearer langsung hasil hashnya tadi, tokennya itu.

16:05Jadi 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.

16:19Jadi 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.

16:32Biasanya begini, kalau sebuah aplikasi, bayangkan sebuah aplikasi, anggapnya aja WordPress deh.

16:41Pasti simple, ada username login. Kalau basic authentication itu kan, nggak mungkin kita, kalau kita ada client API, contohnya client-side JavaScript.

16:57Kalau yang kita kirimkan itu adalah username password kita, itu kan bahaya ya. Orang bisa akses langsung.

17:04Sedangkan kita bisa set dari aplikasi, kita bikin namanya application password. Jadi hanya password aja yang mengidentifikasi kalau itu punya saya.

17:17Dan 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.

17:35Barrel token itu lebih aman daripada yang basic out. - Menarik. Ada apa lagi sih tipe-tipe selanjutnya?

17:49Mungkin kita bisa lihat di artikel yang kedua ini ya. Walaupun judulnya tentang REST API, tapi ini juga bisa berlaku untuk non-REST API.

18:01Yang grafql, gRPC, macam-macam ya. Jadi ada beberapa cara. - Mungkin detailnya bakal sedikit berbeda,

18:12tapi kita di sini lebih lihat ke pola-polanya ya, workflow-nya secara umum. Nah, ini yang barusan dibahas, Evan, yang baru banget.

18:21Gimana caranya kita melakukan mengamankan API kita yang mungkin tidak boleh diakses oleh publik?

18:31Bisa menggunakan yang pertama tadi API key, yang barusan dibahas Evan ya. API key, gimana caranya ini ada ini?

18:40- Biasanya ada public key sama private key. Jadi private key-nya nggak boleh disimpan di mana-mana, termasuk di client, nggak boleh ada.

18:50Private key itu hanya ada di server, jadi public key-nya yang dipakai oleh komunikasi antar.

18:58Kalau misalnya punya client-side JavaScript, kita bisa embed public key-nya di JavaScript application kita

19:06yang kita pakai untuk generate token tadi. Nanti token-nya dikirimkan, diauthenticate pakai private key.

19:18- Private key itu harus di server-side ya, di sisi server ya. Nggak boleh disimpan di sisi client karena bisa dilihat.

19:28Namanya private itu kan nggak boleh dibagikan, gitu ya. Kalau ada di sisi client, kita bisa view source,

19:34terus kita bisa lihat kuncinya. Nah, makanya, ini ada beberapa pertanyaan juga yang muncul ya, cukup sering muncul.

19:42Makanya beberapa service seperti Payment Gateway itu mengharuskan kita punya server, nggak boleh langsung dari client.

19:50Karena dia harus menggenerasi entah itu token ataupun punya private key, harus disimpan di server, tidak boleh di client.

20:00- Untungnya sih kalau disambungin ke implementasi, ya ini framework.

20:06Maksudnya kalau kita cuma pakai yang mentahan React, swell, itu kan masih client-side web browser ya.

20:12Jadi mungkin agak sulit kalau harus server-side. Nah, di sini perannya meta framework.

20:18Jadi sekarang udah lumayan banyak ya, meta framework. Kalau kita pakai React, ya bisa pakai Next atau Gatsby atau Remix.

20:26Kalau pakai Swell, bisa pakai Swell Kit. Terus semua bisa pakai Astro. Jadi ada banyak meta framework

20:37yang bisa berfungsi secara full-stack itu jadi satu solusi. Jadi kalau dulu mungkin kita harus bikin satu aplikasi lagi,

20:46misalnya Express atau KoA, kita harus punya aplikasi Node.js. Terus dari aplikasi React kita,

20:58manggil ke server itu, sekarang bisa ada alternatif lain pakai meta framework yang di satu aplikasi udah full-stack.

21:09Ada sisi browser-nya, client-side-nya, ada sisi yang cuma bisa dibaca di server untuk melakukan operasi seperti ini.

21:17- Ya, alternatif yang lain yang pernah saya kerjakan adalah dengan menggunakan itu serverless lambda.

21:25Jadi kalau misalkan kayak Netlify, Netlify kan hanya client-side ya.

21:30Nah, kita semudah membuat sebuah folder dengan nama functions, didalamnya kita bisa punya server dalam tanda kutip gitu.

21:37Jadi hal-hal yang seperti ini bisa kita tangani di sana. Jadi mungkin kalau nggak mau full-blown langsung ke meta framework,

21:44bisa coba lambda server ada di Netlify, ada di versel juga kalau nggak salah ya. Jadi ada di mana-mana.

21:53Kalau lebih sederhana. Tapi kalau misalkan, wah kayaknya ribet nih, harus pakai AWSK atau pakai GCPK atau yang lain gitu kan.

22:01Nah, mungkin opsi untuk menggunakan meta framework lebih cocok gitu ya.

22:07- Nah, cuma Netlify sama Versel juga sekarang udah bisa ngehosting server-side. Jadi maksudnya itu tergantung complex-side.

22:14Iya, bisa. Jadi misalkan kita punya Next.js, bisa dihosting di Netlify atau Versel.

22:20Node server-nya, jadi mereka sebenarnya under the hood itu pakai AWS.

22:25- Iya, iya. Masih gratis ya? - Ada free tier. Free tiernya gratis.

22:31Iya, gratis ada sekian menit, sekian ratus menit batasnya running compute time.

22:39- Nah, ini ada pro dan cons-nya ya. Kenapa kita perlu menggunakan? Karena mudah dan ya gampang lah ya, cepat juga ya.

22:51Dan lebih fleksibel. Nah, disadvantage-nya adalah security. Security-nya lemah ya.

22:58- Paling gampangnya, ini si GitHub token. Bayangkan aja GitHub token. - Oh iya, token.

23:05- Iya, GitHub token. Kita bisa bikin GitHub personal access token, seperti API key.

23:12Jadi kita bisa access GitHub API dengan menggunakan personal access token untuk mengakses data-data yang kita punya di GitHub.

23:22Bisa bikin repo, bisa search repo, bisa macem-macem, lihat PR gitu ya, full request.

23:28Bisa destroy repo juga kalau memang dikasih aksesnya.

23:32- 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.

23:43Yang versi 2 itu apa namanya, sekarang lumayan banyak yang menggunakan ya.

23:51Jadi kalau teman-teman menggunakan service tuh misalkan kayak Twitter login, atau apa lagi, oh, GitHub login juga termasuk.

23:59- Ya, Facebook login. - Oh, Facebook login, ada macem-macem service yang menyediakan service untuk login

24:09sehingga user tidak perlu register. Memudahkan ya, terutama kalau teman-teman yang bikin produk baru.

24:19- Menggunakan akun user. - Akun yang sudah ada, akun social media biasanya ya.

24:24Jadi daripada kita harus suruh user register, masukin username, masukin password, email, apa segala macem gitu, hobby gitu ya.

24:37Lebih baik kan kita misalkan menggunakan Google atau Facebook atau Twitter, kita bisa ambil data public ya, data public atau data private di sana.

24:49Kemudian kita login dengan menggunakan salah satu akun social media kita.

24:54- Nah, keunggulannya, bukan keunggulan sih, cuma OAuth 2.0 ini adalah standar.

25:01Jadi sebenarnya bukan library, OAuth-nya sendiri bukan library, cuma ada beberapa library yang mengimplementasi ini.

25:10Nah, ini adalah kayak semacam standar spesifikasi. Jadi kan Facebook, Google itu kan perusahaan yang beda-beda, codebase-nya beda-beda.

25:20Jadi OAuth ini men-streamline bentuk workflow-nya. Jadi minta token, minta token dibalikinya seperti apa,

25:31terus 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.

25:50- Oke, jarak kerjanya gimana sih kalau OAuth ini? - Ada itu di link-nya saya kasih.

25:58- Ini ya? - Ini nyambung.

26:02- Nah, OAuth 0 itu salah satu library yang paling major ya, yang mengimplementasi OAuth.

26:08- OAuth 0 itu bukan library, dia service. - Oh, layanan.

26:13- Service, ya, layanan. - Tapi dia punya SDK, kan?

26:17- Ya. Turun dikit, turun dikit. Ada bagannya. Ini yang non-single-sign-on, ini non-single-sign-on.

26:29- Oh, non-single-sign-on. - Kalau login biasa kan kita login, set cookies, kita kembali sedikit deh biar kita bisa lihat kebedaannya.

26:41Jadi 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.

26:55Namun kalau kita ke domain yang berbeda, domain 2. - Cookie-nya nggak ada.

27:01- Kalau kita, cookie-nya kan nggak bisa diases, cookie yang tadi kita sudah login. Meskipun mungkin layanannya sama ya.

27:07Mungkin ya, mungkin. Anggap aja sama-sama blog kita sendiri gitu ya. Tetapi kita nggak bisa akses domain 2 langsung tanpa kita harus login ulang.

27:19Ya kan? Jadi akibatnya apa di sini? Kita harus punya username password di domain 1 dan username password di domain 2.

27:28- Oke. - Kalau itu ada 1000, kita punya 1000, ya kan?

27:33Nah selanjutnya biasanya ini terjadi di sebuah company-company yang enterprise.

27:40Bayangkan aja company enterprise itu punya multiple site, ratusan mungkin.

27:45Kalau satu site harus login kan, repot ya. Dan berbeda. Nah makanya ada disebut single sign-on.

27:53Kalau di Microsoft atau Azure apa itu namanya ya? SSO-nya mereka itu pakai SAML gitu. Saya lupa ininya.

28:03Ah, udahlah. Lalu kalau bisa itu SAML. Nah selanjutnya kalau kita pakai SSO itu cara kerja seperti ini.

28:16Itu 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.

28:26Sebelum jaman itu ya. Itu sudah ada. Itu pakai kembali lagi protokolnya namanya SAML. Saya lupa nama ini. Dan itu produknya dari Microsoft.

28:37Domain satu kita login, dan ternyata kita di redirect ke authentication server. Nah sebesarnya namanya mawar.com.

28:49Domain tiga.

28:51Kita 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

29:13"Hey, user ini sudah benar orangnya, dan ini tokennya lu bisa pakai untuk nanti tanya gue."

29:23Jadi 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."

29:35"Oke, saya mau login ke domain satu." "Oke." Terus Ba Eka langsung kabarin ke Mas Rizze, "Si Ivan sudah terauthentikasi. Ini tokennya."

29:48Terus 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.

30:03Sehingga saat saya akses domain satu sudah dalam keadaan login. Demikian juga kalau saya akses domain dua.

30:15Saya 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.

30:23- Itu cookie-nya? - Cookie-nya nempel ke domain tiga. Cookie yang saya sudah pernah login ke domain tiga.

30:33Ada proses redirect. Tetap saya redirect dulu ke domain tiga. Ternyata saya sudah login dan saya akan redirect lagi ke domain dua.

30:43Domain dua akan tanya, "Ini orang sudah benar nggak?" "Oh benar. Tokennya ini ya?" "Ya, balik." Maka saya login ke domain dua.

30:53- Itulah proses SSO. - Single Sign-On.

30:58- Kalau lebih detailnya, lebih detailnya seperti ini. - Oke.

31:07Jadi, key-nya itu adalah ada domain authentication server sendiri yang mengautotikasi semua.

31:15Kalau kita saat ini pakenya login dengan Google, login dengan GitHub, GitHub-nya yang menjadi authentication server.

31:23- Ya, domain tiga ini ya? - Iya.

31:27Jadi, ini memanfaatkan service external yang sudah ada ya?

31:33Ya, ini biasanya cukup sering digunakan kalau kita sudah menggunakan microservice dan service-nya banyak.

31:43Salah satu service yang berdiri sendiri adalah authentication server atau authentication service.

31:50Dan setiap kali kita mau login ke service A, service B, service C, kita harus consult dulu dengan si authentication service ini.

31:58- Gitu ya? - Ya. Jadi, lewat ada komunikasi dari back-end. Server-to-server.

32:08- Server-to-server. - Untuk nanya, "Ini orang benar nggak?"

32:13Tapi kalau misalnya lebih enterprise lagi, nanti ada lagi key-nya.

32:17Key-nya yang di server satu, sekey-nya di server dua hanya bisa pakai key itu baru bisa ngomong.

32:22Karena kalau ada main-in-the-middle yang intercept, nggak kebaca ternyata.

32:28Itu beda lagi itu ceritanya. Tapi tetap sama, prosesnya sama.

32:34Kita lanjut ke pembahasan tentang empat cara melakukan pengamanan API, termasuk juga autentikasi.

32:45Nanti kita sudah bahas tentang OAuth ini, cara kerjanya tadi sudah kita bahas.

32:51Dan kenapa menggunakan OAuth? Karena industri standar, salah satunya.

32:56Keunggulannya di sini disebutkan untuk improve security, user experience, dan scalability.

33:04Yang seperti yang kita sebutkan tadi, dia sudah service terpisah.

33:07Kalau teman-teman punya banyak service, nggak perlu bikin login satu per satu di setiap service.

33:12Itu juga membuat user jadi malas tiap mengases domain satu login.

33:18"Ah, mau coba domain dua?" Login juga. Padahal kita sudah login sebelumnya.

33:23Jadi itu juga membuat user experience jadi lebih bagus.

33:30Terus tentu ada kekurangan. Di sini kekurangannya adalah complexity.

33:37Semakin sekur, semakin kompleks sistem kita. Jadi ini seperti yang tadi dijelaskan,

33:49setiap kali kita mologin, sebenarnya kita redirect ke service authentication.

33:54Kita bawa kode yang pertama kita bawa. Terus habis itu di redirect.

34:07Habis itu setelah login berhasil di approve dengan domain 3 itu...

34:12yang pertama kali itu akan dibawa request token dan redirect URI.

34:24Di domain 3 kita pakai request token itu, kita login plus name dan passwordnya kita.

34:35Lalu waktu kembali itu adalah access token dan refresh token.

34:41Jadi access tokennya itu ada time to live-nya biasanya 30 hari.

34:51Jadi refresh token itu 6 bulan.

34:57Kalau misalnya access tokennya expired, hanya bisa di refresh pakai refresh token

35:05untuk meminta kembali access token supaya kita bisa pakai.

35:09Selanjutnya kalau bisa refresh tokennya habis, maka kita serius harus login ulang.

35:17Nah bahas token-token ini jadi inget nih, salah satu ini contoh implementasi sih

35:25dari layanan yang menyediakan single sign on kayak gini, itu Spotify.

35:31-Dokumentasinya bagus deh, coba buka. -Oh iya, jadi private chat ya.

35:39Itu contoh untuk layanan mereka, tapi sebetulnya kita pakai website lain juga kurang lebih alurnya mirip seperti ini.

35:51Ini ada beberapa opsi.

35:56Ini application, ada account service dan ada user ya, modelnya mirip juga kayak tadi.

36:02Itu kayak tadi dibahas sama Ivan sih sebetulnya, cuma jadi inget aja sih ini dulu sempat lama

36:09kayak gue nggak paham-paham sulit ngerti OAuth itu kayak gimana.

36:14Akhirnya baru klik, itu pas lihat ini soalnya bagannya bagus, bagannya gampang dipahamin.

36:23Memang OAuth ini implementasinya yang sulit.

36:31Bagi kita, bagi developer sulit, tapi bagi user mudah sebenarnya.

36:36Karena tinggal klik, login, balik. Apalagi kalau dia login dengan account yang sudah sering dia pakai,

36:42misalnya dalam hal ini Google atau Microsoft account, Microsoft T60 ya misalnya,

36:48tinggal login, balik lagi udah selesai. Jadi nggak terjadi apa-apa,

36:54tapi kita yang implementasi itu harus belajar betul ini semua.

36:58- Kita yang pakai aja kadang-kadang, ya pakai dalam artian ini ya, kita menggunakan library

37:04untuk misalkan koneksi antara website kita dengan Spotify misalkan atau dengan GitHub atau dengan apa,

37:12itu lumayan tricky juga kalau kita nggak tahu cara kerjanya kan.

37:16Jadi kita ngirim apa, kita expect dikasih dibalikin apa. Itu tuh harus paham dulu.

37:26- Eka putus-putus ya? - Iya, boleh diulang beberapa kali terakhir.

37:46- Apa tadi jadi lupa? Apanya mental modelnya adalah kita harus tahu apa aja yang harus kita kirim di masing-masing langkah,

37:57habis itu apa yang akan kita terima, habis itu langkah selanjutnya apa.

38:04Jadi yang penting menguasai itu. - Terutama kalau misalkan teman-teman

38:11mau pakai service atau mau menggunakan API yang sifatnya private, misalkan Twitter gitu ya.

38:17Kita mau ngambil data Twitter, bisa, tapi kita harus menggunakan OAuth dulu.

38:21Jadi kita lakukan otentikasi dulu, otentikasinya sudah berhasil, baru kita bisa request data.

38:28Dan request datanya pun... - Nah, itu biasanya ada di parameter,

38:32kan ada parameter scope tuh di Spotify juga ada tuh di langkah pertama scope.

38:37Jadi ada hal-hal yang publik, kayak misalnya biasanya display name atau apa ya, entah itu Spotify atau Twitter.

38:45Tapi kan ada hal-hal yang perlu, apa, harus di grantor sendiri.

38:50Misalnya bikin tweet atau kalau di Spotify misalnya membuat playlist atau menghapus playlist,

38:57itu harus ada scope grantor sendiri. - Oke, mantap.

39:04Kita lanjut ke bagian ketiga. Ini yang udah kita bahas tadi ya, basic dan beerer ya.

39:11Jadi kita lewatin aja ya. - Iya.

39:13- Dan yang keempat adalah UAT. - Ya, dia lihat sekilas aja.

39:17- Oke, lihat sekilas ya. Ini method yang paling luas digunakan, paling banyak digunakan.

39:24Kemudian cara gunanya... - Pakai HTTP header ya.

39:29- Pakai HTTP header... - Dikirim di header, header-nya namanya authorization, basic spasi,

39:35apa tadi, username dan password, atau beerer, spasi, token.

39:39- Ya, dan beberapa keunggulannya ya tentu lebih sederhana ya, paling sederhana.

39:45Tapi kekurangannya adalah... - Nggak ada akses role, scope, scope nggak ada.

39:55- Skop. Terus kemudian kalau... - Ya, dia beresik aja ya.

40:00- Nggak bisa expiry, nggak bisa. - Oke.

40:05- Jadi biasanya udah orang pakai itu ya pakai aja.

40:08Kalau misalnya ada developer-nya udah bolak-balik, ada yang resign, segala macam,

40:13ya bayangin aja kalau kita harus ngereset itu semua, kan susah.

40:17- Setiap ada yang ngereset, direset.

40:21- Terus, jadi apa namanya?

40:27Simple implementasinya, tetapi less secure aja untuk maintenance.

40:35- Oke, dan terakhir di sini kita masuk ke bagian keempat ya itu JWT atau JSON Web Token.

40:43Walaupun di sini menggunakan JSON, tapi seperti yang teman-teman tahu bahwa JSON ini udah dipakai umum ya,

40:48di semua platform, di semua bahasa juga pakainya kebanyakan JSON ya.

40:52Walaupun ini asalnya dari JavaScript kan.

40:56- Bukan JSON Momoa kan ya? - JSON Power Rangers.

41:03- Udah rip. - Nah, gimana cara kerja ini?

41:10Nah, JSON ini lumayan baru ya.

41:18Dan sekarang itu lumayan banyak yang pakai dan framework-nya juga udah lengkap ya.

41:23Jadi cara kerjanya adalah dengan?

41:26- Dan ini sebenarnya mirip dengan kombinasi cara-cara sebelumnya kan.

41:30Jadi sebetulnya ada access token, ada data yang mengidentifikasi user.

41:35Yang paling sering sih ya user ID sama user name ya misalnya. Jadi ada user ID, user name,

41:41access token, terus data internal kayak generated datetime issue-nya kapan,

41:50lalu di-encrypt dengan format tertentu JWT itu kan sebetulnya lagi-lagi dia adalah semacam spesifikasi standar.

42:01Jadi bukan library tapi spesifikasi untuk pola algoritma encryption-nya.

42:07- Nah, yang dikirim adalah? - Ada 3 bagian.

42:13Nah, coba sambil buka itu deh. Sambil buka jwt.io.

42:17Ada header, ada payload, ya header, payload dan signature.

42:31Nah, jadi data yang dikirimkan ke server itu di fetch URL kita atau apapun, pokoknya mau dikirim lewat post

42:54atau lewat pay, apapun, dikirim itu encoded ini.

42:58- Yang ini ya? - Kita cuma kirim encoded aja gitu ya.

43:01Yang kita kirim, yang dikiri itu kalau udah di-code kayak di kanan itu.

43:06Nanti hasilnya itu, header-nya apa? Header-nya itu dia kasih tahu algoritma untuk nge-generate-nya pakai HS256.

43:18- Sorry, HS256 beda, bukan SHA256. - Bukan SHA ya, lainnya?

43:22Bukan, tipe-nya jwt. Terus payload-nya itu semua orang bisa baca, payload-nya itu isinya.

43:30Itu lah isi post data yang kita itu, payload itu adalah isi post data.

43:34Itu nggak sensitif juga sih, biasanya paling user name, user ID, issue type, biasanya standarnya, coba cover di IAT deh.

43:45- Issue Add. - Issue Add. Itu isinya bisa macam-macam.

43:53Itu intinya apapun data yang mau kita kirimkan.

43:56Dan setelah payload itu kita kirimkan apa? Kita sign pakai HMX SHA256.

44:05Isinya itu nanti base64 url, header-nya, code payload-nya, sama secret-nya kita.

44:17Itu lah nanti di client-side secret-nya apa, nanti di server-side secret-nya apa.

44:23Dicocokin sama yang di service-nya.

44:26Jadi dia akan dikirimkan dalam bentuk bahasa Sandi, yang hanya bisa dibuka oleh secret-nya ini ya, kuncinya.

44:36Kalau kuncinya sama, maka dia bisa buka.

44:38Sebenarnya bisa dibuka siapa saja. Payload itu sebenarnya bisa dibuka siapa saja.

44:43Tetapi server hanya mau menerima jika signature verified.

44:49Itu contoh centang tadi itu. Jadi di sisi server, saat kita lakukan decode dan kita harus cek,

44:59ini signature-nya benar tidak? Kalau tidak benar, jangan diproses.

45:05Tapi payload-nya semua bisa baca.

45:09Anggap di sini payload ini bukan sesuatu yang rahasia, karena orangnya sudah login.

45:16Makanya bisa terjadi, ini kan untuk mencegur REST API connection kan ya.

45:22Jadi orangnya itu sebenarnya sudah login, sudah punya access key.

45:26Dan ini hanya untuk mengirimkan data ke REST API.

45:31- Request selanjutnya ya? - Iya.

45:34Untuk mengirimkan data apapun itu.

45:37Dan datanya itu supaya si server tahu kalau itu datanya benar dari orang yang terautentikasi dan terautorisasi.

45:45Pakai ini.

45:48Pertanyaan, encoded ini bagaimana cara kita bikin ya?

45:53Kalau itu, kalau mau simpelnya, itu, itu, itu, dari bawah.

46:06Jadi caranya itu gini, caranya, bentar, kecepatan.

46:13- Oh kecepatan? Ini? - Iya.

46:16- Ini? - Iya.

46:17Yes, stop.

46:19Nah, cara, cara memencode itu sebenarnya itu cuma Base64 encode header-nya.

46:26Header itu JSON kan.

46:28Oh ini, ini datanya kita nih.

46:31Iya, itu Base64.

46:35- Terus sama ini, Base64. - Oh iya ini ya, berarti.

46:39Terus yang signature-nya, Base64 ini, tambah Base64 ini, tambah, tambah secret-nya.

46:47Terus di kassisha 26, 256.

46:53Itulah jadi verified-nya.

46:56- Biasanya di... - Terus dipisahkan titik ya itu.

47:00Bagi dia pake titik ya ini ya.

47:03- Ya ini kan dia? - Iya.

47:06Oke.

47:08Kalau di browser client-side kan ada A to B, B to A kan.

47:13Kalau untuk Base, apa Base64.

47:17Tapi hati-hati jangan lupa di note gak ada itu.

47:21- Itu kan feature browser. - Jadi?

47:23A to B dan B to A itu feature-nya web browser.

47:27Kalau kita pakai JavaScript di server-side,

47:31Pakainya buffer, buffer from, kan ada tuh buffer.from untuk Base64. Cuma exactly gimana ya gak apal sih.

47:40Oke.

47:42Pokoknya pakainya API buffer.

47:46Ya, ya, ya.

47:50Nah, next-nya kita bahas apa nih?

47:53Yang sisa apa ya? Oh ini, apa?

47:57WebAuthent. Nah, ini WebAuthent ini apa nih? Barang baru kayaknya ya.

48:03Nah dia, ini ya. Identity bukan.

48:07WebAuthent.io deh.

48:09Bukan. Bukan web.dev/identity.

48:13Bukan. Nah, itu dia.

48:16WebAuthent itu spesifikasi.

48:20Jadi spesifikasi untuk men-strainline atau menstandarisasi proses autentikasi di web.

48:30Yang sebelumnya kan standarisasi ya misalnya tadi tuh apa?

48:34Authorization scheme yang basic, better.

48:37Tapi sekarang kan makin lama autentikasi makin canggih.

48:41Terus belum teknologi masing-masing device.

48:44Misalnya kan udah ada ya semacam fingerprint atau biometrics fingerprint.

48:50Terus ada juga misalnya perantara Iris ya.

48:56Terus ada Retina.

48:59Mungkin ada perantara atau aplikasi untuk 2 factor authentication juga.

49:05Jadi kan intinya makin sekarang autentikasi makin rumit dan makin bermacam-macam.

49:11Nah, ini adalah spesifikasi yang berusaha men-strainline workflow autentikasi itu.

49:19- Nah, bagusnya Nisa. - Simple-nya begini.

49:24Ada yang pernah punya akun BCA nggak?

49:27Ya, punya.

49:29Pernah nggak dulu dikasih token?

49:32- Oh, yang biru itu. - Iya, yang biru.

49:36Jaman dulu sebelum ada standarisasi autentikasi ini,

49:43kan masing-masing aplikasi punya caranya sendiri untuk nge-generate.

49:48- Belum ada standar ya? - Itu sama aja.

49:50Sebenarnya yang key BCA atau key mendiri itu kan sebenarnya 2 factor authentication.

49:56Sebenarnya, jadi untuk mengautorisasi.

49:59Jadi kita sudah masukin login, mau transfer.

50:02Habis mau transfer, tanya lagi nih, masukin aplikasi 1 di key BCA-nya.

50:08Aplikasi 1, aplikasi 2, gitu kan.

50:10Di lama banget nggak pakai, gila.

50:12Nah, itu kan setelah dia muncul angkanya, di-generate di sini, terus balik sana.

50:19Itu kan standar yang dibikin bank itu sendiri.

50:23Kita nggak tahu standar itu apa.

50:25Itu punya mereka sendiri, algoritmanya nggak ada yang tahu.

50:28Mungkin cuma mereka yang tahu.

50:30Sedangkan web autentikasi ini adalah standarisasi dari sisi web

50:38jika kita ingin punya autentikasi yang seperti itu.

50:44Misalnya pakai 2 factor authentication, pakai uBKey.

50:50Jadi, men standarisasi semua cara meng-generate autentikasi, 2 factor authentication seperti itu.

50:59Oke, ini adalah spesifikasi implementasinya.

51:03Teman-teman bisa cek di sini.

51:05Ada yang pakai Python, Go, pakai TypeScript.

51:09TypeScript ada 2 malah ya.

51:11Ada Ruby, Java, Java juga ada 3.

51:14Bahkan bisa akses itu ya, kayak fingerprint ya.

51:18Kalau di device yang memang support.

51:22Dan kalau buat gue sih, ini yang menarik nih biasanya vendor itu kan agak sulit buat compact ya.

51:29Apalagi buat ala yang major seperti ini.

51:31Nah, tumben banget ini web autentikasi itu udah, walaupun mungkin implementasinya,

51:37maksudnya mungkin nggak semua API di support ya.

51:41Tapi ini Chrome, Firefox, Edge, sama kalau WebKit belum mungkin ya.

51:47Chrome, Firefox, Chromium, dan Firefox udah bisa compact.

51:53WebKit nggak ada ya malah ya.

51:56Oh, WebKit belum.

51:58Gak ada di sini sama sekali.

52:00Iya aja ada walaupun semua nggak bisa gitu.

52:03Safari, safari ada gitu.

52:05Safari, safari.

52:07Cuma emang nggak semua, cuma sebagian.

52:09Tapi kan udah lumayan banget ini.

52:11Maksudnya ini pertanda yang bagus ke depannya.

52:14Iya, bener, bener.

52:17Hampir 2 dari 5 ya.

52:221, 2, 3, 4, 5.

52:24Karena desktop Linux juga nggak ada safari di sana kan.

52:27Desktop Linux nggak ada yang bisa.

52:30Wah, suara robot lagi nih.

52:37Halo?

52:38Sorry, sorry.

52:39Boleh diulang lagi?

52:41Ya, masing-masing vendor udah mulai mengadopsi ini.

52:47Hmm, oke.

52:50Ini roaming authentication.

52:53Apa ini roaming authentication?

52:55Spread Hardware Authenticator.

52:57Oh, ini ya, YubiKey gitu-gitu ya?

52:59Itu tadi key.

53:00Ya, oke.

53:02Ini juga udah hampir semua support ya.

53:06Ada yang punya YubiKey nggak?

53:09Dulu sempat dapat dari Chrome Dev Summit, tapi hilang.

53:13Waduh.

53:15Hilang.

53:16Oh, masih ada.

53:19Yang iru itu kan?

53:21Iya.

53:22Yang kita cuma kayak ditaruh di atas meja, ambil-ambil aja gitu.

53:26Ternyata mahal, Bo.

53:28Mahal ya.

53:30Belum jamannya di Chrome Dev Summit.

53:3250 dolar.

53:3450 dolar?

53:35Oh.

53:36Iya.

53:38Padahal itu cuma ditaruh di atas meja, mau ngambil berapa aja terserah.

53:42Iya.

53:44Kalau mental maling, ambil di jual lagi.

53:47Nah, ini kan, coba kalau si web autent ini lumayan rumit dan lumayan banyak scope-nya.

53:55Tapi yang direkomendasikan sih kalau cuma pengen tahu.

53:58Ini kan belum kebayang kan.

54:00Pasti kalau yang belum pernah pakai, baca ini nggak kebayang, abstrak.

54:05Solusinya itu tuh ada code web-nya.

54:08Ada code web yang cukup bagus.

54:10Ya, kalau mau coba.

54:13Kalau mau coba ya.

54:15Eka jadi robot.

54:23Eka jadi robot.

54:24Lagi, ulang, ulang, ulang.

54:26Iya.

54:27Tuh.

54:28Apa?

54:29Masih, halo, halo, halo.

54:31Halo.

54:33Halo.

54:35Ini direkomendasikan untuk belajar langkah-langkahnya sama bagian-bagiannya.

54:46Kita sendiri belum coba.

54:52Jadi kalau mungkin nanti kita ada kesempatan untuk implementasi,

54:57kita bisa bahas di episode yang terpisah kali ya, lebih detail.

55:01Karena ini lagi hot-hot-nya nih.

55:03Lagi banyak dibahas juga ya.

55:05Lagi menarik.

55:06Webaltern.

55:08Mudah-mudahan nanti dibahas lagi di I/O.

55:11Mudah-mudahan.

55:12Nah, kalau ada pembahasan di I/O atau di conference-conference, nanti mungkin kita bisa bahas.

55:19Kita bahas lebih detail kali ya.

55:22Lebih detail lagi ya.

55:23Jadi mungkin ini agak diluar scope dari topik kita malam hari ini.

55:29Karena kita juga belum ada kesempatan buat nyoba ya.

55:33Buat implementasi ini karena juga cukup baru.

55:35Walaupun secara support kayaknya udah lumayan optimis ya.

55:41Bakal disupport penuh karena ya sekarang aja baru muncul udah disupport banyak browser ya.

55:47Ya.

55:49Oke.

55:51Ada lagi?

55:56Ada lagi.

55:58Sepertinya.

56:00Habis.

56:02Oke, kalau gitu berhubung mata di kita sudah habis.

56:06Kenapa?

56:08Siapa tahu nanti hari Selasa ada yang nonton dan mereka mengikuti WorldCamp Asia di Bangkok.

56:15Oh iya, boleh.

56:17Ya, say hi aja ke saya.

56:19Kenapa saya nggak bisa ikut live karena saya lagi ada di Bangkok.

56:23Lagi organize WorldCamp Asia 2023.

56:26Jadi kalau ada temen-temen, temen-temen ada yang ke Bangkok ikut acara nanti say hi.

56:34Ya.

56:36Atau ada di live stream juga ya?

56:38Live stream, live stream.

56:40Oh, say hi online bisa juga.

56:44Asia.WorldCamp.org 2023.

56:49Oke.

56:51Bagi temen-temen yang nggak bisa datang, ada live streamnya silahkan.

57:00Banyak topik-topik yang menarik tentang WordPress.

57:05Ya.

57:0717 sampai 19.

57:09Suruh sekali.

57:11Mana nih? Agendanya mana agenda?

57:15Schedule, conference day.

57:17Itu 17 itu contributor day.

57:2518 itu acara utamanya.

57:30Jadi evolution segala macam.

57:35SIPI, development, ada security, ada design, ada full-site editing juga tuh, full-site editing.

57:48Menarik ya.

57:51Ya.

57:53Seru, seru, seru.

57:55Ini hari ke-2-nya, hari ke-3-nya tanggal 19.

57:59Masih conference juga ya berarti ya?

58:01Conference juga, ada multilingual, ada automatic QA, visual education testing, progressive web app, and so on.

58:12Ya.

58:14Mungkin nanti kita bisa bahas review-nya juga, pengalamannya di sana.

58:18Oh iya, buat minggu depan ya.

58:20Gimana pengalamannya buat minggu depan mungkin?

58:22Saya organizer, jadi kalau pengalaman ikut session mungkin nggak banyak.

58:26Gak apa-apa, pengalaman menjalankan sebagai organizer.

58:32Karena kan kita juga pengen nih, ada conference-conference di Indonesia kan, mulai bisa dijalankan lagi kan.

58:41Conference development.

58:43Ayo ngobrolin web conference.

58:46Isinya ngobrol-ngobrol.

58:50Jangan terlalu muluk-muluk lah.

58:52Kalau bisa kita live dulu di satu conference, kita numpang.

58:56Oh iya, bisa-bisa.

58:58Yang nonton jumlah nggak sampai 100, mau bikin conference.

59:06Oke kalau gitu, mungkin untuk malam ini kita udahan dulu.

59:12Terima kasih buat teman-teman yang udah nonton.

59:14Jangan lupa, kalau ada kritik, saran, ada topik, diskusi, bisa ke bit.ly/ngobrolinweb.

59:21Malam ini kita pamit.

59:23Saya Riza, bisa kalau ada mo sehai bisa di Twitter, Rizafami22.

59:29Ada Eka juga, di Eka.fi, dan ada Ivan di IvanKris.com.

59:37Oke, sekian dulu.

59:39Selamat malam, selamat istirahat, sampai jumpa minggu depan.

59:42Dadah.