Authelia: Satu Login untuk Semua Layanan Self-Hosted

Dua belas layanan self-hosted berarti dua belas halaman login, dua belas basis data password, dan dua belas kesempatan untuk memakai password yang sama.

Foto: Scandinavian, public domain, via Wikimedia Commons

Authelia menyelesaikan itu dengan satu gerbang di depan reverse proxy: satu login, satu sesi, satu tempat untuk mencabut akses. Yang membuatnya cocok untuk homelab adalah skalanya — satu binary, satu file konfigurasi, dan Redis.

Cara kerjanya: forward auth

Reverse proxy tidak lagi meneruskan permintaan langsung ke aplikasi. Ia bertanya dulu ke Authelia: apakah sesi ini sah dan boleh mengakses hostname ini? Kalau tidak, pengguna diarahkan ke portal login.

Konsekuensinya penting: aplikasi di belakangnya tidak perlu tahu apa pun tentang autentikasi. Nextcloud, Jellyfin, atau dashboard apa pun bisa dilindungi tanpa mengubah konfigurasinya.

Yang perlu disiapkan

• Satu domain utama, misalnya auth.contoh.com, sudah punya sertifikat TLS.
• Redis sebagai penyimpan sesi. Tanpa ini, setiap restart Authelia memaksa semua orang login ulang.
• Tiga rahasia: jwt_secret, session.secret, dan storage.encryption_key. Semuanya string acak panjang, jangan pernah dipakai ulang.
• users_database.yml berisi pengguna dan hash password argon2.

docker run --rm authelia/authelia:latest authelia crypto hash generate argon2 --password 'PasswordAnda'

Konfigurasi inti

access_control:
  default_policy: deny
  rules:
    - domain: "auth.contoh.com"
      policy: bypass
    - domain: "*.contoh.com"
      policy: two_factor

default_policy: deny adalah keputusan terpenting di seluruh file ini. Kebanyakan orang memulai dengan one_factor sebagai default, lalu lupa bahwa layanan baru otomatis terbuka hanya karena tidak ada aturan yang menyebutnya. Dengan deny, layanan baru tertutup sampai Anda sengaja mengizinkannya.

Aturan bypass untuk portal login itu sendiri wajib. Tanpa itu, Authelia meminta login untuk halaman login.

Memasang di reverse proxy

Untuk Nginx, pola forward auth memakai auth_request:

location / {
    auth_request /authelia;
    auth_request_set $user $upstream_http_remote_user;
    proxy_set_header Remote-User $user;
    proxy_pass http://127.0.0.1:8080;
}

location = /authelia {
    internal;
    proxy_pass http://127.0.0.1:9091/api/verify?rd=https://auth.contoh.com;
    proxy_set_header X-Original-URL $scheme://$http_host$request_uri;
}

Header Remote-User yang diteruskan ke aplikasi memungkinkan aplikasi yang mendukung autentikasi berbasis header untuk mengenali pengguna tanpa login terpisah.

Tiga jebakan yang membuat orang terkunci di luar

• Cookie domain salah. Sesi Authelia harus berlaku untuk seluruh domain induk, bukan hanya auth.. Kalau tidak, setiap subdomain meminta login ulang.
• Melindungi panel manajemen reverse proxy. Ini terdengar benar, sampai Authelia mati dan Anda tidak bisa masuk ke panel untuk memperbaikinya. Kecualikan selalu jalur darurat.
• Tidak punya akun cadangan. Simpan satu pengguna admin dengan kredensial di tempat terpisah, dan satu sesi SSH yang tidak lewat proxy.

Dua faktor: pakai atau tidak

TOTP menambah satu langkah, dan untuk layanan yang diakses setiap hari itu terasa mengganggu. Kompromi yang saya pakai: one_factor untuk layanan yang isinya tidak sensitif dan hanya diakses dari jaringan sendiri, two_factor untuk apa pun yang menyimpan data pribadi — password manager, foto, dokumen.

Yang tidak boleh dilakukan: mengaktifkan 2FA untuk semua orang lalu mematikan cadangan kode pemulihan. Kehilangan ponsel tidak boleh berarti kehilangan seluruh akses.

Authelia, Authentik, atau Keycloak

Authelia paling ringan dan paling mudah dipahami, tapi ia bukan penyedia identitas penuh — tidak ada manajemen pengguna lewat antarmuka, tidak ada OIDC lengkap untuk aplikasi yang membutuhkannya. Authentik menutup celah itu dengan kompleksitas yang jauh lebih tinggi. Keycloak adalah jawaban untuk kebutuhan organisasi, bukan homelab.

Untuk sepuluh sampai dua puluh layanan pribadi, Authelia adalah titik seimbang. Kalau Anda sudah butuh SSO untuk aplikasi yang mendukung OIDC dan manajemen pengguna mandiri, mulai langsung dari Authentik — berpindah nanti berarti mengulang semuanya.

Baca juga:

• How to Use Caddy as a Reverse Proxy with Automatic HTTPS
• Cara Self-Host Vaultwarden: Password Manager Pribadi
• Cara Memakai Cloudflare Tunnel: Akses Server Tanpa Buka Port
• Docker Compose yang Tidak Berantakan Setelah 20 Container