Isi JWT dan mengapa decode tidak sama dengan verifikasi

Sebuah JSON Web Token (JWT) terdiri dari tiga bagian teks yang disambung dengan titik: header, payload, dan signature. Dua bagian pertama hanya dikodekan, tidak dienkripsi, sehingga siapa pun yang memegang token dapat membacanya. Signature memungkinkan server memastikan bahwa token diterbitkan oleh pihak tepercaya dan tidak diubah oleh siapa pun. Men-decode token menunjukkan apa isinya. Hanya memverifikasinya yang memberi tahu apakah token itu layak dipercaya.

Decoder JWTToken kedaluwarsa atau masih valid?Pakai gratis

Tiga bagian

Token terlihat seperti header.payload.signature. Bagian pertama dari token contoh yang terkenal dari jwt.io adalah:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Setiap dua bagian pertama adalah JSON yang diubah menjadi base64url, bentuk teks yang aman untuk URL. Bagian pertama ter-decode menjadi:

{"alg":"HS256","typ":"JWT"}

Payload dari contoh yang sama ter-decode menjadi:

{"sub":"1234567890","name":"John Doe","iat":1516239022}

Payload berisi klaim, yaitu pernyataan tentang pengguna atau sesi. Signature dihitung dari dua bagian pertama dan sebuah kunci, sehingga mengubah satu karakter saja membuat signature tidak cocok lagi. Base64url dapat dibalik tanpa kunci, jadi jangan pernah menaruh kata sandi, kunci privat, atau data pribadi di dalam payload.

Klaim terdaftar

RFC 7519, standar untuk JWT, memesan beberapa nama klaim pendek:

• iss (penerbit): pihak yang membuat token.
• sub (subjek): token ini tentang siapa, biasanya ID pengguna.
• aud (audiens): layanan yang dituju token.
• exp (waktu kedaluwarsa): momen setelah token tidak berlaku lagi.
• nbf (tidak sebelum): waktu paling awal token berlaku.
• iat (diterbitkan pada): kapan token dibuat.

Waktu dinyatakan dalam detik sejak 1 Januari 1970 UTC, disebut waktu Unix. Contoh di atas tidak memiliki exp, sehingga menurut standar token itu tidak pernah kedaluwarsa. Token sungguhan sebaiknya memilikinya. Nama lain, seperti role atau email, menjadi milik aplikasi.

Decode bukan verifikasi

Men-decode memisahkan token pada titik, membalik base64url, dan membaca JSON-nya. Hasilnya menunjukkan apa yang diklaim token, dan hal yang sama berlaku untuk token palsu, karena siapa pun dapat menulis klaim apa pun dengan signature apa pun.

Verifikasi menghitung ulang signature dengan kunci yang benar lalu memeriksa apakah cocok. Verifikasi juga memeriksa bahwa exp dan nbf mengapit waktu sekarang, serta bahwa iss dan aud sesuai dengan nilai yang diharapkan layanan. Aplikasi yang membaca klaim role tanpa verifikasi mempercayai siapa pun yang menulis token. Ini kesalahan yang umum.

HS256, RS256 dan ES256

Nilai alg menyebutkan metodenya. Ada tiga yang umum:

• HS256 adalah HMAC dengan SHA-256. Satu rahasia bersama digunakan untuk menandatangani sekaligus memverifikasi, jadi rahasia itu harus tetap berada di server yang menerbitkan token.
• RS256 adalah signature RSA dengan SHA-256. Penerbit menandatangani dengan kunci privat, dan siapa pun yang memegang kunci publik dapat memverifikasi. Layanan lain dapat memeriksa token tanpa bisa membuatnya.
• ES256 adalah signature ECDSA dengan kurva P-256 dan SHA-256. Cara kerjanya seperti RS256, dengan kunci dan signature yang lebih kecil.

Gunakan HS256 jika satu layanan sekaligus menerbitkan dan memeriksa token-nya. Gunakan RS256 atau ES256 jika layanan lain harus memeriksa token yang tidak mereka terbitkan.

Masalah dari mempercayai header

Header ditulis oleh siapa pun yang mengirim token, jadi verifikator tidak boleh membiarkannya menentukan aturannya.

1. alg: none. Token tanpa signature bisa menyatakan "alg":"none". Beberapa pustaka pernah menerima token seperti itu dan melewati pemeriksaan. Tetapkan algoritma yang diizinkan di kode Anda sendiri, jangan pernah mengambilnya dari token.
2. Kebingungan algoritma. Server mengharapkan RS256 dan memegang kunci publik. Penyerang mengirim token HS256 yang ditandatangani dengan kunci publik itu sebagai rahasia HMAC. Verifikator yang menerima algoritma apa pun yang disebut header akan menerimanya. Ikat setiap kunci tepat pada satu algoritma.
3. Rahasia yang lemah. Penyerang memiliki header, payload, dan signature, sehingga mereka dapat menguji kandidat rahasia secara offline. Rahasia pendek atau kata umum cepat ditebak dengan daftar seperti itu. RFC 7518 menyatakan bahwa kunci HS256 sebaiknya minimal 256 bit dan acak.

Menempelkan token produksi ke situs web

Token yang valid dan belum kedaluwarsa berlaku bagi siapa pun yang memegangnya, sampai ia kedaluwarsa. Perlakukan seperti kata sandi. Sebelum menempelkannya ke sebuah situs, cari tahu apakah situs itu mengirimkannya ke server. Alat yang berjalan sepenuhnya di tab peramban tidak perlu melakukannya. Anda dapat memeriksa halaman mana pun dengan melihat permintaan jaringannya di alat pengembang peramban.

Token biasanya tidak dapat dicabut sebelum kedaluwarsa, kecuali server menyimpan daftar. Jika token aktif bocor, minta layanan untuk mencabut sesi atau mengganti kuncinya. Gunakan token dari lingkungan uji untuk debugging jika memungkinkan. Decoder JWT membaca tiga bagian di tab peramban Anda, dan tidak ada yang Anda tempel yang dikirim ke mana pun.

Webhook: ide yang sama dengan rahasia bersama

Sebagian besar penyedia webhook mengirim HMAC dari body permintaan, dihitung dengan rahasia yang Anda bagikan dengan mereka, dalam sebuah header. Penerima Anda menghitung HMAC yang sama lalu membandingkan keduanya. Kesalahan yang umum sering kali kecil. JSON diformat ulang sebelum di-hash, sehingga byte-nya berubah. Rahasia uji dipakai pada trafik langsung. Atau signature dibandingkan dengan kesamaan string biasa, yang dapat membocorkan informasi waktu. Gunakan perbandingan dengan waktu konstan.

Penguji tanda tangan webhook menghitung signature dari rahasia dan body yang Anda tempel, untuk GitHub, Stripe, Slack, Shopify, atau skema HMAC apa pun, sehingga Anda dapat melihat apakah kedua nilainya cocok.

Jawaban singkat

Apakah JWT dienkripsi?

Tidak. JWT standar ditandatangani, dan siapa pun dapat membaca header dan payload-nya. Hanya signature yang melindunginya dari perubahan.

Apa yang terjadi jika saya mengedit payload?

Signature tidak lagi cocok, sehingga server yang memverifikasi menolak token. Membaca klaim tidak memeriksa signature, jadi decoder tetap menampilkan versi yang sudah Anda edit.