Belajar Authelia - Sejarah, Latar Belakang & Mengapa Membutuhkan Authelia

#Pendahuluan

Setelah di episode 0 kita memastikan environment siap — skill dasar reverse proxy dan forward authentication, Docker Compose terpasang, dan topologi laboratorium dirancang — pada episode kali ini kita mundur sejenak untuk menjawab pertanyaan yang paling menentukan: mengapa kita membutuhkan Authelia?

Pertanyaan ini bukan sekadar trivia sejarah. Memahami latar belakang Authelia menjawab tiga pertanyaan praktis: (1) apa sebenarnya masalah dari "banyak aplikasi, banyak sistem login" yang selama ini kita terima sebagai hal normal, (2) mengapa solusi yang ada — basic auth, oauth2-proxy, Authentik, Keycloak — tidak selalu pas, dan (3) kapan Authelia adalah pilihan yang tepat dan kapan bukan. Seperti memahami sejarah sebuah teknologi, memahami latar belakang Authelia membuat kalian tidak hanya bisa memasangnya, tapi tahu mengapa ia ada.

#Masalah: Banyak Aplikasi, Banyak Pintu Masuk

Bayangkan rumah kalian punya sepuluh pintu, dan setiap pintu punya kunci yang berbeda-beda. Tamu yang sama harus membawa sepuluh kunci berbeda, dan kalian harus mengingat sepuluh aturan berbeda tentang siapa boleh lewat pintu mana. Itulah keadaan server self-hosted pada umumnya:

1. Password fatigue. Satu orang mengingat password Grafana, Nextcloud, Portainer, Jellyfin, dan puluhan aplikasi lain. Hasilnya: password diulang, ditulis di sticky note, atau dipilih yang paling mudah ditebak.
2. Kebijakan yang tidak konsisten. Satu aplikasi mewajibkan password kuat, aplikasi lain menerima 123456. Tidak ada standar bersama.
3. Tidak ada satu titik audit. Jika sebuah akun disusupi, tidak ada satu tempat untuk melihat semua aktivitas login — setiap aplikasi mencatatnya sendiri, dengan format sendiri.
4. Keamanan bergantung aplikasi paling lemah. Satu aplikasi yang tidak punya dukungan MFA menjadi titik masuk terlemah ke seluruh jaringan.

Authelia lahir sebagai jawaban atas kekacauan ini: satu pintu masuk, satu kebijakan, satu catatan audit, dan satu tempat untuk memberlakukan MFA.

#Lanskap Autentikasi Sebelum Authelia

#Autentikasi per-Aplikasi

Cara paling tradisional: setiap aplikasi punya sistem login sendiri, database pengguna sendiri, dan kebijakan sendiri. Untuk satu sampai tiga aplikasi, ini masih masuk akal. Setelah itu, beban mengelolanya tumbuh lebih cepat daripada nilainya.

#Basic Auth di Reverse Proxy

Tahap berikutnya yang sering dicoba: reverse proxy (misalnya NGINX) menambahkan lapisan login sederhana dengan directive auth_basic:

