logo
GeekFormat

Decode JWT

Encoded Token172 charsDiperbarui 2026-07
header
payload
signature
Valid JWTHS256
Secret38 chars
Header
{
  "alg": "HS256",
  "typ": "JWT"
}
Payload
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true,
  "iat": 1516239022
}
Claims details4 items
sub· Subjek1234567890
name· NameJohn Doe
admin· Admintrue
iat· Diterbitkan pada151623902218/01/2018, 09.30.22
Header details2 items
algHS256HMAC (simetris)
typ· TypeJWT
All operations run locally in your browser; the Token and key are never sent to any server.

Decode dan analisis token JWT secara gratis, tampilkan Header, Payload, Signature, cocok untuk debugging autentikasi dan verifikasi klaim.

Rekomendasi Terkait

Kasus penggunaan

  • Dekode JWT online: pisahkan token dengan cepat saat debugging login OAuth 2.0 / OIDC untuk memeriksa algoritma Header dan Claims Payload
  • Verifikasi tanda tangan JWT: gunakan Secret / kunci publik untuk memverifikasi tanda tangan token secara real-time dan tentukan apakah 401 adalah 'tanda tangan buruk', 'kedaluwarsa', atau 'algoritma tidak cocok'
  • Generate JWT pengujian selama integrasi: terbitkan JWT di browser dengan pasangan kunci pengujian, tanpa perlu backend sementara mengubah kode untuk menerbitkan token
  • Konversi PEM ↔ JWK: OIDC IdP memberi Anda JWK tetapi server membutuhkan PEM (atau sebaliknya) — konversi di tempat daripada menulis skrip OpenSSL
  • Diagnosis 401 Unauthorized: periksa kedaluwarsa, kecocokan alg-gateway, kecocokan kunci, dan pemformatan PEM langkah demi langkah
  • Bandingkan RS256 vs PS256: banyak penyedia OIDC menggunakan RS256 secara default sementara AWS SigV4 lebih memilih PS256 — ganti algoritma dengan pasangan kunci RSA yang sama dan bandingkan hasilnya
  • Pelajari mekanisme internal JWT: ganti alg, edit Payload, ganti kunci di browser dan lihat bagaimana tanda tangan rusak secara real-time — jauh lebih cepat daripada membaca RFC

Fitur

  • Dekode + Verifikasi + Generate dalam satu tempat: tempel token untuk memisahkan Header/Payload/Signature, ganti algoritma dan kunci untuk memverifikasi tanda tangan, edit Claims dan tanda tangani ulang untuk membuat token baru — mencakup seluruh rantai pemecahan masalah JWT
  • Semua 13 algoritma didukung: HS256/HS384/HS512 (HMAC), RS256/RS384/RS512 (RSA-PKCS1-v1_5), ES256/ES384/ES512 (ECDSA), PS256/PS384/PS512 (RSA-PSS), EdDSA — mencakup OAuth 2.0, OIDC, JWS, gateway API, dan SSO perusahaan
  • Format PEM dan JWK: kunci RSA, ECDSA, dan Ed25519 menerima string PEM (dengan header -----BEGIN PUBLIC KEY-----) dan JSON JWK (field kid/kty/n/e) — langsung tempel output OIDC /.well-known/jwks.json
  • Berbagai format input Secret HMAC: string UTF-8 mentah, byte hex, atau Base64/Base64URL terenkripsi — ganti dengan satu klik, agar tidak pernah terjadi 'terlihat sama tapi tanda tangan gagal'
  • Generasi pasangan kunci otomatis: pasangan kunci RSA-2048, RSA-4096, P-256, P-384, dan Ed25519 dihasilkan di browser, disajikan dalam format PEM dan JWK untuk penggunaan pengujian langsung
  • Penyorotan semantik Claims: exp / iat / nbf secara otomatis dikonversi ke waktu yang dapat dibaca dengan status kedaluwarsa / belum-valid / diterbitkan disorot; alg / typ / kid di Header diberi label secara individual
  • 100% sisi klien, nol unggah: setiap parse, verifikasi, dan tanda tangan berjalan melalui Web Crypto API native browser — token, kunci, dan payload tidak pernah meninggalkan browser, mengikuti prinsip keamanan 'jangan pernah tempel token produksi ke alat online acak'
  • Salin satu klik: Header, Payload, Signature, dan token yang baru dihasilkan dapat disalin secara independen untuk dokumentasi, tiket, dan perintah curl

