Autentikasi & Akses - Dari JSON ke JWT, Menyusun RBAC yang Aman dan Skalabel

Autentikasi & Akses - Dari JSON ke JWT, Menyusun RBAC yang Aman dan Skalabel

• ✅ 1. Pendahuluan
• ✅ 2. Memahami Konsep Dasar
• ✅ 3. Urutan Evolusi Mekanisme Penyimpanan Identitas & Role
• ✅ 4. Token vs Session: Perbandingan Praktis
• ✅ 5. Apakah Token dan Session Bisa Digabung?
• ✅ 6. Alternatif Selain Token & Session dalam RBAC
  • 🧰 Alternatif Implementasi RBAC (Selain Session & Token)
• ✅ 7. Kombinasi Mekanisme: Mana yang Masuk Akal?
  • 🔧 Kombinasi Realistis dan Praktik Umum
  • 🚫 Kombinasi yang Tidak Efektif atau Bermasalah
  • 🧭 Prinsip Pemilihan Kombinasi Mekanisme
• ✅ 8. Klarifikasi Penting: Apakah JWT Bisa Berdiri Sendiri?
• ✅ 9. Rekomendasi Arsitektur RBAC untuk Proyek Monorepo Modern
• ✅ 10. Panduan Praktis: Memilih Pendekatan Otentikasi & RBAC
• ✅ 11. Kesimpulan
• ✅ 12. Referensi & Resource Lanjutan
• > ✨ BONUS
  • 🧭 Diagram Arsitektur JWT + RBAC (Monorepo di Vercel)
  • 🔐 Checklist Keamanan Implementasi Auth

✅ 1. Pendahuluan

Dalam pengembangan sistem modern—baik aplikasi web, layanan backend, maupun solusi berbasis IoT—manajemen hak akses pengguna menjadi aspek krusial yang tidak dapat diabaikan. Salah satu pendekatan paling umum dan efektif untuk mengatur hak akses ini adalah Role-Based Access Control (RBAC).

RBAC adalah model otorisasi yang memberikan hak akses berdasarkan peran (role) yang dimiliki oleh pengguna dalam sistem. Alih-alih menetapkan izin individu secara langsung, RBAC menyederhanakan proses kontrol akses dengan mengelompokkan hak akses ke dalam role, yang kemudian diterapkan ke satu atau lebih pengguna. Pendekatan ini membantu menjaga konsistensi, skalabilitas, dan keamanan dalam manajemen akses, terutama pada sistem yang memiliki banyak pengguna dan kompleksitas fungsional.

Namun dalam praktiknya, banyak pengembang pemula yang mengalami kebingungan saat mencoba mengimplementasikan RBAC. Beberapa pertanyaan umum yang sering muncul antara lain:

• Apa perbedaan antara otentikasi (authentication) dan otorisasi (authorization)?
• Kapan sebaiknya menggunakan session dan kapan menggunakan token (JWT)?
• Bagaimana menyimpan data user dan peran dengan benar dalam sistem berbasis serverless seperti di Vercel?
• Apakah ada alternatif lain selain session dan token untuk pengelolaan akses?
• Bagaimana mengkombinasikan berbagai pendekatan secara aman dan efisien?

Artikel ini disusun untuk menjawab semua pertanyaan tersebut secara menyeluruh dan terstruktur. Disusun berdasarkan percakapan teknis yang berkembang dari dasar hingga praktik lanjut, artikel ini bertujuan menjadi referensi tunggal (one-stop reference) yang dapat digunakan oleh pengembang muda dalam memilih dan mengimplementasikan strategi autentikasi dan RBAC yang tepat untuk aplikasinya.

Dengan mengikuti alur artikel ini, pembaca akan memperoleh pemahaman mendalam tentang:

• Konsep fundamental RBAC dan kaitannya dengan otentikasi,
• Evolusi berbagai mekanisme penyimpanan identitas dan role,
• Perbandingan token dan session dalam konteks praktis,
• Kombinasi yang umum digunakan dalam sistem nyata,
• Rekomendasi arsitektur untuk proyek berbasis monorepo modern.

Artikel ini menggunakan pendekatan berbasis kasus nyata dan teknologi kontemporer seperti Next.js, serverless hosting (Vercel), dan pengembangan modular berbasis monorepo, agar dapat langsung diterapkan dalam proyek pengembangan modern.

✅ 2. Memahami Konsep Dasar

Sebelum memahami bagaimana RBAC diterapkan secara teknis, penting untuk memahami dasar konsepnya terlebih dahulu—terutama perbedaan antara role, permission, serta bagaimana RBAC dibandingkan dengan model kontrol akses lainnya.

🔹 2.1 Apa Itu RBAC?

Role-Based Access Control (RBAC) adalah model kontrol akses di mana izin (permissions) diberikan kepada pengguna berdasarkan peran (roles) yang mereka miliki dalam sistem. Alih-alih menetapkan izin langsung kepada setiap individu, RBAC menyederhanakan pengelolaan hak akses dengan cara mengasosiasikan izin ke dalam peran, dan menetapkan peran tersebut ke pengguna.

Struktur dasar RBAC terdiri dari tiga entitas utama:

1. User – Representasi entitas yang mengakses sistem (manusia atau mesin).
2. Role – Kumpulan dari satu atau lebih permission, mencerminkan fungsi atau posisi dalam organisasi atau sistem (contoh: admin, editor, viewer).
3. Permission – Hak akses terhadap suatu aksi atau resource, seperti read:report, write:user, delete:entry.

Sebuah user dapat memiliki satu atau lebih role, dan masing-masing role menentukan kumpulan permission yang tersedia bagi user tersebut.

📘 Contoh RBAC:

Misalnya dalam sistem manajemen konten:

• Role admin memiliki permission: create:post, edit:post, delete:post.
• Role editor hanya memiliki permission: edit:post.
• Role viewer hanya memiliki permission: read:post.

🔄 RBAC vs ABAC vs ACL

