Apa Itu JWT? Panduan Jelas tentang JSON Web Token

JWT dalam istilah sederhana

Sebuah JWT (JSON Web Token) adalah string ringkas yang aman untuk URL yang merepresentasikan sekumpulan informasi (biasanya tentang pengguna atau sesi) dengan cara yang dapat dikirim antar sistem. Anda sering melihatnya sebagai nilai panjang yang dimulai dengan sesuatu seperti eyJ..., dikirim dalam header HTTP seperti Authorization: Bearer <token>.

Mengapa menggunakan token sama sekali?

Login tradisional sering mengandalkan session server: setelah Anda masuk, server menyimpan data session dan memberi browser cookie dengan ID session. Setiap permintaan menyertakan cookie itu, dan server mencari record session.

Dengan otentikasi berbasis token, server dapat menghindari menyimpan state session untuk setiap permintaan pengguna. Sebaliknya, klien memegang token (seperti JWT) dan menyertakannya pada panggilan API. Ini populer untuk API karena:

• bekerja baik di banyak layanan (API gateway, microservices)
• cocok untuk aplikasi mobile dan single-page apps (SPA) yang memanggil API langsung
• mengurangi kebutuhan penyimpanan session bersama antar server

Nuansa penting: “stateless” tidak berarti “tanpa pengecekan server-side sama sekali.” Banyak sistem nyata masih memvalidasi token terhadap status pengguna, rotasi kunci, atau mekanisme pencabutan.

Autentikasi vs otorisasi (dalam bahasa sederhana)

• Autentikasi menjawab: Siapa Anda? (Anda masuk dan membuktikan identitas.)
• Otorisasi menjawab: Apa yang boleh Anda lakukan? (Anda bisa membaca faktur, mengubah proyek, mengakses halaman admin, dll.)

JWT umum membawa bukti autentikasi (Anda sudah masuk) dan petunjuk otorisasi dasar (peran, izin, scope)—tetapi server Anda tetap harus menegakkan aturan otorisasi.

Di mana JWT muncul

Anda sering melihat JWT digunakan sebagai access token di:

• web API
• SPA
• aplikasi mobile
• sistem yang memakai OAuth 2.0 atau OpenID Connect (OIDC)

Struktur JWT: header, payload, dan signature

JWT adalah string ringkas yang terdiri dari tiga bagian, masing-masing di-Base64URL-kan dan dipisah oleh titik:

header.payload.signature

Contoh (disamarkan):

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwiaWF0IjoxNzAwMDAwMDAwfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c…

1) Header

Header menjelaskan bagaimana token dibuat—terpenting adalah algoritma penandatanganan (mis. HS256, RS256/ES256) dan tipe token.

Field umum:

• typ: sering "JWT" (sering diabaikan dalam praktik)
• alg: algoritma penandatanganan yang digunakan
• kid: identifier kunci untuk membantu verifier memilih kunci yang tepat saat rotasi

Catatan keamanan: jangan percaya header begitu saja. Terapkan allowlist algoritma yang benar-benar Anda gunakan, dan jangan terima alg: "none".

2) Payload

Payload berisi “klaim” (field) tentang pengguna dan konteks token: untuk siapa, siapa yang menerbitkan, dan kapan kadaluarsa.

Penting: JWT tidak terenkripsi secara default. Base64URL membuat token aman untuk URL; itu tidak menyembunyikan data. Siapa pun yang mendapatkan token bisa mendekode header dan payload.

Karena itu, hindari menaruh rahasia (kata sandi, API key) atau data pribadi sensitif ke dalam JWT.

3) Signature

Signature dibuat dengan menandatangani header + payload menggunakan kunci:

• HS256: shared secret menandatangani dan memverifikasi
• RS256/ES256: private key menandatangani; public key memverifikasi

Signature memberikan integritas: memungkinkan server memverifikasi token tidak diubah dan diterbitkan oleh signer tepercaya. Signature tidak memberikan kerahasiaan.

Pertimbangan ukuran

Karena JWT menyertakan header dan payload pada setiap permintaan tempat ia dikirim, token yang lebih besar berarti lebih banyak bandwidth dan overhead. Jaga klaim tetap ringkas dan gunakan identifier daripada data besar.

Payload dan klaim: apa yang boleh (dan tidak boleh) Anda simpan

Klaim umumnya terbagi menjadi dua: registered (nama standar) dan kustom (field aplikasi Anda).

Klaim terdaftar umum

