Setelah Anda login, bagaimana server mengetahui bahwa setiap permintaan selanjutnya benar-benar dari Anda? Salah satu jawaban yang populer adalah JSON Web Token, atau JWT, biasanya diucapkan “jot”. Ini adalah sepotong kecil data bertanda tangan yang dikirimkan klien dengan setiap permintaan, dan server dapat memeriksanya tanpa menyentuh database.

Cara tercepat untuk memahami JWT adalah dengan membangunnya dan kemudian mencoba memecahkannya. Kami melakukannya hanya dengan menggunakan pustaka standar Python, pada Python 3.13, dan output di bawah ini berasal dari proses tersebut. Kode ini untuk pembelajaran. Dalam aplikasi nyata, gunakan perpustakaan yang terpelihara dengan baik, karena detail verifikasi mudah salah.

Apa itu JWT?

JWT adalah standar terbuka, yang didefinisikan dalam RFC 7519, untuk meneruskan klaim antara dua pihak sebagai rangkaian kompak. Klaim hanyalah sebuah pernyataan, seperti “ID pengguna ini adalah 42”. Karena token ditandatangani, penerima dapat mengonfirmasi siapa yang mengeluarkannya dan tidak ada yang mengubahnya.

Bayangkan sebuah gelang festival. Staf di gerbang memeriksa tiket Anda sekali dan memberi Anda pita yang sulit dipalsukan. Setelah itu, masing-masing kios tinggal melihat bandnya, tidak perlu menelepon loket penjualan tiket. JWT bekerja dengan cara yang hampir sama untuk API.

Cara kerja login JWT

1. Pengguna mengirimkan nama pengguna dan kata sandi ke titik akhir login.
2. Server memeriksanya dan membuat token yang ditandatangani.
3. Klien menyimpan token.
4. Setiap permintaan selanjutnya menyertakannya, biasanya dalam header: Authorization: Bearer <token>.
5. Server memverifikasi tanda tangan dan masa berlakunya, kemudian membaca klaimnya.

Manfaat utamanya ada pada langkah 5. Server tidak perlu mencari sesi, yang berguna ketika banyak layanan atau server perlu memeriksa token yang sama. Jika Anda baru mengenal API, mulailah dengan apa itu API.

Tiga bagian JWT

JWT tampak seperti teks acak, tetapi merupakan tiga bagian berkode URL Base64 yang dipisahkan oleh titik. Ini yang kami hasilkan:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiI0MiIsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzkzNTAwMDAwLCJleHAiOjE3OTM1MDA5MDB9
.7YfUDH_T-iDh8bMmUT8mmKYwOstzT8Ty--DTTAmQGWM

Kami telah menambahkan jeda baris agar lebih mudah dibaca. Menguraikan dua bagian pertama menghasilkan JSON biasa:

Header:  {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"42","role":"user","iat":1793500000,"exp":1793500900}

Klaim standar

Anda juga dapat menambahkan klaim khusus, seperti role. Waktu adalah cap waktu Unix, dalam hitungan detik. Pertahankan muatannya tetap kecil, karena token berpindah dengan setiap permintaan.

Bangun sendiri

Membuat token melibatkan pengkodean dua bagian JSON, dan kemudian menandatanganinya dengan rahasia menggunakan HMAC-SHA256:

import base64, hashlib, hmac, json

SECRET = b"demo-secret-do-not-use-in-production"

def b64url(data):
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode()

def sign(message):
    return b64url(hmac.new(SECRET, message.encode(), hashlib.sha256).digest())

def create_token(payload):
    header = {"alg": "HS256", "typ": "JWT"}
    parts = [
        b64url(json.dumps(header, separators=(",", ":")).encode()),
        b64url(json.dumps(payload, separators=(",", ":")).encode()),
    ]
    message = ".".join(parts)
    return message + "." + sign(message)

Verifikasi bekerja dengan menghitung ulang tanda tangan, dan membandingkannya dengan yang ada di token. Hanya seseorang yang mempunyai rahasia yang dapat menghasilkan rahasia yang cocok:

def verify_token(token, now):
    header, payload, signature = token.split(".")
    expected = sign(header + "." + payload)
    if not hmac.compare_digest(signature, expected):
        raise ValueError("bad signature")
    claims = json.loads(b64url_decode(payload))
    if claims["exp"] < now:
        raise ValueError("token expired")
    return claims

Token yang valid mengembalikan klaimnya seperti yang diharapkan. compare_digest digunakan karena berjalan dalam waktu yang konstan, yang menghindari kebocoran informasi melalui perbedaan waktu.

Cobalah untuk mengutak-atiknya