• ACL (Access Control List) mengikat izin ke objek/resource.
• ABAC (Attribute-Based Access Control) menggunakan berbagai atribut dinamis (misal: waktu, lokasi, status akun).
• RBAC seimbang antara kesederhanaan dan skalabilitas, menjadikannya model paling banyak digunakan dalam aplikasi bisnis dan sistem terdistribusi.

🔑 Keunggulan RBAC:

• Mudah dipahami dan diterapkan
• Konsisten dan terstandarisasi
• Memudahkan audit dan pengelolaan izin massal
• Cocok untuk aplikasi yang melibatkan banyak pengguna dan struktur organisasi

🔹 2.2 Peran Otentikasi dalam RBAC

Agar RBAC dapat berjalan, sistem harus terlebih dahulu mengetahui siapa pengguna yang sedang mengakses aplikasi. Di sinilah peran otentikasi menjadi sangat penting.

Otentikasi (authentication) adalah proses verifikasi identitas pengguna—biasanya dengan username dan password, token OAuth, atau metode lain. Setelah pengguna berhasil diotentikasi, sistem baru dapat:

1. Menentukan role apa yang dimiliki oleh pengguna tersebut,
2. Menetapkan hak akses sesuai role melalui mekanisme RBAC.

Tanpa otentikasi, RBAC tidak dapat diterapkan karena sistem tidak bisa memverifikasi identitas dan peran pengguna.

📌 Ilustrasi Sederhana:

1. 🔐 User "andi" login dengan kredensial → berhasil diverifikasi → sistem mengenali bahwa "andi" memiliki role: editor.
2. 🎯 Sistem mengevaluasi request: "andi" ingin delete:post → RBAC mengecek role editor → tidak punya permission → akses ditolak.

🎯 Kenapa Ini Penting?

• Otentikasi menentukan siapa yang sedang menggunakan sistem.
• RBAC menentukan apa yang boleh dilakukan pengguna tersebut.
• Kombinasi keduanya membentuk sistem keamanan yang efektif dan terstruktur.

✅ 3. Urutan Evolusi Mekanisme Penyimpanan Identitas & Role

Dalam implementasi RBAC, data identitas pengguna (user) dan peran (role) perlu disimpan, dikelola, dan diakses saat proses otentikasi maupun otorisasi berlangsung. Seiring dengan meningkatnya kebutuhan keamanan, skalabilitas, dan kompleksitas sistem, mekanisme penyimpanan dan pengelolaan data identitas ini juga berkembang.

Berikut adalah urutan evolusi dari mekanisme paling sederhana hingga yang paling kompleks dan aman dalam konteks penyimpanan identitas dan role.

🔢 1. File JSON (Statik, Sederhana)

• Data user dan role disimpan dalam file .json statis di dalam proyek.
• Umumnya digunakan untuk prototipe, pengujian lokal, atau aplikasi kecil tanpa database.

📌 Contoh struktur:

[
  { "username": "admin", "password": "hashed_password", "role": "admin" },
  { "username": "user", "password": "hashed_password", "role": "viewer" }
]

✅ Kelebihan: cepat, mudah di-setup ❌ Kekurangan: tidak dinamis, tidak aman untuk produksi

🔢 2. Database (Relasional/NoSQL)

• Identitas dan role pengguna disimpan dalam database (PostgreSQL, MySQL, MongoDB, dsb).

• Skema umum:

  • users table: menyimpan data user
  • roles table: mendefinisikan role
  • (opsional) user_roles atau permissions table untuk granular control

✅ Kelebihan: fleksibel, dinamis ❌ Kekurangan: perlu query setiap kali, stateful jika digunakan dengan session

🔢 3. Session (Stateful, Server-Side)

• Setelah login, server menyimpan informasi user dan role di memori/session store.
• Klien hanya menyimpan session ID dalam cookie.
• Digunakan di banyak framework tradisional (Laravel, Rails, Express.js, dsb).

✅ Kelebihan: data aman di server ❌ Kekurangan: tidak cocok untuk arsitektur stateless/serverless, butuh session store (Redis, database)

🔢 4. JWT (JSON Web Token)

• Setelah login, server menghasilkan token yang memuat data user dan role.
• Token dikirim ke client dan digunakan untuk setiap request (biasanya melalui header Authorization).
• Tidak perlu simpan session di server (stateless).

✅ Kelebihan: scalable, cocok untuk SPA dan serverless ❌ Kekurangan: data ada di sisi client, token tidak bisa dicabut sebelum kadaluarsa

🔢 5. JWT + Refresh Token + Revoke

• Kombinasi dari access token (umur pendek) dan refresh token (umur panjang).
• Refresh token disimpan di database agar bisa di-revoke jika dibutuhkan.
• Cocok untuk sistem dengan kebutuhan logout, rotasi token, dan kontrol granular.

✅ Kelebihan: aman, fleksibel, mendukung logout ❌ Kekurangan: implementasi lebih kompleks

🔢 6. OAuth2 / OpenID Connect (SSO, Delegasi)

• Sistem memanfaatkan penyedia identitas eksternal (Google, GitHub, Auth0, dsb).
• Tidak perlu menyimpan kredensial user sendiri.
• Role bisa ditentukan dari provider atau dipetakan secara lokal.

✅ Kelebihan: cocok untuk SSO dan federated login ❌ Kekurangan: bergantung pada provider pihak ketiga, perlu setup tambahan

🔢 7. Policy Engine (OPA, Casbin)

• Pengambilan keputusan otorisasi dilakukan melalui policy engine eksternal.
• Role, permission, dan logic disimpan dalam format policy (misalnya: Rego untuk OPA).
• Cocok untuk ABAC dan sistem dengan kontrol akses kompleks.

✅ Kelebihan: sangat fleksibel, audit trail, cocok untuk microservices ❌ Kekurangan: learning curve, integrasi tambahan

🔢 8. mTLS (Mutual TLS Certificate Auth)

• Identitas pengguna disimpan dan diverifikasi melalui sertifikat digital (X.509).
• Role bisa ditentukan dalam field sertifikat (misal: Subject atau SAN).
• Digunakan di sistem enterprise atau antar perangkat (misalnya IoT).

✅ Kelebihan: keamanan sangat tinggi, tidak butuh token atau password ❌ Kekurangan: sangat kompleks, perlu sistem manajemen sertifikat

