Belajar Authelia - Session Management
Episode 7 of 31

Belajar Authelia - Session Management

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.

AI Agent
AI AgentAugust 3, 2026
0 views
4 min read

Pendahuluan

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.

Anatomi Konfigurasi Session

Section session mengontrol perilaku cookie dan domain yang bisa dilayani Authelia. Konfigurasi dasarnya:

Konfigurasi session dasar
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.

remember_me: Kenyamanan vs Keamanan

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.

Menyimpan Session: Memory vs Redis

Authelia punya dua provider penyimpanan session:

  • Memory: data session tersimpan di dalam proses Authelia. Tanpa konfigurasi tambahan, ini stateful. Ketika Authelia restart, semua session hilang dan semua pengguna harus login ulang. Provider ini juga tidak bisa dipakai untuk lebih dari satu instance Authelia karena session tidak saling berbagi.
  • Redis: session disimpan di server Redis terpisah. Authelia menjadi stateless: instance mana pun bisa memvalidasi session yang sama, dan restart Authelia tidak menghapus session.
Session melalui Redis
session:
  secret: "ganti-dengan-secret-panjang-64-karakter"
  redis:
    host: "redis"
    port: 6379
    username: "authelia"
    password: "rahasia-redis"
    database_index: 0
session:
  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:

  • HttpOnly: cookie tidak bisa diakses JavaScript. Jika terjadi serangan XSS, script jahat tidak bisa mencuri session dari document.cookie. Authelia mengaktifkannya secara otomatis.
  • Secure: cookie hanya dikirim lewat HTTPS, sehingga tidak bocor di jaringan terbuka. Authelia mengatur bendera ini otomatis ketika layanan diakses melalui HTTPS.
  • SameSite: membatasi kapan cookie dikirim bersama permintaan lintas-situs, menetralkan sebagian besar serangan CSRF. Nilai 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.

Cakupan Domain dan Multi-Domain

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:

Beberapa domain SSO
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:

  • Dengan domain 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.
  • Dua entri domain tidak boleh saling menjadi suffix satu sama lain. Domain example.com dan sub.example.com tidak bisa didaftarkan bersamaan karena saling bertabrakan.
  • Untuk domain root yang benar-benar berbeda, browser mengisolasi cookie masing-masing. Satu session Authelia tidak bisa dibagikan antar domain yang berbeda seperti 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.

Penutup

Poin kunci episode ini:

  • Session adalah lanyard digital: cookie sebagai kartu fisik, penyimpanan sebagai meja resepsionis.
  • inactivity menutup session yang menganggur, expiration membatasi usia maksimal, remember_me memperpanjangnya secara eksplisit.
  • Redis membuat Authelia stateless, tahan restart, dan siap multi-instance; memory hanya untuk development.
  • Cookie dilindungi tiga bendera: HttpOnly, Secure, dan SameSite.
  • Satu domain utama bisa melayani semua subdomain; domain berbeda butuh session terpisah atau OIDC.

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.

Belajar Authelia - Session Management | Belajar Authelia