API Key: Kunci Sederhana untuk Integrasi Server

Kunci gudang untuk pemasok

Pemilik toko memberi kunci gudang ke pemasok tetap: sederhana, tidak perlu sidik jari. API key adalah "kunci gudang" untuk integrasi antar server: string acak panjang yang mengidentifikasi siapa yang memanggil API. Cocok untuk cuaca, peta, payment gateway, dan layanan pihak ketiga.

Kenapa API key masih dipakai luas

Tidak semua klien adalah manusia yang bisa login. Cron job, webhook, dan layanan backend butuh kredensial yang simpel, tahan lama, dan mudah dicabut. API key memenuhi semuanya tanpa kompleksitas OAuth. Kelemahannya: siapa pun yang memegang key punya akses penuh, jadi pengamanannya harus disiplin.

Contoh 1: mengirim API key lewat header

GET /api/cuaca?kota=jakarta HTTP/1.1
Host: api.contoh.id
X-API-Key: sk_live_abc123xyz789

const response = await fetch("https://api.contoh.id/cuaca?kota=jakarta", {
  headers: { "X-API-Key": API_KEY }
});

Header kustom (X-API-Key) adalah pola umum, meski sebagian API memakai Authorization: ApiKey .... Jangan taruh di query kecuali dokumentasi memaksa: query tersimpan di log.

Contoh 2: praktik aman di server

const VALID_KEYS = new Set(["sk_live_abc123", "sk_live_def456"]);

app.use("/api", function(req, res, next) {
  const key = req.headers["x-api-key"];
  if (!key || !VALID_KEYS.has(key)) {
    return res.status(401).json({ error: "API key tidak valid" });
  }
  next();
});

Di production, key disimpan hashed di database (seperti password), bukan plain text. Setiap key sebaiknya punya nama/label ("key untuk aplikasi Android") dan tanggal kedaluwarsa agar mudah dilacak saat bocor.

Kesalahan umum

Salah: commit API key ke Git. Key production tersebar di repository publik. Yang benar: simpan di environment variable, tambahkan ke .gitignore, dan cabut key yang terlanjur bocor.

Salah: satu key untuk semua kebutuhan. Bocor satu, semua layanan terdampak. Yang benar: key terpisah per aplikasi/lingkungan dengan izin minimal.

Salah: tidak pernah rotasi. Key dipakai 5 tahun tanpa diganti. Yang benar: rotasi berkala (misalnya tiap 90 hari) dan sediakan masa transisi dua key aktif.

Salah: menampilkan key penuh setelah dibuat. Dashboard menampilkan key kapan pun. Yang benar: tampilkan penuh HANYA sekali saat pembuatan, setelahnya hanya 4 karakter terakhir.

Membedakan key publik vs key privat

Sebagian layanan punya dua jenis key:

• Publishable key (misal pk_live_...): aman dipasang di frontend. Hanya bisa melakukan aksi terbatas (misal membuat token pembayaran, bukan menarik dana).
• Secret key (misal sk_live_...): HANYA di server. Bisa melakukan segalanya.

Aturannya keras: secret key tidak pernah menyentuh browser, tidak pernah masuk ke repository frontend, tidak pernah dikirim ke klien. Kalau secret key bocor, cabut segera dan rotasi. Publishable key bocor? Tidak masalah besar, tapi tetap rotasi.

Catatan teknis: Bedakan API key (identifikasi aplikasi) dengan token user (identifikasi manusia). API key menjawab "aplikasi apa ini?", token menjawab "user siapa ini?". Keduanya bisa dipakai bersamaan.