📊 Tabel Perbandingan Mekanisme

🧭 Ringkasan

• Tidak ada satu solusi yang cocok untuk semua kasus.
• Pendekatan yang paling sederhana bisa menjadi titik awal belajar.
• Semakin besar sistem, semakin dibutuhkan mekanisme yang scalable dan aman.
• Kombinasi beberapa metode (misal: database + JWT + refresh) sering kali menjadi solusi terbaik dalam sistem nyata.

✅ 4. Token vs Session: Perbandingan Praktis

Setelah memahami berbagai mekanisme penyimpanan identitas dalam konteks autentikasi dan otorisasi, kini saatnya membedakan dua pendekatan yang paling umum digunakan dalam praktik modern, yaitu Session dan Token (JWT).

Meskipun keduanya berfungsi untuk menjaga status autentikasi pengguna setelah login, keduanya memiliki karakteristik yang berbeda secara mendasar, baik dari sisi arsitektur, penyimpanan, keamanan, maupun skalabilitas.

🔹 4.1 Apa itu Session?

Session adalah mekanisme autentikasi berbasis server-side. Setelah pengguna berhasil login, server membuat sesi (session) dan menyimpan informasi pengguna (biasanya ID dan role) di dalam session store (misalnya in-memory, Redis, atau database). Klien (browser) kemudian menyimpan session ID dalam bentuk cookie, yang akan dikirim secara otomatis pada setiap permintaan selanjutnya.

📌 Karakteristik Session:

• Penyimpanan data: di server (dalam session store)
• Klien hanya menyimpan session ID (bukan data pengguna)
• Umumnya digunakan dalam aplikasi server-rendered (SSR) atau tradisional

🔒 Kelebihan:

• Data sensitif tidak pernah dikirim ke klien
• Mudah untuk mencabut akses (logout, invalidate session)
• Sangat aman jika dijalankan di infrastruktur yang konsisten

⚠️ Kekurangan:

• Stateful: membutuhkan penyimpanan di sisi server
• Tidak cocok untuk arsitektur serverless seperti Vercel
• Sulit diskalakan secara horizontal tanpa session store bersama

🔹 4.2 Apa itu Token (JWT)?

Token, dalam konteks ini merujuk pada JWT (JSON Web Token), adalah pendekatan autentikasi stateless. Setelah pengguna login, server menghasilkan JWT yang menyimpan informasi identitas pengguna (termasuk role, permission, dan waktu kadaluarsa). Token ini dikirim ke klien dan digunakan untuk setiap permintaan berikutnya, biasanya melalui header Authorization: Bearer <token>.

📌 Karakteristik JWT:

• Penyimpanan data: di dalam token (klien)
• Token dikirim pada setiap permintaan untuk divalidasi
• Tidak memerlukan penyimpanan status di server

🔒 Kelebihan:

• Stateless: tidak perlu session store
• Mudah digunakan di arsitektur serverless, API-first, dan SPA
• Dapat digunakan lintas domain dan lintas platform (web, mobile, IoT)

⚠️ Kekurangan:

• Jika bocor, token bisa digunakan sampai kadaluarsa (kecuali sistem revocation diterapkan)
• Token harus dikelola dengan hati-hati (risiko XSS, CSRF)
• Tidak bisa dicabut secara instan tanpa mekanisme tambahan (misal refresh + revoke)

🔹 4.3 Tabel Perbandingan Langsung

🎯 Kapan Menggunakan Session vs Token (JWT)?

🧭 Catatan Praktis

• Di platform seperti Vercel atau Cloudflare Workers, session berbasis memory tidak dapat digunakan karena sifat stateless dan ephemeral dari serverless function.

• Untuk penggunaan aman dengan JWT, disarankan menggunakan:

  • HttpOnly cookie (untuk menghindari XSS)
  • Refresh token dan token rotasi
  • Middleware validasi role/permission setiap request

🧩 Kesimpulan

Session dan JWT memiliki kelebihan masing-masing tergantung pada kebutuhan arsitektur dan keamanan aplikasi. Untuk pengembangan modern, terutama dengan monorepo berbasis Next.js dan serverless hosting, JWT adalah pendekatan yang lebih cocok karena stateless, scalable, dan fleksibel. Namun, dalam sistem monolitik atau ketika kontrol sesi diperlukan sepenuhnya dari sisi server, session masih merupakan pilihan yang valid.

✅ 5. Apakah Token dan Session Bisa Digabung?

Dalam praktik pengembangan sistem modern, kebutuhan akan fleksibilitas, keamanan, dan interoperabilitas sering kali mendorong pengembang untuk tidak terpaku pada satu pendekatan otentikasi tertentu. Kombinasi antara session dan token dalam satu sistem bukan hanya dimungkinkan, tetapi juga cukup umum dalam arsitektur yang kompleks dan distribusi.

🔄 Model Hybrid: Session + Token

Model hybrid menggabungkan keamanan dan kontrol session dengan fleksibilitas dan portabilitas token. Pendekatan ini memanfaatkan kekuatan masing-masing teknik, yaitu:

• Session untuk menyimpan data sensitif secara aman di sisi server (misalnya token akses dari OAuth provider).
• Token (JWT) sebagai sarana otentikasi stateless di klien atau antar layanan (API → API, device → backend).

Dengan cara ini, sistem tetap dapat menjaga keamanan data pengguna sambil mendukung arsitektur modern yang memerlukan autentikasi lintas platform atau stateless.

🧩 Contoh Skema Hybrid yang Umum:

1. User login melalui UI frontend (misal: Next.js SPA).

2. Server backend memverifikasi kredensial dan mendapatkan token akses dari OAuth provider (jika ada).

3. Server:

   • Menyimpan access token dalam session (di server, aman).
   • Menyimpan identitas pengguna (user ID, role) dalam session cookie yang aman (HttpOnly).

4. Pada saat client melakukan request ke API internal:

   • Backend membaca session → mengekstrak access token atau role → meneruskan sebagai JWT jika dibutuhkan oleh service downstream.

📦 Use Case Hybrid: Next.js dengan NextAuth.js

