Pemilihan Kunci JWS Adalah Keputusan Trust, Bukan Instruksi Header

Token bertanda tangan dapat membawa metadata yang mengarahkan verifier ke sebuah kunci. Protected header JWS dapat menyebut algoritma melalui alg, mengidentifikasi kunci melalui kid, atau, pada profile yang mengizinkannya, membawa maupun mereferensikan material kunci melalui parameter seperti jwk, jku, x5c, atau x5u. Field tersebut berguna untuk mengarahkan proses verifikasi, terutama saat rotasi kunci.

Field tersebut tidak membuktikan bahwa kunci yang dipilih memang tepercaya untuk token yang sedang diproses.

Perbedaan itu menempatkan security boundary di dalam verifier. Nilai header datang bersama objek yang autentisitasnya masih sedang diperiksa. Verifier dapat memakainya untuk mempersempit sekumpulan kunci yang sebelumnya sudah dianggap layak, tetapi menerima kunci hanya karena objek menunjuk ke sana akan mengubah metadata yang dikendalikan penyerang menjadi konfigurasi trust.

kid memilih di dalam key set; ia tidak mengautentikasi set tersebut

RFC 7515 mendefinisikan kid sebagai key identifier dan menyebutnya sebagai petunjuk yang menunjukkan kunci yang mengamankan JWS. Saat dipakai bersama JWK, nilainya dapat dicocokkan dengan member kid dari kandidat kunci. Identifier ini tidak memiliki struktur standar dan tidak membawa bukti independen bahwa kunci yang cocok dimiliki issuer tertentu.

Karena itu, verifier memerlukan sumber tepercaya untuk key set sebelum kid menjadi berguna. Pada deployment yang umum, konfigurasi mengikat issuer atau security domain ke key set lokal atau endpoint JWKS tertentu. kid dari token kemudian dapat memilih kandidat dari set yang sudah dibatasi tersebut.

Urutannya penting:

konfigurasi issuer tepercaya
          |
sumber kunci yang disetujui
          |
       kid match
          |
pemeriksaan algoritma dan kunci
          |
verifikasi signature

Membalik hubungan tersebut mengubah model keamanan. Jika input kid arbitrer dapat memilih kunci di luar set yang dikonfigurasi untuk issuer, identifier itu telah keluar dari fungsi routing dan mulai memengaruhi trust.

Duplikasi key identifier juga memerlukan penanganan eksplisit. Spesifikasi JOSE tidak membuat kid unik secara global. Verifier yang menggabungkan kunci dari beberapa issuer atau tenant ke satu namespace harus mempertahankan konteks yang cukup agar identifier yang sama tidak melintasi boundary tersebut.

Kebijakan algoritma berada di sisi verifier

Header alg menyatakan algoritma yang digunakan untuk mengamankan JWS. Field ini wajib dalam pemrosesan JWS, tetapi keberadaannya bukan izin untuk memakai algoritma apa pun yang kebetulan didukung library.

RFC 8725 mewajibkan library menyediakan cara bagi caller untuk menentukan kumpulan algoritma yang didukung dan melarang penggunaan algoritma di luar set tersebut dalam operasi kriptografi. RFC itu juga mensyaratkan algoritma pada header sama dengan operasi yang benar-benar dijalankan serta menetapkan bahwa setiap kunci dipakai dengan tepat satu algoritma.

Pilihan algoritma menjadi irisan dari tiga input:

deklarasi token: alg = ES256
kebijakan verifier: allowed = {ES256}
kebijakan kunci:    kunci valid untuk ES256
                    ------------------------
hasil:               kandidat dapat diverifikasi

Jika salah satu kondisi gagal, parsing yang berhasil tidak relevan. Verifier belum mencapai operasi kriptografi yang dapat diterima.