• iss (issuer): siapa yang membuat token
• sub (subject): tentang siapa token ini (sering id pengguna)
• aud (audience): untuk siapa token ini ditujukan (mis. API tertentu)
• exp (expiration time): kapan token harus berhenti diterima
• iat (issued at): kapan token dibuat
• nbf (not before`): token tidak boleh diterima sebelum waktu ini

Klaim kustom: jaga seminimal mungkin

Sertakan hanya apa yang benar-benar dibutuhkan layanan penerima untuk membuat keputusan otorisasi.

Contoh yang baik:

• identifier pengguna internal yang stabil (user_id)
• set kecil peran/izin (hanya jika dapat dipertahankan tetap up-to-date)
• ID tenant/organisasi pada aplikasi multi-tenant

Hindari klaim “kenyamanan” yang menduplikasi banyak data profil. Mereka membuat token bengkak, cepat kadaluarsa, dan meningkatkan dampak jika token bocor.

Apa yang tidak boleh Anda taruh di payload JWT

Karena payload dapat dibaca, jangan simpan:

• kata sandi, API key, refresh token, atau nilai rahasia apa pun
• detail pembayaran, nomor identitas pemerintah, atau data pribadi sensitif
• apa pun yang tidak ingin Anda salin dari browser, proxy, atau log

Jika perlu informasi sensitif, simpan di server dan letakkan hanya referensi (mis. ID) di token—atau gunakan format token terenkripsi (JWE) bila sesuai.

Bagaimana signature bekerja (dan apa yang dijaminnya)

Penandatanganan bukan enkripsi.

• Penandatanganan seperti menyegel surat: orang bisa membacanya, tetapi mereka bisa memverifikasi tidak ada perubahan.
• Enkripsi seperti mengunci surat dalam kotak: hanya yang punya kunci yang bisa membaca.

Saat JWT diterbitkan, server menandatangani header + payload terenkode. Saat token disajikan nanti, server menghitung ulang signature dan membandingkannya. Jika seseorang mengubah walau satu karakter (mis. "role":"user" menjadi "role":"admin"), verifikasi gagal dan token ditolak.

JWT vs OAuth, OpenID Connect, dan tipe token

JWT adalah format token. OAuth 2.0 dan OpenID Connect (OIDC) adalah protokol yang menjelaskan bagaimana aplikasi meminta, menerbitkan, dan menggunakan token.

OAuth 2.0 dan access/refresh token

OAuth 2.0 terutama soal otorisasi: memberi aplikasi hak mengakses API atas nama pengguna tanpa membagikan kata sandi pengguna.

• Access token: disajikan ke API untuk membuktikan izin; bisa berupa JWT atau token opaque
• Refresh token: token berumur lebih panjang yang dipakai untuk memperoleh access token baru

Access token biasanya berumur pendek (menit). Masa berlaku pendek membatasi kerusakan jika token bocor.

OpenID Connect (OIDC) dan ID token

OIDC menambahkan autentikasi (siapa pengguna) di atas OAuth 2.0 dan memperkenalkan ID token, yang biasanya berupa JWT.

• ID token: untuk aplikasi klien memastikan identitas pengguna
• Access token: untuk API memberikan otorisasi permintaan

Aturan penting: jangan gunakan ID token untuk memanggil API.

Jika Anda ingin konteks lebih tentang flow praktis, lihat /blog/jwt-authentication-flow.

Flow autentikasi JWT yang umum

Flow tipikal:

1) Login

Pengguna masuk (email/password, SSO, dll.). Jika berhasil, server membuat JWT (sering access token) dengan klaim penting seperti subject dan expiry.

2) Penerbitan token

Server menandatangani token dan mengembalikannya ke klien (web app, mobile app, atau layanan lain).

3) Panggilan API

Untuk endpoint terlindung, klien menyertakan JWT di header Authorization:

Authorization: Bearer <JWT>

4) Verifikasi

Sebelum melayani permintaan, API biasanya memeriksa:

• signature (integritas + issuer tepercaya)
• exp (belum kadaluarsa)
• iss (issuer yang diharapkan)
• aud (ditujukan untuk API ini)

Jika semua pengecekan lulus, API menganggap pengguna terautentikasi dan menerapkan aturan otorisasi (mis. izin per-record).

5) Catatan singkat tentang clock skew

Karena jam sistem bisa bergeser, banyak sistem mengizinkan sedikit clock skew saat memvalidasi klaim berbasis waktu seperti exp (dan kadang nbf). Jaga skew kecil agar tidak memperpanjang masa berlaku token lebih dari yang dimaksud.

Di mana menyimpan JWT dengan aman

Pilihan penyimpanan menentukan apa yang dapat dicuri penyerang dan seberapa mudah mereka dapat memutar ulang token.

Aplikasi browser: memory vs localStorage vs cookies

Penyimpanan di memori (sering direkomendasikan untuk SPA) menyimpan access token di state JS. Token hilang saat refresh dan mengurangi risiko “diambil belakangan”, tetapi bug XSS masih bisa membacanya saat halaman berjalan. Pasangkan dengan akses token berumur pendek dan flow refresh.

localStorage/sessionStorage mudah tapi berisiko: setiap kerentanan XSS dapat mengekstrak token dari storage web. Jika menggunakannya, pencegahan XSS tidak bisa ditawar (CSP, escaping output, kebersihan dependency) dan jaga token berumur pendek.

Cookie aman (sering default teraman untuk web) menyimpan token di cookie HttpOnly sehingga JavaScript tidak bisa membacanya—mengurangi dampak pencurian token via XSS. Trade-off-nya adalah risiko CSRF, karena browser melampirkan cookie otomatis.

Jika memakai cookie, setel:

• HttpOnly
• Secure (HTTPS saja)
• SameSite=Lax atau SameSite=Strict (beberapa flow lintas situs mungkin perlu SameSite=None; Secure)

Pertimbangkan juga token CSRF untuk permintaan yang mengubah state.

Aplikasi mobile: utamakan penyimpanan aman OS

Di iOS/Android, simpan token di penyimpanan aman platform (Keychain / Keystore-backed storage). Hindari file biasa atau preferences. Jika model ancaman Anda mencakup perangkat yang di-root/jailbreak, anggap ekstraksi mungkin terjadi dan andalkan token berumur pendek serta kontrol server-side.

Prinsip least privilege

Batasi apa yang dapat dilakukan token: gunakan scope/claims minimal, buat access token berumur pendek, dan hindari menanam data sensitif.

Kesalahan keamanan JWT umum yang harus dihindari

JWT praktis, tetapi banyak insiden berasal dari kesalahan yang mudah diprediksi. Anggap JWT seperti uang tunai: siapa pun yang mendapatkannya biasanya bisa menggunakannya.

1) Masa berlaku terlalu lama

Jika token bertahan berhari-hari atau berminggu-minggu, kebocoran memberi penyerang jendela waktu sebesar itu.

Utamakan access token berumur pendek (menit) dan refresh mereka melalui mekanisme yang lebih aman. Jika perlu “ingat saya”, lakukan dengan refresh token dan kontrol server-side.

2) Lewatkan pengecekan issuer dan audience

Signature yang valid tidak cukup. Verifikasi iss dan aud, serta validasi klaim berbasis waktu seperti exp dan nbf.

3) Mempercayai payload yang sudah didekode

Dekode bukan verifikasi. Selalu verifikasi signature di server dan terapkan izin di sisi server.

4) Kebingungan algoritma dan campur aduk kunci

• Jangan terima algoritma yang diklaim token begitu saja. Gunakan allowlist.
• Jangan mencampur kunci simetris (HS256) dengan kunci publik/privat (RS256/ES256).
• Kurangi blast radius dengan memisahkan kunci per environment dan merotasinya.

5) Kebocoran token lewat URL, log, dan referrer

Hindari menaruh JWT di query params. Mereka bisa berakhir di riwayat browser, log server, alat analitik, dan header referrer.

Gunakan Authorization: Bearer ... sebagai gantinya.

6) Tidak ada rencana rotasi kunci atau pencabutan

Asumsikan kunci dan token bisa bocor. Rotasi kunci tanda tangan, gunakan kid untuk mendukung rotasi mulus, dan miliki strategi pencabutan (masa berlaku pendek + kemampuan menonaktifkan akun/session). Untuk panduan penyimpanan, lihat /blog/where-to-store-jwts-safely.

Kapan menggunakan JWT (dan kapan tidak)

JWT berguna, tetapi bukan pilihan terbaik secara otomatis. Pertanyaan sebenarnya: apakah Anda mendapat manfaat dari token yang self-contained dan bisa diverifikasi tanpa lookup database pada setiap permintaan.

Cocok untuk JWT

• API stateless skala besar: verifikasi lokal (signature + expiry) tanpa lookup session per permintaan
• Banyak layanan / microservices: aturan verifikasi bersama dan public key
• SPA dan aplikasi mobile: klien memanggil API langsung
• Access token berumur pendek: mengurangi dampak pencurian

Saat JWT kurang cocok

• Perlu pencabutan instan: session lebih sederhana jika Anda butuh “logout di semua tempat sekarang” tanpa infrastruktur tambahan
• Perlu membawa data sensitif: JWT biasa ditandatangani, bukan dienkripsi
• Token berumur panjang: bernilai tinggi dan layak dicuri

Kapan cookie session sederhana lebih baik

Untuk aplikasi web tradisional yang dirender server di mana invalidasi mudah penting, session server-side dengan cookie HttpOnly seringkali lebih sederhana dan lebih aman.

Checklist keputusan singkat

Pilih JWT jika Anda perlu verifikasi stateless antar layanan dan dapat menjaga token berumur pendek.

Hindari JWT jika Anda butuh pencabutan instan, berencana menyimpan data sensitif di token, atau bisa menggunakan cookie session tanpa hambatan.

Checklist praktis dan FAQ

Checklist verifikasi (yang harus diperiksa setiap kali)

1. Signature valid

Verifikasi menggunakan kunci yang benar dan algoritma yang di-allowlist. Tolak signature yang tidak valid—tanpa pengecualian.

2. exp (kadaluarsa)

Pastikan token belum kedaluwarsa.

3. nbf (not before)

Jika ada, pastikan token tidak digunakan terlalu awal.

4. aud (audience)

Konfirmasi token memang ditujukan untuk API/layanan Anda.

5. iss (issuer)

Konfirmasi token berasal dari issuer yang diharapkan.

6. Pemeriksaan sanity (direkomendasikan)

Validasi format token, terapkan ukuran maksimum, dan tolak tipe klaim yang tidak diharapkan untuk mengurangi bug edge-case.

Memilih HS256 vs RS256/ES256

• HS256 (kunci simetris): satu secret bersama untuk menandatangani dan memverifikasi.

  • Cocok untuk: satu aplikasi/API yang dikendalikan oleh satu tim.
  • Perhatian: siapa pun verifier yang punya secret juga bisa membuat token.

• RS256 / ES256 (kunci asimetris): private key menandatangani; public key memverifikasi.

  • Cocok untuk: banyak layanan yang memverifikasi token; mendistribusikan public key tanpa memberi kemampuan menandatangani.
  • Catatan operasional: rotasi biasanya lebih aman karena hanya signer yang memegang private key.

Aturan praktis: jika lebih dari satu sistem independen perlu memverifikasi token (atau Anda tidak sepenuhnya mempercayai setiap verifier), pilih RS256/ES256.

Monitoring dan logging (tanpa membocorkan token)

• Jangan log token mentah (header, cookie, query string).
• Jika perlu korelasi, log fingerprint token (mis. hash) atau metadata aman (iss, aud, dan user ID hanya jika kebijakan mengizinkan).
• Awasi anomali: kegagalan signature, lonjakan token kadaluarsa, audience/issuer yang mencurigakan, dan pola refresh yang tidak biasa.

FAQ

Apakah JWT terenkripsi?

Tidak secara default. Sebagian besar JWT ditandatangani, bukan dienkripsi, artinya konten dapat dibaca siapa pun yang punya token. Gunakan JWE atau jangan letakkan data sensitif dalam JWT.

Bisakah saya mencabut JWT?

Tidak mudah jika hanya mengandalkan access token self-contained. Pendekatan umum meliputi token akses berumur pendek, deny-list untuk peristiwa berisiko tinggi, atau refresh token dengan rotasi.

Berapa lama exp sebaiknya?

Sesingkat mungkin sesuai UX dan arsitektur Anda. Banyak API memakai menit untuk access token, dipasangkan dengan refresh token untuk sesi yang lebih lama.

Membangun aplikasi terlindungi JWT lebih cepat dengan Koder.ai

Jika Anda mengimplementasikan otentikasi JWT di API atau SPA baru, banyak pekerjaan yang repetitif: memasang middleware, memvalidasi iss/aud/exp, menyetel flag cookie, dan menjaga agar penanganan token tidak masuk log.

Dengan Koder.ai, Anda bisa mempercepat pembuatan aplikasi web (React), layanan backend (Go + PostgreSQL), atau aplikasi mobile Flutter melalui workflow berbasis chat—lalu iterasi dalam planning mode, gunakan snapshot dan rollback saat menyempurnakan keamanan, dan ekspor kode sumber saat siap. Ini cara praktis mempercepat pembuatan flow autentikasi berbasis JWT sambil tetap mengendalikan logika verifikasi, strategi rotasi kunci, dan pengaturan deployment/hosting (termasuk domain kustom).