Belajar Authelia - Storage Backend

#Pendahuluan

Di episode 7, session kalian simpan di Redis: cepat, sementara, dan lenyap saat kedaluwarsa. Tapi Authelia punya data yang tidak boleh hilang — data permanen yang menentukan apakah pengguna bisa login kembali besok. Session memang sementara, tetapi kepercayaan yang membangunnya harus bertahan.

Data permanen ini disimpan di storage backend, sebuah database yang mengingat: TOTP secret, kredensial WebAuthn, device ID Duo, token verifikasi identitas, hingga record consent untuk OIDC. Jika database ini rusak tanpa backup, setiap pengguna harus mendaftarkan ulang seluruh perangkat MFA-nya — satu malam yang melelahkan bagi admin dan pengguna. Di episode ini kalian akan memilih backend yang tepat, mengonfigurasinya, menjalankan migrasi schema, dan menyusun strategi backup yang sehat.

#Apa Saja yang Disimpan di Storage?

Storage backend adalah memori jangka panjang Authelia. Isinya antara lain:

• TOTP secret: kunci rahasia yang sama dengan yang ada di aplikasi authenticator pengguna. Bocor berarti penyerang bisa memproduksi kode OTP.
• Kredensial WebAuthn: public key dan metadata authenticator, termasuk YubiKey dan passkey.
• Device ID Duo: identitas perangkat yang sudah di-enroll untuk Duo Push.
• Token verifikasi identitas: token sementara untuk alur reset password atau verifikasi email.
• Record consent OIDC: izin yang pernah diberikan pengguna kepada aplikasi klien.

Dengan kata lain: apapun yang harus diingat Authelia setelah proses login selesai, ada di database ini. Kehilangan database berarti kehilangan akses.

#Memilih Backend: SQLite, MySQL, atau PostgreSQL

Authelia mendukung tiga opsi storage:

• SQLite (local): default dan paling sederhana. Satu file database, tanpa server terpisah, nol konfigurasi ekstra. Cocok untuk homelab, single instance, dan traffic rendah.
• MySQL/MariaDB: pilihan yang baik saat sudah punya server database MySQL. Perlu penyiapan user dan database terlebih dahulu.
• PostgreSQL: rekomendasi utama untuk produksi. Mendukung encryption key, connection pooling, dan menjadi basis yang solid untuk high availability.

storage:
  local:
    path: "/config/db.sqlite3"

storage:
  postgres:
    address: "tcp://postgres:5432"
    database: "authelia"
    schema: "public"
    username: "authelia"
    password: "rahasia-database"
    encryption_key: "kunci-enkripsi-panjang-sama-disemua-instance"

Perhatikan encryption_key di konfigurasi PostgreSQL. Kunci ini mengenkripsi data sensitif seperti TOTP secret dan private key WebAuthn saat disimpan di database — layer pertahanan terakhir jika file database bocor. Hanya tersedia untuk MySQL dan PostgreSQL, bukan SQLite.

#Konfigurasi Koneksi

Secara umum, konfigurasi storage mengikuti pola yang sama: alamat server, nama database, user, dan password.

storage:
  mysql:
    address: "tcp://mysql:3306"
    database: "authelia"
    username: "authelia"
    password: "rahasia-database"
    encryption_key: "kunci-enkripsi-panjang-sama-disemua-instance"

Sebelum Authelia bisa dipakai, database dan user-nya harus dibuat lebih dulu di server MySQL atau PostgreSQL. Buat user khusus dengan hak akses terbatas pada database authelia saja — jangan pernah memakai akun root.

Jika kalian berpindah dari SQLite ke PostgreSQL, urutan yang aman adalah: backup dulu, buat database tujuan, lalu lakukan migrasi dengan CLI sambil memindahkan data pengguna lewat perintah export dan import.

#Migrasi Schema Database

Authelia berkembang cepat, dan setiap versi baru bisa mengubah struktur tabel database. Schema inilah yang dijaga tetap sinkron oleh migrasi. Secara default, Authelia otomatis menjalankan migrasi ke atas saat startup. Untuk kendali penuh, tersedia subcommand CLI:

authelia storage migrate up
authelia storage migrate history
authelia storage migrate list-up

• migrate up: menjalankan semua migrasi yang belum diterapkan.
• migrate history: melihat riwayat versi schema.
• migrate list-up dan migrate list-down: memeriksa migrasi yang tersedia sebelum dijalankan.

Ketika kalian mengubah konfigurasi storage (misalnya berpindah dari SQLite ke PostgreSQL), Authelia menyesuaikan schema di database tujuan secara otomatis saat pertama kali terhubung. Proses berpindah backend bisa ditampilkan sebagai perubahan konfigurasi:

storage:
  local: 
    path: "/config/db.sqlite3"
  postgres: 
    address: "tcp://postgres:5432"
    database: "authelia"
    username: "authelia"
    password: "rahasia-database"

#Strategi Backup yang Sehat

Backup storage Authelia tidak berbeda dengan backup database biasa, dengan satu tambahan wajib: jangan lupa encryption_key. Rencanakan backup sebagai berikut:

• SQLite: cukup salin file db.sqlite3 saat Authelia berhenti, atau gunakan snapshot konsisten. Jangan menyalin file yang sedang ditulis aktif.
• PostgreSQL: pakai pg_dump atau backup fisik, lalu simpan hasilnya di lokasi terpisah.
• MySQL: pakai mysqldump dengan pola yang sama.

pg_dump -h localhost -U authelia authelia > authelia-backup.sql

Selain dump database, Authelia menyediakan perintah export untuk data spesifik pengguna — berguna saat memindahkan sebagian data antar instance, misalnya export TOTP configuration:

authelia storage user totp export
authelia storage user webauthn export

#Catatan Performa untuk Produksi

Untuk satu instance homelab, SQLite hampir selalu cukup. Namun ketika pengguna bertambah dan kalian menambah instance Authelia (untuk ketersediaan tinggi), perhatikan hal berikut:

• Gunakan PostgreSQL atau MySQL: kedua backend ini mendukung akses bersamaan dari banyak instance dengan aman, sedangkan SQLite tidak dirancang untuk itu.
• Gabungkan dengan Redis: storage database menangani data permanen, Redis menangani session. Keduanya harus berbagi infrastruktur yang sama tinggi ketersediaannya.
• Hindari penulisan berlebih: data storage jarang ditulis (hanya saat enrollment, reset, dan consent). Pastikan database berada di storage yang terpercaya, karena setiap penulisan melibatkan enkripsi jika encryption_key dipakai.

#Penutup

Poin kunci episode ini:

• Storage menyimpan data permanen: TOTP secret, kredensial WebAuthn, device ID Duo, token verifikasi, dan consent OIDC.
• SQLite untuk homelab; PostgreSQL atau MySQL untuk produksi dan multi-instance.
• encryption_key menambah enkripsi-at-rest, tetapi wajib dibackup bersama database.
• Migrasi schema otomatis saat startup, dengan kendali manual lewat authelia storage migrate.
• Backup database adalah rencana keselamatan yang paling penting; backup encryption_key adalah syarat mutlaknya.

Sekarang fondasi penyimpanan sudah kokoh, saatnya menyalakan lapisan kedua keamanan yang telah kalian janjikan di episode 6: two_factor. Di episode 9, kalian akan memahami TOTP — kode enam digit yang berubah setiap 30 detik — mulai dari cara kerjanya secara kriptografis hingga proses enrollment dan konfigurasinya.