Pendahuluan

Validasi Token Otentikasi menjadi garis pertahanan pertama API Gateway. Dalam artikel ini langsung dibahas langkah konkret: bagaimana API Gateway memeriksa token, memastikan secret tetap aman, menangani sesi, serta mitigasi kasus upload dan penyalahgunaan.

Strategi yang dijabarkan dapat diterapkan pada gateway yang mendukung middleware, plugin, atau lambda authorizer—selama ia mampu memeriksa header Authorization, memanggil store untuk secret, dan menerapkan aturan rate limit.

1. Validasi Token Otentikasi di GateWay

1.1. Asumsi Token

PUT API Gateway harus memeriksa token yang dikirim dalam header Authorization. Strategi paling umum adalah JWT atau token reference (opaque). Gateway wajib:

  • Membaca header Authorization: Bearer <token>
  • Memanggil penyedia identitas (jika JWT) untuk memverifikasi signature dan claim.
  • Untuk opaque token, memanggil service introspeksi atau cache token aktif sebelum meneruskan.

1.2. Contoh Mekanisme Validasi

Implementasi di gateway berbasis Lua atau plugin Node bisa memanggil store. Contoh sederhana validasi JWT di middleware API Gateway:

function validate(ctx)
  local token = ctx.request.headers['authorization']
  if not token then return {status=401, body='Missing token'} end
  local payload, err = jwt.decode(token)
  if not payload or err then return {status=401, body='Invalid token'} end
  if payload.exp < ngx.time() then return {status=401, body='Expired token'} end
  ctx.auth = payload
  return nil
end

Menambahkan caching kunci publik (public key) membantu performa. Pastikan gateway meng-cache key dengan TTL pendek agar rotasi key tetap efektif.

2. Rotasi Secret dan Proteksi Rahasia GateWay

2.1. Rotasi Key/Secret

API Gateway harus mengantisipasi rotasi key. Pendekatan:

  1. Gunakan key ID (kid) di header JWT.
  2. Gateway menyimpan beberapa versi kunci publik/secret terhadap kid.
  3. Untuk rotasi, tambahkan key baru, update client, lalu hapus key lama setelah grace period.

Tanpa key ID, gateway perlu mencoba memverifikasi dengan semua secret yang mungkin—ini harus dihindari karena mempengaruhi performa.

2.2. Penyimpanan Rahasia

Jangan taruh secret di file konfigurasi terbuka. Gunakan secret manager (Vault, AWS Secrets Manager) dan mekanisme pull aman. Gateway harus:

  • Memuat secret secara dinamis saat start dan refresh berkala.
  • Menyimpan secret dalam memory terproteksi, bukan log.

Jika gateway menggunakan container, pastikan secret tidak ada di image layer.

3. Menangani Session & Penanganan Refresh/Blacklist

3.1. Session Transparan di API Gateway

Gateway bisa menyimpan state sesi minimal: token ID, expiry, status blacklist. Untuk token reference, gateway memeriksa store session (Redis, in-memory) sebelum meneruskan.

3.2. Mekanisme Refresh dan Blacklist

Untuk refresh token, gateway hanya menerima access token yang valid—refresh process tetap dibatasi ke auth server.

Ditambahkan juga blacklist yang disimpan di store cepat:

  • On logout atau revoke: tambahkan token ID ke blacklist dengan TTL sesuai sisa expiry.
  • Blacklist di-cache di gateway; expire entry otomatis atau dipanggil secara periodik.

Pastikan gateway tidak hanya memeriksa expiry namun juga blacklist, karena token bisa dicabut sebelum selesai masa hidupnya.

4. Proteksi Upload dan Rate Limiting

4.1. Kontrol Upload

Upload harus melewati gateway sebelum service backend. Implementasi:

  • Batasi tipe file/size di gateway.
  • Gunakan streaming langsung ke storage (misalnya signed URLs) agar gateway tidak menangani payload besar.
  • Verifikasi token yang mengotorisasi upload dan tambahkan per-user quota.

Gateways modern mendukung chunked upload monitoring. Pastikan gateway memblokir content-type yang tidak diharapkan.

4.2. Rate Limit dan Abuse Monitoring

Rate limit harus berdasarkan identitas token, bukan hanya IP.

Contoh strategi:

  • Limit per token/organisasi per endpoint atau metode (misalnya 100 req/menit). Gunakan counter di Redis dengan expiry.
  • Tambahkan throttle incremental: penalti sementara jika limit terlampaui.
  • Monitoring: kirimkan alert saat bot traffic di atas threshold per token.

Pastikan gateway menghasilkan header limit (X-RateLimit-Remaining) agar client dapat menyesuaikan.

5. Monitoring Abuse dan Debugging

Gunakan metric dan log di gateway untuk memonitor:

  • Jumlah 401/403 per endpoint.
  • Latency validasi token.
  • Blacklist hits.

Jika terjadi false positive (valid token dianggap invalid), periksa:

  1. Server time drift (untuk JWT).
  2. Konsistensi kid dan kunci publik.
  3. Ketersediaan store session atau cache.

Gunakan distributed tracing untuk melihat path token validasi sebelum diteruskan ke backend.

6. Checklist Implementasi oleh Tim Backend

  • Pastikan semua API melewati gateway yang memvalidasi Authorization header.
  • Terapkan caching key/secret dengan mekanisme rotasi (kid + grace period).
  • Implementasikan blacklist session di store cepat dan verifikasi di gateway.
  • Batasi upload di gateway dengan ukuran, tipe, dan autentikasi eksplisit.
  • Aktifkan rate limit per token serta throttle dan header limit.
  • Monitor 401/403 abnormal, hit blacklist, dan expired token.
  • Siapkan proses refresh token terpisah dan revocation endpoint.
  • Dokumentasikan BCP saat secret perlu di-rotate atau disusupi.

Dengan pendekatan ini, API Gateway tidak hanya meneruskan request, tetapi juga menjadi enforcement point yang solid untuk otentikasi, proteksi session, dan deteksi abuse.