Alat pengembang · dekoder JWT
Base64 vs Base64url: Mengapa JWT Gagal dalam Dekoder Base64 Standar
· Cara kerjanya
jwt base64 pengkodean
Tempelkan segmen JWT ke dekoder base64 biasa dan mungkin ada keluhan tentang karakter atau padding. Posting ini menjelaskan mandat varian base64url JWS dan cara mengonversi keduanya.
Karakter tidak valid, padding salah — kesalahan yang muncul saat base64 bertemu base64url
Pesan “karakter tidak valid” atau “padding salah” sering kali berarti segmen JWT diberikan ke decoder yang mengharapkan Base64 biasa. Token dapat disalin dengan benar. Representasinya mengikuti konvensi base64url, sedangkan utilitas penerima menerima alfabet terkait tetapi tidak identik atau memaksakan padding eksplisit.
ToolAcre menghindari ketidakcocokan antara header dan payload. Dekoder byte-nya menghilangkan spasi, menerjemahkan simbol aman URL, memulihkan padding yang dihilangkan jika panjangnya mengizinkan, lalu mengonversi byte menjadi UTF-8 yang ketat. Kegagalan pada tahap apa pun menjadi kesalahan INVALID_JWT dan bukan pengecualian browser mentah.
Dua huruf — plus dan garis miring versus tanda hubung dan garis bawah, dan alasan URL memaksakan perubahan
Standar Base64 menggunakan plus dan garis miring untuk dua posisi alfabet terakhirnya. Base64url memberikan tanda hubung dan garis bawah ke posisi yang sama. Nilai enam-bit yang mendasarinya tidak berubah, jadi menerjemahkan `-` ke `+` dan `_` ke `/` akan mempertahankan setiap byte yang didekodekan; hanya ejaan aman transportasi yang berubah.
Pergantian tersebut penting dalam saluran yang plus atau garis miring sudah memiliki sintaksis. Ejaan yang aman URL mengurangi interpretasi yang tidak disengaja melalui pemrosesan bentuk atau jalur. Itu tidak menambah kerahasiaan, integritas atau keaslian. Siapapun yang menerima segmen dapat membalikkan substitusi dan memulihkan byte yang sama tanpa kunci kriptografi.
Padding — mengapa JWS menghapus tanda sama dengan dan cara mengembalikannya untuk decoder yang ketat
ToolAcre menerima padding yang dihilangkan. Setelah normalisasi alfabet, ia memeriksa modulo empat panjang segmen. Sisa dua memerlukan dua tanda sama dengan, dan sisa tiga memerlukan satu. Sisanya tidak mungkin untuk nilai Base64 yang lengkap dan ditolak sebagai string terpotong, bukan ditebak bentuknya.
Pemulihan padding adalah pembingkaian mekanis, bukan perbaikan token. Menambahkan tanda sama dengan tidak dapat memulihkan karakter yang hilang selama penyalinan, dan decoding byte yang berhasil tidak menunjukkan bahwa byte tersebut berasal dari penerbit. Implementasinya hanya merekonstruksi panjang kanonik yang diperlukan oleh dekoder browser sebelum memanggil `atob`.
Menguraikan seluruh token sekaligus — kesalahan karena tidak membagi titik-titiknya terlebih dahulu
Token bertanda tangan kompak harus dipisahkan pada titik-titiknya sebelum segmen mana pun didekodekan. Meneruskan `header.payload.signature` ke fungsi Base64 akan memperkenalkan titik-titik milik serialisasi JWT, bukan salah satu alfabet Base64. ToolAcre memerlukan tepat tiga segmen untuk masukan berbentuk JWS ini dan melaporkan jumlah pengamatan ketika struktur tersebut tidak ada.
Kasus lima bagian menerima pesan JWE terpisah karena serialisasi ringkas terenkripsi bukanlah objek yang sama. Dua atau empat bagian malah menyarankan pemotongan atau masukan yang salah. Pemeriksaan struktural ini dilakukan sebelum penafsiran JSON, sehingga kesalahan penyalinan berbeda dari teks berkode yang formatnya salah atau format JSON yang salah.
Contoh praktis — mengonversi satu segmen dari base64url ke base64, mengisinya, dan mendekodekannya menjadi JSON
Untuk konversi yang berhasil, ambil `eyJhbGciOiJIUzI1NiJ9`. Ini tidak berisi karakter alfabet yang berbeda antar varian, tetapi padding yang hilang masih menggambarkan alurnya. Panjangnya memungkinkan restorasi padding; decoding menghasilkan UTF-8 byte untuk `{"alg":"HS256"}`, dan penguraian JSON menghasilkan objek dengan satu properti `alg`.
Segmen yang berisi tanda hubung atau garis bawah mengikuti urutan yang sama dengan dua penggantian simbol terlebih dahulu. ToolAcre melakukan operasi ini di dalam `base64ToBytes`, lalu `decodeSegment` mem-parsing teks yang dihasilkan. Algoritme yang ditampilkan adalah apa pun yang dinyatakan oleh header yang belum diverifikasi; itu tidak dipilih sebagai kebijakan verifikasi.
Unicode dalam klaim — mengapa byte yang didekodekan harus dibaca sebagai UTF-8 untuk menampilkan nama dengan benar
Klaim mungkin berisi aksen, CJK karakter, atau emoji. Base64 beroperasi pada byte, jadi memperlakukan setiap byte yang didekodekan sebagai karakter independen akan merusak teks multibyte. Jalur yang benar adalah simbol yang dikodekan ke byte, kemudian decoder UTF-8. ToolAcre membuat `TextDecoder` dengan mode fatal sehingga UTF-8 yang tidak valid gagal dengan keras.
Pengujian mencakup payload yang berisi `Zoë 世界 🙂` dan mengharapkan string yang tepat setelah decoding. Hasil tersebut membuktikan bahwa pipeline byte-ke-teks mempertahankan nilai pengujian ini. Masih belum disebutkan apa pun tentang apakah orang yang disebutkan dalam payload itu ada, apakah penerbit menyetujui klaim tersebut, atau apakah tokennya diubah.
Apa yang tidak tercakup di sini - segmen tanda tangan, yang diterjemahkan menjadi byte, bukan teks, dan memerlukan kunci untuk mengartikan apa pun
Segmen tanda tangan berada di luar jalur JSON. ToolAcre mempertahankan bentuk aslinya yang dikodekan dan hanya mencoba mengukur panjang byte yang didekodekan. Tanda tangan tidak valid Base64 menghasilkan peringatan tetapi tidak mencegah pemeriksaan header dan payload; segmen ketiga yang kosong menghasilkan peringatan berbeda bahwa tidak ada byte tanda tangan.
Tidak ada hasil yang merupakan hasil verifikasi. Validasi tanda tangan yang bermakna memerlukan materi kunci yang tepercaya, algoritme yang diizinkan yang dipilih secara independen dari masukan yang dikontrol penyerang, dan pemeriksaan aplikasi. Jumlah byte berguna saat mendiagnosis bentuk, namun nol atau tiga puluh dua byte terukur tidak dapat mengotorisasi permintaan atau menetapkan penerbit.
Kesimpulan: gunakan decoder yang menggunakan base64url — decoder ToolAcre JWT menangani alfabet dan padding untuk header dan payload
Gunakan decoder yang memahami base64url ketika pekerjaan langsungnya adalah memeriksa JSON. ToolAcre menangani alfabet, menghilangkan padding, UTF-8 yang ketat dan JSON khusus objek untuk dua segmen pertama. Ini juga menolak panjang yang tidak mungkin dan menggabungkan kegagalan parse dalam pesan yang mengidentifikasi apakah header atau payload gagal.
Berhenti di batas itu. Dekode yang bersih berarti string tersebut memiliki byte yang dapat dipulihkan dan objek JSON yang sesuai. Hal ini tidak berarti bahwa klaimnya dapat dipercaya, diautentikasi, sah, atau tidak dimodifikasi. Hanya pemverifikasi yang dikonfigurasi secara terpisah yang dapat menjawab pertanyaan tersebut, dan alat browser ini sengaja tidak menampilkan operasi verifikasi.