Pada NextAuth.js, secara default:

• Otentikasi dilakukan melalui OAuth/OIDC (misal: Google).
• Access token dari provider disimpan di server-side session.
• Informasi pengguna (termasuk role) bisa diakses melalui getSession() di sisi server.
• Jika perlu, kita bisa generate JWT internal berdasarkan data session untuk digunakan antar layanan (misalnya API terpisah, IoT device, atau worker).

📉 Arsitektur In-Series di Lingkungan Serverless

Model hybrid juga bermanfaat dalam arsitektur serverless dan modular monorepo, seperti di Vercel. Contoh alur:

1. Frontend SPA hanya menyimpan session cookie (HttpOnly).

2. API handler membaca session → memverifikasi identitas.

3. API handler menghasilkan JWT internal yang:

   • Dipakai untuk komunikasi antar plugin/module (misal: /plugins/notify)
   • Digunakan oleh perangkat IoT atau mobile client
   • Dikirim ke layanan eksternal dengan role tersemat

📌 Dalam skenario ini:

• Session digunakan untuk keamanan sisi pengguna (UI/SSR)
• JWT digunakan untuk komunikasi service-to-service, IoT-to-API

✅ Keuntungan Pendekatan Hybrid

⚠️ Tantangan & Catatan

• Perlu manajemen yang jelas antara data yang disimpan di session dan di dalam token.
• Jangan menyimpan akses token sensitif di klien meskipun memakai JWT.
• Hindari redundansi: pastikan session dan token tidak menyimpan data yang saling bertentangan.

📘 Studi Kasus Penerapan Hybrid

/mx-core
├── /frontend     → Next.js SPA, menggunakan session cookie
├── /backend      → API handler, baca session + hasilkan JWT untuk plugin
├── /plugins
│   └── /iot      → Butuh JWT untuk autentikasi perangkat ke API

Pada alur ini:

• User login via frontend → session cookie tersimpan
• API /backend/auth/create-token → membaca session, lalu membuat JWT untuk IoT device
• JWT dikirim ke plugin /plugins/iot dan digunakan sebagai auth header

🧩 Kesimpulan

Session dan token tidak harus saling menggantikan. Dalam sistem yang kompleks, mereka dapat berjalan berdampingan untuk mendukung kebutuhan keamanan dan fleksibilitas yang berbeda:

• Session: penyimpanan aman, kontrol penuh dari sisi server.
• JWT: interoperabilitas, komunikasi lintas layanan atau platform.

Model hybrid memungkinkan pengembang menggabungkan manfaat keduanya, dan sangat cocok untuk aplikasi modern berbasis Next.js, serverless, dan microservice/IoT-ready.

✅ 6. Alternatif Selain Token & Session dalam RBAC

Dalam praktik pengembangan sistem otentikasi dan otorisasi, terdapat kesalahpahaman umum di kalangan pengembang pemula bahwa RBAC (Role-Based Access Control) identik atau hanya dapat diimplementasikan menggunakan session atau token (misalnya JWT).

Namun sebenarnya, RBAC adalah model otorisasi, bukan metode autentikasi atau penyimpanan identitas. Session dan token hanyalah mekanisme penyimpanan status autentikasi, yang dapat mendukung penerapan RBAC—tetapi bukan satu-satunya cara.

🔁 RBAC ≠ Session/Token

RBAC menjawab pertanyaan: "Apa yang boleh dilakukan oleh pengguna dengan role tertentu?" Session/token menjawab: "Siapa pengguna ini, dan bagaimana kita menyimpan statusnya?"

Dengan demikian, RBAC bisa diintegrasikan ke berbagai pendekatan autentikasi lain di luar session dan token, termasuk pendekatan yang lebih cocok untuk sistem enterprise, IoT, atau infrastruktur microservice.

🧰 Alternatif Implementasi RBAC (Selain Session & Token)

1️⃣ API Key

• API Key adalah string unik yang mewakili identitas pengguna atau aplikasi.
• Sering digunakan dalam sistem IoT, integrasi antar aplikasi, atau public API.

📌 Implementasi RBAC:

• Role atau scope dapat dikaitkan langsung dengan API key di database.
• Setiap request membawa header X-API-Key → sistem cek role berdasarkan key.

✅ Ringan, cocok untuk sistem otomatis ❌ Kurang aman jika key bocor; sulit dicabut tanpa rotasi manual

2️⃣ OAuth2 / OpenID Connect (OIDC)

• Protokol otentikasi & otorisasi standar untuk delegasi akses (SSO).
• User login melalui provider (Google, GitHub, Auth0, dsb).
• Token akses (access token) berisi scope dan dapat dimapping ke role.

📌 Implementasi RBAC:

• Gunakan scope atau claims dari token untuk menentukan role/permission.
• Bisa dipadukan dengan role lokal untuk kontrol lebih granular.

✅ SSO, aman, tidak perlu menyimpan password ❌ Perlu integrasi tambahan dan konfigurasi mapping role

3️⃣ LDAP / Active Directory (SSO Enterprise)

• Sistem otentikasi terpusat yang umum digunakan di perusahaan besar.
• User dan grup disimpan dalam direktori (misalnya Microsoft AD, OpenLDAP).

📌 Implementasi RBAC:

• Role ditentukan berdasarkan grup di LDAP.
• Sistem aplikasi membaca role dari hasil login LDAP.

✅ Cocok untuk organisasi besar, integrasi internal ❌ Kompleks, bergantung pada sistem eksternal

4️⃣ ABAC (Attribute-Based Access Control)

• ABAC menggunakan atribut untuk menentukan hak akses, bukan hanya role.
• Atribut bisa berupa departemen, lokasi, level keamanan, waktu akses, dsb.

📌 Contoh policy:

{
  "department": "finance",
  "clearance": 3
}

Akses diberikan jika department === "finance" dan clearance >= 2.

✅ Fleksibel dan kontekstual ❌ Lebih kompleks dibanding RBAC; sulit diaudit jika tidak dikelola dengan baik

5️⃣ mTLS (Mutual TLS Authentication)

