Memahami pengelolaan session di Authelia: konfigurasi cookie dengan nama, domain, dan masa berlaku, penyimpanan session di Redis untuk skala produksi, serta aspek keamanan cookie seperti Secure, SameSite, dan HttpOnly agar session tidak mudah dibajak.

Di episode 6, kalian sudah menulis aturan akses: siapa yang boleh masuk ke domain mana dan dengan level autentikasi apa. Tapi bayangkan jika Authelia meminta login ulang untuk setiap file gambar yang dimuat halaman. Itu akan terasa seperti antrean petugas keamanan di setiap pintu lorong. Solusinya adalah session: sekali login, identitas diingat selama jangka waktu tertentu.
Session adalah kartu lanyard yang diberikan setelah login. Cookie adalah kartu fisik yang dibawa browser kalian, dan penyimpanan session adalah meja resepsionis tempat petugas memeriksa keaslian kartu itu. Di episode ini kalian akan mengatur kartu lanyard tersebut: namanya, masa berlakunya, di mana datanya disimpan, dan bagaimana membuatnya sulit dipalsukan.
Section session mengontrol perilaku cookie dan domain yang bisa dilayani Authelia. Konfigurasi dasarnya:
session:
secret: "ganti-dengan-secret-panjang-64-karakter"
name: "authelia_session"
same_site: "lax"
inactivity: "5m"
expiration: "1h"
remember_me: "1M"
cookies:
- domain: "example.com"
authelia_url: "https://auth.example.com"Setiap field punya peran spesifik:
secret: kunci untuk mengenkripsi data session yang disimpan di Redis. Wajib kuat dan acak, karena siapa pun yang memegang secret ini bisa membongkar isi session.name: nama cookie yang dipakai browser, defaultnya authelia_session.inactivity: session kedaluwarsa setelah pengguna tidak aktif selama durasi ini. Nilai singkat seperti 5m menutup session otomatis ketika kalian meninggalkan laptop.expiration: batas maksimal usia session, tidak peduli seberapa aktif penggunanya. Ini memaksa re-autentikasi berkala.remember_me: durasi session saat kotak "remember me" dicentang, biasanya jauh lebih panjang dari expiration.Tip
Pikirkan inactivity seperti lampu kantor yang mati otomatis setelah tidak ada gerakan, dan expiration seperti kewajiban mengganti kartu akses setiap bulan. Keduanya menutup celah saat akun sudah tidak dipakai tapi masih diingat sistem.
Saat pengguna mencentang "remember me", cookie bertahan selama remember_me (contoh 1M untuk satu bulan) alih-alih expiration yang pendek. Ini nyaman untuk perangkat pribadi, tetapi berbahaya jika dipakai di perangkat bersama. Kebijakan umum di banyak organisasi: aktifkan remember_me hanya di jaringan yang kalian percaya.
Authelia punya dua provider penyimpanan session:
session:
secret: "ganti-dengan-secret-panjang-64-karakter"
redis:
host: "redis"
port: 6379
username: "authelia"
password: "rahasia-redis"
database_index: 0session:
secret: "ganti-dengan-secret-panjang-64-karakter"
name: "authelia_session"Redis sangat disarankan untuk produksi. Karena secret session dienkripsi dengan kunci ini, pastikan secret tersebut kuat dan sama di semua instance Authelia yang berbagi Redis. Untuk ketersediaan tinggi, Authelia juga mendukung Redis Sentinel agar failover otomatis saat server Redis utama tumbang.
Cookie session adalah kunci yang memvalidasi identitas kalian di setiap permintaan. Jika cookie bisa dibaca atau dicuri, penyerang bisa meniru kalian tanpa tahu password. Tiga mekanisme pertahanan yang dimiliki cookie:
document.cookie. Authelia mengaktifkannya secara otomatis.lax (default) adalah keseimbangan yang baik antara keamanan dan fungsionalitas.Warning
Jangan menurunkan same_site: "lax" menjadi none tanpa alasan kuat. Nilai none mengharuskan koneksi HTTPS murni dan memperluas permukaan serangan CSRF. Jika sebuah layanan bermasalah dengan cookie, periksa konfigurasi proxy dan header terlebih dahulu sebelum melonggarkan SameSite.
Session hijacking tidak hanya dicegah dari sisi cookie: dengan Redis sebagai penyimpanan, kalian juga bisa memakai Redis Sentinel, serta mengatur database_index untuk memisahkan data session dari data aplikasi lain di Redis yang sama. Semakin sedikit pihak yang bisa mengakses penyimpanan session, semakin sulit session dipalsukan.
Cookie hanya dikirim ke domain yang cocok dengan atribut domainnya. Authelia menangani ini melalui list cookies tempat setiap entri mendefinisikan domain SSO yang dilindungi beserta URL portalnya:
session:
cookies:
- domain: "example.com"
authelia_url: "https://auth.example.com"
default_redirection_url: "https://app.example.com"
- domain: "example.org"
authelia_url: "https://auth.example.org"
default_redirection_url: "https://app.example.org"Beberapa aturan penting di sini:
example.com, cookie berlaku untuk seluruh subdomainnya — app.example.com, admin.example.com, dan seterusnya. Ini yang membuat SSO antar layanan di satu domain utama terasa mulus.example.com dan sub.example.com tidak bisa didaftarkan bersamaan karena saling bertabrakan.example.com dan example.net. Untuk skenario tersebut kalian membutuhkan jalur OpenID Connect, yang akan dibahas pada fase identitas di episode 17.Tip
Biasakan menguji di browser yang sama dengan developer tools. Periksa nilai cookie authelia_session, perhatikan atribut HttpOnly, Secure, dan SameSite-nya, lalu simulasikan masa tidak aktif untuk melihat kapan session kedaluwarsa. Pengamatan langsung lebih meyakinkan daripada sekadar membaca log.
Poin kunci episode ini:
inactivity menutup session yang menganggur, expiration membatasi usia maksimal, remember_me memperpanjangnya secara eksplisit.Session bersifat sementara: saat Authelia restart atau session kedaluwarsa, semuanya hilang. Tapi ada data yang harus bertahan seumur hidup — TOTP secret, kredensial WebAuthn, hingga device ID Duo. Di episode 8, kalian akan mengenal storage backend: pilihan database penyimpanan data permanen, konfigurasinya, migrasi schema, dan strategi backup yang mencegah pengguna kehilangan perangkat MFA-nya.