Boundary ini sangat penting saat library menyediakan API verifikasi generik yang mendukung algoritma MAC simetris sekaligus algoritma signature asimetris. Konfigurasi aplikasi harus menentukan family dan algoritma yang valid untuk suatu kelas token, bukan membiarkan token mengambil keputusan itu sendiri.

Referensi kunci remote menambah network trust boundary

JWS mendefinisikan parameter header yang dapat mereferensikan material remote. jku dapat menunjuk ke JWK Set URL, sedangkan x5u dapat menunjuk ke sertifikat X.509 atau certificate chain. RFC 7515 menetapkan persyaratan integrity dan TLS untuk pengambilan material sertifikat, tetapi trust aplikasi tetap tidak dapat direduksi menjadi “ambil URL dari header.”

Deployment yang mengizinkan referensi kunci remote memerlukan kebijakan lokasi yang dapat diterima. Kebijakan tersebut dapat mengikat issuer token ke endpoint yang persis, origin yang dikendalikan, atau sumber lain yang ditetapkan aplikasi. Verifier juga memerlukan kontrol jaringan normal yang sesuai untuk akses keluar.

Tanpa boundary tersebut, key discovery dan akses jaringan menjadi terikat pada input tidak tepercaya. Masalahnya lebih luas dari verifikasi signature: resolver tanpa pembatasan juga dapat menciptakan perilaku server-side request menuju lokasi yang tidak pernah dimaksudkan aplikasi.

Caching tidak menghilangkan keputusan trust. Cache dapat mengurangi traffic jaringan dan mendukung rotasi, tetapi entry tetap perlu dipisahkan berdasarkan konteks keamanan yang membuat kunci tersebut dapat diterima. kid saja biasanya terlalu lemah sebagai global cache key ketika beberapa issuer dapat menggunakan identifier yang sama.

Kunci embedded memerlukan alasan eksternal untuk dipercaya

Parameter header jwk dapat membawa public key secara langsung di dalam JWS. Secara mekanis ini praktis karena verifikasi tidak lagi memerlukan lookup terpisah. Namun, bentuk ini juga membuat perbedaan trust sangat jelas: kepemilikan public key yang dapat memvalidasi signature membuktikan konsistensi antara kunci dan signature, bukan bahwa aplikasi harus memercayai signer.

Penyerang dapat membuat key pair, menandatangani content arbitrer, lalu menyertakan public key pasangannya. Verifikasi kriptografi dapat berhasil sempurna sementara autentikasi aplikasi gagal total jika verifier menerima setiap kunci embedded.

Sebuah profile dapat secara sah memakai kunci embedded ketika mekanisme lain mengautentikasi atau membatasinya. Binding dapat berasal dari registrasi sebelumnya, certificate chain yang berakar pada trust store yang diterima, thumbprint yang sudah dikaitkan dengan principal, atau aturan khusus protocol. Intinya, alasan untuk memberikan trust berasal dari luar nilai kunci yang menyatakan dirinya sendiri.

Rotasi kunci mengubah kandidat, bukan trust anchor

Rotasi sering menjadi alasan penggunaan pemilihan kunci dinamis. Issuer dapat mempublikasikan beberapa kunci aktif saat token lama masih valid dan token baru berpindah ke signing key yang baru. kid memungkinkan verifier memilih kandidat yang cocok tanpa mencoba setiap kunci.

Verifier tetap perlu mengikat set yang diperbarui ke konteks issuer yang sama. Dokumen JWKS yang berubah dapat secara sah menambah dan menghapus kunci, tetapi mekanisme pengambilannya tidak boleh diam-diam mengganti authority yang menentukan set tersebut.

Perilaku operasional juga memerlukan kebijakan kegagalan yang terbatas. kid yang belum tersedia setelah rotasi dapat memicu refresh pada sebagian implementasi, tetapi refresh tanpa batas untuk identifier arbitrer dapat mengubah token yang dikendalikan penyerang menjadi outbound request berulang. Cache, refresh suppression, dan rate limit adalah kontrol implementasi di sekitar perilaku itu; semuanya tidak mengubah semantik kriptografi JWS.

