Menjawab Inti Masalah Middleware Auth Nuxt.js

Jika Anda ingin middleware autentikasi Nuxt.js yang juga memastikan validasi session, artikel ini langsung menyajikan pendekatan praktis: mulai dari struktur middleware yang memeriksa klaim dan session store, pola penyimpanan refresh token, hingga penguatan header dan cookie. Fokusnya adalah memastikan hanya pengguna yang valid tetap bisa mengakses route, sekaligus memudahkan invalidasi ketika logout atau token dicabut.

Struktur Middleware Auth Nuxt.js yang Aman

Nuxt 3 menjalankan middleware pada sisi server (Nitro) dan/atau edge runtime. Middleware auth idealnya dijalankan di server untuk memastikan akses ke session store atau basis data yang aman; untuk edge, gunakan middleware untuk memvalidasi token JWT yang ringan dan tidak perlu panggilan ke DB.

Contoh Middleware Validasi Session

export default defineNuxtRouteMiddleware(async (to, from) => {
  const runtimeConfig = useRuntimeConfig()
  const token = useCookie('session_token').value

  if (!token) {
    return navigateTo('/login')
  }

  const session = await $fetch(`${runtimeConfig.apiBase}/sessions/validate`, {
    method: 'POST',
    headers: { 'Authorization': `Bearer ${token}` }
  })

  if (!session.valid || session.expiresAt < Date.now()) {
    useCookie('session_token').value = null
    return navigateTo('/login')
  }
})

Middleware di atas menunjukkan validasi session via endpoint backend. Pendekatan ini menghindari JWT yang tidak dapat dicabut dan memungkinkan server menyimpan status session lengkap.

Server vs Edge Runtime

  • Server (Nitro/Node): Dapat mengakses basis data atau cache session, cocok untuk mengecek status refresh token, invalidasi, atau rate limiting.
  • Edge: Hanya boleh menjalankan validasi tanda tangan JWT, ideal untuk route yang sensitif terhadap latensi. Gunakan token signed dengan key yang rotasi rutin.

Jika arsitektur Anda memerlukan kedua opsi, funnel traffic dengan dukungan middleware yang memilih jalur berdasarkan environment variable atau header.

Pengelolaan Secret dan Refresh Token

Refresh token sebaiknya disimpan dengan cara yang memungkinkan invalidasi sebelum kadaluarsa. Dua pola utama:

  • Stateful: Simpan refresh token (atau hash-nya) di database/Redis. Setiap refresh request mencocokkan token dan memperbarui timestamp. Ini memudahkan revoke atau logout global.
  • Stateless: Gunakan JWT refresh token dengan klaim dan signature. Namun, tambahkan daftar revoked token atau gunakan short-lived refresh token plus rolling update.

Selalu simpan secret (misalnya key HMAC, client secret) di environment terproteksi atau Vault, bukan di kode.

Pola Penyimpanan Refresh Token

Gunakan storage yang mendukung TTL dan lookup cepat, seperti Redis. Simpan metadata seperti userId, issuedAt, deviceId, lalu buat indeks untuk invalidasi sesi tertentu. Contoh walidasi semacam ini menjaga logout per-device efisien.

Strategi Invalidasi Session

Logout dan revoke harus membersihkan state tidak hanya di sisi klien.

  • Hapus session token dari database dan dari cookie (set null, expired).
  • Jika Anda menyimpan refresh token hash, hapus entry atau tambahkan flag revoked.
  • Pertimbangkan "session revocation list" untuk JWT agar token yang belum kadaluarsa tetap tidak dapat digunakan.
  • Log event logout/revoke untuk audit dan observability.

Hardening Header, Cookie, dan Timeout

Berikut praktek hardening yang memperkecil surface attack:

  • Header: Aktifkan Strict-Transport-Security, Content-Security-Policy (terbatas), X-Frame-Options: DENY, dan Referrer-Policy.
  • Cookie: Set HttpOnly, Secure, SameSite=Strict untuk cookie session. Tambahkan atribut Max-Age sesuai TTL.
  • Timeout: Tetapkan timeout validasi session singkat dan renew token secara berkala. Tangani fallback pada middleware ketika request berulang mengalami timeout.

Hardening ini bekerja karena meminimalkan eksposur token ke skrip dan mitigasikan clickjacking serta sniffing.

Ilustrasi Flow Auth dan Validasi Session

  1. Pengguna login → server mengeluarkan session token (cookie HttpOnly) dan refresh token (HttpOnly atau response body tergantung arsitektur).
  2. Middleware Nuxt.js membaca cookie, memvalidasi session melalui endpoint backend.
  3. Jika perlu refresh, klien memanggil endpoint refresh yang memeriksa refresh token di database dan menerbitkan session baru.
  4. Logout menghapus session & refresh token dari store, middleware selanjutnya akan memaksa redirect login.

Flow ini mendasari keamanan karena setiap akses diaudit dan token dapat dicabut kapan pun.

Observability untuk Deteksi Penyalahgunaan Klaim

Untuk mendeteksi klaim/session abuse, catat metrik dan log berikut:

  • Jumlah validasi session gagal (misalnya karena token mismatch).
  • Frekuensi refresh token dari satu user/device (tanda scraping atau reuse).
  • Trace request dengan klaim berulang dari IP berbeda.

Integrasi dengan tools seperti OpenTelemetry atau middleware logging Nuxt bisa mengirimkan event ke observability stack. Ketika anomali terdeteksi (misalnya refresh token diverifikasi setelah logout), Anda bisa meng-trigger alert dan force revoke.

Checklist Implementasi Middleware Auth Nuxt.js

  • [ ] Middleware memvalidasi session melalui API/DB, tidak hanya mengandalkan cookie.
  • [ ] Refresh token disimpan hashed dan dapat dicabut (logout, rotate).
  • [ ] Header dan cookie sudah di-hardening (Secure, HttpOnly, CSP, HSTS).
  • [ ] Timeout session diatur & diperbarui sesuai aktivitas pengguna.
  • [ ] Observability memonitor invalid login, refresh rate, dan revoke.
  • [ ] Deployment environment (server/edge) diterapkan sesuai kebutuhan latency vs kontrol.
  • [ ] Secret seperti key JWT dikelola lewat Vault atau environment terteam.

Penutup

Middleware auth di Nuxt.js menjadi lebih aman bila Anda menggabungkan validasi session yang stateful, penyimpanan refresh token yang bisa dicabut, hardening header/cookie, serta observability proaktif. Pendekatan berlapis ini membantu menjaga klaim tetap valid dan memudahkan respon saat ada indikasi penyalahgunaan.