Bahasa Indonesia

Alat pengembang · dekoder JWT

Men-debug 401: Apa yang Harus Diperiksa dalam JWT yang Didekodekan Sebelum Menyalahkan API

· Mengapa itu penting

jwt melakukan debug otentikasi

JWT yang ditolak melewati daftar periksa debug terstruktur
Ilustrasi vektor ToolAcre asli

Sebagian besar penolakan token disebabkan oleh beberapa masalah klaim yang dapat Anda temukan dengan membaca muatannya. Postingan ini memberikan checklist, mulai dari kadaluarsa hingga audiens hingga kesalahan copy-paste, untuk memeriksanya.

Ini berfungsi kemarin — 401 yang muncul tanpa perubahan kode

401 yang muncul tanpa perubahan kode klien dapat berasal dari usia token, kebijakan penerbit, rotasi kunci, pemilihan audiens, atau salinan yang rusak. Mulailah dengan bukti daripada berasumsi API tidak berfungsi. Pertahankan detail respons dan pengidentifikasi korelasi sebelum memanipulasi kredensial.

Decode hanya salinan yang kadaluwarsa, sintetis, atau dikontrol dengan tepat. ToolAcre dapat mengungkap petunjuk struktural dan klaim, namun tidak dapat mengidentifikasi setiap penolakan server karena tidak memiliki kunci, kebijakan penerbit, atau log API. Daftar periksa ini mempersempit pertanyaan; itu tidak menggantikan keputusan server sumber daya.

Salin kesalahan terlebih dahulu — awalan 'Pembawa', baris baru di akhir, dan token terpotong

Periksa nilai yang disalin terlebih dahulu. ToolAcre memangkas spasi di sekitarnya dan menghapus satu awalan `Bearer ` yang tidak peka huruf besar-kecil, yang menangani pasta header Otorisasi umum. Ini kemudian membutuhkan tepat tiga segmen yang dipisahkan titik. Penghitungan yang salah mengarah pada pemotongan, bentuk token yang salah, atau tanda baca tambahan sebelum analisis klaim dimulai.

Header atau payload kosong gagal secara spesifik. Url base64 tidak valid, UTF-8 tidak valid, dan JSON tidak valid memiliki kesalahan terpisah. Perbedaan tersebut membantu menentukan apakah transportasi merusak token. Tanda tangan mungkin salah format tanpa menghalangi pemeriksaan, namun peringatan tersebut tetap merupakan kemungkinan kegagalan verifikasi yang memerlukan konfirmasi sisi server.

exp dan nbf: memeriksa nilai berdasarkan detik tanpa mengubah tampilan menjadi keputusan validitas

Periksa nilai numerik `exp` dan `nbf` selanjutnya. ToolAcre mengalikan detik dengan 1,000, menampilkan UTC dan memberi label masa berlaku yang lebih awal atau masa depan yang bukan sebelumnya relatif terhadap jam browser. Nilai tiga belas digit dapat mengungkapkan milidetik ditulis sesuai dengan perkiraan detik.

Jangan promosikan label ini ke penegakan hukum. Token yang dipalsukan dapat mengklaim masa berlakunya di masa depan, dan server mungkin menggunakan kebijakan jam atau kelonggaran yang berbeda. Layar mengidentifikasi nilai aritmatika yang dibandingkan dengan log tepercaya; verifikasi kriptografi harus berhasil sebelum klaim dapat mempengaruhi penerimaan.

aud dan iss — apakah token ini untuk API ini, dari penerbit yang API ini percayai?

`aud` harus mengidentifikasi penerima yang dituju berdasarkan kebijakan API, sedangkan `iss` harus sesuai dengan hubungan penerbit tepercaya. ToolAcre mencantumkan keduanya sebagai nilai yang didekodekan dan menjelaskan makna terdaftarnya. Itu tidak membandingkannya dengan konfigurasi API atau mengikat string penerbit ke kumpulan kunci.