Cara Penggunaan

  1. Tempel atau ketik token: letakkan string JWT di bidang input; alat secara otomatis memisahkan Header, Payload, dan Signature dan menampilkan masing-masing sebagai JSON yang diformat
  2. Pilih algoritma: beralih antara HS256 / RS256 / ES256 / PS256 / EdDSA; alat menyimpulkan dari Header.alg dan menandai ketidakcocokan apa pun
  3. Impor kunci: tempel Secret HMAC, string PEM, atau JSON JWK; untuk algoritma asimetris, klik 'Generate pasangan kunci' untuk mendapatkan kunci pengujian segera
  4. Verifikasi atau tanda tangani ulang: di mode Decode, verifikasi dengan kunci publik dan lihat '✅ tanda tangan valid / ❌ tanda tangan tidak valid'; di mode Encode, edit Claims dan tanda tangani dengan kunci pribadi untuk membuat token baru

Pertanyaan Umum

Apa tiga bagian dari JWT?

String JWT memiliki bentuk `Header.Payload.Signature`, setiap segmen dienkode Base64URL. Header mendeklarasikan algoritma (seperti HS256, RS256) dan jenis token (typ: JWT); Payload membawa Claims pengguna (pernyataan), field umum adalah sub (ID pengguna), iat (waktu penerbitan), exp (waktu kedaluwarsa), nbf (not-before), aud (audiens), iss (penerbit); Signature adalah hasil dari penandatanganan dua segmen pertama dengan kunci, tujuannya adalah 'deteksi perubahan' bukan 'anti-kebocoran'.

Bisakah saya mengedit Payload setelah mendekode?

Anda dapat melihat dan mengedit, tetapi **tidak dapat memalsukan**. Segera setelah Anda mengubah Header atau Payload, Signature asli menjadi tidak valid dan server akan menolak verifikasi. Untuk membuat token yang dimodifikasi valid kembali, Anda harus **menandatangani ulang** dengan algoritma yang sama dan kunci yang sama — itulah sebabnya alat ini menawarkan 'decode + edit + generate' dalam satu tempat: decode untuk melihat, ubah dan segera generate token baru untuk pengujian, sehingga Anda tidak perlu setiap kali meminta backend untuk sementara mengubah kode untuk menerbitkan.

Apa perbedaan antara HS256, RS256, ES256, PS256, dan EdDSA?

HS256 menggunakan HMAC dengan Secret bersama (simetris), cepat tetapi manajemen secret sangat penting. RS256 menggunakan kunci pribadi/publik RSA (asimetris), penerbit menandatangani dengan pribadi, verifier menggunakan publik. ES256 menggunakan ECDSA dengan kurva eliptik (P-256), tanda tangan lebih pendek. PS256 menggunakan RSA-PSS, lebih aman daripada RS256. EdDSA (biasanya Ed25519) cepat dan deterministik, direkomendasikan untuk OAuth 2.1.

Mengapa JWT saya terus menampilkan 'Invalid Signature'?

Biasanya karena kunci, format Secret, algoritma, atau pengkodean Base64URL tidak cocok persis. Spasi tambahan, baris baru PEM yang salah, atau kebingungan antara Base64 dan Base64URL sudah cukup. Periksa byte demi byte dan konfirmasi bahwa Header.alg cocok dengan algoritma yang dipilih.

Bisakah kunci RSA yang sama memverifikasi silang RS256 dan PS256?