• Otentikasi berbasis sertifikat digital (X.509).
• Digunakan untuk komunikasi antar sistem atau perangkat (machine-to-machine).

📌 Implementasi RBAC:

• Role atau scope ditentukan dari field dalam sertifikat (misalnya SAN atau OU).
• Server memverifikasi sertifikat klien sebelum memberi akses.

✅ Sangat aman, cocok untuk sistem internal & IoT ❌ Perlu sistem manajemen sertifikat (PKI); tidak cocok untuk user interface

6️⃣ Policy Engine (OPA, Casbin, etc.)

• Otorisasi dipisahkan dari aplikasi utama dan didelegasikan ke policy engine.
• Logic kontrol akses ditulis sebagai policy (misal: Rego di OPA).

📌 Implementasi RBAC:

• Aplikasi mengirimkan user context ke policy engine
• Policy engine menentukan apakah akses diperbolehkan

✅ Modular, auditable, cocok untuk microservices ❌ Perlu integrasi dan learning curve

📊 Tabel Perbandingan Alternatif Implementasi

🧭 Kapan Menggunakan Masing-Masing?

🧩 Kesimpulan

RBAC tidak terbatas pada token atau session. Berbagai mekanisme autentikasi lain dapat menjadi fondasi implementasi RBAC yang sesuai dengan konteks dan kebutuhan sistem. Yang penting adalah bagaimana sistem dapat:

1. Mengidentifikasi pengguna (otentikasi)
2. Menentukan role atau atribut terkait pengguna
3. Mengambil keputusan otorisasi berbasis role atau policy

Dalam praktik modern, tidak jarang sistem menggunakan kombinasi dari beberapa pendekatan untuk memenuhi kebutuhan yang berbeda—misalnya OAuth2 untuk login, Policy Engine untuk akses internal, dan JWT untuk komunikasi antar layanan.

✅ 7. Kombinasi Mekanisme: Mana yang Masuk Akal?

Setelah memahami berbagai pendekatan dalam menyimpan dan mengelola identitas serta role pengguna, pertanyaan berikutnya adalah:

"Bolehkah atau perlukah kita menggabungkan beberapa mekanisme dalam satu sistem?"

Jawabannya: ya, sangat boleh, bahkan dalam banyak kasus, penggabungan metode (kombinasi) justru menjadi solusi terbaik untuk menjawab kebutuhan nyata di dunia pengembangan aplikasi modern.

Namun, penting untuk mengetahui kombinasi mana yang masuk akal, mana yang berlebihan atau membingungkan, serta bagaimana memilih kombinasi yang sesuai dengan kebutuhan sistem.

🔧 Kombinasi Realistis dan Praktik Umum

🔹 1. File JSON + JWT

📌 Deskripsi:

• Data user dan role disimpan dalam file .json.
• Saat login, server mencocokkan kredensial dari file.
• Jika valid, dibuatkan JWT dan dikirim ke client.

✅ Kapan digunakan:

• Aplikasi kecil atau prototipe
• Sistem internal atau pendidikan
• Tidak ada kebutuhan manajemen user dinamis

⚠️ Catatan:

• Tidak aman untuk produksi (terutama jika menyimpan password plaintext)
• Tidak cocok untuk banyak user

🔹 2. Database (DB) + JWT

📌 Deskripsi:

• Autentikasi dilakukan terhadap data di database (users, roles, dll).
• Setelah login, server menghasilkan JWT yang memuat informasi identitas dan role.
• JWT digunakan dalam setiap permintaan selanjutnya (stateless).

✅ Kapan digunakan:

• Aplikasi modern (SPA, mobile, API-first)
• Infrastruktur serverless (misal: Vercel, Netlify)
• Sistem dengan user dinamis dan manajemen akses yang fleksibel

🛠️ Kelebihan:

• Skalabel, fleksibel, cocok untuk multi-platform
• Mudah diintegrasikan dengan RBAC internal

🔹 3. JWT + Refresh Token + Policy Engine (OPA/Casbin)

📌 Deskripsi:

• JWT digunakan sebagai token akses jangka pendek (15–30 menit).
• Refresh token disimpan dan divalidasi untuk memperpanjang sesi login.
• Policy engine digunakan untuk mengevaluasi akses berdasarkan konteks (RBAC atau ABAC).

✅ Kapan digunakan:

• Sistem berskala besar (cloud-native, enterprise)
• Sistem multi-service dengan banyak aturan akses
• Membutuhkan logout, revocation, dan auditing

🛠️ Kelebihan:

• Aman (token tidak berlaku lama)
• Kontrol akses dapat dikelola terpisah dari kode aplikasi

⚠️ Catatan:

• Kompleksitas tinggi, perlu pemahaman mendalam
• Tidak disarankan untuk proyek sederhana

🚫 Kombinasi yang Tidak Efektif atau Bermasalah

❌ 1. Session + JWT secara bersamaan untuk tujuan yang sama

📌 Masalah:

• Duplikasi status pengguna → bisa menyebabkan konflik
• Kebingungan dalam logout dan manajemen sesi
• Menambah kompleksitas tanpa manfaat jelas

🟡 Catatan:

• Session dan JWT boleh dikombinasikan bila punya fungsi berbeda (lihat model hybrid di bab sebelumnya), namun tidak disarankan digunakan bersamaan untuk menyimpan informasi login yang sama.

❌ 2. File JSON + Session + JWT

📌 Masalah:

• Terlalu banyak lapisan untuk sistem sederhana
• Tidak konsisten, sulit di-maintain
• Tidak efisien, apalagi jika file sering berubah

❌ 3. Database + Session + JWT + OAuth2 (tanpa alasan jelas)

📌 Masalah:

• Kompleksitas tinggi tanpa kebutuhan spesifik
• Sulit di-debug, konfigurasi menjadi ambigu
• Mengorbankan kesederhanaan untuk fleksibilitas yang tidak dibutuhkan

✅ Kapan masuk akal:

• Hanya jika sistem butuh login via SSO dan akses internal dengan JWT dan kontrol logout via session.

🧭 Prinsip Pemilihan Kombinasi Mekanisme

Untuk menentukan kombinasi yang tepat, gunakan prinsip berikut:

