Blog

Bayangkan Anda datang ke sebuah festival musik besar. Di pintu masuk, Anda menukarkan tiket dengan sebuah gelang VIP. Gelang itu memiliki nama Anda, area mana saja yang boleh Anda masuki, dan penanda keaslian dari panitia.

Setiap kali Anda ingin masuk ke area panggung utama atau lounge eksklusif, Anda tidak perlu lagi menunjukkan KTP atau tiket asli. Cukup perlihatkan gelang tersebut. Petugas keamanan bisa dengan cepat memverifikasi keasliannya dan mengizinkan Anda masuk. Gelang itu adalah bukti terpercaya identitas dan hak akses Anda selama di festival.

Di dunia digital, terutama dalam pengembangan aplikasi modern, JSON Web Token (JWT) bekerja persis seperti gelang VIP itu.

JWT (dibaca “jot”) adalah sebuah standar terbuka (RFC 7519) yang mendefinisikan cara ringkas dan mandiri untuk mentransmisikan informasi secara aman antara dua pihak sebagai sebuah objek JSON. Informasi ini dapat diverifikasi dan dipercaya karena ditandatangani secara digital.

Mari kita kupas tuntas mengapa “kunci digital” ini begitu fundamental dalam ekosistem teknologi saat ini.

Session vs. Token: Pertarungan Dua Dunia Otentikasi

Sebelum ada JWT, metode paling umum untuk mengelola login pengguna adalah menggunakan Session. Cara kerjanya begini:

1. Anda login dengan username dan password.
2. Server memverifikasi data Anda, lalu membuat sebuah ID unik (Session ID) dan menyimpannya di database server.
3. Server mengirimkan Session ID ini kembali ke browser Anda, biasanya dalam bentuk cookie.
4. Setiap kali Anda membuat permintaan baru (misal: membuka halaman profil), browser akan mengirimkan kembali cookie berisi Session ID. Server akan mencocokkannya dengan data di database untuk mengetahui siapa Anda.

Pendekatan ini disebut stateful, karena server harus “mengingat” atau menyimpan state (status login) dari setiap pengguna aktif. Ini bekerja dengan baik, tetapi menjadi masalah saat aplikasi tumbuh besar dan perlu di-scaling. Bayangkan jika Anda punya 10 server, data session pengguna harus disinkronkan ke semua server tersebut. Repot!

Di sinilah JWT hadir sebagai solusi stateless. Server tidak perlu menyimpan apa pun. Informasi tentang siapa Anda dan apa hak akses Anda sudah terkandung di dalam token itu sendiri, sama seperti gelang VIP tadi yang sudah berisi semua informasi yang dibutuhkan.

Struktur JWT: Membedah Tiga Bagian Kunci

Setiap JWT terdiri dari tiga bagian yang dipisahkan oleh tanda titik (.), yaitu: Header.Payload.Signature.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Mari kita bedah masing-masing bagian:

1. Header (Kepala)

Bagian pertama ini berisi metadata tentang token itu sendiri. Biasanya terdiri dari dua bagian:

• alg: Algoritma signing yang digunakan, misalnya HS256 (HMAC aSHA-256) atau RS256 (RSA).
• typ: Tipe token, yang selalu bernilai JWT.

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

Header ini kemudian di-encode menggunakan Base64Url untuk membentuk bagian pertama dari JWT.

2. Payload (Muatan)

Bagian kedua adalah tempat semua “daging” informasinya berada. Ini berisi claims atau klaim, yaitu pernyataan tentang entitas (biasanya pengguna) dan data tambahan. Ada tiga jenis klaim:

• Registered claims: Klaim yang sudah terstandarisasi seperti iss (issuer/penerbit), exp (expiration time/waktu kedaluwarsa), sub (subject/subjek), aud (audience).
• Public claims: Klaim yang kita definisikan sendiri tetapi harus unik untuk menghindari bentrokan, biasanya dengan menempatkannya dalam sebuah URI.
• Private claims: Klaim kustom yang dibuat untuk berbagi informasi antara pihak-pihak yang menyetujuinya.

{
  "sub": "user-123",
  "name": "Rama Wijaya",
  "role": "admin",
  "iat": 1516239022
}

Sama seperti Header, Payload ini juga di-encode menggunakan Base64Url untuk membentuk bagian kedua dari JWT.

Peringatan Penting: Jangan Simpan Data Sensitif di Payload!

Karena Payload hanya di-encode, bukan dienkripsi, siapa pun dapat men-decode dan membaca isinya. Oleh karena itu, jangan pernah menyimpan informasi sensitif seperti password, nomor kartu kredit, atau data pribadi rahasia di dalam Payload JWT.

3. Signature (Tanda Tangan)

Ini adalah bagian terpenting yang menjamin keamanan dan keaslian token. Tanda tangan ini dibuat dengan cara:

1. Mengambil Header yang sudah di-encode.
2. Mengambil Payload yang sudah di-encode.
3. Menggabungkannya dengan sebuah secret key (kunci rahasia) yang hanya diketahui oleh server.
4. Menjalankan gabungan tersebut melalui algoritma enkripsi yang didefinisikan di Header (misal: HS256).

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  your_secret_key
)

Signature inilah yang digunakan server untuk memverifikasi bahwa token tersebut asli, tidak dimodifikasi di tengah jalan, dan benar-benar dikeluarkan oleh server yang sah. Jika seseorang mencoba mengubah data di Payload, Signature-nya akan menjadi tidak valid.

Kesimpulan: Sebuah Fondasi yang Kokoh

Anda sekarang telah memahami konsep fundamental di balik JWT. Anda tahu bahwa JWT adalah sebuah “kunci digital” stateless yang ideal untuk ekosistem modern seperti microservices dan aplikasi mobile, memecahkan masalah skalabilitas yang sering dihadapi oleh otentikasi berbasis Session.

Anda juga telah membedah anatominya—Header, Payload, dan Signature—serta memahami peran krusial dari setiap bagian, terutama Signature yang menjadi segel keasliannya.

Namun, teori hanyalah langkah pertama. Bagaimana cara kita membuat, mengirim, dan memverifikasi token ini dalam kode nyata? Bagaimana kita menanganinya di sisi client dan server?

Semua pertanyaan praktis itu akan kita jawab tuntas di artikel selanjutnya.

Baca Selanjutnya >> Tutorial JWT: Panduan Langkah-demi-Langkah Membuat dan Memverifikasi Token dengan Node.js & Express