Tidak. RS256 menggunakan RSASSA-PKCS1-v1_5, PS256 menggunakan RSA-PSS. Bahkan dengan kunci RSA yang sama, mereka tidak dapat memverifikasi silang. Penandatangan dan verifier harus menggunakan algoritma yang sama.

Apa itu serangan alg:none?

Penyerang mengubah Header menjadi `{"alg":"none"}` (tanpa tanda tangan) atau mengganti RS256 dengan HS256 (menggunakan kunci publik seolah-olah itu adalah Secret HMAC). Server harus memaksakan whitelist algoritma dan tidak pernah membiarkan token memutuskan algoritma mana yang digunakan.

Bagaimana cara mengonversi antara PEM dan JWK?

PEM adalah notasi OpenSSL klasik dengan baris BEGIN/END. JWK adalah JSON dan umum di OAuth/OIDC. Penyedia OIDC sering mempublikasikan kunci publik melalui `/.well-known/jwks.json`. Alat ini dapat memproses format PEM dan JWK secara langsung.

Bisakah browser memverifikasi tanda tangan JWT secara langsung?

Ya. Web Crypto API native browser (`window.crypto.subtle`) mendukung penandatanganan dan verifikasi HMAC, RSA, ECDSA, RSA-PSS, dan Ed25519, tanpa pustaka pihak ketiga. Alat ini menggunakan `crypto.subtle.importKey` dan `crypto.subtle.verify` di front-end untuk setiap verifikasi, sehingga tidak pernah mengirim token atau kunci Anda. Catatan: Web Crypto hanya tersedia di konteks aman: **HTTPS** atau `localhost`.

Apakah token saya dikirim ke server?

Tidak. Semua parsing, verifikasi, dan penandatanganan di alat ini berjalan di browser melalui Web Crypto API native. Token, Header, Payload, Signature, secret / kunci pribadi, dan pasangan kunci yang dihasilkan tidak pernah dikirim ke server. Buka tab Network DevTools browser Anda dan Anda tidak akan melihat permintaan keluar apa pun yang membawa konten token. Halaman dapat digunakan secara offline setelah dimuat.

Apakah JWT adalah tempat yang aman untuk informasi pengguna yang sensitif?

**Tidak.** Payload JWT secara default adalah teks polos — siapa pun dengan token dapat mendekode Base64URL dan membaca isinya. Tidak ada enkripsi. **Jangan pernah menempatkan** kata sandi, nomor ID nasional, nomor kartu kredit, kunci API, access token, atau refresh token sebagai teks polos di JWT. Jika Anda membutuhkan enkripsi, gunakan JWE (RFC 7516) daripada JWS. JWT cocok untuk Claims yang tidak sensitif (ID pengguna, peran, kedaluwarsa, ID penyewa); data sensitif harus dikueri di sisi server menggunakan `sub`.

Apa itu Dekode, Verifikasi, dan Generate JWT?

JWT (JSON Web Token) adalah standar terbuka yang didefinisikan oleh IETF dalam RFC 7519 (RFC 7515 menjelaskan format tanda tangan JWS, RFC 7516 menjelaskan enkripsi JWE, RFC 7517 mendefinisikan kunci JWK) untuk mentransfer informasi pengguna 'yang dideklarasikan' dengan aman antara permintaan HTTP, alur OIDC, dan panggilan layanan mikro. String JWT standar terdiri dari tiga segmen yang dienkode Base64URL: Header (algoritma dan jenis), Payload (Claims, data pengguna), dan Signature (tanda tangan berbasis kunci atas dua segmen pertama). Tiga segmen digabungkan dengan titik `.`, contoh `eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c`.

