# JWT Adalah: Pengertian, Struktur, dan Cara Kerjanya

> JWT adalah JSON Web Token, format token untuk autentikasi API. Pahami struktur header, payload, signature, klaim, JWT secret, expired, dan risikonya.

**URL:** https://www.ciptadusa.com/blog/jwt-adalah  
**Type:** blog  
**Author:** PT Cipta Dua Saudara  
**Category:** Teknologi  
**Published:** 2026-11-02  
**Cover:** https://www.ciptadusa.com/media/uploads/blog/2026-11/1793585800283-jwt-adalah-20261102.webp  

## Article

JWT adalah singkatan dari JSON Web Token, yaitu format token yang ringkas dan aman dipakai di URL untuk membawa klaim (data) antara dua pihak. Isi token ditulis sebagai objek JSON, lalu ditandatangani secara digital atau diberi kode autentikasi pesan (MAC) dan/atau dienkripsi, sehingga penerima bisa memeriksa bahwa isinya tidak diubah ([sumber](https://www.rfc-editor.org/rfc/rfc7519)). Dalam aplikasi web, JWT dipakai sebagai "tiket" yang dikirim klien ke API setelah login, misalnya di header `Authorization: Bearer <token>`.

Artikel ini membahas pengertian JWT, struktur tiga bagiannya, isi klaim standar, alur JWT authentication, perbedaan JWT dengan session, arti JWT secret dan JWT expired, serta kesalahan keamanan yang perlu dihindari saat memakainya.

## Pengertian JWT

JWT distandarkan oleh IETF dalam RFC 7519 yang terbit Mei 2015. RFC itu menyarankan JWT dilafalkan seperti kata bahasa Inggris "jot" ([sumber](https://www.rfc-editor.org/rfc/rfc7519)). NIST mendefinisikan JWT sebagai format pertukaran data yang terdiri dari header, payload, dan signature, dengan header dan payload berbentuk objek JSON yang di-encode lalu digabung dan ditandatangani ([sumber](https://csrc.nist.gov/glossary/term/jwt)).

Yang dibawa JWT disebut klaim (claims), yaitu pernyataan tentang suatu entitas, misalnya "user ini bernama Budi" atau "token ini berlaku sampai pukul 07.15". Karena isinya JSON, JWT mudah dibaca oleh bahasa pemrograman apa pun. Jika Anda belum familiar dengan format ini, baca dulu [pengertian JSON](/blog/json-adalah).

### JWT Adalah Singkatan dari Apa?

JWT adalah singkatan dari JSON Web Token. JSON merujuk pada format isi klaimnya, Web menunjukkan bahwa token ini dirancang untuk lingkungan web dan HTTP, dan Token berarti potongan data yang mewakili hak atau identitas.

### Apakah JWT Sama dengan Enkripsi?

Tidak selalu. JWT punya dua bentuk. JWT yang ditandatangani memakai JSON Web Signature (JWS, RFC 7515) dan menjamin isi tidak diubah, tetapi isinya tetap bisa dibaca ([sumber](https://www.rfc-editor.org/rfc/rfc7515)). JWT yang dienkripsi memakai JSON Web Encryption (JWE, RFC 7516) sehingga isinya rahasia ([sumber](https://www.rfc-editor.org/rfc/rfc7516)). OWASP menegaskan JWT bertanda tangan memberi integritas dan keaslian, bukan kerahasiaan, karena payload hanya di-encode base64url, bukan dienkripsi ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html)).

## Struktur JWT: Header, Payload, Signature

Dalam bentuk ringkasnya, JWT terdiri dari tiga bagian yang dipisahkan titik: header, payload, dan signature, sehingga bentuknya seperti `xxxxx.yyyyy.zzzzz` ([sumber](https://www.jwt.io/introduction)). Berikut contoh token yang dibuat CDS untuk ilustrasi artikel ini dengan secret contoh, bukan token sungguhan:

```
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJ1c2VyLTEyMyIsIm5hbWUiOiJCdWRpIiwicm9sZSI6ImFkbWluIiwiaWF0IjoxNzkzNTc3NjAwLCJleHAiOjE3OTM1Nzg1MDB9.kuTry3zCk0fPoNGiNn5Ywd-KUNCuARrq3BppgRd2zaY
```

| Bagian | Isi | Contoh setelah di-decode |
|---|---|---|
| Header | Jenis token dan algoritma tanda tangan | `{"alg":"HS256","typ":"JWT"}` |
| Payload | Klaim tentang user dan masa berlaku token | `{"sub":"user-123","name":"Budi","role":"admin","iat":1793577600,"exp":1793578500}` |
| Signature | Hasil tanda tangan atas header dan payload | Deretan karakter base64url, tidak bisa di-decode menjadi teks |

### Header

Header berisi dua informasi: jenis token (`typ`, bernilai JWT) dan algoritma tanda tangan (`alg`), misalnya HMAC SHA256 (HS256) atau RSA. JSON ini di-encode Base64Url menjadi bagian pertama token ([sumber](https://www.jwt.io/introduction)). Base64url adalah varian Base64 yang aman untuk URL dan nama file, didefinisikan di RFC 4648 ([sumber](https://www.rfc-editor.org/rfc/rfc4648)).

### Payload

Payload berisi klaim. Pada contoh di atas, `sub` adalah ID user, `name` dan `role` adalah klaim tambahan buatan aplikasi, sedangkan `iat` dan `exp` adalah waktu terbit dan waktu kedaluwarsa. Bagian ini juga di-encode Base64Url. Dokumentasi jwt.io mengingatkan bahwa untuk token bertanda tangan, informasi ini terlindung dari perubahan tetapi bisa dibaca siapa pun, sehingga jangan menaruh informasi rahasia di payload atau header kecuali dienkripsi ([sumber](https://www.jwt.io/introduction)).

### Signature

Signature dibuat dari header dan payload yang sudah di-encode, sebuah secret atau private key, dan algoritma yang tertulis di header ([sumber](https://www.jwt.io/introduction)). Jika satu karakter payload diubah, misalnya `role` diganti, signature tidak lagi cocok dan server wajib menolak token tersebut.

Token terenkripsi (JWE) bentuknya berbeda: RFC 7516 menyebut JWE punya lima segmen yang dipisahkan empat titik ([sumber](https://www.rfc-editor.org/rfc/rfc7516)).

## Klaim Standar di JWT

RFC 7519 mendaftarkan tujuh klaim standar. Semuanya opsional, tetapi maknanya sudah disepakati sehingga library bisa memeriksanya secara otomatis ([sumber](https://www.rfc-editor.org/rfc/rfc7519)). Daftar lengkap klaim yang terdaftar dikelola IANA ([sumber](https://www.iana.org/assignments/jwt/jwt.xhtml)).

| Klaim | Kepanjangan | Arti |
|---|---|---|
| `iss` | Issuer | Pihak yang menerbitkan token |
| `sub` | Subject | Subjek token, misalnya ID user |
| `aud` | Audience | Penerima yang dituju token, misalnya API tertentu |
| `exp` | Expiration Time | Waktu sejak kapan token tidak boleh lagi diterima |
| `nbf` | Not Before | Waktu sebelum kapan token belum boleh diterima |
| `iat` | Issued At | Waktu token diterbitkan |
| `jti` | JWT ID | ID unik token, berguna untuk mencegah pemakaian ulang |

Nilai waktu seperti `exp` dan `iat` ditulis dalam format NumericDate, yaitu jumlah detik sejak 1970-01-01T00:00:00Z UTC ([sumber](https://www.rfc-editor.org/rfc/rfc7519)). Pada contoh token di atas, `iat` 1793577600 berarti 2 November 2026 pukul 00.00 UTC dan `exp` 1793578500 berarti 15 menit setelahnya.

## Cara Kerja JWT Authentication

Alur login berbasis JWT pada aplikasi web dan [API](/blog/api-adalah) berjalan seperti ini:

1. User mengirim username dan password ke endpoint login.
2. Server memeriksa kredensial. Jika benar, server membuat JWT berisi klaim seperti `sub` dan `exp`, lalu menandatanganinya.
3. Klien menyimpan token tersebut.
4. Setiap kali mengakses resource yang dilindungi, klien mengirim JWT di header Authorization dengan skema Bearer ([sumber](https://www.jwt.io/introduction)).
5. Server [backend](/blog/backend-adalah) memverifikasi signature, algoritma, `exp`, `iss`, dan `aud`. Jika semua lolos, request diproses. Jika tidak, server membalas 401.

Format header Bearer berasal dari RFC 6750 untuk OAuth 2.0, contohnya `Authorization: Bearer mF_9.B5f-4.1JqM`. RFC yang sama mewajibkan TLS (HTTPS) saat memakai bearer token ([sumber](https://www.rfc-editor.org/rfc/rfc6750)). Penjelasan header ini juga tersedia di dokumentasi MDN ([sumber](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Authorization)).

Pemeriksaan token bisa dilakukan di setiap layanan atau di satu lapisan [middleware](/blog/middleware-adalah) seperti API gateway, terutama pada arsitektur [microservices](/blog/microservices-adalah) yang punya banyak layanan.

### Di Mana JWT Dipakai?

OWASP mencatat beberapa pemakaian JWT ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html)):

- ID token di OpenID Connect, yang menurut spesifikasi OpenID Connect Core direpresentasikan sebagai JWT ([sumber](https://openid.net/specs/openid-connect-core-1_0.html)).
- Access token OAuth 2.0. Profil access token berformat JWT distandarkan di RFC 9068 (Oktober 2021) ([sumber](https://www.rfc-editor.org/rfc/rfc9068)).
- Sesi user "stateless", pemakaian yang menurut OWASP kurang dianjurkan.
- DPoP proof untuk membuktikan kepemilikan private key, dan JWT-SVID di SPIFFE untuk autentikasi workload.

## JWT vs Session: Mana yang Dipakai?

Session klasik menyimpan data login di server dan hanya memberi browser sebuah ID sesi di cookie. JWT membawa klaimnya sendiri, sehingga server bisa memverifikasi tanpa mencari data sesi. Tabel berikut disusun CDS dari dokumentasi OWASP dan oauth.net:

| Aspek | Session berbasis cookie | JWT |
|---|---|---|
| Tempat data login | Server (database atau cache) | Di dalam token yang dibawa klien |
| Verifikasi | Cari ID sesi di penyimpanan server | Cek signature dan klaim secara lokal |
| Mencabut akses | Hapus sesi di server | Perlu denylist, token status list, atau masa berlaku pendek |
| Cocok untuk | Aplikasi web satu domain | API, aplikasi mobile, antarlayanan, SSO |

oauth.net menyarankan JWT saat resource server perlu memvalidasi token secara lokal tanpa panggilan jaringan, dan token opaque plus introspeksi saat akses perlu bisa dicabut seketika ([sumber](https://oauth.net/2/jwt/)). OWASP mengingatkan, jika JWT dipakai untuk sesi user, Anda butuh cara membatalkan sesi, misalnya denylist token yang dicabut. Begitu denylist dipakai, sesi tidak lagi sepenuhnya stateless, sehingga sistem sesi biasa yang mengikuti panduan OWASP Session Management bisa jadi pilihan yang lebih sederhana ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html), [panduan sesi](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html)).

## JWT Secret dan JWT Expired

### Apa Itu JWT Secret?

JWT secret adalah kunci rahasia untuk algoritma HMAC seperti HS256. Server yang sama memakai secret ini untuk membuat dan memverifikasi signature. Siapa pun yang memegang secret bisa membuat token yang terlihat sah, sehingga secret wajib disimpan di server, tidak masuk repository, dan tidak dikirim ke klien. RFC 8725 meminta kunci punya entropi yang cukup dan menyebut password hanya boleh dipakai untuk enkripsi kunci, bukan sebagai kunci isi ([sumber](https://www.rfc-editor.org/rfc/rfc8725)).

Alternatifnya adalah algoritma kunci publik seperti RS256 atau ES256: penerbit menandatangani dengan private key, dan layanan lain cukup memegang public key untuk memverifikasi.

### Apa Arti JWT Expired?

JWT expired berarti waktu sekarang sudah sama dengan atau melewati nilai klaim `exp`. RFC 7519 menyatakan token tidak boleh diterima untuk diproses pada atau setelah waktu kedaluwarsa itu ([sumber](https://www.rfc-editor.org/rfc/rfc7519)). Pesan seperti "jwt expired" atau "token expired" dari library berarti klien harus login ulang atau meminta token baru lewat mekanisme refresh token yang disediakan server otorisasi. Panduan jwt.io menyarankan agar token tidak disimpan lebih lama dari yang dibutuhkan ([sumber](https://www.jwt.io/introduction)).

## Kesalahan Keamanan JWT yang Perlu Dihindari

RFC 8725 (Februari 2020, BCP 225) adalah panduan praktik terbaik resmi untuk JWT ([sumber](https://www.rfc-editor.org/rfc/rfc8725)). Bersama OWASP, berikut daftar periksanya:

- **Menerima `"alg":"none"`.** OWASP mencatat beberapa library dulu menerima JWT tanpa tanda tangan secara default, sehingga penyerang bisa memalsukan token. Pastikan parser Anda menolaknya ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html)).
- **Tidak mengunci algoritma.** RFC 8725 mewajibkan library membiarkan pemanggil menentukan daftar algoritma yang diizinkan dan tidak memakai algoritma lain. OWASP menjelaskan serangan "algorithm confusion", yaitu public key RS/ES dipakai sebagai secret HMAC untuk memalsukan token.
- **Tidak memeriksa `iss` dan `aud`.** Tanpa pemeriksaan ini, token yang diterbitkan untuk satu layanan bisa diputar ulang ke layanan lain. RFC 8725 menyebutnya substitution attack.
- **Memercayai kunci dari header token.** Parameter seperti `jwk`, `jku`, dan `x5u` adalah input dari penyerang. Ambil kunci verifikasi dari sumber yang sudah dipercaya, misalnya `jwks_uri` milik penerbit.
- **Menaruh data sensitif di payload.** Payload JWT bertanda tangan bisa dibaca siapa pun yang memegang token, termasuk lewat log aplikasi dan penyimpanan browser. Simpan data sensitif di server, atau pakai JWE jika klaim memang harus ikut di token.
- **Menyimpan token di localStorage tanpa pertimbangan.** OWASP HTML5 Security Cheat Sheet menyarankan tidak menyimpan session identifier di local storage karena selalu bisa diakses JavaScript, dan satu celah XSS bisa mencuri semua isinya. Cookie dengan flag HttpOnly bisa mengurangi risiko ini ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html), [RFC 6265](https://www.rfc-editor.org/rfc/rfc6265)).
- **Tidak punya cara mencabut token.** OWASP menyebut Token Status List atau denylist berbasis `jti` dan `iss` sebagai opsi pencabutan ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html)).

Untuk pengujian, PortSwigger Web Security Academy menyediakan materi dan lab serangan JWT yang bisa dipakai tim QA atau security ([sumber](https://portswigger.net/web-security/jwt)).

## JWT dalam Proyek Software

Saat membangun aplikasi web, mobile, atau [integrasi sistem](/blog/integrasi-sistem-adalah), keputusan autentikasi sebaiknya diambil di tahap desain: apakah memakai session cookie, JWT, atau penyedia identitas OpenID Connect, berapa lama token berlaku, dan bagaimana mencabutnya. Hal yang sama berlaku untuk [webhook](/blog/webhook-adalah) dan integrasi antarsistem lain yang juga butuh verifikasi pengirim.

Tim [jasa pembuatan software custom](/services/software) CDS memilih stack teknologi per proyek sesuai kebutuhan, termasuk skema autentikasinya. Untuk sistem yang sudah berjalan, layanan [konsultasi IT](/services/consulting) bisa dipakai untuk audit dan desain ulang arsitektur. Sebagai contoh produk, [Zetta CRM](/incubating/zetta-crm), MCP server berbasis Go yang dikembangkan CDS, diakses lewat endpoint `POST /mcp` dengan API key.

## FAQ Seputar JWT

### JWT adalah singkatan dari apa?

JWT adalah singkatan dari JSON Web Token, standar IETF RFC 7519 untuk membawa klaim antara dua pihak dalam format yang ringkas dan aman untuk URL ([sumber](https://www.rfc-editor.org/rfc/rfc7519)).

### JWT token adalah apa?

JWT token adalah string tiga bagian (header.payload.signature) yang diterbitkan server setelah user login, lalu dikirim klien di setiap request untuk membuktikan identitas dan hak aksesnya.

### Apakah isi JWT bisa dibaca orang lain?

Bisa, untuk JWT bertanda tangan. Header dan payload hanya di-encode base64url, sehingga siapa pun yang memegang token bisa men-decode isinya. Signature hanya mencegah isi diubah ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html)).

### Apa beda JWT dan API key?

API key adalah kunci tetap yang mengidentifikasi aplikasi pemanggil. JWT membawa klaim seperti identitas user dan waktu kedaluwarsa, lalu bisa diverifikasi lewat signature tanpa mencari data di database.

### Berapa lama masa berlaku JWT yang ideal?

RFC 7519 tidak menetapkan angka. Masa berlaku ditentukan per aplikasi lewat klaim `exp`. Prinsip dari jwt.io adalah tidak menyimpan token lebih lama dari yang dibutuhkan ([sumber](https://www.jwt.io/introduction)), lalu memakai refresh token untuk sesi yang lebih panjang.

### Apakah JWT pengganti session?

Tidak harus. JWT cocok untuk API dan antarlayanan, sedangkan untuk sesi user di satu aplikasi web, OWASP mencatat bahwa JWT tetap butuh mekanisme pembatalan sesi, sehingga session biasa bisa lebih sederhana ([sumber](https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_Cheat_Sheet.html)).

## Butuh Sistem Login dan API yang Aman?

Jika aplikasi Anda perlu login user, akses API dari aplikasi mobile, atau integrasi dengan sistem lain, tim CDS bisa merancang skema autentikasi, masa berlaku token, dan pemeriksaannya sejak awal. Mulai dari [jasa pembuatan software custom](/services/software), diskusikan sistem yang sudah ada lewat [konsultasi IT](/services/consulting), atau lihat dulu [karya CDS](/works).


---

*Markdown version of https://www.ciptadusa.com/blog/jwt-adalah — generated for AI agents and LLM crawlers.*