Alat pengembang · dekoder JWT
Dekode vs Verifikasi: Apa yang Dibuktikan oleh Tanda Tangan JWT dan Mengapa Decoder Melewatkannya
· Cara kerjanya
jwt keamanan kriptografi
Decoding tidak memerlukan kunci; verifikasi membutuhkan yang benar. Postingan ini menjelaskan apa saja yang tercakup dalam tanda tangan, perbedaan HMAC dan verifikasi asimetris, dan mengapa alat khusus dekode jujur dalam tidak membuktikan apa pun.
Ini diterjemahkan dengan baik, jadi harus valid — asumsi yang mengarah pada penerimaan token palsu
Token dapat memecahkan kode dengan sempurna setelah penyerang menulis muatan baru dan melampirkan teks arbitrer sebagai segmen ketiga. Penguraian Base64url dan JSON adalah transformasi publik; tidak ada yang memeriksa siapa yang merakit string tersebut. Oleh karena itu, “klaim yang muncul di layar” bukan merupakan bukti bahwa penerbit membuat atau menyetujui klaim tersebut.
ToolAcre memperkuat batas ini di beberapa tempat. Hasilnya selalu membawa `signatureVerified: false`, UI mengulangi peringatan klaim yang belum diverifikasi di samping keluaran, dan pengujian menyatakan tidak ada permukaan `valid` atau `verify`. Itu adalah kejujuran yang disengaja, bukan fitur kenyamanan yang hilang.
Apa yang dicakup oleh tanda tangan — byte persis dari header dan payload yang dikodekan, digabungkan dengan sebuah titik
Untuk JWS yang ringkas, input penandatanganannya adalah segmen header terlindungi yang dikodekan, titik literal, dan segmen muatan yang dikodekan. Verifikasi menyangkut byte yang dikodekan secara persis, bukan JSON yang baru dicetak. Menyusun ulang properti atau mengubah spasi dapat menghasilkan byte yang berbeda bahkan ketika manusia melihat objek yang setara.
Segmen ketiga membawa tanda tangan yang disandikan atau MAC byte yang dihasilkan melalui masukan tersebut. ToolAcre mempertahankan segmen mentah dan dapat melaporkan panjang byte-nya, namun tidak pernah menjalankan pemeriksaan kriptografi. Mengukur bentuk data tidak dapat memastikan bahwa kunci yang diharapkan menciptakannya atau bahwa dua segmen pertama tetap tidak berubah.
HMAC versus asimetris — rahasia bersama yang dapat dipalsukan oleh siapa pun yang dapat memverifikasinya, versus kunci publik yang hanya dapat memverifikasi
Dengan HMAC, rahasia bersama mendukung pembuatan dan pemeriksaan MAC. Pihak yang dapat memverifikasi dengan rahasia tersebut juga dapat membuat token lain, sehingga distribusi rahasia menentukan batas kepercayaan. Catatan ToolAcre membuat konsekuensi ini eksplisit untuk label algoritma HS yang diakui.
Tanda tangan asimetris memisahkan kemampuan penandatanganan pribadi dari materi verifikasi publik. Memiliki kunci publik dapat mendukung pemeriksaan tanpa memberikan otoritas penandatanganan. Perbedaan ini tidak membuat label asimetris yang dinyatakan dalam header dapat dipercaya: pemverifikasi harus sudah mengetahui algoritma dan kunci penerbit mana yang dapat diterima.
Dari mana kunci tersebut berasal — konfigurasi untuk rahasia bersama, titik akhir JWKS untuk kunci publik, dicocokkan oleh anak
Rahasia bersama harus berasal dari konfigurasi layanan yang dilindungi, bukan teks token. Kunci verifikasi publik mungkin berasal dari hubungan penerbit tepercaya dan kumpulan kunci yang dikontrol. `kid` dapat membantu memilih dalam kumpulan tersebut, namun tidak boleh mengubah konten header yang tidak dipercaya dan sewenang-wenang menjadi pencarian file, database, atau jaringan.
ToolAcre tidak memiliki konfigurasi penerbit dan tidak meminta kunci, sehingga verifikasi tidak mungkin dilakukan secara bertanggung jawab di sana. Halaman web umum tidak dapat menyimpulkan organisasi mana yang Anda percayai, audiens mana yang Anda layani, atau algoritme mana yang diizinkan oleh aplikasi Anda. Itu adalah masukan kebijakan aplikasi, bukan properti yang dapat ditemukan dengan decoding.
Mengapa decoding tidak memerlukan kunci — base64url adalah pengkodean, bukan enkripsi, sehingga siapa pun dapat membaca klaimnya
Tidak diperlukan kunci untuk memecahkan kode karena base64url adalah pengkodean yang dapat dibalik, bukan enkripsi. Header dan payload dimaksudkan untuk dibawa bersama token dan dapat dipulihkan oleh pemegang mana pun. Hal ini memungkinkan pemeriksaan yang berguna, namun juga berarti informasi rahasia tidak boleh disembunyikan di balik gangguan visual karakter yang dikodekan.
Penguraian JSON hanya menambahkan struktur. Ini dapat memberi tahu Anda bahwa `roles` adalah array atau `exp` adalah angka, bukan nilai mana pun yang asli. ToolAcre menjadikan nilai terstruktur sebagai teks dan deskripsi terdaftar sebagai dokumentasi sambil menyerahkan otorisasi kepada sistem yang dapat memverifikasi dan menegakkan kebijakan.
Contoh praktis — token dengan satu karakter muatan yang diubah masih diterjemahkan dengan sempurna; hanya pemberitahuan verifikasi
Mulailah dengan token sintetis yang muatannya bertuliskan `{"sub":"demo","role":"reader"}`. Ubah satu karakter payload yang disandikan sehingga byte tetap membentuk JSON yang valid, mungkin menghasilkan peran yang berbeda. Kedua versi dapat membagi, memecahkan kode, dan mencetak cantik. Jalur dekode tidak memiliki alasan untuk menolak versi yang diubah.
Pemverifikasi yang dikonfigurasi dengan benar menghitung ulang atau memeriksa hasil kriptografi atas input penandatanganan yang diubah dan menolak ketidakcocokan. Perbandingan ini menunjukkan batasan yang tepat: keberhasilan dekoder mencakup sintaksis, sedangkan keberhasilan pemverifikasi dapat menetapkan integritas relatif terhadap kunci tepercaya dan algoritme yang diizinkan sebelum kebijakan klaim dievaluasi.
Apa yang tidak tercakup dalam hal ini — dekoder ToolAcre JWT tidak pernah memverifikasi tanda tangan, berdasarkan desain; tidak ada yang ditampilkan yang membuktikan bahwa token itu asli
ToolAcre tidak pernah memverifikasi tanda tangan. Segmen kosong menerima peringatan, pengkodean tanda tangan yang salah menerima yang lain, dan byte terukur dilaporkan ada tetapi tidak diverifikasi. Tak satu pun dari cabang-cabang ini menghasilkan putusan yang asli. Implementasinya tidak memiliki akuisisi kunci tersembunyi atau jalur eksekusi algoritma.
Bahkan verifikasi kriptografi yang berhasil tidak akan secara otomatis mengotorisasi suatu tindakan. Layanan yang memakan waktu masih memerlukan pemeriksaan khusus penerbit, audiens, waktu, dan aplikasi. Artikel ini berhenti sebelum konfigurasi perpustakaan karena dukungan dan default bervariasi; konsultasikan dengan pemverifikasi dan versi yang tepat yang digunakan oleh layanan Anda.
Kesimpulan: dekode untuk memeriksa, verifikasi untuk mempercayai — gunakan dekoder ToolAcre JWT untuk yang pertama dan pustaka sisi server dengan kunci yang tepat untuk yang kedua
Dekode untuk memeriksa dan memverifikasi sebelum dipercaya. Gunakan alat browser untuk token yang kedaluwarsa atau sintetis ketika Anda perlu melihat bidang header, nilai muatan, konversi waktu, dan peringatan struktural. Jangan biarkan keluaran yang dapat dibaca tersebut mengalir langsung ke dalam keputusan akses.
Pindahkan pekerjaan penting ke verifikator tepercaya dengan materi kunci yang disediakan secara independen, algoritma yang disematkan, dan kebijakan layanan. Hanya jalur tersebut yang dapat menguji keaslian dan integritas, dan hanya pemeriksaan klaim selanjutnya yang dapat memutuskan otorisasi. Penolakan decoder untuk mengaburkan pekerjaan tersebut adalah fitur keamanan.