Belajar Fullstack Developer - Multi-Tenancy & Authorization

#Pendahuluan

Sebagian besar produk SaaS akhirnya melayani banyak organisasi dalam satu aplikasi: perusahaan A tidak boleh melihat data perusahaan B. Episode ini membahas multi-tenancy & authorization — model yang memisahkan data antar tenant, dan kontrol akses berbasis peran yang benar di level data.

Kesalahan paling mahal di sini bukan di UI — tombol yang disembunyikan bisa diklik. Kesalahan terjadi di query: ketika satu klien bisa membaca baris milik klien lain karena filter tenant terlewat di satu tempat.

#Model Tenancy: Shared vs Isolated

Dua ujung spektrum, dengan kompromi di tengah:

Mayoritas produk memulai dengan shared (filter organizationId) lalu menawarkan isolated untuk pelanggan enterprise. Kuncinya: keputusan ini memengaruhi skema dari hari pertama — selalu bawa organizationId sejak awal, sulit ditambahkan belakangan.

model Organization {
  id   String @id @default(cuid())
  name String
  notes Note[]
}
 
model Note {
  id             String       @id @default(cuid())
  title          String
  content        String
  organizationId String
  organization   Organization @relation(fields: [organizationId], references: [id])
  @@index([organizationId])
}

#Pola Query yang Aman

Bahaya multi-tenancy adalah query yang "lupa" filter tenant. Dua pola bertahan:

1. Konteks tenant per request — tentukan organisasi aktif dari session, bukan dari input:

"use server"
 
export async function getNotes() {
  const session = await auth()
  const organizationId = session.user.organizationId // dari session, bukan input
  return prisma.note.findMany({ where: { organizationId } })
}

2. Membawa filter di mana-mana — jangan pernah memakai findMany tanpa filter tenant. Untuk menguatkan, service layer atau helper:

export function noteQuery(organizationId: string) {
  return prisma.note.whereTenant(organizationId)
}

Aturan emasnya: filter tenant selalu berasal dari session/source tepercaya, tidak pernah dari parameter request. Jika organizationId diambil dari URL body, penyerang tinggal mengubahnya.

#Row-Level Security (RLS): Jaring Pengaman Terakhir

Bahkan dengan disiplin, satu query yang terlewat sudah cukup. PostgreSQL RLS menambahkan jaring pengaman di level database: baris yang tidak berhak tidak akan pernah kembali, apa pun querynya.

ALTER TABLE "Note" ENABLE ROW LEVEL SECURITY;
 
CREATE POLICY tenant_isolation ON "Note"
  USING (organization_id = current_setting('app.organization_id'));

Kemudian setiap koneksi menetapkan tenant-nya sebelum query:

await prisma.$executeRaw`
  SET app.organization_id = ${organizationId}
`

Jika tenant tidak ditetapkan, current_setting kosong dan query mengembalikan baris apa pun — justru tujuan RLS: default ke tidak ada data.

#Authorization Berbasis Peran (RBAC)

Tenancy memisahkan perusahaan, RBAC memisahkan peran dalam perusahaan — admin, editor, viewer. Modelnya sederhana:

enum Role {
  OWNER
  ADMIN
  EDITOR
  VIEWER
}
 
model OrganizationMember {
  userId         String
  organizationId String
  role           Role
  @@id([userId, organizationId])
}

Hierarki peran (OWNER > ADMIN > EDITOR > VIEWER) diwujudkan dalam helper:

import { Role } from "@prisma/client"
 
const ROLE_LEVEL: Record<Role, number> = {
  OWNER: 4, ADMIN: 3, EDITOR: 2, VIEWER: 1,
}
 
export function can(memberRole: Role, required: Role) {
  return ROLE_LEVEL[memberRole] >= ROLE_LEVEL[required]
}

Dan dipakai di server action — di sisi server, bukan di UI:

"use server"
 
export async function deleteNote(noteId: string) {
  const session = await auth()
  if (!can(session.memberRole, Role.EDITOR)) {
    throw new Error("Kamu tidak punya izin")
  }
  await prisma.note.delete({
    where: { id: noteId, organizationId: session.organizationId },
  })
  revalidatePath("/notes")
}

Perhatikan dua lapis di query delete: filter organizationId (tenancy) dan pengecekan peran (authorization). Keduanya selalu berpasangan.

#Praktik: Aplikasi Multi-Tenant

Selesaikan dengan urutan berikut:

1. Tambahkan model Organization dan OrganizationMember + kolom organizationId di Note.
2. Jalankan migration; tambahkan index organizationId.
3. Ubah semua query dan server action agar memfilter tenant dari session.
4. (Lanjutan) Aktifkan RLS di PostgreSQL dan uji: akun org A tidak bisa baca data org B, bahkan lewat query manual.
5. Terapkan RBAC: OWNER kelola member, EDITOR ubah catatan, VIEWER hanya baca.

curl -s http://localhost:3000/notes -H "Cookie: session=org-a-session"
# data org B tidak boleh muncul, apa pun yang diminta

#Penutup

Inti yang harus dibawa pulang:

• Model tenancy (shared/isolated/hybrid) diputuskan di awal — selalu bawa organizationId sejak hari pertama.
• Filter tenant dari session, tidak pernah dari input request; disiplin di semua query.
• RLS PostgreSQL sebagai jaring pengaman terakhir di level database.
• RBAC memisahkan peran dalam organisasi; cek peran di server, bukan hanya sembunyikan tombol.
• Tenancy + authorization selalu berpasangan di setiap query mutasi.

Di episode 20 selanjutnya kita membahas privacy & compliance — GDPR, cookie consent, dan penanganan data pengguna yang benar. Sampai jumpa di episode 20!