**JWT bukan enkripsi.** Ini adalah kesalahpahaman paling umum. Payload secara default adalah teks polos — siapa pun dapat mendekode Base64URL dan membaca isinya. JWT menyediakan **deteksi perubahan**, bukan kerahasiaan: server menandatangani ulang Header.Payload dengan kunci bersama dan membandingkan dengan Signature token. Jika cocok, token tidak diubah selama transit. Ini adalah metafora 'tiket kereta dengan stempel anti-pemalsuan': inspektur peduli apakah tiket asli, bukan apakah kode QR dapat dibaca.

JWT membagi tanggung jawab dengan jelas di antara 13 algoritma. **Keluarga HMAC** (HS256/HS384/HS512) menggunakan kunci simetris untuk penandatanganan dan verifikasi, cepat dan sederhana, cocok untuk satu layanan atau kluster tepercaya; secret harus setidaknya sepanjang digest (contoh: ≥ 32 byte untuk HS256). **Keluarga RSA** (RS256/RS384/RS512) menggunakan RSASSA-PKCS1-v1_5, skema asimetris paling umum — penandatangan memiliki kunci pribadi, verifier memiliki kunci publik. **Keluarga RSA-PSS** (PS256/PS384/PS512) menggunakan padding RSA-PSS yang lebih baru dengan jaminan keamanan yang lebih kuat, disukai oleh AWS SigV4 dan penyedia identitas OIDC modern. **Keluarga ECDSA** (ES256/ES384/ES512) menggunakan kurva eliptik (P-256/P-384/P-521 masing-masing) dengan tanda tangan yang lebih pendek dan kinerja yang lebih baik. **EdDSA** (terutama Ed25519) sangat cepat dan deterministik (pesan yang sama + kunci yang sama = tanda tangan yang sama setiap saat) dan merupakan algoritma yang direkomendasikan dalam OAuth 2.1 dan protokol baru.

Keamanan adalah tempat JWT tersandung dalam produksi. OWASP JWT Cheat Sheet mencantumkan setidaknya empat aturan keras: (1) jangan pernah menempatkan kata sandi, dokumen identitas nasional, nomor kartu, atau kunci API sebagai teks polos di Payload; (2) server harus **tidak pernah mempercayai field alg** yang dideklarasikan di Header Token — harus memverifikasi dengan algoritma yang di-hardcode, jika tidak penyerang yang menulis ulang header menjadi `alg: none` melewati semuanya (ini adalah sumber CVE historis seperti CVE-2015-9235); (3) secret HMAC harus acak dan setidaknya 32 byte, tidak pernah string pendek; (4) verifikasi lebih dari sekadar pemeriksaan tanda tangan — Anda juga harus memvalidasi `exp` (kedaluwarsa), `nbf` (not-before), `iss` (penerbit), dan `aud` (audiens). Alat ini menyoroti masing-masing Claims ini di UI sehingga Anda dapat langsung mengetahui apakah kegagalan adalah masalah tanda tangan, masalah waktu, atau masalah Claims.

JWT bukan pengganti sesi. Sesi menyimpan status pengguna di server (Redis atau database); JWT mengemas status ke dalam token. Arsitektur layanan mikro, API tanpa status, klien seluler, dan pengaturan dengan banyak CORS mendapat manfaat dari JWT; sistem perusahaan tradisional dan alur yang memerlukan pencabutan segera (contoh: 'keluarkan pengguna ini sekarang') masih lebih baik dilayani oleh sesi. Alat ini mencakup debugging JWT murni serta langkah-langkah parsing Token / verifikasi tanda tangan / editing Payload dari migrasi sesi ke JWT.

Code Examples

50 lines of Node.js: hand-written HS256 sign and verify

javascript

Distills JWT's core mechanism: encode Header and Payload in Base64URL, then HMAC-SHA256 the `header.payload` string. In production, use a library like jsonwebtoken or jose — this snippet exists to make signature failures debuggable.

const crypto = require('node:crypto')