Misalkan seorang penyerang mendekode payload, mengubah "role":"user" menjadi "role":"admin", mengkodekannya lagi dan mempertahankan tanda tangan lama. Kami mencoba ini, bersama dengan dua serangan lainnya:

Upaya terakhir ini menargetkan kelemahan historis yang nyata. Beberapa perpustakaan pernah mempercayai header token itu sendiri, sehingga penyerang dapat dengan mudah menyatakan bahwa tidak diperlukan tanda tangan. Kode kami selalu menggunakan satu algoritma tetap, itulah sebabnya kode tersebut ditolak. Di perpustakaan nyata, selalu tentukan algoritma yang Anda terima.

Ditandatangani, tidak dienkripsi

Ini adalah poin yang paling disalahpahami tentang JWT. Token palsu kami ditolak, namun isinya masih dapat dibaca dengan sempurna:

{"sub":"42","role":"admin","iat":1793500000,"exp":1793500900}

Base64URL adalah pengkodean, bukan enkripsi, dan siapa pun dapat membalikkannya tanpa kunci sama sekali. Tanda tangan menghentikan orang untuk mengubah data, namun tidak menghentikan membaca data tersebut. Jadi jangan pernah memasukkan kata sandi, nomor kartu, atau data pribadi pribadi ke dalam muatan JWT. Jika isinya harus disembunyikan, gunakan token terenkripsi (JWE), atau simpan saja datanya di server.

HS256 vs RS256

Dengan penandatanganan asimetris, layanan lain dapat memverifikasi token tanpa dapat membuat tokennya sendiri, sehingga membatasi kerusakan jika ada yang disusupi.

JWT vs sesi

JWT sering kali disajikan sebagai pengganti sesi modern. Pada kenyataannya, masing-masing memiliki trade-off:

Untuk situs web tradisional yang dirender oleh server, cookie sesi seringkali lebih sederhana dan lebih aman. JWT cenderung lebih masuk akal untuk API yang digunakan oleh beberapa layanan, atau untuk klien seluler.

Tempat menyimpan token di browser

Banyak panduan keamanan mendukung cookie HttpOnly, Secure, SameSite untuk aplikasi web. Apa pun yang Anda pilih, selalu gunakan HTTPS. Untuk mengirim token dari JavaScript, lihat tutorial JavaScript Fetch API kami.

Segarkan token

Kedaluwarsa yang singkat membatasi kerusakan dari token yang dicuri, tetapi tidak ada yang mau masuk setiap 15 menit. Solusi yang biasa menggunakan dua token:

• Token akses: berumur pendek, seperti menit, dan dikirim bersama setiap permintaan API.
• Segarkan token: berumur lebih panjang, disimpan lebih hati-hati dan hanya digunakan untuk mendapatkan token akses baru.

Server melacak token penyegaran, sehingga dapat mencabutnya, sehingga Anda dapat keluar secara praktis. Memutarnya setiap kali digunakan juga membantu Anda mendeteksi pencurian, karena token lama yang dicuri akan diputar ulang.

Kesalahan keamanan umum

• Decoding tanpa verifikasi. Membaca payload tidak membuatnya dapat dipercaya. Selalu periksa tanda tangannya.
• Menerima algoritme apa pun. Tetapkan daftar eksplisit algoritme yang diizinkan.
• Menggunakan rahasia yang lemah. Rahasia pendek dapat dipecahkan secara offline. Gunakan nilai acak yang panjang, dan jauhkan dari kendali sumber.
• Melewatkan masa berlaku. Token tanpa exp dapat berfungsi selamanya jika dicuri.
• Tidak memeriksa iss dan aud. Jika tidak, token yang diterbitkan untuk satu layanan dapat diterima oleh layanan lain.
• Memercayai klaim yang sudah ketinggalan zaman. Peran di dalam token bisa saja kedaluwarsa hingga habis masa berlakunya.
• Logging token. Siapa pun yang membaca log Anda dapat menggunakannya kembali.
• Tidak menguji jalur kegagalan. Tambahkan pengujian untuk token yang kedaluwarsa dan dimodifikasi, serta yang valid. Panduan Pengujian API dengan Tukang Pos kami dapat membantu.

Penutup

JWT adalah data bertanda tangan yang dapat dipercaya oleh server tanpa pencarian, bukan wadah rahasia dan bukan peningkatan otomatis melalui sesi. Gunakan masa berlaku yang singkat, verifikasi semuanya dengan perpustakaan yang dikelola, dan jauhkan data pribadi dari muatan. Untuk melihatnya sendiri, jalankan skrip kecil seperti milik kami, ubah satu karakter token dan lihat verifikasi gagal.

Pertanyaan yang sering diajukan

Teruslah belajar