Autentikasi Anda baru saja gagal di production. Pengguna mendapatkan error “Invalid Token”, dan Anda harus segera mencari tahu penyebabnya. Anda membuka JWT tersebut, dan isinya terlihat seperti teks acak: tiga blok karakter tak terbaca yang dipisahkan oleh titik. Datanya ada di dalam sana, tetapi Anda tidak bisa membacanya tanpa sebuah parser.
Sebuah JWT Parser adalah alat khusus yang memecah tiga bagian dari sebuah JSON Web Token — Header, Payload, dan Signature — mengikuti standar RFC 7519. Per April 2026, parser ini men-decode data berenkode Base64URL dan memverifikasi signature menggunakan secret atau public key untuk memastikan token tidak telah diubah, memblokir ancaman seperti serangan “alg: none”.
Apa yang Sebenarnya Dilakukan oleh JWT Parser
Anggaplah JWT parser sebagai penerjemah. Alat ini mengambil sebuah string panjang yang opaque dan mengubahnya kembali menjadi objek JSON yang bisa dibaca. Hal ini mendasar untuk mengelola identitas pengguna dan mengamankan pertukaran data pada aplikasi modern.
Secara internal, parser menemukan dua tanda titik (.) yang membagi token menjadi tiga bagian:
| Bagian | Tujuan | Dienkode? | Dapat Dibaca Tanpa Key? |
|---|---|---|---|
| Header | Metadata: algoritma penandatanganan (HS256, RS256) | Base64URL | Ya |
| Payload | Claims: data pengguna, kedaluwarsa, peran | Base64URL | Ya |
| Signature | Stempel digital yang membuktikan keaslian | HMAC/RSA | Tidak — membutuhkan key |
Decode Langkah demi Langkah: Apa yang Terjadi di Dalamnya
Mari telusuri sebuah token nyata. Ambil contoh JWT berikut:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4iLCJpYXQiOjE3MDAwMDAwMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Langkah 1: Pisahkan berdasarkan tanda titik
[0] eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
[1] eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4iLCJpYXQiOjE3MDAwMDAwMDB9
[2] SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Langkah 2: Base64URL-decode bagian [0] (Header)
{
"alg": "HS256",
"typ": "JWT"
}
Langkah 3: Base64URL-decode bagian [1] (Payload)
{
"sub": "1234567890",
"name": "John",
"iat": 1700000000
}
Langkah 4: Verifikasi bagian [2] (Signature) — membutuhkan secret key
Parser mengambil header berenkode Base64URL + “.” + payload, lalu menghitung sebuah HMAC-SHA256 menggunakan secret tersebut. Jika hasilnya cocok dengan bagian [2], berarti token itu asli.
Catatan Keamanan Penting: Base64URL Bukan Enkripsi
Jebakan umum bagi developer pemula adalah menganggap bahwa header dan payload yang telah dienkode itu terenkripsi. Nyatanya tidak. Seperti dijelaskan oleh JustUse.me, enkode Base64URL hanya membuat JSON aman untuk dikirim melalui URL dan header. Siapa pun yang memiliki token bisa men-decode payload tanpa password atau key.
Jangan pernah menyimpan data sensitif (password, SSN, API key) di dalam payload JWT. Data tersebut terlihat oleh siapa pun yang berhasil mencegat token.
Verifikasi Signature: Gerbang Keamanan
Meskipun siapa pun bisa membaca data sebuah token, verifikasi signature adalah yang benar-benar menjaga sistem Anda tetap aman. Sebuah JWT parser tidak hanya membaca informasi — ia membuktikan dari mana informasi itu berasal.
Parser menghitung ulang signature menggunakan header, payload, dan sebuah key, lalu memeriksa apakah hasilnya cocok dengan signature pada token. Jika tidak cocok, berarti token telah diubah.
Dua Famili Algoritma
| Algoritma | Tipe Key | Cara Kerjanya | Kasus Penggunaan Umum |
|---|---|---|---|
| HS256 (HMAC) | Simetris — secret key yang sama untuk menandatangani dan memverifikasi | Kedua pihak berbagi satu secret | Autentikasi layanan tunggal, microservices dalam satu tim |
| RS256 (RSA) | Asimetris — private key menandatangani, public key memverifikasi | Pengirim menyimpan private key; siapa pun dengan public key bisa memverifikasi | Penyedia OAuth2, integrasi API pihak ketiga |
| ES256 (ECDSA) | Asimetris — model yang sama dengan RSA tetapi menggunakan kurva eliptis | Key lebih kecil, verifikasi lebih cepat | Aplikasi mobile, layanan yang sensitif terhadap performa |
Serangan “alg: none”
Ini adalah salah satu kerentanan JWT yang paling berbahaya. Penyerang mengubah header untuk menyatakan "alg": "none" dan menghapus signature. Parser yang diimplementasikan dengan buruk mungkin menerimanya, memperlakukan token sebagai valid tanpa verifikasi apa pun.
Pertahanan: Parser Anda harus secara eksplisit menolak token apa pun yang algoritmanya adalah “none” atau tidak cocok dengan algoritma yang Anda harapkan. Stas Persiianenko, yang mengembangkan tool JWT Apify, menekankan bahwa meskipun token secara desain bersifat transparan, keamanannya bergantung pada parser yang menolak secara ketat token yang tidak ditandatangani atau telah diubah.
decoded = jwt.decode(token, key, algorithms=None) # NEVER do this
decoded = jwt.decode(token, key, algorithms=["HS256"])
JWT Claims Standar: Arti Setiap Field
Sebuah JWT parser mengekstrak “claims” dari payload. Claim-claim ini mengikuti kerangka kerja JOSE (JSON Object Signing and Encryption) untuk kompatibilitas lintas sistem.
| Claim | Nama Lengkap | Tujuan | Nilai Contoh |
|---|---|---|---|
iss |
Issuer | Siapa yang menerbitkan token | "auth.example.com" |
sub |
Subject | Pengguna atau entitas yang diwakili token | "user:12345" |
aud |
Audience | Penerima yang dituju dari token | "api.example.com" |
exp |
Expiration Time | Kapan token menjadi tidak valid | 1700000000 (Unix timestamp) |
iat |
Issued At | Kapan token dibuat | 1699999999 |
nbf |
Not Before | Token tidak valid sebelum waktu ini | 1699999999 |
jti |
JWT ID | Pengenal unik untuk token | "a1b2c3d4" |
Saat menggunakan signature asimetris, parser sering merujuk pada sebuah JWK (JSON Web Key) — struktur JSON yang merepresentasikan sebuah public key. Parser secara otomatis mengambil JWK yang benar dari endpoint metadata penerbit untuk memverifikasi token.
Implementasi: Kode Nyata untuk Production
PHP dengan lcobucci/jwt
Standar ekosistem PHP adalah lcobucci/jwt. Data dari Packagist menunjukkan lebih dari 322 juta instalasi per April 2026, menjadikannya pilihan utama untuk proyek Laravel dan Symfony.
use Lcobucci\JWT\Configuration;
use Lcobucci\JWT\Signer\Hmac\Sha256;
use Lcobucci\JWT\Signer\Key\InMemory;
$config = Configuration::forSymmetricSigner(
new Sha256(),
InMemory::plainText('your-secret-key')
);
// Parsing and validating a token
$token = $config->parser()->parse($jwtString);
// Verify constraints: expiration, issuer, etc.
$constraints = [
new \Lcobucci\JWT\Validation\Constraint\IssuedBy('auth.example.com'),
new \Lcobucci\JWT\Validation\Constraint\PermittedFor('api.example.com'),
new \Lcobucci\JWT\Validation\Constraint\SignedWith(
$config->signer(),
$config->signingKey()
),
];
$isValid = $config->validator()->validate($token, ...$constraints);
Hono (Edge/Serverless) dengan Web Crypto
Untuk aplikasi edge yang ringan, Hono JWT Helper menyediakan fungsi decode() minimal yang sempurna untuk platform serverless tempat Anda menginginkan cold start yang cepat dan dependensi seminimal mungkin.
import { jwt } from 'hono/jwt'
// Middleware to verify JWT on every request
app.use('/api/*', jwt({ secret: 'your-secret' }))
// Access decoded claims in your handler
app.get('/api/profile', (c) => {
const payload = c.get('jwtPayload')
return c.json({ user: payload.sub })
})
Analisis JWT Berbasis AI dengan MCP
Pada 2026, Model Context Protocol (MCP) memungkinkan asisten AI seperti Claude Code atau Cursor berbicara langsung dengan tool JWT. Siapkan sebuah MCP server, dan seorang developer bisa meminta AI untuk “Periksa semua JWT di log ini untuk error kedaluwarsa” — agen menangani parsing melalui command line.
Menurut Apify, pemrosesan massal membutuhkan biaya sekitar $11.50 per 10.000 token per 2026. Otomatisasi ini memungkinkan agen AI menemukan token kedaluwarsa dan segera menyarankan perbaikan kode untuk pengaturan keamanan aplikasi.
Kesimpulan
Sebuah JWT parser lebih dari sekadar kemudahan debugging — ia adalah titik pemeriksaan keamanan yang vital. Parser memastikan token asli melalui pemeriksaan signature dan valid melalui verifikasi claim. Ingatlah dua aturan yang paling penting: Base64URL bukan enkripsi, jadi jangan pernah menyimpan secret di payload. Dan selalu tentukan algoritma yang diizinkan secara eksplisit untuk mencegah serangan “alg: none”.
Untuk aplikasi production, gunakan library yang teruji seperti lcobucci/jwt atau JWT helper milik Hono daripada membuat parser sendiri. Untuk debugging dan analisis massal, tool MCP berbasis AI adalah pendekatan modern untuk menjaga audit keamanan tetap otomatis dan menyeluruh.
FAQ
Apakah legal men-decode JWT token yang saya temukan di browser saya?
Ya, sepenuhnya legal. JWT dirancang untuk bersifat transparan — header dan payload dienkode untuk transport, bukan dienkripsi untuk kerahasiaan. Memiliki token menyiratkan bahwa Anda memiliki akses ke data dalam claim-claimnya. Namun, selalu patuhi hukum perlindungan data lokal seperti GDPR ketika token berisi informasi pribadi.
Mengapa JWT parser saya menampilkan isExpired: true untuk token yang baru saja saya buat?
Hal ini biasanya disebabkan oleh clock drift antara server yang membuat token dan sistem yang mem-parsing-nya. Jika jam kedua sistem tidak tersinkronisasi (melalui UTC/NTP), claim exp atau nbf mungkin terlihat tidak valid. Atasi ini dengan memastikan kedua sistem menggunakan NTP untuk sinkronisasi waktu, atau tambahkan “leeway” kecil (biasanya 60 detik) di library parsing Anda untuk mengakomodasi sedikit pergeseran.
Bisakah saya men-decode JWT tanpa memiliki secret atau public key?
Ya, Anda selalu bisa men-decode dan membaca Header serta Payload tanpa key karena keduanya hanyalah JSON berenkode Base64URL. Namun, Anda tidak bisa memverifikasi Signature atau mempercayai bahwa datanya asli tanpa secret yang sesuai (untuk HS256) atau public key (untuk RS256). Tanpa verifikasi, perlakukan data tersebut sebagai belum terverifikasi dan kemungkinan telah diubah.
Apa itu serangan “alg: none” dan bagaimana cara mencegahnya?
Serangan “alg: none” mengeksploitasi parser yang menerima algoritma yang dinyatakan di header token tanpa validasi. Penyerang mengubah header menjadi "alg": "none" dan menghapus signature, sehingga menipu parser yang rentan untuk menerima token sebagai valid. Cegah hal ini dengan selalu menentukan algoritma yang diizinkan secara eksplisit di kode verifikasi Anda — jangan pernah menerima “none” atau mengizinkan token menentukan algoritma mana yang akan digunakan.
