Arsitektur JWT untuk banyak pengguna?

Kebanyakan contoh selalu mempertimbangkan hanya satu pengguna yang menggunakan sistem dalam tutorial JWT/Flask. Saya ingin memahami hal ini pada tingkat multi-pengguna tetapi tidak dapat menemukan sumber daya yang tepat.

Katakanlah kita memiliki kunci rahasia berikut:

app.config['SECRET_KEY'] = 'randomkey'

Dua pertanyaan:

  • Apakah kunci ini akan sama untuk setiap pengguna? jika demikian, bukankah hal ini menimbulkan risiko keamanan karena jika kuncinya dicuri, siapa pun akan memiliki akses untuk melakukan apa pun yang mereka inginkan?
  • Jika tidak sama, bagaimana kuncinya disimpan di sisi server sehingga bisa diautentikasi saat meminta informasi? Apakah itu akan disimpan dalam tabel pengguna dengan token saat ini atau semacamnya?

jwt
person STOPIMACODER    schedule 13.09.2020    source sumber

Jawaban (1)


arrow_upward
0
arrow_downward

Dalam hal ini, kunci tersebut adalah kunci penandatanganan JWT. Ini juga bisa berbeda dari pengaturan kunci rahasia labu (lihat dokumen labu). Ini tidak digunakan untuk enkripsi sehingga tidak dimaksudkan untuk menjadi rahasia bersama antara server dan pengguna. Perannya adalah memberikan bukti kepada server bahwa konten JWT dibuat oleh server itu sendiri: ini adalah bukti integritas.

Memiliki pengetahuan tentang kunci tersebut berarti memiliki hak untuk menerbitkan JWT atas nama aplikasi, penyerang dapat menyamar sebagai server atau membuat permintaan dengan beberapa klaim yang dimodifikasi, misalnya berpura-pura menjadi pengguna lain. Artinya, kunci-kunci ini cukup masuk akal dari sudut pandang keamanan

Ternyata 1 aplikasi : 1 kunci, dengan beberapa keterangan

  1. Kunci ini secara teoritis tidak boleh berubah: jika pada waktu T1 KEY=x, pengguna dapat masuk dan menerima JWT yang ditandatangani dengan KEY=x. di T2 KEY=y, pengguna akan memanggil beberapa API menggunakan JWT sebelumnya dan server akan mencoba memverifikasi(signature(payload , x) , y). Jadi setiap pengguna akan logout secara otomatis

  2. Meskipun 1. Akan lebih baik jika memutar kuncinya. Dalam hal ini sistem otentikasi harus menyimpan buffer kunci lama dan menggunakannya untuk memvalidasi JWT terlama. Karena JWT harus berumur pendek, akan berguna untuk mengatur waktu rotasi yang lebih besar daripada waktu berakhirnya JWT dan hanya menyimpan kunci yang terakhir digunakan bersama dengan kunci saat ini.

  3. Kunci ini bersifat rahasia dan harus dikelola sama seperti rahasia lainnya. Selain pendekatan yang buruk seperti membiarkannya dalam teks biasa di kode/konfigurasi, terdapat pengelola rahasia dari penyedia cloud, atau rahasia kubernetes jika Anda menggunakan yang terakhir, serta pengelola rahasia dari alat manajemen konfigurasi (salt, ansible) atau Gudang Hashicorp yang merupakan mesin penyimpanan khusus untuk data yang masuk akal. Bagaimanapun, ini lebih menjadi perhatian tim infra/keamanan jika Anda berada dalam organisasi terstruktur

person Carmine Ingaldi    schedule 13.09.2020