function b64url(input) {
  return Buffer.from(input)
    .toString('base64')
    .replace(/\+/g, '-')
    .replace(/\//g, '_')
    .replace(/=+$/, '')
}

function hmacSign(data, secret) {
  return b64url(crypto.createHmac('sha256', secret).update(data).digest())
}

function sign(payload, secret) {
  const header = b64url(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
  const body = b64url(JSON.stringify(payload))
  const signature = hmacSign(`${header}.${body}`, secret)
  return `${header}.${body}.${signature}`
}

function verify(token, secret) {
  const [h, p, s] = token.split('.')
  const expected = hmacSign(`${h}.${p}`, secret)
  const a = Buffer.from(s)
  const b = Buffer.from(expected)
  return a.length === b.length && crypto.timingSafeEqual(a, b)
}

const SECRET = 'my-super-secret-key'
const payload = { userId: 42, role: 'admin', exp: Math.floor(Date.now() / 1000) + 3600 }
const token = sign(payload, SECRET)

console.log(token)
console.log(verify(token, SECRET))       // true
console.log(verify(token, 'wrong-key'))  // false

Browser-side: Web Crypto API for HMAC signing

html

The core idea of this tool's front-end: use the browser's native crypto.subtle for HMAC, RSA, ECDSA, RSA-PSS and Ed25519 verification — no third-party library needed. Drop this into any HTML page to mint HS256 tokens.

<!doctype html>
<html>
  <body>
    <pre id="out"></pre>
    <script>
      const out = document.getElementById('out')

      const b64url = buf =>
        btoa(String.fromCharCode(...new Uint8Array(buf)))
          .replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')

      const b64urlStr = str => b64url(new TextEncoder().encode(str))

      async function sign(payload, secret) {
        const header = b64urlStr(JSON.stringify({ alg: 'HS256', typ: 'JWT' }))
        const body = b64urlStr(JSON.stringify(payload))
        const data = new TextEncoder().encode(`${header}.${body}`)

        const key = await crypto.subtle.importKey(
          'raw',
          new TextEncoder().encode(secret),
          { name: 'HMAC', hash: 'SHA-256' },
          false,
          ['sign']
        )

        const sig = await crypto.subtle.sign('HMAC', key, data)
        return `${header}.${body}.${b64url(sig)}`
      }

      ;(async () => {
        const token = await sign({ user: 'alice', role: 'admin' }, 'browser-demo-secret')
        out.textContent = token
      })()
    </script>
  </body>
</html>

Node.js: verify RS256 with jose (the right way)

javascript

Use a mature library like jose, jsonwebtoken, or PyJWT in production — never roll your own. This snippet shows how jose verifies an RS256 token, prints the failure reason on error (alg mismatch, bad signature, expired, kid not found, etc).

import { jwtVerify, importSPKI } from 'jose'
import { readFile } from 'node:fs/promises'

const token = 'eyJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.payload.signature'
const publicKeyPem = await readFile('public.pem', 'utf8')

try {
  const { payload, protectedHeader } = await jwtVerify(
    token,
    await importSPKI(publicKeyPem, 'RS256'),
    {
      issuer: 'https://idp.example.com',
      audience: 'my-app',
      algorithms: ['RS256'],     // critical: algorithm whitelist blocks alg:none and HS256-substitution attacks
    }
  )
  console.log('alg =', protectedHeader.alg)
  console.log('sub  =', payload.sub)
} catch (err) {
  console.error('verify failed:', err.code, err.message)
  // common: ERR_JWT_EXPIRED / ERR_JWS_INVALID / ERR_JWS_SIGNATURE_VERIFICATION_FAILED
}

Python: parse a token and print its Claims with PyJWT

python

The most common way to debug JWT on the Python side. PyJWT's decode() validates exp / nbf / iat by default and returns the result as a plain dict.

import jwt

token = 'eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0In0.SflKxw'

# Parse (no signature check, just look at Header and Payload)
print(jwt.get_unverified_header(token))
# {'alg': 'HS256', 'typ': 'JWT'}

print(jwt.decode(token, options={'verify_signature': False}))
# {'sub': '1234'}

# Full verification
claims = jwt.decode(
    token,
    'my-super-secret-key',
    algorithms=['HS256'],
    audience='my-app',
    issuer='my-service',
)
print(claims['sub'])

Supported Video Formats

FormatMIMEBrowser supportWhen to use
HS256 / HS384 / HS512HMAC + SHA-256/384/512UniversalAlgoritma kunci simetris: Secret yang sama dipakai untuk menandatangani dan memverifikasi. Sederhana, cepat, dan cocok untuk cluster layanan di dalam batas yang tepercaya. Secret minimal 32 byte untuk HS256, 48 byte untuk HS384, dan 64 byte untuk HS512.
RS256 / RS384 / RS512RSASSA-PKCS1-v1_5 + SHA-2Web Crypto APIAlgoritma asimetris yang paling umum. Token ditandatangani dengan private key dan diverifikasi dengan public key. Ini sering menjadi default pada penyedia OIDC, API gateway, dan SSO perusahaan.
PS256 / PS384 / PS512RSA-PSS + SHA-2Web Crypto APIRSA-PSS adalah pengganti RS256 yang lebih baru dan lebih aman. AWS SigV4, AWS Cognito, dan penyedia OIDC modern cenderung memilihnya. saltLength perlu ditentukan secara eksplisit agar verifikasi cocok.
ES256 / ES384 / ES512ECDSA + P-256/P-384/P-521Web Crypto APITanda tangan berbasis elliptic curve. Ukurannya pendek (ES256 hanya 64 byte), performanya cepat, dan ukuran JWT jadi lebih kecil. Sign in with Apple memakai ES256 secara default.
EdDSA (Ed25519)Ed25519 / Ed448Web Crypto APIAlgoritma tanda tangan generasi baru dengan performa tinggi. Tanda tangannya deterministik (pesan yang sama + kunci yang sama = tanda tangan yang sama), tidak berisiko karena nonce dipakai ulang, dan cocok untuk protokol baru.

Output Example

A real MP3 file encoded to a Data URI — copy-ready:

Header (Base64URL): eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload (Base64URL): eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkphbmUgRG9lIiwiaWF0IjoxNzE2MjM5MDIyfQ
Signature: kZJfaYjK3iCkVFL5EL9zGRZ5SmD8_x2h6B5c7pVFfVGo

Privacy & Security

Meja kerja JWT ini berjalan 100% di browser Anda, didukung oleh Web Crypto API native browser. Token yang Anda tempel, Header, Payload, Signature, Secret HMAC, kunci pribadi RSA/ECDSA apa pun, pasangan kunci yang dihasilkan apa pun, dan setiap perhitungan tanda tangan/verifikasi tetap di perangkat Anda — mereka tidak pernah pergi ke server, tidak pernah dicatat, tidak pernah dianalisis, dan tidak pernah di-cache. Halaman dapat digunakan secara offline setelah dimuat. Praktik terbaik: jangan pernah tempel token produksi yang berumur panjang atau kunci pribadi produksi ke alat online apa pun, termasuk yang ini. Alat ini cocok untuk debugging, pengujian integrasi, pembelajaran, dan pembuatan token pengujian — secret produksi dan kunci pribadi harus ditangani di lingkungan yang terkontrol dan lokal.

Authoritative References

Troubleshooting

Invalid Signature: 'signature is invalid'

Token dan kunci verifikasi tidak cocok. Penyebab umum: (1) kunci server dan kunci yang Anda tempel di alat berbeda (paling umum); (2) kunci mengandung karakter tak terlihat (spasi akhir, baris baru, karakter lebar-nol); (3) Base64 dan Base64URL tercampur; (4) algoritma yang salah dipilih (Header mengatakan HS256, server memverifikasi sebagai RS256 atau sebaliknya). Pertama periksa apakah kunci cocok byte demi byte: perhatikan baris baru akhir PEM, spasi akhir Secret HMAC, dan nilai `k` JWK yang mungkin telah didekodekan URL secara salah. Konfirmasi bahwa algoritma di alat cocok dengan Header.alg token. Gunakan decode-plus-verify alat ini untuk mereproduksi kesalahan yang tepat dan konfirmasi bahwa itu terjadi antara 'decode berhasil' dan 'verifikasi gagal'.

HTTP 401 Unauthorized: Token Expired atau iat di masa depan

Verifikasi tanda tangan lulus tetapi `exp` di masa lalu (Token Expired), `nbf` masih di masa depan (Not Before), atau `iat` setelah waktu server saat ini (sering karena pergeseran sinkronisasi jam). Kasus umum lain adalah `aud` (audiens) yang tidak cocok: token diterbitkan untuk Aplikasi A tetapi diverifikasi oleh Aplikasi B. Gunakan area Claims yang disorot di alat ini untuk melihat status exp / nbf / iat sekilas. exp merah = kedaluwarsa, terbitkan ulang. nbf merah = belum valid, periksa apakah iat adalah waktu masa depan. aud merah = audiens salah, periksa apakah server dikonfigurasi dengan audiens yang benar.

Kesalahan impor PEM atau JWK

PEM memiliki baris kosong tambahan atau kehilangan penanda header/footer (`-----BEGIN PUBLIC KEY-----`); JWK kehilangan field wajib (`kty` / `n` / `e` / `kid`); nilai `k` JWK kehilangan padding Base64URL (harus diisi dengan `=` atau ketat tanpa `=`); kunci pribadi RSA diimpor sebagai kunci publik; kunci pribadi Ed25519 (seed 32 byte) disediakan sebagai 64 byte. Ekspor ulang PEM PKIX standar dengan `openssl rsa -in key.pem -pubout -outform PEM` atau `openssl ec -in key.pem -pubout`; untuk JWK, gunakan output mentah dari endpoint OIDC Discovery `/.well-known/jwks.json` daripada mengkodekan secara manual. Alat ini secara otomatis mendeteksi header PEM, padding yang hilang, dan field JWK yang hilang dan memberikan petunjuk.

RS256 vs PS256 kegagalan tanda tangan antar bahasa

RS256 menggunakan RSASSA-PKCS1-v1_5, PS256 menggunakan RSA-PSS. Keduanya **tidak dapat memverifikasi silang** — token yang ditandatangani RS256 dengan kunci RSA tertentu akan selalu gagal verifikasi PS256, dan tanda tangan dapat berbeda panjang beberapa byte. Pastikan penandatangan dan verifier menggunakan algoritma yang sama. AWS SigV4 menggunakan PS256, sebagian besar OIDC IdP menggunakan RS256. RSA-PSS juga memiliki parameter `saltLength` — OpenSSL default 32, jose default 32, `rsa.PSSOptions{SaltLength: rsa.PSSSaltLengthEqualsHash}` Go adalah padanan yang benar. Kunci ini sebelum menguji integrasi antar bahasa.

Serangan alg:none dan serangan penggantian kunci HS256

Server memilih algoritma verifikasi berdasarkan alg yang dideklarasikan di Header token. Penyerang menulis ulang header menjadi `alg: none` (tanpa tanda tangan) atau menulis ulang token RS256 menjadi HS256 (menggunakan kunci publik seolah-olah itu adalah Secret HMAC bersama) dan melewati verifikasi. CVE historis seperti CVE-2015-9235 (jsonwebtoken) dan CVE-2022-23529 (banyak pustaka Node) berasal dari pola ini. Server harus memaksakan whitelist algoritma — contoh `algorithms: ['RS256']` — dan tidak pernah membiarkan token memutuskan algoritma mana yang digunakan. UI alat ini menampilkan baik Header.alg maupun algoritma yang benar-benar Anda pilih, dan menandai ketidakcocokan: ini adalah demo langsung 'klien tidak boleh mempercayai Header.alg'.