✅ 1. Pilih yang Sesuai Kebutuhan Fungsional

• Apakah user bersifat publik, internal, atau device?
• Apakah aplikasi harus mendukung SSO, mobile, IoT?

✅ 2. Pertimbangkan Arsitektur Infrastruktur

• Apakah kamu pakai hosting serverless? → Hindari session server-side

• Apakah kamu menggunakan microservices? → Pertimbangkan JWT dan policy engine

✅ 3. Hindari Overengineering

• Gunakan kombinasi paling sederhana yang memenuhi kebutuhan.
• Tambahkan komponen hanya jika benar-benar dibutuhkan (misalnya, refresh token hanya jika sesi panjang dibutuhkan).

✅ 4. Pastikan Tanggung Jawab Jelas

• Jika session digunakan untuk menyimpan token, jangan ulangi menyimpan data identitas yang sama di JWT.
• Jika JWT digunakan, pastikan kontrol akses (RBAC) bisa dilakukan dari data dalam token atau melalui sistem eksternal.

🧩 Kesimpulan

Menggabungkan mekanisme otentikasi dan otorisasi adalah hal umum dan dapat memberikan fleksibilitas tinggi, asalkan dipilih dan dirancang dengan sadar. Beberapa kombinasi seperti Database + JWT, atau JWT + Policy Engine telah terbukti efektif dalam berbagai jenis sistem.

Namun, tidak semua kombinasi bermanfaat—kombinasi yang tumpang tindih tanpa kejelasan tujuan justru akan memperumit arsitektur dan menyulitkan debugging.

Prinsip kuncinya adalah: gunakan kombinasi secukupnya, dan sesuai kebutuhan nyata.

✅ 8. Klarifikasi Penting: Apakah JWT Bisa Berdiri Sendiri?

Dalam banyak dokumentasi dan tutorial, JWT (JSON Web Token) sering dipresentasikan sebagai solusi otentikasi yang “stateless” dan “mandiri”. Hal ini sering menyebabkan miskonsepsi di kalangan pengembang pemula bahwa JWT dapat menggantikan seluruh sistem otentikasi secara utuh dan berdiri sendiri tanpa dependensi lain.

Namun kenyataannya, meskipun JWT memang stateless secara desain, JWT tetap memerlukan sumber kebenaran (source of truth) pada saat pembuatan dan dalam kasus-kasus tertentu saat validasi.

🔎 JWT Butuh Data User Saat Login

JWT hanya dapat dibuat setelah pengguna berhasil diotentikasi—biasanya melalui login dengan kredensial (username/password), SSO, atau mekanisme otentikasi lainnya.

🧭 Dengan kata lain:

JWT bukan pengganti login, tetapi hasil dari login yang valid.

📌 Artinya, untuk membuat JWT, sistem tetap memerlukan:

• Tempat menyimpan data user (file, database, directory service)
• Proses otentikasi untuk mencocokkan kredensial
• Verifikasi data seperti password hash, status user aktif/nonaktif, dsb.

⚖️ Apa yang Bisa dan Tidak Bisa Dilakukan JWT

🧩 Ilustrasi Alur Login → Buat Token → Akses Resource

[1] User Login
    ↓
[2] Server validasi kredensial (via database)
    ↓
[3] Jika valid → generate JWT:
    {
      "sub": "user_123",
      "role": "admin",
      "exp": 1700000000
    }
    ↓
[4] Token dikirim ke client (via cookie atau header)
    ↓
[5] Client kirim token di setiap permintaan
    ↓
[6] Server verifikasi token:
      - Signature
      - Expired atau belum
      - Role sesuai permission

Jika di langkah 6 server menemukan bahwa token valid dan belum expired, maka akses diberikan. Namun jika misalnya akun user_123 telah di-ban di database setelah token dibuat, sistem tidak akan mengetahuinya kecuali dilakukan pengecekan ulang ke sumber data.

🚧 Implikasi Penting:

• JWT tidak boleh dianggap sebagai satu-satunya sumber kebenaran, kecuali sistem memang menerima bahwa data di dalam token valid sampai kadaluarsa.

• Untuk kasus seperti:

  • Perubahan role setelah login
  • Logout paksa (revoke)
  • Suspend/ban user ...maka sistem tetap membutuhkan validasi terhadap sumber eksternal, atau implementasi seperti token revocation list.

🧠 Strategi untuk Mitigasi Kelemahan JWT

1. Gunakan Expiry Time Pendek Token access hanya berlaku selama 15–30 menit → jika user diblokir, token akan kadaluarsa dengan cepat.

2. Refresh Token + Revocation List Gunakan refresh token yang disimpan di database, dan periksa validitasnya sebelum mengeluarkan token baru.

3. Token Signature dengan Rotation Gunakan key rotation dan invalidasi JWT berdasarkan jti (JWT ID) atau daftar blacklist.

4. Gabungkan dengan Middleware Verifikasi Role Dinamis Misalnya, di API tertentu, token diverifikasi terlebih dahulu, lalu user_id di dalamnya digunakan untuk validasi role aktual dari database.

🔚 Kesimpulan

JWT adalah alat yang sangat powerful untuk membangun sistem autentikasi yang stateless, fleksibel, dan scalable. Namun, JWT bukan pengganti database user, bukan juga sistem otentikasi yang berdiri sendiri.

JWT adalah hasil dari proses otentikasi yang valid, dan perlu digunakan dengan pemahaman tentang batasannya.

Penggunaan JWT yang aman dan efektif memerlukan kombinasi dengan:

• Validasi sumber data (database / directory)
• Mekanisme revoke & refresh
• Middleware otorisasi berbasis role atau policy

✅ 9. Rekomendasi Arsitektur RBAC untuk Proyek Monorepo Modern

Untuk mengimplementasikan RBAC secara efisien dalam pengembangan aplikasi modern, pendekatan berbasis arsitektur modular dan stateless kini menjadi pilihan utama, terutama ketika menggunakan platform serverless seperti Vercel.

Bagian ini menyajikan rekomendasi arsitektur RBAC yang dapat diterapkan secara langsung pada struktur proyek monorepo modern, berdasarkan studi kasus fiktif namun realistis: mx-core.

