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

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:

```text
xxxxx.yyyyy.zzzzz
```

Terdiri dari 3 bagian:

```text
header.payload.signature
```

Contoh nyata:

```text
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.
eyJ1c2VySWQiOjEsInJvbGUiOiJhZG1pbiJ9
.
sdfkjh23498sdf9234...
```

* * *

# Bagian JWT

## 1\. Header

Berisi metadata:

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

Artinya:

*   algoritma signing: HS256
    
*   tipe token: JWT
    

* * *

## 2\. Payload

Berisi data:

```json
{
  "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:

```text
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:

```text
eyJ1c2VySWQiOjEsInJvbGUiOiJhZG1pbiJ9
```

Developer bisa membukanya hanya dengan:

```js
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:

```json
{
  "role": "user"
}
```

Lalu server membuat signature menggunakan secret key rahasia.

* * *

# Hacker Mengubah Payload

Misal hacker mencoba:

```json
{
  "role": "admin"
}
```

Masalahnya:

*   signature lama tidak cocok lagi.
    

Backend akan melakukan verifikasi:

```text
signature_valid ?
```

Jika tidak cocok:

```text
401 Unauthorized
```

* * *

# Analogi yang Lebih Tepat

JWT lebih mirip:

```text
surat resmi bertanda tangan
```

daripada:

```text
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:

```json
{
  "password": "123456"
}
```

atau:

```json
{
  "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:

```json
{
  "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:

```text
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:

```text
JWT + session lookup
```

misalnya payload hanya:

```json
{
  "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:

```text
payload terlihat atau tidak
```

padahal inti keamanan JWT adalah:

```text
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.