Belajar Authentik - Authentication Stages & MFA

#Pendahuluan

Di episode 6, kalian belajar membuat policy — termasuk pola yang memaksa sebagian user melewati MFA. Sekarang saatnya membuka bagian dalam mesin: bagaimana alur autentikasi benar-benar bekerja, dan bagaimana lapisan kedua keamanan itu dijalankan oleh Authentik.

Bayangkan sebuah gedung dengan dua pintu berlapis. Pintu pertama mengunci dengan password — siapa pun yang hafal kombinasi bisa masuk. Pintu kedua baru terbuka jika kalian juga membawa kartu akses khusus. Satu kunci saja tidak cukup; kombinasi itulah yang disebut Multi-Factor Authentication. Di episode ini kalian akan memprogram kedua pintu itu, mulai dari identification stage sampai authenticator validate stage.

#Alur Autentikasi dalam Tiga Tahap

Secara umum, alur login di Authentik berjalan melalui tiga tahap yang diwakili tiga jenis stage:

1. Identification stage: mencari tahu user mana yang mencoba login.
2. Password stage: memvalidasi kredensial user tersebut.
3. Authenticator validate stage: memeriksa perangkat MFA, jika diwajibkan.

Urutan ini bukan aturan kaku — Authentik membiarkan kalian menyusun ulang dan menambahkan stage lain — tapi ini pola default yang masuk akal. Tiap tahap menjawab pertanyaan yang berbeda: "kamu siapa", "apa bukti kamu tahu", dan "apa bukti kamu punya".

#Identification Stage

Identification stage menjawab pertanyaan pertama. Stage ini menampilkan formulir login, lalu mencari user berdasarkan username atau email. Beberapa perilaku yang bisa dikonfigurasi:

• User lookup: pencarian bisa case-insensitive, dan bisa dibatasi ke source tertentu.
• CAPTCHA bawaan: Authentik menyediakan uji CAPTCHA internal yang bisa dinyalakan untuk mempersulit bot sederhana yang mencoba menebak username.
• Pseudonym mode: mode yang menyembunyikan daftar user valid — berguna mencegah enumerasi akun.

Hasil pencarian ini disimpan sebagai user yang sedang diproses, sering disebut pending_user, di dalam flow context — data yang nanti dibaca oleh stage berikutnya dan oleh policy seperti yang kalian pelajari di episode 6.

#Password Stage

Password stage memvalidasi password terhadap authentication backend yang sudah disetel: database user internal Authentik, atau source LDAP jika kalian memakai federasi. Beberapa hal yang bisa diatur:

• Password policies: aturan kompleksitas, kedaluwarsa, dan larangan penggunaan ulang dari episode 6 ikut dievaluasi di sini.
• Remember me: opsi yang membuat session bertahan lebih lama; keputusan ini disimpan sebagai penanda session di flow context.
• Password change: stage yang sama bisa dipakai dalam flow ganti password atau reset password.

Perlu dicatat: password stage hanya memvalidasi "apa yang kamu tahu". Ia tidak menjamin keamanan jika password sudah bocor — itulah mengapa pintu kedua diperlukan.

#Authenticator Validate Stage

Inilah pintu kedua. Authenticator validate stage memeriksa apakah user memiliki perangkat MFA yang sudah terdaftar, lalu memintanya melakukan verifikasi. Yang menarik, stage ini bersifat kondisional: ia hanya berjalan jika policy yang di-bind ke stage binding tersebut lulus. Dari sinilah pola "MFA wajib untuk admin" di episode 6 bekerja.

#Metode MFA yang Didukung

Authentik mendukung beberapa jenis authenticator yang bisa didaftarkan user:

