Belajar Authentik - Arsitektur & Core Concepts

#Pendahuluan

Setelah di episode 1 kita memahami mengapa Authentik dibutuhkan — satu pintu masuk untuk banyak aplikasi — pada episode kali ini kita membedah bagaimana Authentik bekerja di balik layar. Ini episode paling penting sebelum menyentuh konfigurasi: tanpa arsitektur, semua tombol di UI Authentik hanyalah hafalan yang mudah salah terpakai.

Kita akan memetakan komponen-komponen arsitektur, memahami konsep inti (tenant, application, provider, flow, stage, policy, user & group), lalu mengikuti perjalanan satu permintaan dari browser hingga kembali membawa token. Seperti pilot yang wajib paham bagaimana sayap bekerja sebelum terbang, engineer yang memahami arsitektur Authentik akan jauh lebih cepat men-debug masalah di episode-episode berikutnya.

#Komponen Arsitektur

Authentik tidak pernah berjalan sendirian. Ia adalah satu titik koordinasi di antara beberapa komponen. Mari bedah satu per satu.

#Authentik Server

Jantungnya adalah proses server — aplikasi web yang melayani tiga hal: API (ujung tombak untuk web UI dan integrasi), web UI (antarmuka admin dan portal login pengguna), dan eksekusi flows. Secara default ia mendengarkan di port 9000. Image-nya ghcr.io/goauthentik/server. Semua permintaan dari browser maupun aplikasi pada akhirnya berujung pada server.

#Authentik Worker

Worker adalah proses pendamping yang menjalankan tugas asinkron: sinkronisasi sumber (LDAP, social login), pengiriman email, task terjadwal, dan pekerjaan background lainnya. Ia memakai image yang sama dengan server (ghcr.io/goauthentik/server) hanya dengan perintah command: worker. Jika kalian melihat perilaku aneh seperti email tidak terkirim atau sinkronisasi macet, cek dulu log worker dengan docker compose logs -f worker.

#PostgreSQL

Semua data persisten Authentik — konfigurasi, user, group, aplikasi, provider, flow, stage, policy, dan event — disimpan di PostgreSQL. Ini sumber kebenaran tunggal (source of truth). Kehilangan database berarti kehilangan segalanya, jadi episode backup akan menjadikan PostgreSQL prioritas utama.

#Redis

Redis berperan ganda: cache (session, hasil policy, dan data yang sering dibaca) dan message queue (menyalurkan tugas dari server ke worker). Karena berisi data sementara, Redis bisa dibangun ulang tanpa kehilangan data — tapi tanpa Redis, Authentik tidak akan berfungsi normal.

#Outposts

Outpost adalah komponen yang berjalan di luar server inti dan berkomunikasi dengannya untuk melayani kebutuhan khusus. Dua jenis utama: proxy outpost (berdiri di depan aplikasi untuk forward auth, image ghcr.io/goauthentik/proxy) dan LDAP outpost (menyajikan user Authentik sebagai direktori LDAP untuk aplikasi warisan). Outpost bisa berjalan embedded di dalam server (default untuk lab) atau terpisah di host atau Kubernetes lain (untuk produksi).

#Web UI (Admin Interface)

UI Authentik terdiri dari dua wajah: admin interface (tempat kalian mengelola tenant, user, flow, aplikasi — diakses oleh admin) dan interface pengguna (tempat pengguna mengelola profil, perangkat MFA, dan aplikasi yang tersedia). Episode 3 akan membawa kalian ke sana.

#Konsep Inti

Beberapa istilah akan kalian temui terus-menerus. Pahami sekarang agar tidak tersesat nanti:

• Tenant — ruang lingkup (namespace) yang terisolasi untuk branding, flow default, dan konfigurasi. Seperti "apartemen" dalam satu gedung: dinding memisahkan, pipa air bisa saja dibagikan.
• Application — sebuah aplikasi yang diaktifkan untuk SSO dan muncul di portal pengguna. Application melekat pada satu provider.
• Provider — implementasi protokol yang menghubungkan Authentik dengan aplikasi: OAuth2/OIDC, SAML, LDAP, Proxy, atau SCIM. Application + Provider = satu entri SSO.
• Source — koneksi ke sistem identitas eksternal: OAuth (Google, GitHub), SAML, atau LDAP/Active Directory. Source memungkinkan login dengan identitas dari luar.
• Flow — perjalanan autentikasi yang dijalankan untuk satu tujuan: login, pendaftaran, reset password, logout, dan lainnya.
• Stage — blok bangunan terkecil dalam sebuah flow: minta username, validasi password, minta consent, dan sebagainya.
• Policy — logika bersyarat yang mengembalikan hasil boleh/tidak boleh, dipakai untuk mengontrol akses aplikasi atau langkah dalam flow.
• User & Group — entitas identitas. User adalah manusia (atau service account), group adalah kumpulan user untuk mengelola akses secara terpusat.
• Outpost — komponen remote (proxy/LDAP) yang berdiri di luar server inti.

