- JWT adalah singkatan dari JSON Web Tokens, yaitu standar untuk token yang terautentikasi.
- JWT terdiri dari header, payload, dan signature atau message authentication code.
- Siapa pun yang memiliki kunci verifikasi dapat memeriksa keaslian payload.
Pola penggunaan JWT yang umum
- JWT memuat informasi seperti penerbit, penerima, subjek, dan waktu kedaluwarsa.
- Penerima memverifikasi keaslian token, lalu memeriksa apakah token belum kedaluwarsa, dan menganggap subjek sebagai pengguna yang telah terautentikasi.
Kelebihan JWT
- Kelebihan utama JWT adalah penerima dapat memverifikasi keaslian token tanpa terhubung ke basis data pengguna.
- Pada lingkungan instalasi berskala besar, layanan autentikasi dapat menjadi satu-satunya layanan yang mengakses basis data pengguna pusat.
Masalah logout dan invalidasi sesi
- Masa hidup token autentikasi harus pendek. Misalnya, maksimal 5 menit.
- Klien juga menerima refresh token yang dapat digunakan untuk meminta token autentikasi baru.
- Refresh token pada praktiknya berperan sebagai token sesi yang sebenarnya.
Kapan JWT tidak diperlukan
- Untuk mengimplementasikan logout, Anda harus mempertahankan allowlist untuk JWT yang valid atau denylist untuk JWT yang telah dicabut.
- Untuk memblokir pengguna, Anda perlu memeriksa flag "pengguna aktif" di basis data.
- Diperlukan relasi tambahan antara objek pengguna dan objek lainnya.
- Anda melakukan pekerjaan yang berkaitan dengan basis data.
Kesimpulan
- Jika salah satu kondisi di atas berlaku, maka JWT tidak diperlukan.
- Lebih baik menggunakan token sesi opak biasa dan menyimpannya di basis data.
- Anda dapat menghindari kekurangan JWT dan mengurangi kompleksitas.
Opini GN⁺
- JWT cocok untuk layanan berskala besar, tetapi bagi sebagian besar layanan kecil, JWT dapat menimbulkan kompleksitas yang berlebihan.
- Mekanisme manajemen sesi yang umum sudah memadai untuk sebagian besar aplikasi web.
- Penggunaan JWT dapat mempersulit implementasi fitur seperti logout dan invalidasi sesi.
- Untuk memanfaatkan kelebihan JWT, Anda perlu mempertimbangkan dengan cermat skala dan kebutuhan layanan.
- Sebagai alternatif lain, Anda dapat mempertimbangkan framework autentikasi seperti OAuth2.
8 komentar
Saat diperlukan autentikasi untuk berbagai klien, penggunaan JWT memberi banyak keuntungan.
Namun, karena skalabilitas dan keamanan selalu mengarah ke arah yang berbeda, jika keamanan sangat penting, saya rasa lebih baik menggunakan metode lain.
Secara pribadi, menurut saya token JWT sebaiknya dipakai saat bertukar data sementara antarsistem melalui browser, ketika datanya tidak masalah jika terekspos.
Untuk token yang dipakai untuk autentikasi dan berisi informasi pribadi, saya rasa lebih baik menggunakan token opaque..
Berdasarkan pengalaman pribadi, JWT memang punya kelebihan saat membuat MVP.
Misalnya, kalau ini layanan yang dibuat dan dipelihara sendirian, saya merasa ini bisa mengurangi biaya perencanaan akibat permintaan yang datang tiba-tiba. Soalnya, relasi data yang awalnya ditetapkan sering kali berubah total satu atau dua bulan kemudian, jadi ketika perencanaan belum benar-benar jelas, setidaknya untuk hal yang terkait
auth, saya ingat pernah mengimplementasikan fitur dengan menyusun payload JWT dalam bentuk field opsional. Dengan begitu, tanpa tim perencanaan harus langsung mengerjakan pemisahan domain dan pemisahan layanan, kami bisa lebih dulu mengimplementasikannya dalam layanan monolitik dengan bentuk yang memudahkan pemisahan domain saja, lalu mengujinya ke pasar. (Setelah itu baru masuk ke tahap memisahkan layanannya. Atau malah dihapus.)Tapi, menurut saya ini juga akan berbeda tergantung domain dari layanan yang ingin dibuat. Proyek tersebut adalah proyek real-time service yang tingkat keterikatannya dengan third party cukup tinggi.... jadi saya ingat waktu itu memilih pendekatan tersebut dengan pemikiran bahwa jika diimplementasikan terlalu cepat, lalu menumpuk dokumen/row dalam jumlah sangat besar di database, biaya pengelolaannya bisa membesar.
Tentu saja, kalau fokusnya benar-benar pada membuatnya secepat mungkin, saya rasa pendekatan sesi lebih baik. (Pada tahap awal, coupling antar layanan juga belum terlalu kuat, jadi lebih mudah dibongkar dan dibuat ulang.) Biaya serah terima saat anggota tim lain bergabung juga lebih kecil.
Saat itu saya sempat memikirkannya dari berbagai sisi, tetapi kalau dipikir-pikir sekarang, rasanya apa pun pendekatan implementasinya, dampaknya ke proyek mungkin tidak akan terlalu serius.
Secara pribadi saya merasa saat menggunakan API gateway, saya mendapat keuntungan ketika mengimplementasikan auth dengan JWT, tetapi saya penasaran apa saja kelebihan JWT pada layanan berskala kecil. Apakah yang Anda maksud adalah kasus ketika informasi pengguna yang dimasukkan ke dalam JWT sering berubah?
Secara garis besar saya sependapat dengan yang Anda katakan. Hanya saja, alih-alih pemodelan pengguna itu sendiri berubah sehingga informasinya harus sering diubah, kasusnya lebih dekat ke penambahan opsional ketika ada fitur baru atau layanan baru yang memerlukan informasi tambahan karena harus memakai tool pihak ketiga. (Sedikit menambahkan, ada juga situasi yang samar apakah auth secara potensial akan dipisahkan unit pengelolaannya memakai semacam API gateway, atau akan ada satu server yang menjalankan peran serupa...)
Kalau dijelaskan sedikit lebih konkret, waktu itu kondisinya adalah kami menjadikan layanan A sebagai yang utama. Karena masih tahap MVP, di tabel pengguna hanya ada informasi pembayaran dan apakah pengguna sudah terverifikasi. Lalu masuk permintaan untuk menambahkan layanan B dan C, yang hanya bisa digunakan jika tiap pengguna punya informasi autentikasi yang berbeda. Di antaranya, bahkan belum diputuskan apakah B akan masuk ke dalam layanan A, sedangkan C bisa saja dihapus jadi mereka ingin mengujinya secara ringan. (Dan fitur manajemen plan, meski tidak perlu disebutkan pun, pada akhirnya harus ditambahkan agar tidak menimbulkan masalah). Selain itu, mereka ingin memulainya dalam bentuk penggunaan B dan C bersama-sama di halaman web yang sudah menyediakan layanan A. Karena karakteristik layanan yang sudah berjalan, sebelum kami membuat tabel manajemen plan (atau tabel autentikasi yang lebih umum) lalu menggambar relasi domain per layanan dan mengimplementasikan pemetaannya, situasi di mana harus melakukan kueri ke beberapa tabel (atau beberapa koleksi) tidak bisa dihindari. Kalau ada orang yang bisa merapikan proyek ini, mungkin akan lebih baik kalau kami sempat beberapa kali rapat untuk benar-benar menajamkan sebenarnya masalah apa yang ingin diselesaikan dan fitur apa yang diinginkan, tetapi situasi seperti itu tidak terjamin. Selain itu, juga tidak jelas kapan utang-utang teknis seperti ini bisa dibereskan. Jadi, karena tanda-tanda bahwa hal seperti ini akan terjadi sudah terlihat bahkan sebelum peluncuran layanan A... saat menyusun arsitektur awal, saya jadi berpikir sebaiknya auth dibuat dengan bentuk yang sebisa mungkin menghemat biaya kueri dan biaya pemeliharaan ke depannya, dan akhirnya memilih JWT. Selain itu, sepertinya memang ada sangat banyak hal kecil serupa yang terus terjadi.
Namun, seperti yang saya sebutkan di akhir komentar, sebenarnya apa pun yang dipakai untuk implementasinya, dampaknya ke proyek secara keseluruhan mungkin tidak akan terlalu besar. Kalau diimplementasikan dengan session, saya rasa kami juga akan menemukan caranya sendiri. Justru yang jauh lebih fatal tampaknya adalah situasi ketika developer harus mengerjakan pekerjaan dari fungsi lain atau terus-menerus terekspos pada kondisi di mana biaya komunikasi menjadi berantakan.
Meskipun cocok untuk struktur monolitik, ketika sebagian layanan mulai dipisahkan atau berada di persimpangan untuk melakukan ekspansi, JWT dan logika berbasis sesi jelas menunjukkan perbedaan. Bukan hanya pada prosedur autentikasi yang sederhana, tetapi juga pada kegunaan dalam logika internal, karena teknik untuk menangani sumber data akan berbeda. Saya kurang paham dengan standar apa konteks "layanan kecil" dinilai cocok. Apakah premisnya semua layanan pasti akan tetap kecil? Atau premisnya layanan besar akan sulit? Namun, saya merasa bahwa layanan yang selalu kita buat setidaknya perlu memiliki struktur minimum yang mendukung konteks yang mungkin tidak kita ketahui situasinya, tetapi tetap berguna. Premis tentang layanan kecil sepertinya hanya akan terus membuatnya tetap kecil.
Opini Hacker News
Ringkasan komentar Hacker News