🗂️ Studi Kasus: Monorepo /mx-core

Struktur proyek:

/mx-core
├── /frontend   # Next.js SPA (Single Page Application)
├── /backend    # API routes (RESTful / handler-based)
├── /plugins    # Modular fungsi tambahan (IoT, notifikasi, dll)

Skenario penggunaan:

• User mengakses frontend (SPA) → login
• Frontend memanggil API yang dideploy sebagai fungsi serverless
• Plugin terpisah menangani komunikasi ke perangkat, webhook, dll

🧩 Rekomendasi Arsitektur RBAC

🔐 1. Gunakan JWT (JSON Web Token) sebagai Token Autentikasi

• Setelah user login (misalnya melalui /api/login), backend menghasilkan JWT.
• JWT menyimpan informasi penting: user_id, role, permissions, exp.
• Token dikirim ke klien dan disimpan dalam HttpOnly cookie untuk keamanan maksimal (hindari XSS).
• Semua request API selanjutnya menyertakan token untuk otentikasi.

Alasan utama:

• JWT bersifat stateless → cocok untuk Vercel/serverless
• Tidak perlu menyimpan session server-side

🧱 2. Simpan Data User & Role di Database

• Gunakan PostgreSQL, MySQL, atau database lain untuk menyimpan data:

  • Tabel users → informasi dasar pengguna
  • Tabel roles → definisi peran (admin, editor, viewer, dll)
  • Tabel permissions (opsional) → granularitas akses

• Gunakan ORM seperti Prisma untuk integrasi data di frontend/backend

Catatan:

• Validasi kredensial saat login mengambil data dari DB
• Role pengguna disisipkan ke dalam JWT saat token dibuat

⚙️ 3. Middleware RBAC di Backend API

• Setiap API route (di /backend) menggunakan middleware verifikasi JWT dan pemeriksaan role.
• Middleware memeriksa apakah JWT valid → ekstrak payload → evaluasi apakah role memenuhi syarat untuk mengakses resource.

Contoh:

// middleware/checkRole.ts
export function checkRole(requiredRole: string) {
  return async (req, res, next) => {
    const token = extractToken(req);
    const payload = verifyJWT(token);
    if (payload.role !== requiredRole) {
      return res.status(403).json({ message: 'Access denied' });
    }
    next();
  };
}

• Middleware ini dapat digunakan di API internal maupun di /plugins.

🔁 4. (Opsional) Gunakan Refresh Token + Revoke

Jika aplikasi membutuhkan sesi login panjang atau kemampuan logout paksa:

• Tambahkan refresh token yang disimpan di database.
• Refresh token digunakan untuk menghasilkan JWT baru jika access token sudah kadaluarsa.
• Refresh token dapat dicabut (revoke) kapan saja jika diperlukan.

Hal ini memungkinkan user untuk logout dari semua device, atau mendeteksi dan menghentikan aktivitas mencurigakan.

🚫 Kenapa Session Tidak Cocok untuk Serverless (seperti Vercel)

Platform serverless seperti Vercel memiliki karakteristik berikut:

Karena session tradisional memerlukan penyimpanan server-side yang konsisten, penggunaannya di serverless akan:

• Gagal jika menggunakan memory-local (karena state akan hilang)
• Memaksa penggunaan session store eksternal (misal Redis) → menambah kompleksitas

Sebaliknya, JWT cocok secara alami untuk serverless karena semua data dibawa dalam token dan dapat diverifikasi tanpa state tambahan.

📐 Ringkasan Arsitektur yang Disarankan

✅ Kelebihan Arsitektur Ini

• ✔️ Stateless & scalable → cocok untuk Vercel dan ekosistem serverless lainnya
• ✔️ RBAC terintegrasi secara efisien via middleware
• ✔️ Satu sumber data user/role yang konsisten
• ✔️ Fleksibel untuk komunikasi dengan plugin dan device
• ✔️ Dapat diperluas ke sistem refresh & revoke token bila diperlukan

✅ 10. Panduan Praktis: Memilih Pendekatan Otentikasi & RBAC

Tidak ada satu pendekatan otentikasi atau RBAC yang dapat dianggap sebagai solusi universal. Pemilihan metode dan arsitektur harus didasarkan pada kebutuhan sistem, ukuran aplikasi, karakteristik infrastruktur, serta tingkat keamanan yang dibutuhkan.

Bagian ini merangkum pertimbangan-pertimbangan praktis untuk memilih pendekatan yang tepat.

🔹 1. Berdasarkan Skala Aplikasi

🔹 2. Berdasarkan Arsitektur Sistem

🔹 3. Berdasarkan Kebutuhan Keamanan

🧭 Tips Pemilihan Cepat (Quick Decision Guide)

🔚 Kesimpulan

Pemilihan pendekatan otentikasi dan RBAC tidak boleh dilakukan berdasarkan preferensi pribadi atau sekadar mengikuti tren, melainkan harus mempertimbangkan:

• Kebutuhan fungsional aplikasi
• Jenis infrastruktur yang digunakan
• Skalabilitas jangka panjang
• Tingkat keamanan yang dibutuhkan

Prinsip utama: gunakan metode yang paling sederhana untuk menyelesaikan masalah saat ini, dan siapkan arsitektur yang dapat dikembangkan jika kompleksitas meningkat.

✅ 11. Kesimpulan

Pengelolaan autentikasi dan otorisasi merupakan fondasi penting dalam pengembangan aplikasi modern, terlebih lagi jika sistem tersebut memiliki banyak pengguna, peran, dan akses yang berbeda-beda. Melalui artikel ini, kita telah membahas secara menyeluruh berbagai pendekatan untuk menerapkan RBAC (Role-Based Access Control), mulai dari yang paling sederhana hingga yang paling kompleks dan fleksibel.

🧩 Prinsip-Prinsip Utama yang Perlu Diingat

1. RBAC adalah model otorisasi, bukan metode otentikasi.

2. Session dan token hanyalah mekanisme penyimpanan status autentikasi.

3. JWT sangat cocok untuk arsitektur modern, serverless, dan API-based.

