Belajar Authentik - Sejarah, Latar Belakang & Mengapa Membutuhkan Authentik

#Pendahuluan

Setelah di episode 0 kita memastikan environment siap — skill dasar protokol identitas, Docker Compose terpasang, dan topologi laboratorium dirancang — pada episode kali ini kita mundur sejenak untuk menjawab pertanyaan yang paling menentukan: mengapa kita membutuhkan Authentik?

Pertanyaan ini bukan sekadar trivia sejarah. Memahami latar belakang menjawab tiga pertanyaan praktis: (1) apa sebenarnya masalah dari "banyak aplikasi, banyak sistem login" yang selama ini kita terima sebagai hal normal, (2) mengapa solusi yang ada — Okta, Keycloak, Authelia — tidak selalu pas untuk kebutuhan kalian, dan (3) kapan Authentik adalah pilihan yang tepat dan kapan bukan. Seperti memahami sejarah sebuah teknologi, memahami latar belakang membuat kalian tidak hanya bisa memasangnya, tapi tahu mengapa ia ada.

#Masalah: Banyak Aplikasi, Banyak Pintu Masuk

Bayangkan rumah kalian punya sepuluh pintu, dan setiap pintu punya kunci yang berbeda. Tamu yang sama harus membawa sepuluh kunci berbeda, dan kalian harus mengingat sepuluh aturan berbeda tentang siapa boleh lewat pintu mana. Itulah keadaan server self-hosted maupun kantor pada umumnya:

1. Password fatigue. Satu orang mengingat password Grafana, Nextcloud, Portainer, Jellyfin, dan puluhan aplikasi lain. Hasilnya: password diulang, ditulis di sticky note, atau dipilih yang paling mudah ditebak.
2. Kebijakan yang tidak konsisten. Satu aplikasi mewajibkan password kuat dan MFA, aplikasi lain menerima 123456. Tidak ada standar bersama.
3. Tidak ada satu titik audit. Jika sebuah akun disusupi, tidak ada satu tempat untuk melihat semua aktivitas login — setiap aplikasi mencatatnya sendiri, dengan format sendiri.
4. Keamanan bergantung aplikasi paling lemah. Satu aplikasi yang tidak punya dukungan MFA menjadi titik masuk terlemah ke seluruh jaringan.

Authentik lahir sebagai jawaban atas kekacauan ini: satu pintu masuk, satu kebijakan, satu catatan audit, dan satu tempat untuk memberlakukan MFA.

#Lanskap Identity Provider

#Solusi Komersial: Okta, Auth0, Azure AD

Okta, Auth0, dan Microsoft Entra ID (dulu Azure AD) mendominasi pasar Identity-as-a-Service. Kekuatannya: dikelola vendor, SLA terjamin, integrasi enterprise luas, dan fitur lengkap. Harganya mengikuti — biasanya per pengguna per bulan, dan biaya membengkak seiring fitur (MFA, passwordless, lifecycle management) dan volume pengguna. Untuk perusahaan besar, ini wajar. Untuk homelab, VPS pribadi, atau startup kecil, biaya bulanan berulang sering terasa tidak proporsional.

#Alternatif Open Source: Keycloak dan Authentik

Di sisi open source, dua nama terbesar adalah Keycloak (didukung Red Hat, ditulis dalam Java) dan Authentik (proyek goauthentik, ditulis dalam Python). Keduanya bisa di-self-host dengan biaya server saja. Perbedaannya menentukan pilihan kalian, dan akan kita bedah di bagian perbandingan.

#Self-Hosted vs Cloud-Hosted

• Cloud-hosted menang dalam hal kemudahan: tidak perlu memelihara server, upgrade, atau backup. Kalian membayar untuk itu.
• Self-hosted menang dalam hal kontrol dan biaya: data identitas tinggal di server kalian, tidak ada vendor lock-in, dan biayanya hanya listrik dan waktu pemeliharaan.

Untuk series ini kita fokus pada self-hosted lewat Docker Compose — pola paling umum di ekosistem Authentik dan paling mudah dipraktikkan.