Penerbit URL dan nama audiens yang masuk akal dapat dibuat-buat. Bandingkan nilai persis yang didekodekan dengan ekspektasi yang dikonfigurasi server hanya setelah mempertahankan batas verifikasi tanda tangan. Jika beberapa layanan berbagi infrastruktur identitas, pemeriksaan audiens sangat penting untuk mencegah token valid untuk satu layanan digunakan di layanan lain.

Jenis token mungkin disarankan oleh header dan klaim, tetapi penguraian kode tidak dapat mengautentikasi klasifikasi tersebut

Token ID dan token akses keduanya dapat terlihat seperti JWT tiga bagian. Header `typ`, audiens, cakupan, dan klaim khusus profil mungkin menyarankan klaim mana yang Anda miliki. ToolAcre memperingatkan tentang string yang tidak terduga `typ`, tetapi tidak menerapkan klasifikasi token OpenID Connect atau OAuth.

Gunakan dokumentasi penerbit dan alur klien untuk menetapkan jenis token yang diharapkan. Mengirim token ID ke API bisa gagal meskipun tanda tangannya valid untuk penyedia identitas. Penguraian kode mendukung diagnosis; itu tidak dapat mengautentikasi label jenis atau memberikan otoritas API.

kid setelah rotasi kunci — token valid yang mereferensikan kunci yang tidak lagi dimiliki server

Setelah rotasi kunci, header `kid` mungkin merujuk ke kunci yang tidak ada dalam jaringan tepercaya server saat ini. Baca pengidentifikasi, lalu periksa cache dan log kumpulan kunci pada pemverifikasi. Jangan mengambil URL yang disediakan header atau menerima materi kunci yang disematkan sebagai solusi cepat.

Token yang ditandatangani dengan benar mungkin masih gagal jika pemverifikasi tidak dapat menemukan kunci yang diizinkan, sementara penyerang dapat menulis `kid` apa pun ke dalam header yang belum diverifikasi. Nilainya adalah petunjuk pencarian yang dibatasi oleh konfigurasi penerbit tepercaya, bukan bukti bahwa kunci tertentu harus dipercaya.

Contoh praktis — menjalankan token yang ditolak melalui daftar periksa di dekoder ToolAcre JWT

Untuk triase yang berhasil, ambil token yang ditolak terkontrol, konfirmasikan tiga segmen, periksa kesalahan, lalu catat `exp`, `nbf`, `aud`, `iss`, `typ` dan `kid` tanpa mengeditnya. Bandingkan setiap kolom dengan target permintaan API dan konfigurasi tepercaya pemverifikasi. Biarkan log server tetap terbuka untuk kategori kegagalan sebenarnya.

Jika semua nilai yang terlihat terlihat seperti yang diharapkan, jangan menyimpulkan bahwa API salah. Korupsi tanda tangan, materi kunci yang salah, negara yang dicabut, atau kebijakan yang tidak ditampilkan masih dapat menjelaskan 401. `signatureVerified` ToolAcre tetap salah terlepas dari seberapa rapi JSON tampilannya.

Apa yang tidak tercakup dalam hal ini dan kesimpulannya — dekoder tidak dapat memberi tahu Anda apakah tanda tangan itu valid; daftar periksa menemukan masalah klaim, dan kegagalan tanda tangan memerlukan log server

Dekoder tidak dapat memberi tahu Anda apakah tanda tangan tersebut valid. Daftar periksa klaimnya menemukan masalah penyalinan dan muatan yang terlihat tanpa kunci; kegagalan tanda tangan dan keputusan kebijakan yang berwenang memerlukan bukti server. Perlakukan decoding sebagai satu pengamatan diagnostik di antara beberapa pengamatan diagnostik.

Jalur tercepat yang dapat diandalkan diurutkan: pertahankan konteks respons, periksa bentuk token, bandingkan satuan waktu, lalu bandingkan penerbit, audiens, jenis, dan pengidentifikasi kunci dengan konfigurasi tepercaya. Hentikan rasa percaya sampai pemverifikasi sebenarnya mengonfirmasi kriptografi dan kebijakan.