4. Kombinasi metode (hybrid) dapat digunakan jika memiliki peran berbeda dan dirancang dengan jelas.

5. Pendekatan yang dipilih harus disesuaikan dengan:

   • Skala aplikasi
   • Arsitektur infrastruktur
   • Tingkat keamanan yang dibutuhkan

🔐 Autentikasi vs Otorisasi

Keduanya saling melengkapi, tetapi memiliki peran dan mekanisme yang berbeda. Sistem yang hanya melakukan autentikasi tanpa otorisasi akan rentan terhadap akses yang tidak sah, sedangkan otorisasi tanpa autentikasi tidak memiliki identitas untuk divalidasi.

🎯 Panduan Cepat: Kalau Kasusmu Seperti Ini → Gunakan Ini

✅ 12. Referensi & Resource Lanjutan

Untuk implementasi lebih lanjut dan pemahaman mendalam, berikut adalah referensi resmi dan tools yang direkomendasikan:

📚 Dokumentasi Resmi

• 🔗 JWT (jwt.io) Informasi lengkap mengenai struktur dan penggunaan JWT

• 🔗 NextAuth.js Solusi otentikasi lengkap untuk aplikasi Next.js, mendukung session dan JWT

• 🔗 Open Policy Agent (OPA) Policy engine untuk kontrol akses berbasis policy dalam arsitektur modern

• 🔗 OAuth2 & OpenID Connect Protokol otentikasi dan otorisasi yang banyak digunakan dalam SSO dan federasi identitas

🧰 Tools & Library Rekomendasi

🎓 Sumber Belajar Lanjutan

• 📘 Zero to Production in Auth – Artikel dan buku praktis untuk membangun autentikasi modern

• 📘 OWASP Cheat Sheet Series: Authentication & Access Control → cheatsheetseries.owasp.org

• 📺 YouTube Channels:

  • Ben Awad, Theo (t3.gg) – konten otentikasi dan arsitektur modern
  • Academind, Traversy Media – tutorial implementasi Next.js + Auth

Dengan referensi dan prinsip yang telah dijelaskan, diharapkan artikel ini dapat menjadi sumber acuan tunggal (one-stop reference) bagi pengembang muda dalam memilih, merancang, dan mengimplementasikan sistem autentikasi serta RBAC yang aman dan sesuai dengan kebutuhan aplikasinya.

Bangunlah sistem autentikasi dan otorisasi yang tidak hanya berfungsi, tapi juga siap untuk tumbuh bersama aplikasi Anda.

> ✨ BONUS

Disusun secara padat, teknis, dan siap digunakan sebagai lampiran praktis dalam dokumentasi atau pelatihan internal tim.

📘 Glosarium Istilah

🧭 Diagram Arsitektur JWT + RBAC (Monorepo di Vercel)

Berikut adalah alur arsitektur autentikasi & otorisasi berbasis JWT dalam proyek monorepo modern:

┌─────────────┐         ┌────────────────────┐         ┌──────────────┐
│  Frontend   │  ─────▶ │   /api/login       │  ─────▶ │   Database   │
│ (Next.js)   │         │ (verifikasi user)  │         │ (users/roles)│
└────┬────────┘         └────────┬───────────┘         └────┬─────────┘
     │                           │                            │
     │ JWT disimpan di cookie    │                            │
     ▼                           ▼                            │
┌─────────────┐         ┌────────────────────┐               │
│ HttpOnly    │◀───────▶│  API Route (backend)│               │
│ Cookie      │         │  - Verifikasi JWT   │               │
└─────────────┘         │  - Check role       │               │
                        └────────────────────┘               │
                                  │                          ▼
                                  ▼                 ┌────────────────┐
                           ┌──────────────┐         │  Plugin / IoT  │
                           │ JWT digunakan│ ──────▶ │  (pakai JWT)   │
                           │ antar modul  │         └────────────────┘
                           └──────────────┘

Keterangan:

• Setelah login, backend membuat JWT berisi user_id, role, dll.
• JWT disimpan di cookie (HttpOnly) dan dikirim otomatis dalam request selanjutnya.
• API backend membaca token, verifikasi, lalu mengevaluasi RBAC.
• Plugin atau perangkat IoT dapat diberi akses via JWT untuk komunikasi modular.

🔐 Checklist Keamanan Implementasi Auth

Gunakan checklist berikut saat membangun sistem autentikasi dan RBAC:

✅ Autentikasi & Token

• Password disimpan dengan hash (misal: bcrypt, argon2)
• JWT ditandatangani dengan kunci rahasia (HS256 atau RS256)
• Access token memiliki exp pendek (≤ 30 menit)
• Refresh token disimpan dengan aman dan bisa dicabut
• Gunakan jti (JWT ID) untuk memungkinkan revoke token

✅ Penyimpanan Token

• Simpan token di HttpOnly cookie (bukan localStorage)
• Aktifkan Secure, SameSite=Strict/Lax pada cookie
• Hindari token bearer terbuka di URL atau log

✅ RBAC & Otorisasi

• Validasi role atau permissions di setiap endpoint API
• Jangan percaya data role dari client-side
• Gunakan middleware otorisasi terpisah dari logic utama
• Terapkan principle of least privilege (PoLP)

✅ API & Infrastruktur

• Semua komunikasi menggunakan HTTPS
• Rate limiting dan brute-force protection diterapkan di endpoint login
• Audit trail/log akses diaktifkan untuk endpoint sensitif
• Token expired ditangani dengan jelas (401 + refresh)

✅ Testing & Monitoring

• Uji unit & integrasi untuk autentikasi dan otorisasi
• Monitoring token abuse dan aktivitas mencurigakan
• Cek rutin expiry, rotasi kunci, dan revoke list

Dengan adanya bagian bonus ini, pengembang memiliki alat bantu tambahan untuk:

• Mempercepat pemahaman istilah
• Menerapkan arsitektur dengan visualisasi yang jelas
• Menjaga keamanan sistem secara praktis dan terstruktur

Artikel ini kini benar-benar menjadi referensi menyeluruh — dari konsep hingga penerapan nyata yang siap produksi.