location / {
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

Masalahnya: kredensial dikirim sebagai teks (hanya di-encode base64, tidak dienkripsi — aman hanya di atas HTTPS), tidak ada dukungan MFA, tidak ada manajemen pengguna, dan semua pengguna biasanya berbagi satu username/password yang sama.

#Forward Authentication

Pola yang lebih modern: proxy "menyerahkan" keputusan autentikasi ke layanan eksternal. Authelia adalah salah satu implementasi forward authentication — ia mengecek session, mengarahkan ke portal login bila perlu, lalu memberi tahu proxy apakah permintaan boleh diteruskan. Pola inilah yang menjadi tulang punggung Authelia dan akan kita bedah di episode 2.

#Munculnya Kebutuhan SSO di Dunia Self-Hosted

Semakin banyak layanan yang di-homelab, semakin kuat kebutuhan Single Sign-On (SSO): login sekali, semua aplikasi terbuka. SSO bukan kemewahan enterprise — bagi pemilik satu VPS dengan lima aplikasi, SSO adalah cara mengelola identitas yang masuk akal secara manusiawi.

#Kelahiran Authelia

Authelia lahir pada tahun 2016 sebagai proyek open-source yang digerakkan komunitas, dengan lisensi Apache 2.0. Visinya sejak awal sederhana namun tegas: menjadi lightweight authentication server yang fokus pada forward authentication — satu hal yang dikerjakan dengan sangat baik — alih-alih platform raksasa yang mencoba mengerjakan segalanya.

Karena ditulis dalam Go, Authelia dikompilasi menjadi satu binary tunggal: pemasangannya ringan, konsumsi memorinya rendah, dan tidak ada runtime yang perlu dikelola. Desain ini lahir dari kebutuhan nyata komunitas self-hosting: solusi yang muat di server kecil, mudah di-deploy, dan berintegrasi mulus dengan reverse proxy yang sudah ada.

#Fitur Utama Authelia

• SSO portal — satu halaman login untuk semua aplikasi yang dilindungi.
• MFA lengkap — TOTP (Google Authenticator, Authy), WebAuthn/FIDO2 (YubiKey, Touch ID), dan Duo Push.
• Access control rules — kebijakan granular berbasis domain, path, user, grup, dan jaringan (policy bypass, one_factor, two_factor, deny).
• Identity proxying — identitas pengguna diteruskan ke aplikasi lewat header HTTP (Remote-User, Remote-Groups, dan lainnya), sehingga aplikasi tanpa sistem login pun bisa mengenali pengguna.
• Brute force protection (regulation) — pembatasan percobaan login gagal berbasis IP dan pengguna.
• OIDC provider — Authelia juga bisa bertindak sebagai Identity Provider untuk aplikasi modern yang mendukung OpenID Connect (dibahas di fase 5 series ini).

#Authelia vs Alternatif

Inti perbandingannya: Authentik dan Keycloak adalah platform identitas raksasa — hebat, tapi butuh sumber daya dan waktu belajar yang besar. Authelia sengaja sempit: ia menangani forward authentication, SSO, dan MFA dengan sangat baik, dan hampir tidak melakukan hal lain. Untuk homelab dan bisnis kecil, sempit bukan kelemahan — itu kekuatan.

#Mengapa Memilih Authelia

• Ringan dan efisien — ditulis dalam Go, satu binary, hemat RAM; nyaman di VPS 1–2 GB.
• Mudah di-deploy — image Docker resmi authelia/authelia dan binary tunggal.
• Dirancang untuk reverse proxy — integrasi NGINX, Traefik, Caddy, dan HAProxy adalah warga negara kelas satu.
• Keamanan kuat — MFA, access control berbasis aturan, dan proteksi brute force.
• Privasi-first — tanpa telemetry, data pengguna tersimpan di penyimpanan milik kalian sendiri.
• Tanpa vendor lock-in — open source Apache 2.0, konfigurasi berbasis file sederhana, migrasi keluar mudah.
• Komunitas aktif — dokumentasi yang baik, perkembangan yang stabil.

#Use Case yang Tepat

Authelia sangat cocok untuk:

• Homelab SSO — melindungi seluruh server rumah dengan satu portal login.
• Self-hosted services — Grafana, Nextcloud, Portainer, dan aplikasi lain yang tidak ingin kalian biarkan "polos" tanpa autentikasi sendiri.
• Internal tools perusahaan kecil — kontrol akses tim tanpa biaya lisensi IdP enterprise.
• Development environments — melindungi staging dan preview environment.
• Perangkat IoT dan home automation — membungkus dashboard yang biasanya tanpa login kuat.

#Penutup

Pada episode 1 ini kita telah memahami akar masalah yang Authelia selesaikan: kekacauan banyak pintu login — password fatigue, kebijakan tidak konsisten, dan keamanan yang bergantung aplikasi paling lemah. Kita menelusuri evolusi solusinya dari autentikasi per-aplikasi, basic auth di proxy, hingga pola forward authentication, dan melihat kelahiran Authelia di tahun 2016 sebagai lightweight forward authentication server yang fokus pada SSO, MFA, dan access control — ditulis dalam Go, berlisensi Apache 2.0, tanpa telemetry. Kita juga membandingkannya secara jujur dengan oauth2-proxy, Authentik, dan Keycloak.

Inti yang harus kalian bawa:

• Masalah nyatanya adalah banyak aplikasi dengan banyak sistem login yang tidak terkelola.
• Authelia adalah specialist, bukan all-in-one — dan sempit justru kekuatannya.
• Untuk homelab dan bisnis kecil, Authelia menang karena ringan, mudah, dan fokus.
• Keamanan terbaik adalah yang konsisten — satu pintu, satu kebijakan, satu audit.

Di episode 2 selanjutnya kita akan membedah arsitektur dan konsep inti Authelia: bagaimana server Authelia, Redis, database pengguna, dan reverse proxy bekerja sama, perjalanan satu permintaan dari browser hingga kembali dengan cookie session, dan istilah-istilah kunci seperti access control dan policy. Sampai jumpa di episode 2!