• TOTP: kode enam digit yang berubah setiap 30 detik, dihasilkan aplikasi authenticator seperti Google Authenticator atau Aegis. Standar dan paling universal.
• WebAuthn/FIDO2: passkey dan security key seperti YubiKey. Tidak memakai rahasia bersama — browser dan Authentik bertukar tanda tangan kriptografis.
• Static OTP: token sekali pakai yang dicetak sebagai backup codes. Persis seperti kunci cadangan di bawah pot bunga.
• Duo Push: notifikasi persetujuan lewat aplikasi Duo, lewat provider pihak ketiga.
• SMS atau Email OTP: bisa dibangun lewat stage kustom atau integrasi outpost/workflow, berguna saat user tidak punya perangkat authenticator.

#Duplicate Stage: Login dengan Satu dari Banyak Cara

Ada situasi di mana kalian ingin memberi user pilihan: "login dengan password ATAU passkey", atau "verifikasi dengan TOTP ATAU backup code". Inilah fungsi duplicate stage.

Duplicate stage menandai langkah yang sudah berhasil diselesaikan. Jika dalam satu alur ada beberapa stage yang ditandai sebagai duplikat satu sama lain, begitu salah satu selesai, sisanya dilewati otomatis. Analoginya seperti gerbang stasiun: setelah tiket kalian divalidasi di satu pintu, pintu antrean lain tidak perlu dilalui lagi.

Ini juga pola kunci untuk passwordless: jalankan duplicate stage WebAuthn di samping password stage, sehingga user dengan passkey bisa masuk tanpa mengetik password sama sekali.

#Enrollment dan Recovery

MFA tidak berguna jika user tidak punya cara mendaftarkan perangkat. Di sinilah peran stage setup dan flow pendukung:

• Authenticator setup stages: authenticator-totp-setup, authenticator-webauthn-setup, dan authenticator-static-setup. Setiap stage menampilkan instruksi, memvalidasi perangkat, lalu menyimpannya ke user.
• Enrollment flow: saat user baru mendaftar (default-enrollment-flow), stage setup MFA ditambahkan di akhir sehingga perangkat pertama langsung terdaftar.
• Recovery flow: default-recovery-flow digunakan saat user lupa password atau kehilangan perangkat. Alur ini biasanya memverifikasi email atau kode cadangan sebelum mengizinkan pengaturan perangkat baru.

#Mengikat MFA ke Aplikasi

Cara paling umum mengaktifkan MFA adalah mengikat policy ke stage binding authenticator validate di dalam authentication flow. Contohnya: wajibkan MFA hanya untuk anggota grup admins.

Expression policy: MFA wajib untuk grup admins

if ak_is_group_member(request.user, name="admins"):
    return True
return False

Policy ini di-bind ke stage binding authenticator validate. Hasilnya: anggota grup admins melewati pintu kedua, user biasa langsung masuk setelah password. Perhatikan cara kerjanya — policy yang gagal membuat stage dilewati, bukan membuat login berhenti. Untuk memaksa MFA, stage validation memang harus menjadi stage yang lolos hanya jika perangkat diverifikasi.

Pola kedua yang sering dipakai adalah hanya menjalankan stage setup ketika user belum punya perangkat sama sekali — misalnya dalam enrollment flow.

Expression policy: setup hanya untuk yang belum punya perangkat

return not ak_user_has_authenticator(request.user)

#Penutup

Poin kunci episode ini:

• Alur login dasar: identification stage mencari user, password stage memvalidasi kredensial, authenticator validate stage memeriksa MFA.
• Metode MFA: TOTP, WebAuthn, static OTP, Duo Push, serta SMS dan email OTP via integrasi kustom.
• Duplicate stage memungkinkan login "satu dari banyak cara" dan pola passwordless.
• Enrollment dan recovery flow menjaga siklus hidup perangkat MFA.
• MFA diaktifkan lewat policy yang di-bind ke stage binding authenticator validate.

Sekarang kedua pintu gedung sudah terprogram: identitas sudah terverifikasi, dan MFA mengamankan yang paling penting. Tinggal satu pertanyaan tersisa — bagaimana aplikasi di luar sana bisa ikut memanfaatkan semua ini? Di episode 8, kalian akan membuka pintu ketiga: membuat OAuth2 dan OIDC provider di Authentik agar aplikasi eksternal bisa login dengan standar industri.