Alat pengembang · dekoder JWT
RFC 7519 dan Keluarga JOSE: JWT, JWS, JWE, JWK dan JWA Dijelaskan
· Latar belakang
jwt kriptografi standar
JWT adalah salah satu anggota kelompok spesifikasi dari kelompok kerja IETF JOSE. Postingan ini menjelaskan definisi masing-masing RFC, bagaimana keduanya cocok satu sama lain, dan mengapa JWT biasanya merupakan JWS.
Lima akronim, satu token — mengapa dokumentasi menyebutkan JWS dan JWE padahal Anda hanya bertanya tentang JWT
Dokumentasi token berpindah antara JWT, JWS, JWE, JWK dan JWA karena keduanya menggambarkan berbagai lapisan ekosistem yang sama. Kebingungan dimulai ketika “JWT” digunakan sebagai singkatan untuk setiap token bertanda tangan tiga bagian yang ringkas. Memisahkan klaim dari sampul dan representasi kunci membuat penerapannya lebih mudah untuk dipertimbangkan.
Dekoder ToolAcre sengaja dibuat lebih sempit daripada dekoder keluarga. Ini menangani masukan berbentuk tiga bagian JWS yang dua segmen pertamanya yang didekodekan adalah objek JSON. Ini mendeteksi input kompak terenkripsi lima bagian dan berhenti, karena membaca ciphertext tanpa kunci penerima tidak akan memecahkan kode hal yang sama.
Dokumen JOSE menentukan format terkait; repositori ini tidak menetapkan garis waktu kelompok kerjanya
Spesifikasi terkait berasal dari pekerjaan IETF JOSE, tetapi sumber repositori tidak menetapkan garis waktu organisasi terperinci yang diminta oleh garis besar. Oleh karena itu, artikel ini menghindari pembuatan tanggal atau riwayat proses dan berkonsentrasi pada hubungan format yang dapat diamati dalam alat dan rencana.
Pertanyaan praktisnya adalah lapisan mana yang memiliki setiap keputusan. Nama klaim menjelaskan pernyataan aplikasi, tanda tangan melindungi materi yang dikodekan, enkripsi melindungi konten, objek kunci JSON mewakili informasi penting, dan operasi nama pengidentifikasi algoritme. Tidak ada akronim yang menggantikan akronim lainnya.
JWS (RFC 7515) — menandatangani konten sewenang-wenang dan serialisasi ringkas yang digunakan JWT
JWS menjelaskan konten yang ditandatangani atau MAC dilindungi. Bentuknya yang ringkas memiliki tiga segmen: header yang dilindungi, payload, dan tanda tangan. Masukan penandatanganan menggunakan dua segmen pertama yang dikodekan yang digabungkan dengan sebuah titik. JWT biasanya dibawa dalam amplop ini, yang merupakan formulir ToolAcre dibelah dan diperiksa.
Header dan payload dapat didekode menjadi JSON, sedangkan tanda tangannya berupa byte, bukan objek ketiga. ToolAcre melaporkan keberadaan dan ukuran tanda tangan tetapi selalu menandainya sebagai belum diverifikasi. Dengan demikian dapat mengilustrasikan struktur JWS tanpa mengklaim hasil kriptografi apa pun.
JWE (RFC 7516) — mengenkripsi konten, dengan serialisasi lima bagian
JWE menjelaskan konten terenkripsi. Bentuknya yang ringkas memiliki lima segmen yang mewakili header yang dilindungi, materi kunci terenkripsi, nilai inisialisasi, teks tersandi, dan tag otentikasi. Oleh karena itu, empat titik merupakan petunjuk struktural yang kuat bahwa dekoder JWT tiga bagian telah menerima amplop yang berbeda.
ToolAcre mengeluarkan kesalahan JWE tertentu dan menjelaskan bahwa konten tidak dapat dibaca tanpa kunci dekripsi. Itu tidak memperlakukan ciphertext sebagai JSON yang salah atau mencoba menampilkan byte acak. Enkripsi dan penandatanganan juga dapat dilakukan, tetapi pemrosesan bersarang berada di luar rute ini.
JWK dan JWA (RFC 7517 dan 7518) — merepresentasikan kunci sebagai JSON dan memberi nama algoritme
JWK memberikan representasi JSON untuk informasi kunci kriptografi, sementara JWA memberi nama pengidentifikasi algoritme dan parameter terkait yang digunakan di JOSE. Keberadaan mereka tidak berarti token dapat memilih kunci atau algoritmanya sendiri yang terpercaya. Verifikator harus membatasi kebijakan penerbit dan aplikasi.
Catatan algoritme ToolAcre hanya menjelaskan sekumpulan label terbatas yang ada di sumber dan menyebut label lain yang tidak dikenali. Itu hanyalah deskripsi, bukan implementasi. Dekoder tidak mengimpor JWK atau menjalankan algoritme dari JWA, yang menjaga batas inspeksi tetap eksplisit.
JWT (RFC 7519) — format klaim yang menggunakan JWS atau JWE
JWT mendefinisikan objek klaim dan nama terdaftar seperti penerbit, subjek, audiens, dan Tanggal Numerik. Klaim tersebut dapat dilakukan dalam struktur JOSE yang ditandatangani atau dienkripsi. Oleh karena itu, lapisan payload menjawab “pernyataan apa yang direpresentasikan,” sedangkan envelope menjawab bagaimana byte tersebut dilindungi atau disembunyikan.
ToolAcre mengharapkan payload yang didekodekan menjadi objek JSON dan mencantumkan klaimnya. Array, angka, atau null ditolak untuk alat ini. Bahkan objek yang bentuknya bagus tetap tidak dipercaya sampai amplop yang relevan diproses oleh pemverifikasi atau penerima yang dikonfigurasi.
Yang tidak tercakup dalam hal ini — profil selanjutnya seperti RFC 8725 praktik terbaik dan RFC 9068 token akses, yang memiliki postingannya sendiri
Dokumen praktik terbaik dan profil selanjutnya dapat mempersempit cara penggunaan mekanisme umum ini. Mereka berhak mendapatkan perlakuan terpisah karena format dasar tidak menyediakan kebijakan penerbit, audiens, atau jenis token khusus aplikasi. Artikel ini tidak mengklaim bahwa dekoder mengimplementasikan profil tersebut.
Saat meninjau suatu sistem, tuliskan profil persisnya, batasan yang diharapkan, algoritme yang diterima, sumber kunci, dan aturan klaim. Daftar tersebut mencegah keakraban akronim berubah menjadi asumsi kompatibilitas atau keamanan.
Kesimpulan: JWT adalah klaimnya, JWS adalah amplopnya — dekoder ToolAcre JWT membaca formulir ringkas JWS dan menampilkan JWT header dan klaim di dalamnya
JWT memberi nama pada lapisan klaim; JWS dan JWE memberikan amplop pelindung; JWK mewakili data penting; JWA memberi nama pilihan algoritme. ToolAcre membaca bentuk tanda tangan tiga bagian yang umum dan menampilkan header dan klaim sambil menolak memverifikasi atau mendekripsi.
Gunakan peta itu untuk menanyakan pertanyaan berikutnya yang tepat. JSON yang dapat dibaca mengidentifikasi lapisan klaim. Tiga atau lima segmen mengidentifikasi kemungkinan keluarga sampul. Kepercayaan masih bergantung pada kriptografi dan kebijakan yang dikonfigurasi secara independen, bukan pada dekoder yang mengenali akronim.