#Flow System

Flow adalah pembeda utama Authentik dibanding IdP lain. Setiap flow punya designation (penunjukan) yang menentukan tujuan dan cara dipanggilnya:

• Authentication flow — alur login (username, password, MFA).
• Authorization flow — alur yang menjalankan kebijakan otorisasi sebelum akses diberikan.
• Enrollment flow — alur pendaftaran pengguna baru (registrasi).
• Unenrollment flow — alur penonaktifan akun.
• Recovery flow — alur pemulihan akun (reset password).

Setiap flow dirangkai dari stages: identification, password, authenticator validation, user write, consent, email, prompt, deny, dan lainnya. Episode 4 akan membedah seluruhnya.

#Provider Types

• OAuth2/OIDC Provider — untuk aplikasi modern; menerbitkan access token dan id token JWT.
• SAML Provider — untuk aplikasi enterprise; menerbitkan assertion XML.
• Proxy Provider — untuk forward auth via reverse proxy; menyuntikkan header identitas.
• LDAP Provider — lewat LDAP outpost; menyajikan user Authentik sebagai direktori LDAP.
• SCIM Provider — provisioning otomatis user ke aplikasi target.

#Alur Autentikasi End-to-End

Inilah momen "semuanya menyatu". Ikuti perjalanan satu permintaan:

1. Pengguna membuka aplikasi (misalnya https://grafana.example.com) yang terintegrasi OIDC dengan Authentik.
2. Aplikasi belum melihat session → aplikasi mengarahkan pengguna ke endpoint authorization Authentik.
3. Authentik melihat pengguna belum login → mengeksekusi authentication flow.
4. Flow berjalan stage demi stage: identification (username), password, lalu MFA bila diminta.
5. Setelah terautentikasi, policies dievaluasi untuk memutuskan apakah pengguna boleh lanjut.
6. Jika perlu, authorization flow berjalan dan consent stage menanyakan izin aplikasi.
7. Authentik menerbitkan authorization code, browser diarahkan kembali ke aplikasi.
8. Aplikasi menukar code dengan token di endpoint token, lalu membaca identitas dari id token atau UserInfo endpoint.
9. Aplikasi membuka halaman — untuk pengguna yang sudah dikenal.

Browser            Aplikasi (SP)         Authentik
   |  1. buka app       |                      |
   |-------------------->|                      |
   |  2. redirect ke auth|                      |
   |<--------------------|                      |
   |  3. execute flow    |--------------------->|
   |  4. identification + password + MFA        |
   |<------------------->|                      |
   |  5. policies evaluasi -> 6. consent        |
   |  7. authorization code ->|                 |
   |<--------------------|  8. tukar code ->    |
   |                     |  <- id token + AT    |
   |                     |  9. halaman aplikasi |

#Glosarium Istilah

#Penutup

Pada episode 2 ini kalian telah memetakan arsitektur Authentik: server (API + web UI + eksekusi flow), worker (tugas asinkron), PostgreSQL (sumber kebenaran data), Redis (cache dan message queue), serta outposts (proxy dan LDAP) yang bisa berjalan embedded atau terpisah. Kalian juga mengenali konsep inti — tenant, application, provider, source, flow, stage, policy, user & group — dan mengikuti alur login OIDC end-to-end dari aplikasi, ke endpoint authorization, melalui flow dan policies, hingga kembali membawa token.

Poin yang harus kalian bawa:

• Server + worker + PostgreSQL + Redis adalah tulang punggung; outpost adalah perpanjangan remote.
• Flow merangkai stages; policies mengontrol keputusan di dalamnya.
• Application + Provider adalah satu entri SSO; tenant adalah namespace; source adalah pintu masuk identitas eksternal.
• Aplikasi tidak pernah melihat password — hanya token.

Di episode 3 selanjutnya kita akan mulai beraksi: memasang Authentik dengan Docker Compose — menyusun stack server, worker, PostgreSQL, Redis, dan proxy, mengelola secret lewat file .env, mem-bootstrap admin, dan memverifikasi UI Authentik pertama kalian. Sampai jumpa di episode 3!