Checklist Review Keamanan JWT untuk API Web
Profil token, batas key, dan uji penolakan
Tentukan profil token untuk setiap penggunaan: algoritme yang diizinkan, issuer tepercaya, key set, audience, claim wajib, tipe token, dan toleransi clock. RFC 8725 meminta pemanggil mengonfigurasi algoritme yang diterima, bukan mengikuti alg yang tidak tepercaya. kid memilih di dalam key set yang dikonfigurasi; nilainya tidak boleh memilih file, record SQL, nilai LDAP, atau URL jku maupun x5u sewenang-wenang.
Buat uji penolakan untuk none, pertukaran algoritme, ID key tidak dikenal, signature rusak, token kedaluwarsa, token belum berlaku, issuer salah, audience salah, tipe salah, dan token valid dari aplikasi lain. Token akses pembayaran harus gagal di API administrasi walau kriptografi lolos. Token bertingkat yang ditandatangani serta dienkripsi memerlukan validasi setiap operasi. Simpan header uji yang telah disamarkan, versi konfigurasi verifier, timeline rotasi key, dan output batas clock.
Perbaikan menggunakan library yang dipelihara dengan opsi algoritme serta claim eksplisit, instance verifier terpisah per issuer atau tujuan token, dan overlap key terbatas saat rotasi. Uji penutup membuktikan perilaku key lama mengikuti rencana rotasi dan token audience salah tetap ditolak. Otorisasi selalu mengikuti verifikasi: claim subject valid tidak memberi aksi yang tidak terdaftar. Pengecualian kompatibilitas harus menyebut issuer lama, tanggal akhir, dan audience terbatas.
Penanganan clock membutuhkan data uji eksplisit. Verifikasi expiry pada batas, skew yang diterima, dan penolakan sesudahnya; jangan diam-diam bergantung pada default sistem. Uji rotasi key harus menunjukkan penerimaan key baru serta perilaku key pensiun tanpa meminta lokasi tidak tepercaya. Bila claim memilih record database atau izin, perlakukan claim sebagai input tervalidasi yang tetap tunduk pada otorisasi lokal. JWT ringkas dapat bertanda tangan tetapi memuat claim berlebihan atau tidak sesuai; profil harus menolaknya.
Menentukan profil verifier
Signature JWT saja bukan otorisasi. Tentukan satu profil verifier untuk setiap penggunaan token: algoritme diizinkan, issuer, sumber key tepercaya, audience yang diharapkan, tipe token, claim wajib, clock skew diizinkan, dan policy otorisasi lokal. RFC 8725 menyatakan aplikasi harus menentukan algoritme diterima serta menolak lainnya. Jangan biarkan alg tidak tepercaya memilih perilaku, dan jangan biarkan kid, jku, atau x5u menjadi nama file, pemilih database, atau fetch URL sewenang-wenang.
Buat suite penolakan yang bekerja. Mulai dengan token valid untuk API pembayaran, lalu coba pada API administrasi. Berikutnya ubah alg, ganti key ID, rusak signature, hapus audience, ganti issuer, tukar tipe token, tetapkan exp kedaluwarsa, nbf masa depan, claim waktu rusak, dan header terlalu besar. Hasil yang diharapkan adalah gagal sebelum lookup subjek, cek policy, query database, atau panggilan provider. Token dengan substring audience akrab tidak cukup; cocokkan identifier layanan tujuan secara exact, termasuk aturan penanganan array.
Pemilihan key dan rotasi
Ambil metadata issuer serta JWK set hanya dari lokasi HTTPS tepercaya yang dikonfigurasi. Perilaku cache perlu membedakan key pensiun yang dikenal dari key yang tidak pernah terlihat. Saat rotasi terencana, uji penerimaan key baru, overlap key lama valid, dan penolakan key lama setelah pensiun. Saat respons kompromi, hapus key terdampak lalu pastikan cache menyatu pada penolakan. Simpan versi key set, interval cache, konfigurasi verifier, dan uji header tersamarkan sebagai bukti. Token nested memerlukan validasi tiap lapisan kriptografis menurut profil.
Claim, replay, dan policy lokal
Validasi tipe claim selain nilainya. iss harus terikat ke kepemilikan key; aud harus menyebut penerima ini; sub harus mewakili pasangan issuer-subjek yang diizinkan. Terapkan tipe eksplisit atau aturan validasi saling eksklusif saat ID token, access token, dan security-event token dapat berbagi issuer. Validasi token memberi konteks; policy lokal terpisah tetap memutuskan apakah subjek boleh menyetujui refund atau membaca objek.
JWT tidak sendirian memberi pencabutan seketika. Untuk sesi sensitif, gabungkan lifetime token pendek dengan sesi server atau policy pencabutan. Uji token setelah logout, penghapusan izin, dan pensiun key. Perbaiki dengan panggilan library terpelihara yang mematok algoritme serta claim, profil terpisah per tujuan, overlap key terbatas, dan metrik penolakan. Pengecualian migrasi issuer menyebut issuer tepat, audience, tanggal akhir, dan output test. Penutupan menjalankan ulang uji algorithm confusion, audience salah, serta rotasi setelah deployment.
Telemetry penolakan
Klasifikasikan penolakan tanpa mengembalikan detail claim kepada pemanggil: algoritme tidak cocok, key tidak dikenal, signature gagal, issuer salah, audience salah, tipe salah, dan token kedaluwarsa. Metrik membuka drift konfigurasi sambil menjaga kerahasiaan token. Lonjakan audience salah setelah deployment dapat menunjukkan klien memakai resource server keliru. Selidiki memakai identifier korelasi dan revisi konfigurasi, bukan nilai bearer yang disalin. Sinyal ini juga menegaskan verifier memakai profil tujuan, bukan fallback permisif.
Artefak review verifier JWT
| Pemeriksaan token | Penanggung jawab identitas | Status verifikasi | Bukti JWT | Hasil verifier yang diharapkan | Hasil verifier teramati | Pengecualian token | Penutupan verifikasi |
|---|---|---|---|---|---|---|---|
JWT-ROT-03 key penandatangan pensiun | owner platform identitas | Terbuka | konfigurasi verifier v42, uji kid tersamarkan, log rotasi | key baru diterima; key pensiun ditolak setelah overlap | key pensiun masih diterima satu node cache | EX-17, overlap cache sampai 2026-06-20, disetujui owner keamanan | bersihkan cache, ulang uji key pensiun dan audience salah, lampirkan ID request |