#Pertimbangan Biaya

Garis besarnya: solusi komersial bisa menghabiskan ratusan juta rupiah per tahun untuk ratusan pengguna, sedangkan Authentik self-hosted di VPS kelas menengah bisa dibilang "gratis" selain biaya server dan waktu. Tapi ingat, self-hosted bukan nol biaya — ada biaya pemeliharaan, upgrade, dan risiko jika salah konfigurasi. Keputusan "komersial vs open source" adalah keputusan bisnis, bukan sekadar preferensi teknis.

#Kelahiran Authentik

Authentik dikembangkan oleh proyek goauthentik dan mulai dikenal luas sejak awal 2020-an. Ia dirancang dari dasar sebagai identity provider modern untuk aplikasi kontemporer — bukan adaptasi dari sistem lama, dan didistribusikan sebagai image Docker seperti ghcr.io/goauthentik/server dan ghcr.io/goauthentik/proxy. Beberapa ciri desainnya:

• Python-based — ditulis dalam Python dengan framework web, mudah dipahami dan dikontribusikan oleh komunitas besar Python.
• Cloud-native — didistribusikan sebagai image Docker, dirancang untuk deployment container dari hari pertama, bukan setelah melalui proses "kontainerisasi".
• UI-first — hampir semua konfigurasi dilakukan lewat antarmuka web, bukan file konfigurasi yang ditulis tangan. Ini perbedaan paling mencolok dibanding Keycloak.
• Flow-based — alur autentikasi dibangun dari blok-blok kecil bernama stages yang dirangkai menjadi flows. Fleksibilitas ini tidak dimiliki auth proxy sederhana.
• Lisensi — open source dengan lisensi MIT hingga rilis 2023.8, kemudian beralih ke BUSL (Business Source License). Source code tetap terbuka, dengan pembatasan komersial tertentu setelah masa embargo.

2021+    Proyek goauthentik mulai dikenal sebagai IdP open-source modern
2023.8   Lisensi berubah dari MIT menjadi BUSL (Business Source License)
sekarang  Aktif dikembangkan, komunitas besar, dokumentasi lengkap, Docker-first

#Filosofi: Flows & Stages sebagai Blok Bangunan

Inti dari kekuatan Authentik ada di satu ide: semua alur autentikasi dibangun dari blok kecil yang bisa dirangkai. Sebuah stage adalah satu langkah (misalnya "minta username", "minta password", "tampilkan consent"), dan sebuah flow adalah rangkaian stage yang menjalankan satu tujuan (misalnya "login", "daftar", "reset password"). Seperti LEGO: dengan beberapa puluh jenis stage, kalian bisa merakit alur login sederhana maupun alur onboarding perusahaan yang kompleks. Ini akan kita bedah tuntas di episode 4.

#Fitur Utama Authentik

• Provider lengkap — OAuth2/OIDC, SAML, dan LDAP provider dalam satu produk; plus SCIM untuk provisioning.
• Proxy provider (forward auth) — Authentik bisa berdiri di depan aplikasi via reverse proxy dan menyuntikkan identitas lewat header — fitur yang biasanya hanya ada di auth proxy khusus.
• Outposts — komponen remote (proxy, LDAP) yang bisa dideploy terpisah dari server inti untuk skala dan segmentasi jaringan.
• Policies — logika bersyarat (termasuk ekspresi Python) untuk mengontrol akses, misalnya "hanya grup admin pada jam kerja".
• MFA — TOTP, WebAuthn/FIDO2, static tokens, dan lainnya.
• Social login — OAuth sources untuk Google, GitHub, Discord, dan lainnya.
• UI-first yang bersih — antarmuka modern dan mudah dinavigasi.
• Docker-first deployment — satu file compose untuk memulai semuanya.

#Authentik vs Alternatif

#Authentik vs Keycloak

