Belajar Authelia - Arsitektur & Core Concepts

#Pendahuluan

Setelah di episode 1 kita memahami mengapa Authelia dibutuhkan — satu pintu masuk untuk banyak aplikasi — pada episode kali ini kita membedah bagaimana Authelia bekerja di balik layar. Ini episode paling penting untuk dipahami sebelum menyentuh konfigurasi: tanpa arsitektur, semua sintaks configuration.yml hanyalah hafalan yang mudah salah terpakai.

Kita akan memetakan komponen-komponen arsitektur, memahami konsep inti (portal, access control, 1FA vs 2FA, session), lalu mengikuti perjalanan satu permintaan HTTP dari browser hingga kembali membawa cookie session. Seperti pilot yang wajib paham bagaimana sayap bekerja sebelum terbang, engineer yang memahami arsitektur Authelia akan jauh lebih cepat men-debug masalah di episode-episode berikutnya.

#Komponen Arsitektur

Authelia tidak pernah berjalan sendirian. Ia adalah satu titik koordinasi di antara lima komponen lain. Mari bedah satu per satu.

#Authelia Server

Jantungnya adalah binary Authelia yang ditulis dalam Go. Ia melayani dua hal: endpoint verifikasi (yang dipanggil reverse proxy untuk menilai setiap permintaan) dan portal login (antarmuka tempat pengguna masuk). Secara default ia mendengarkan di port 9091. Server ini "tanpa keadaan" (stateless) untuk urusan session — semua session disimpan di Redis, sehingga nanti mudah diskalakan secara horizontal di episode high availability.

#Configuration File

Semua perilaku Authelia ditentukan oleh satu file: configuration.yml. Dari sini Authelia tahu di mana pengguna disimpan, di mana session disimpan, bagaimana mengirim notifikasi, dan aturan akses apa yang berlaku. Kita akan membedah file ini secara menyeluruh di episode 4.

#Session Storage

Keadaan login (session) disimpan secara terpusat — biasanya di Redis. Mengapa tidak di dalam Authelia sendiri? Karena dengan Redis, session bisa dibagikan antar beberapa instance Authelia, dan session bisa di-revoke secara terpusat. Untuk development, Authelia juga mendukung session di memori (in-memory), tapi Redis adalah rekomendasi production. Episode 7 akan membahas session secara tuntas.

#User Database (Authentication Backend)

Sumber kebenaran untuk akun pengguna. Authelia tidak memaksa format tertentu — ia mendukung file YAML (users_database.yml) untuk skala kecil, serta LDAP dan Active Directory untuk organisasi. Ini disebut authentication backend, dan episode 5 akan membahas ketiganya secara mendalam.

#Storage Backend

Berbeda dari database pengguna, storage backend menyimpan data yang dihasilkan Authelia itu sendiri: secret TOTP, kredensial WebAuthn, token verifikasi identitas, dan catatan consent OIDC. Opsinya: SQLite lokal (default, paling sederhana), PostgreSQL, atau MySQL/MariaDB. Episode 8 membahasnya.

#Notifier

Authelia perlu mengirim email — misalnya kode verifikasi untuk reset password atau konfirmasi pendaftaran perangkat. Dua opsi: SMTP untuk produksi, dan filesystem (menulis "email" ke file lokal) untuk laboratorium. Episode 12 membahas konfigurasi SMTP.

#Konsep Inti

Beberapa istilah akan kalian temui terus-menerus di seluruh series ini. Pahami sekarang agar tidak tersesat nanti:

• Portal — halaman login Authelia (auth.example.com). Ini satu-satunya pintu masuk untuk semua aplikasi yang dilindungi.
• Protected domain — subdomain yang dilindungi, misalnya grafana.example.com. Semua permintaan ke domain ini harus lulus verifikasi Authelia.
• Access control rules — daftar aturan yang menentukan siapa boleh mengakses apa. Aturan dievaluasi berurutan, yang cocok pertama menang, dengan policy bypass, one_factor, two_factor, atau deny.
• 1FA vs 2FA — one-factor berarti hanya password; two-factor berarti password + metode kedua (TOTP, WebAuthn, atau Duo). Authelia tidak mengharuskan semua aplikasi memakai 2FA — kalian yang memutuskan per aturan.
• Session — keadaan "sudah login" yang disimpan di cookie dan Redis. Mengatur berapa lama session bertahan, kapan kadaluarsa, dan fitur "remember me".
• OIDC provider — Authelia juga bisa bertindak sebagai Identity Provider bagi aplikasi modern yang mendukung OpenID Connect (dibahas di fase 5).

