Skip to main content

Command Palette

Search for a command to run...

JWT Bukan Enkripsi: Kesalahpahaman yang Masih Sering Terjadi di Dunia Developer

Updated
5 min read
JWT Bukan Enkripsi: Kesalahpahaman yang Masih Sering Terjadi di Dunia Developer
A

I am an enthusiastic researcher and developer with a passion for using technology to innovate in business and education.

Banyak developer pertama kali melihat JWT lalu berpikir:

“Wah aman, datanya sudah terenkripsi.”

Padahal kenyataannya:

JWT umumnya tidak dienkripsi. JWT biasanya hanya encoded dan signed.

Ini kesalahpahaman yang sangat umum, bahkan di kalangan developer berpengalaman. Akibatnya, banyak sistem tanpa sadar menyimpan data sensitif di dalam token karena mengira payload tidak bisa dibaca.

Padahal:

  • siapa pun bisa membuka isi JWT

  • tanpa password

  • tanpa secret key

  • tanpa akses server

Artikel ini membahas:

  • mengapa JWT tetap aman walau bisa dibaca,

  • bagaimana signature bekerja,

  • kenapa JWT bukan tempat menyimpan data rahasia,

  • dan bagaimana memahami JWT dengan cara yang benar.


Apa Itu JWT?

JWT atau JSON Web Token adalah format token berbasis JSON yang biasa digunakan untuk:

  • autentikasi,

  • otorisasi,

  • session modern,

  • OAuth,

  • microservice authentication.

Bentuk JWT biasanya seperti ini:

xxxxx.yyyyy.zzzzz

Terdiri dari 3 bagian:

header.payload.signature

Contoh nyata:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJ1c2VySWQiOjEsInJvbGUiOiJhZG1pbiJ9
.
sdfkjh23498sdf9234...

Bagian JWT

1. Header

Berisi metadata:

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

Artinya:

  • algoritma signing: HS256

  • tipe token: JWT


2. Payload

Berisi data:

{
  "userId": 1,
  "role": "admin",
  "exp": 1779898977
}

Inilah bagian yang sering disalahpahami.

Payload JWT:

  • bisa dibaca siapa saja

  • bukan terenkripsi

  • hanya Base64 encoded


3. Signature

Inilah inti keamanan JWT.

Signature dibuat menggunakan:

  • header,

  • payload,

  • secret key server.

Contoh sederhana:

HMACSHA256(
  header.payload,
  SECRET_KEY
)

Hasilnya menjadi signature.


Encoding ≠ Encryption

Kesalahan paling umum adalah menganggap Base64 sebagai enkripsi.

Padahal Base64 hanya encoding.

Analogi

Encoding seperti:

  • menerjemahkan tulisan ke format lain.

Encryption seperti:

  • mengunci tulisan dengan kunci rahasia.

JWT Bisa Dibuka Semua Orang

Misalnya token:

eyJ1c2VySWQiOjEsInJvbGUiOiJhZG1pbiJ9

Developer bisa membukanya hanya dengan:

atob(tokenPart)

atau website decoder online.

Tidak perlu:

  • password,

  • secret key,

  • akses backend.


Lalu Kenapa JWT Tetap Aman?

Karena keamanan JWT bukan pada “kerahasiaan payload”.

Tetapi pada:

Signature

JWT aman karena client tidak bisa memalsukan signature.


Cara Signature Bekerja

Misalnya server membuat payload:

{
  "role": "user"
}

Lalu server membuat signature menggunakan secret key rahasia.


Hacker Mengubah Payload

Misal hacker mencoba:

{
  "role": "admin"
}

Masalahnya:

  • signature lama tidak cocok lagi.

Backend akan melakukan verifikasi:

signature_valid ?

Jika tidak cocok:

401 Unauthorized

Analogi yang Lebih Tepat

JWT lebih mirip:

surat resmi bertanda tangan

daripada:

brankas terkunci

Semua orang bisa membaca isi surat.

Tetapi:

  • tidak semua orang bisa membuat tanda tangan resmi.

Kesalahan Fatal yang Masih Sering Dilakukan

Karena mengira JWT terenkripsi, beberapa developer menyimpan:

  • password,

  • API key,

  • nomor kartu,

  • data sensitif,

  • informasi internal.

Contoh buruk:

{
  "password": "123456"
}

atau:

{
  "creditCard": "..."
}

Ini berbahaya.

Karena siapa pun yang memegang token bisa membacanya.


Data Apa yang Aman Disimpan di JWT?

Biasanya hanya:

  • user id,

  • role,

  • session id,

  • issuer,

  • audience,

  • expiry.

Contoh aman:

{
  "sub": "123",
  "role": "admin",
  "exp": 1779898977
}

JWT dan Stateless Authentication

Alasan JWT populer:

  • backend tidak perlu session store,

  • cocok untuk microservice,

  • scalable,

  • mudah diverifikasi.

Server cukup:

verify signature

tanpa query database.


Tapi JWT Murni Juga Punya Masalah

Karena stateless:

  • sulit revoke token,

  • logout tidak langsung invalid,

  • token tetap valid sampai expired.

Makanya banyak sistem modern memakai hybrid approach:

JWT + session lookup

misalnya payload hanya:

{
  "ref": "session_id"
}

Lalu backend cek Redis/database.

Ini mulai populer di:

  • enterprise apps,

  • banking systems,

  • internal ERP,

  • modern SaaS.


Kenapa Banyak Sistem Sekarang Tidak Menyimpan Banyak Data di JWT?

Karena:

  • payload terlihat user,

  • ukuran token bisa besar,

  • data mudah stale,

  • sulit revoke.

Sekarang tren modern:

  • payload minimal,

  • session server-side,

  • access token pendek,

  • refresh token rotation.


JWT Bukan Solusi Semua Hal

JWT sering dipakai berlebihan.

Padahal pada beberapa kasus:

  • session tradisional lebih aman,

  • cookie auth lebih sederhana,

  • stateful auth lebih mudah revoke.

Tidak semua aplikasi harus JWT.


Jika Ingin Token Benar-Benar Terenkripsi

Ada standar bernama:

JSON Web Encryption

Tetapi lebih kompleks:

  • lebih berat,

  • implementasi lebih sulit,

  • jarang dibutuhkan.

Mayoritas sistem modern cukup memakai:

  • signed JWT,

  • bukan encrypted JWT.


Memahami JWT dengan Benar

JWT bukan:

  • tempat menyimpan rahasia,

  • enkripsi data,

  • anti-baca.

JWT adalah:

  • format token terstandar,

  • membawa claim,

  • diverifikasi dengan signature.

Keamanan JWT terletak pada:

  • secret key server,

  • validasi signature,

  • expiry,

  • refresh flow,

  • transport security (HTTPS).

Bukan pada “payload tidak bisa dibaca”.


Penutup

Banyak developer terlalu fokus pada:

payload terlihat atau tidak

padahal inti keamanan JWT adalah:

apakah payload bisa dipalsukan?

Itulah fungsi signature.

Jika memahami ini dengan benar, developer akan:

  • lebih bijak menyimpan data,

  • memahami batas JWT,

  • menghindari kebocoran sensitif,

  • dan membangun sistem auth yang jauh lebih matang.

JWT bukan “data rahasia terenkripsi”.

JWT adalah:

data yang bisa dibaca, tetapi tidak bisa dimanipulasi tanpa secret key.