Ini perbandingan yang paling sering ditanyakan. Keycloak adalah veteran — fitur enterprise paling lengkap dan paling banyak dipakai di perusahaan. Tapi konfigurasinya berat: banyak menu, konsep realm, dan sebagian besar diatur lewat form yang rapat. Authentik menjawabnya dengan pendekatan berbeda: UI yang bersih, konsep flows yang ekspresif, dan deployment Docker yang sederhana. Ditulis dalam Python vs Java, Authentik juga terasa lebih ringan di operasional sehari-hari. Untuk proyek baru yang self-hosted, banyak engineer memilih Authentik demi pengalaman konfigurasi yang lebih manusiawi.

#Authentik vs Authelia

Authelia adalah auth proxy specialist: ia berdiri di depan aplikasi dan menangani forward authentication dengan sangat baik — ringan, satu binary Go, dan konfigurasi berbasis file. Tapi ia bukan identity provider lengkap: OIDC-nya terbatas, dan tidak ada provider SAML atau LDAP outpost. Authentik adalah IdP penuh yang juga punya kemampuan forward auth lewat proxy provider. Jika kalian hanya butuh melindungi beberapa aplikasi dengan SSO + MFA dan ingin yang serba ringan, Authelia cukup. Jika kalian butuh identity platform yang bisa diintegrasikan sebagai OIDC/SAML IdP ke aplikasi lain, Authentik jauh lebih lengkap.

#Authentik vs Zitadel

Zitadel adalah pesaing modern berbasis Go yang mengusung desain cloud-first dan fitur-fitur menarik seperti action API dan human-to-machine. Ia kuat di ekosistem cloud dan Kubernetes. Keunggulan Authentik di sini: ekosistem outpost yang memudahkan deployment di luar cluster (Docker standalone, VPS, bare metal), dokumentasi yang lebih berorientasi praktik, dan komunitas self-hosting yang sangat aktif. Keduanya mumpuni; pilihan sering turun ke preferensi deployment dan kedekatan dengan ekosistem Docker klasik.

#Kapan Memilih Authentik

• Self-hosted SSO — menyatukan login semua aplikasi di server rumah atau VPS.
• Application authentication — bertindak sebagai OIDC/SAML IdP untuk aplikasi modern.
• Forward auth untuk reverse proxy — melindungi aplikasi tanpa sistem login (Grafana, Portainer, dll.) via Traefik, NGINX, atau Caddy.
• LDAP outpost untuk legacy apps — aplikasi tua yang hanya paham LDAP bisa diautentikasi ke user Authentik.
• Social login aggregation — satu portal yang menerima login Google, GitHub, Discord, sekaligus akun lokal.
• Employee/customer identity management — SMB yang butuh manajemen identitas tanpa biaya lisensi IdP enterprise.

#Penutup

Pada episode 1 ini kita telah memahami akar masalah yang Authentik selesaikan: kekacauan banyak pintu login — password fatigue, kebijakan tidak konsisten, dan keamanan yang bergantung aplikasi paling lemah. Kita menelusuri lanskap identity provider dari solusi komersial (Okta, Auth0, Azure AD) hingga alternatif open source, melihat kelahiran Authentik oleh proyek goauthentik — Python-based, cloud-native, UI-first, berlisensi MIT hingga 2023.8 lalu BUSL — dan membandingkannya secara jujur dengan Keycloak, Authelia, dan Zitadel.

Inti yang harus kalian bawa:

• Masalah nyatanya adalah banyak aplikasi dengan banyak sistem login yang tidak terkelola.
• Authentik adalah IdP modern all-in-one: OIDC, SAML, LDAP, dan forward auth dalam satu produk.
• vs Keycloak: lebih bersih dan UI-first; vs Authelia: jauh lebih lengkap; vs Zitadel: lebih ramah ekosistem Docker dan outpost.
• Untuk self-hosting dan SMB, Authentik menang pada keseimbangan fitur dan kemudahan.

Di episode 2 selanjutnya kita akan membedah arsitektur dan konsep inti Authentik: bagaimana server, worker, PostgreSQL, Redis, dan outpost bekerja sama, apa itu tenant, application, provider, flow, stage, dan policy, serta perjalanan satu permintaan dari browser hingga kembali dengan token. Sampai jumpa di episode 2!