#Alur Autentikasi End-to-End

Inilah momen "semuanya menyatu". Ikuti perjalanan satu permintaan:

1. Pengguna mengetik https://grafana.example.com di browser.
2. Reverse proxy (misalnya NGINX) menerima permintaan dan menanyakan Authelia: "Apakah pengguna ini terautentikasi?" — melalui endpoint verifikasi.
3. Authelia memeriksa cookie session di permintaan tersebut.
4. Tidak ada session sah → Authelia menjawab "belum terautentikasi" dan memberikan lokasi portal login.
5. Proxy mengarahkan browser pengguna ke portal https://auth.example.com.
6. Pengguna login dengan username + password di portal.
7. Jika resource mensyaratkan dua faktor, Authelia meminta metode kedua (TOTP/WebAuthn/Duo).
8. Authelia membuat session, menyimpannya di Redis, dan menetapkan cookie session di browser.
9. Browser diarahkan kembali ke https://grafana.example.com — kini membawa cookie session.
10. Proxy kembali menanyakan Authelia; kali ini session sah → Authelia menjawab "boleh" beserta identitas pengguna.
11. Proxy meneruskan permintaan ke Grafana, menyertakan header identitas (Remote-User, Remote-Groups).
12. Grafana membuka halaman — untuk pengguna yang sudah dikenal.

Browser                    Proxy (NGINX)          Authelia              Redis
   |  1. GET / (no cookie)      |                      |                   |
   |--------------------------->|  2. verify?          |                   |
   |                            |--------------------->|  3. cek session   |
   |                            |                      |------------------>|
   |                            |                      |  4. tidak ada     |
   |                            |<---------------------|<------------------|
   |  5. redirect ke portal     |                      |                   |
   |<---------------------------|                      |                   |
   |  6. POST username+pass     |                      |                   |
   |--------------------------------------------------->|  7. validasi user |
   |                            |                      |  8. buat session  |
   |                            |                      |------------------>|
   |  9. set cookie + redirect  |                      |                   |
   |<---------------------------|                      |                   |
   | 10. GET / (dengan cookie)  |                      |                   |
   |--------------------------->| 11. verify?          |                   |
   |                            |--------------------->| 12. session sah   |
   |                            |                      |------------------>|
   |                            |<---------------------|<------------------|
   | 13. GET / + Remote-User    |                      |                   |
   |<---------------------------| 14. response Grafana |                   |

#Model Keamanan

Authelia dibangun di atas prinsip defense in depth — beberapa lapis pertahanan, bukan satu pagar:

• Rule-based access control — akses ditolak secara default (deny), hanya dibuka lewat aturan eksplisit.
• Multi-factor authentication — lapisan kedua untuk resource sensitif.
• Brute force protection (regulation) — percobaan login gagal dibatasi berbasis IP dan pengguna.
• Session security — cookie di-enkripsi, dikunci ke domain, dan bisa dibatasi masa hidupnya.
• Password policies — Authelia tidak memaksa password "kuat" di tingkat server untuk file backend, tapi mengandalkan hashing argon2id yang tahan terhadap serangan offline (detail di episode 5).

#Penutup

Pada episode 2 ini kalian telah memetakan arsitektur Authelia: server Go sebagai koordinator, configuration.yml sebagai otak, Redis untuk session, authentication backend (file/LDAP/AD) untuk akun pengguna, storage backend (SQLite/PostgreSQL/MySQL) untuk data MFA, dan notifier untuk email. Kalian juga mengikuti alur lengkap satu permintaan: dari browser, ke proxy, ke verifikasi Authelia, ke portal, kembali dengan cookie session, hingga aplikasi menerima header identitas.

Poin yang harus kalian bawa:

• Authelia adalah penilai keputusan; reverse proxy adalah pintu; aplikasi adalah ruangan yang tidak pernah melihat kredensial.
• Session di Redis memungkinkan skala horizontal dan revoke terpusat.
• Access control dievaluasi berurutan, first match wins — dan default yang aman adalah deny.
• 1FA vs 2FA adalah pilihan per aturan, bukan satu saklar global.
• Aplikasi mengenali pengguna lewat header identitas, bukan lewat session Authelia.

Di episode 3 selanjutnya kita akan mulai beraksi: memasang Authelia dengan Docker Compose — menyusun stack Authelia + Redis + database, membuat file konfigurasi minimal, mengelola secret lewat file .env, dan memverifikasi portal Authelia pertama kalian. Sampai jumpa di episode 3!