Kunci lama menimbulkan pertanyaan kebijakan yang berbeda. Menghapus kunci seketika dapat membuat token yang masih aktif menjadi tidak valid. Mempertahankannya tanpa batas dapat memperpanjang penerimaan melewati jendela rotasi yang diinginkan. Periode overlap yang tepat mengikuti masa berlaku token dan kebijakan deployment, bukan properti yang dikodekan oleh kid.

Kelas token harus tetap menjadi bagian dari konteks verifikasi

Sebuah service dapat menerima beberapa jenis objek bertanda tangan dari ekosistem yang sama: access token, ID token, logout token, request object, atau assertion khusus aplikasi. Walaupun dua objek memakai algoritma JOSE yang sama, menerima kunci dan claim yang sama tanpa konteks dapat meruntuhkan boundary yang dipisahkan oleh protocol.

Karena itu, pemilihan kunci sebaiknya berjalan bersama pemeriksaan kelas token, issuer yang diharapkan, audience, dan constraint lain yang ditetapkan profile. Validitas signature menjawab pertanyaan yang sempit: byte tersebut ditandatangani pemegang kunci yang dipilih. Validitas itu tidak membuktikan bahwa objek sah untuk endpoint atau peran protocol ini.

RFC 8725 menempatkan explicit typing dan aturan validasi yang saling eksklusif sebagai pertahanan terhadap cross-JWT confusion. Dalam praktiknya, verifier lebih kuat ketika entry point sudah membawa konteks seperti “validasi access token dari issuer A untuk resource B”, alih-alih menerima objek bertanda tangan generik dan mengambil seluruh kebijakan dari isinya.

Verifier yang aman mempersempit input penyerang pada setiap tahap

Jalur verifikasi yang kokoh memperlakukan metadata JOSE sebagai data yang harus divalidasi di dalam kebijakan yang sudah ada:

  1. Tentukan kelas token dan konteks issuer yang diharapkan dari protocol flow atau state aplikasi tepercaya.
  2. Muat atau identifikasi sumber kunci yang diizinkan untuk konteks tersebut.
  3. Terapkan allowlist algoritma secara eksplisit.
  4. Gunakan kid atau identifier lain yang diizinkan hanya untuk mempersempit kandidat di dalam sumber tersebut.
  5. Konfirmasi key type, kompatibilitas algoritma, dan constraint kunci khusus profile.
  6. Verifikasi JWS secara kriptografis.
  7. Terapkan validasi claim token dan protocol secara terpisah dari keberhasilan signature.

API yang tepat berbeda pada tiap library JOSE, tetapi boundary-nya seharusnya tetap terlihat. Parsing, key discovery, verifikasi signature, dan penerimaan oleh aplikasi adalah keputusan yang terpisah.

Validitas kriptografi berada setelah provenance kunci

JWS menyediakan format portabel untuk menandatangani data beserta metadata yang cukup untuk mendukung pemilihan kunci secara praktis. Format tersebut secara sengaja menyerahkan sebagian keputusan trust kunci dan kebijakan aplikasi kepada protocol serta deployment yang memakainya.

Pembagian ini berguna. Verifier dapat merotasi kunci, menyimpannya dalam cache, dan mengarahkan verifikasi secara efisien tanpa menjadikan setiap field header sebagai sinyal authority. Properti penentunya adalah provenance: kandidat kunci harus sudah menjadi bagian dari konteks trust yang diterima aplikasi, dan algoritma yang dideklarasikan harus sesuai dengan kebijakan konteks tersebut.

Signature yang diperiksa menggunakan kunci pilihan penyerang yang dipercaya secara default tetap merupakan signature matematis yang valid. Hasil itu bukan keputusan autentikasi yang valid.

Keamanan Siber JWS JWT JOSE Kriptografi