Authentik vs ZITADEL vs Keycloak: SSO Self-Hosted Mana yang Sebaiknya Anda Pilih?

Anda punya delapan kontainer Docker yang berjalan di sebuah VPS. Gitea, Nextcloud, Grafana, Vaultwarden, n8n, Portainer, sebuah halaman status, dan satu aplikasi internal yang Anda tulis sendiri. Masing-masing punya login sendiri. Setiap pagi Anda menyalin kata sandi dari pengelola kata sandi, dan mulai bertanya-tanya apakah single sign-on sepadan dengan biaya operasionalnya.

Biasanya sepadan. Pertanyaannya adalah penyedia identitas mana yang dijalankan.

Keycloak adalah pilihan default yang sudah dikenal, tetapi pilihan yang lebih tepat bergantung pada bentuk stack Anda, berapa banyak pengguna yang Anda kelola, dan apakah Anda mengintegrasikan perangkat lunak yang sudah berjalan atau membangun autentikasi ke dalam aplikasi Anda sendiri.

Perbandingan SSO self-hosted ini melihat Authentik, ZITADEL, Keycloak, dan Authelia lewat keputusan yang penting setelah penerapan: dukungan protokol, manajemen pengguna, alur kerja developer, kebutuhan sumber daya, dan apa yang terjadi saat penyedia identitas Anda tumbang.

Mengapa SSO Self-Hosted Penting

Begitu beberapa aplikasi bergantung pada orang dan grup yang sama, login terpisah tidak lagi praktis. Penyedia identitas self-hosted memberi Anda satu tempat untuk mengelola akun, MFA, keanggotaan grup, dan kebijakan akses, alih-alih mengonfigurasi kontrol itu secara terpisah di setiap aplikasi.

Imbal baliknya sama pentingnya: IdP menjadi infrastruktur yang diandalkan aplikasi lain. Login baru dan penyegaran token bisa gagal saat IdP tidak tersedia, sehingga cadangan, akses pemulihan, peningkatan, dan uptime lebih penting di sini dibanding aplikasi self-hosted biasa.

TL;DR

Pilih Authentik Jika Anda Menginginkan Opsi Default Terbaik

Untuk homelab, stack alat internal, atau tim kecil yang menghubungkan aplikasi yang sudah ada melalui OIDC atau SAML, Authentik adalah default terkuat. Alur kerja adminnya lebih mudah didekati daripada Keycloak, mendukung beberapa metode integrasi, dan penyiapan Docker Compose resminya dimulai dari 2 inti CPU dan RAM 2 GB.

Pilih ZITADEL Jika Anda Membangun Aplikasi

Pilih ZITADEL ketika autentikasi adalah bagian dari produk yang Anda bangun. Model organisasinya, API, multi-tenancy, OIDC, SAML, passkey, MFA, dan dukungan penyedia identitas LDAP lebih masuk akal untuk tim aplikasi SaaS dan B2B daripada untuk homelab pada umumnya.

Pilih Keycloak Jika Anda Membutuhkan Fitur Identitas Enterprise

Pilih Keycloak ketika Anda memerlukan federasi LDAP atau Active Directory yang lebih dalam, beberapa realm, kebijakan otorisasi yang rinci, atau lingkungan yang sudah dibangun di sekitar Keycloak. Dokumentasinya menyarankan batas memori 2 GB untuk kontainer Keycloak kecil yang siap produksi; VPS serba ada yang juga menjalankan PostgreSQL membutuhkan ruang tambahan.

Pilihan Alternatif: Pilih Authelia Jika Anda Terutama Membutuhkan Gerbang Login

Pilih Authelia ketika masalah utama Anda adalah melindungi aplikasi di lapisan reverse proxy, bukan menjalankan platform identitas penuh. Authelia juga bisa bertindak sebagai penyedia OpenID Connect, tetapi autentikasi reverse proxy tetap menjadi pusat gravitasinya.

Apa yang Perlu Diperiksa Sebelum Memilih Alat SSO

Sebelum membandingkan fitur, petakan setiap alat terhadap aplikasi, protokol, dan sumber identitas yang sudah perlu Anda dukung.

Berapa Banyak Aplikasi yang Membutuhkan SSO?

Mulailah dari aplikasi, bukan dari penyedia identitas. Stack dengan enam aplikasi yang sudah mendukung OIDC atau SAML adalah masalah yang berbeda dari stack alat internal lama yang tidak mengenal kedua protokol tersebut. Kasus pertama mengarah ke IdP penuh. Kasus kedua mungkin membutuhkan autentikasi di lapisan reverse proxy.

Apakah Aplikasi Anda Mendukung OIDC atau SAML?

OIDC adalah pilihan umum untuk aplikasi web modern. SAML masih penting di perangkat lunak enterprise dan integrasi lama. LDAP bisa penting ketika aplikasi mengharapkan direktori, bukan alur SSO berbasis web. Periksa apa yang benar-benar diterima setiap aplikasi sebelum memilih IdP yang akan berada di tengah.

Apakah Anda Mengelola Pengguna atau Membangun Login ke dalam Aplikasi?

Jika sebagian besar pekerjaan Anda akan terjadi di antarmuka admin sambil menghubungkan aplikasi yang sudah ada, Authentik adalah titik awal yang alami. Jika autentikasi adalah bagian dari produk yang Anda bangun dan Anda berharap menyediakan organisasi, pengguna, dan izin lewat kode, ZITADEL jauh lebih dekat dengan alur kerja itu.

Apakah Anda Membutuhkan LDAP, Active Directory, atau Kebijakan Lanjutan?

Authentik, ZITADEL, dan Keycloak semuanya dapat terhubung ke sumber identitas berbasis LDAP dalam bentuk tertentu, jadi LDAP saja tidak lagi menentukan perbandingan. Keycloak menjadi lebih menarik ketika federasi direktori dipadukan dengan beberapa realm, mapper yang rinci, kebutuhan sinkronisasi, atau kebijakan otorisasi di tingkat sumber daya.

Authentik vs ZITADEL vs Keycloak vs Authelia

Keempat alat ini beririsan dalam SSO, tetapi mendekati identitas dari arah yang berbeda: integrasi aplikasi, identitas produk, IAM enterprise, dan akses reverse proxy.

Authentik

Authentik menjalankan penerapan intinya sebagai server, worker, dan basis data PostgreSQL. Redis tidak lagi menjadi bagian dari stack: Authentik menghapus dependensi itu sepenuhnya pada rilis 2025.10. Dokumentasi Docker Compose saat ini mewajibkan host dengan setidaknya 2 inti CPU dan RAM 2 GB.

Ciri khasnya adalah UI admin. Mesin alur Authentik, penyediaan aplikasi, dan kebijakan berbasis grup lebih mudah didekati daripada model konfigurasi Keycloak yang lebih luas. Jika Anda pernah menyiapkan aplikasi OIDC di Keycloak lalu menghabiskan waktu mencari tahu mengapa klaim token Anda hilang, perbedaannya cepat terasa.

Authentik mendukung SAML, OAuth2/OIDC, LDAP, dan RADIUS. Ini adalah default yang tepat untuk homelab atau tim rekayasa kecil yang menjalankan stack aplikasi self-hosted.

ZITADEL

ZITADEL ditulis terutama dalam Go, berlisensi AGPL-3.0, dan berada di jalur rilis v4.x. Penerapannya terdiri dari API Go, UI login Next.js, dan PostgreSQL; persyaratan saat ini mendukung PostgreSQL 14 hingga 18. Dokumentasi Docker Compose resmi mewajibkan host dengan setidaknya RAM 2 GB.

Ciri khasnya adalah API. ZITADEL mengekspos permukaan identitas lengkap melalui gRPC dan REST dan dibangun di atas model multi-tenant sejak awal. Jika Anda membangun produk SaaS dan ingin lapisan login yang dapat diprogram, diotomatisasi, dan multi-tenant secara default, ZITADEL lebih dekat dengan yang Anda inginkan daripada alternatifnya.

ZITADEL mendukung OIDC, SAML, passkey, MFA, penyedia identitas LDAP, dan antarmuka SCIM v2 yang saat ini ditandai Preview. Model organisasi dan alur kerja API-first membuatnya lebih cocok untuk tim produk daripada untuk homelab sederhana.

Keycloak

Keycloak adalah platform manajemen identitas dan akses berbasis Java yang berjalan di atas Quarkus. Permukaan konfigurasinya lebih luas daripada opsi lain di sini, terutama begitu Realms, Clients, Roles, federasi pengguna, dan Authorization Services ikut bermain.

Dokumentasi kontainer resminya menyarankan batas memori 2 GB untuk penerapan kecil yang siap produksi. Angka itu hanya mencakup kontainer Keycloak; jika PostgreSQL berbagi VPS yang sama, beri host ruang lebih.

Alasan untuk menerima kerumitan itu konkret. Keycloak dapat memfederasikan direktori LDAP dan Active Directory, mencatat peristiwa pengguna dan administrator, serta menerapkan otorisasi rinci menggunakan RBAC, ABAC, kebijakan berbasis pengguna, berbasis konteks, dan jenis kebijakan lainnya. Jika Anda membutuhkan kontrol tersebut, konfigurasi tambahannya punya tujuan.

Authelia

Authelia adalah yang terkecil dari keempatnya: berlisensi Apache 2.0, satu biner Go tunggal, saat ini di v4.39.x. Arsitekturnya berbeda dari tiga lainnya: Authelia berada di depan reverse proxy (nginx, Traefik, Caddy, HAProxy) dan memutuskan apakah permintaan boleh mencapai backend.

Authelia juga menyertakan penyedia OpenID Connect. Dokumentasinya masih menggambarkan implementasi OIDC sebagai beta terbuka, tetapi penyedianya sudah bersertifikat OpenID untuk profil Basic OP, Implicit OP, Hybrid OP, Form Post OP, dan Config OP. Set fitur OIDC-nya lebih sempit daripada yang disediakan Authentik atau Keycloak untuk manajemen identitas, itulah sebabnya Authelia tetap paling masuk akal ketika autentikasi reverse proxy adalah tugas utamanya.

Kita akan kembali ke Authelia di bagian tersendiri. Versi singkatnya: pusat gravitasi Authelia adalah penjagaan di reverse proxy, bukan manajemen identitas penuh.

Perbandingan Fitur

Tabel di bawah membatasi perbandingan pada perbedaan yang memengaruhi penerapan dan administrasi harian.

Alat Mana yang Cocok untuk Stack Mana?

Pilihan terbaik berubah tergantung siapa yang mengoperasikan IdP dan bagaimana aplikasi berintegrasi dengannya.

Opsi Terbaik untuk Homelab

Authentik adalah default untuk homelab di mana sebagian besar aplikasi sudah mendukung OIDC atau SAML. Ia memberi Anda penyedia identitas penuh tanpa mengharuskan Anda mengadopsi model IAM Keycloak yang lebih luas. Jika sebagian besar stack membutuhkan layar login di reverse proxy alih-alih SSO bawaan, Authelia mungkin pilihan yang lebih sederhana.

Opsi Terbaik untuk Stack Bisnis Kecil

Authentik cocok untuk sebagian besar stack aplikasi internal kecil, terutama ketika tujuannya adalah satu lapisan identitas untuk alat seperti Grafana, Gitea, Nextcloud, dan Vaultwarden. Keycloak menjadi lebih menarik ketika direktori yang sudah ada, beberapa realm, atau kebijakan otorisasi yang lebih dalam menjadi bagian dari kebutuhan.

Opsi Terbaik untuk Developer dan Produk SaaS

ZITADEL paling cocok ketika autentikasi adalah bagian dari produk yang Anda bangun. Model organisasi, multi-tenancy, API, dan permukaan otomatisasinya lebih masuk akal ketika pengguna dan tenant perlu disediakan dari kode aplikasi, bukan terutama lewat panel admin.

BACA

CIAM Self-Hosted Terbaik untuk Pembangun SaaS B2B

Opsi Terbaik untuk Tim Enterprise atau Sarat Kepatuhan

Keycloak masuk akal ketika daftar kebutuhan mencakup federasi direktori yang kompleks, beberapa realm, kebijakan otorisasi yang rinci, dan tim yang mampu mengoperasikan kerumitan IAM tambahan. Meng-hosting Keycloak sendiri tidak serta-merta membuat lingkungan patuh; cadangan, ketersediaan, pencatatan log, tinjauan akses, dan kontrol perubahan tetap menjadi tanggung jawab tim Anda.

Opsi Terbaik untuk Aplikasi Tanpa SSO Bawaan

Authelia adalah pilihan paling jelas ketika autentikasi harus terjadi sebelum permintaan mencapai aplikasi. Ia bekerja sangat baik dengan reverse proxy yang melindungi alat internal lama, dasbor, dan layanan yang tidak mendukung OIDC atau SAML sendiri.

Bagian Sulit dari Self-Hosting SSO

Begitu SSO diwajibkan, kesalahan konfigurasi atau pemulihan yang gagal dapat memengaruhi beberapa aplikasi sekaligus.

Instalasi dan Konfigurasi

Menjalankan kontainer hanyalah langkah pertama. DNS, TLS, URI pengalihan, klaim token, pemetaan grup, pengiriman email, dan akses pemulihan adalah titik di mana penerapan SSO mulai menjadi infrastruktur, bukan sekadar aplikasi Docker lainnya.

Sumber Daya Server

IdP hanyalah sebagian dari anggaran sumber daya. PostgreSQL, reverse proxy, worker, hashing kata sandi, log, dan sinkronisasi direktori semuanya bisa bersaing memperebutkan CPU dan memori ketika berbagi satu VPS.

Manajemen Basis Data dan Cadangan

Authentik, ZITADEL, dan penerapan produksi Keycloak yang normal bergantung pada basis data. Cadangkan basis data itu di luar server, dokumentasikan cara memulihkannya, dan uji pemulihannya. Tugas pencadangan yang berhasil tidak sama dengan prosedur pemulihan yang berfungsi.

Risiko Terkunci dan Pemulihan

URI pengalihan yang salah, rahasia klien yang kedaluwarsa, koneksi direktori yang putus, atau kebijakan yang terlalu ketat dapat mengunci administrator bersama semua orang. Siapkan jalur pemulihan yang tidak bergantung pada alur autentikasi yang sedang Anda perbaiki.

Menjaga IdP Tetap Tersedia

Gangguan IdP tidak selalu langsung mengakhiri setiap sesi aplikasi yang ada. Sesi yang ada mungkin berlanjut sampai token atau cookie-nya kedaluwarsa, tetapi login baru dan penyegaran token bisa gagal. Uji mode kegagalan itu sebelum mewajibkan SSO di seluruh stack.

Kapan Anda Sebaiknya Tidak Self-Host SSO

Self-hosting berhenti menjadi pilihan yang baik ketika tim Anda tidak dapat memulihkan dan mengoperasikan lapisan identitas dengan keandalan yang dibutuhkan aplikasi Anda.

Kapan Identitas Terkelola Lebih Aman

Identitas terkelola layak dibayar ketika biaya mengoperasikan IdP lebih tinggi daripada kendali yang Anda peroleh dari self-hosting. Layanan seperti Auth0, Clerk, WorkOS, dan Microsoft Entra ID memindahkan sebagian besar ketersediaan platform, patching, dan pemeliharaan infrastruktur ke penyedia.

Anda tetap memegang konfigurasi aplikasi, izin, dan perencanaan pemulihan, tetapi tidak lagi bertanggung jawab menjaga platform identitas itu sendiri tetap online.

Kapan Tim Anda Tidak Sanggup Menghadapi Downtime

Jika tidak ada seorang pun di tim yang dapat memulihkan IdP, memperbaiki PostgreSQL, mengganti rahasia yang kedaluwarsa, atau mendiagnosis koneksi federasi yang gagal selama gangguan, self-hosting identitas mungkin merupakan pertukaran operasional yang keliru.

Kegagalannya lebih luas daripada satu aplikasi yang tidak tersedia. Login baru dan penyegaran token di beberapa aplikasi bisa gagal pada saat yang sama.

Kapan Kebutuhan Kepatuhan Terlalu Tinggi

Identitas self-hosted dapat digunakan di lingkungan yang diregulasi, tetapi menjalankan perangkat lunak sendiri tidak otomatis menghasilkan kontrol atau bukti yang diharapkan auditor. Tim Anda tetap memegang pencatatan log, tinjauan akses, cadangan, manajemen perubahan, ketersediaan, respons insiden, dan dokumentasi apa pun yang diwajibkan kerangka kerja yang berlaku.

SSO self-hosted bukan simbol status. Jika tim Anda tidak dapat mengoperasikan lapisan identitas dengan aman, membayar identitas terkelola bisa menjadi keputusan rekayasa yang lebih baik.

Di Mana Cloudzy Membantu

Cloudzy mengubah lapisan penerapan; ia tidak menghilangkan pekerjaan konfigurasi identitas dan operasional yang dijelaskan di atas.

Masalah dengan Penerapan SSO Manual

Penerapan SSO manual berarti menyiapkan server, memasang aplikasi dan basis data, mengonfigurasi reverse proxy, mengatur DNS dan TLS, dan baru kemudian memulai konfigurasi identitas itu sendiri. Tidak satu pun dari itu menggantikan pekerjaan OIDC, SAML, direktori, atau kebijakan yang datang setelahnya.

Penerapan SSO Sekali Klik di Cloudzy

Cloudzy memiliki penerapan sekali klik untuk Authentik dan Keycloak. Aplikasi sekali klik Authentik tersedia di marketplace Cloudzy. Aplikasi sekali klik Keycloak juga tersedia di marketplace Cloudzy. ZITADEL saat ini tidak ada di marketplace, jadi terapkan dengan penyiapan Docker Compose-nya di VPS standar. Instalasi sekali klik membuat aplikasi dasar berjalan, sementara konfigurasi identitas, DNS, cadangan, peningkatan, kebijakan, dan pengujian pemulihan tetap berada di bawah kendali Anda.

Kapan Menggunakan VPS Terpisah untuk IdP Anda

Menempatkan IdP bersama aplikasi Anda masuk akal untuk homelab di mana downtime dapat diterima. Untuk stack yang kritis bagi bisnis, memisahkan penyedia identitas menghilangkan domain kegagalan bersama yang jelas: memulai ulang, menghabiskan sumber daya, atau menyusupi server aplikasi tidak lagi berarti menjatuhkan lapisan identitas bersamanya.

VPS terpisah tidak sama dengan ketersediaan tinggi, tetapi ia memberi IdP anggaran sumber daya, jadwal pemeliharaan, dan batas pemulihannya sendiri.

Rekomendasi Ukuran VPS

Ukur seluruh stack, bukan hanya proses IdP, terutama ketika PostgreSQL dan reverse proxy berbagi VPS yang sama.

Kebutuhan VPS Authentik

Dokumentasi Docker Compose resmi Authentik mewajibkan host dengan setidaknya 2 inti CPU dan RAM 2 GB. Itulah titik awal yang tepat untuk penerapan kecil. Beri server ruang lebih ketika PostgreSQL, outpost tambahan, sinkronisasi direktori, atau lalu lintas login yang lebih berat berbagi host yang sama.

Kebutuhan VPS ZITADEL

Penerapan Docker Compose resmi ZITADEL mewajibkan setidaknya RAM 2 GB untuk host. Ukur VPS serba ada untuk ZITADEL, UI login-nya, PostgreSQL, dan reverse proxy secara bersama-sama alih-alih memperlakukan layanan Go secara terpisah.

Kebutuhan VPS Keycloak

Dokumentasi kontainer Keycloak menyarankan batas memori 2 GB untuk penerapan Keycloak kecil yang siap produksi. Angka itu berlaku untuk kontainer Keycloak itu sendiri, bukan seluruh VPS yang juga menjalankan PostgreSQL.

Jika Keycloak dan PostgreSQL berbagi satu VPS, RAM sistem 4 GB adalah titik awal yang masuk akal. Anggap itu sebagai panduan host yang praktis, bukan minimum resmi Keycloak.

Kebutuhan VPS Authelia

Authelia tidak menerbitkan minimum server 1 GB atau 2 GB yang dapat dibandingkan langsung. Ukur host untuk Authelia bersama reverse proxy, backend penyimpanan, direktori pengguna, dan layanan lain yang berbagi mesin.

Authelia umumnya memiliki jejak penerapan yang lebih kecil daripada menjalankan IdP penuh bersama PostgreSQL, tetapi kebutuhan VPS sebenarnya bergantung pada sisa stack.

Contoh Penyiapan: Authentik dengan Vaultwarden

Vaultwarden menambahkan dukungan SSO OpenID Connect bawaan pada versi 1.35.0 pada Desember 2025. Authentik adalah contoh yang berguna karena integrasinya memperlihatkan komponen OIDC yang juga akan Anda temui di aplikasi lain: URI pengalihan, kredensial klien, scope, URL issuer, dan akses pemulihan.

Penyiapan Dasar Authentik

Di Authentik:

1. Buat pemetaan scope email kustom untuk Vaultwarden. Vaultwarden mewajibkan scope email mengembalikan email_verified: true atau tidak mengembalikan nilai email_verified sama sekali, sedangkan scope email default Authentik saat ini mengembalikan false.
2. Buat sepasang aplikasi dan penyedia OAuth2/OpenID Connect.
3. Tambahkan https://vault.example.com/identity/connect/oidc-signin sebagai URI pengalihan Authorization yang ketat.
4. Pilih kunci penandatanganan apa pun yang tersedia.
5. Catat Client ID, Client Secret, dan slug aplikasi.
6. Atur masa berlaku token akses menjadi lebih dari lima menit.
7. Tambahkan pemetaan offline_access milik Authentik ke scope yang dipilih.
8. Ganti pemetaan email default dengan pemetaan email terverifikasi kustom dari langkah 1.

Penyiapan OIDC Dasar Vaultwarden

Gunakan:

DOMAIN=https://vault.example.com
SSO_ENABLED=true
SSO_AUTHORITY=https://idp.example.com/application/o/vaultwarden/
SSO_CLIENT_ID=vaultwarden
SSO_CLIENT_SECRET=<paste-secret-from-authentik>
SSO_SCOPES=email profile offline_access
SSO_ALLOW_UNKNOWN_EMAIL_VERIFICATION=false
SSO_CLIENT_CACHE_EXPIRATION=0
SSO_ONLY=false
SSO_SIGNUPS_MATCH_EMAIL=true

Ganti domain contoh, slug aplikasi, ID klien, dan rahasia klien dengan nilai dari penerapan Anda sendiri, lalu mulai ulang Vaultwarden.

BACA

Self-Host Password Manager Bitwarden: Panduan Lengkap

Apa yang Perlu Diuji Sebelum Mewajibkan SSO

Biarkan SSO_ONLY tetap false selagi Anda menguji login, logout, penyegaran token, pencocokan akun, dan pemulihan. Uji juga apa yang terjadi saat Authentik sementara tidak tersedia.

Setelah SSO dan pemulihan berfungsi seperti yang diharapkan, Anda dapat memutuskan apakah mewajibkan SSO untuk setiap login masuk akal untuk penerapan Anda.

Konsep OIDC yang sama berlaku untuk aplikasi self-hosted lainnya, tetapi URI pengalihan, scope, klaim, dan lisensinya berbeda. Periksa dokumentasi SSO setiap aplikasi alih-alih menyalin konfigurasi Vaultwarden secara langsung.

Kapan Authelia Lebih Baik daripada IdP Penuh

Authelia menjadi lebih menarik ketika aplikasi sama sekali tidak perlu memahami penyedia identitas.

Autentikasi Reverse Proxy

Authelia terutama dirancang untuk melindungi aplikasi di lapisan reverse proxy. Anda mendefinisikan aturan kontrol akses, dan Authelia memutuskan apakah permintaan boleh mencapai backend sebelum aplikasi itu sendiri menangani autentikasi.

Melindungi Aplikasi Tanpa OIDC

Ini berguna untuk alat internal lama, dasbor, dan layanan yang tidak mendukung OIDC atau SAML. Alih-alih memodifikasi setiap aplikasi, Anda dapat menempatkan autentikasi di depannya, di reverse proxy.

Authelia juga dapat bertindak sebagai penyedia OIDC, tetapi autentikasi reverse proxy tetap menjadi kekuatan utamanya.

Menggunakan Authelia Bersama Authentik

Anda dapat menggunakan Authentik untuk aplikasi yang mendukung OIDC atau SAML dan Authelia untuk aplikasi yang membutuhkan autentikasi di reverse proxy.

Anda tidak selalu membutuhkan keduanya. Authentik juga mendukung perlindungan aplikasi berbasis proxy, jadi menggunakan Authelia di sampingnya hanya masuk akal ketika alur kerja reverse proxy Authelia menyelesaikan bagian tertentu dari stack Anda dengan lebih rapi.

Pertanyaan yang Sering Diajukan

Apakah Authentik Lebih Baik daripada Keycloak?

Untuk sebagian besar homelab dan stack aplikasi self-hosted kecil, Authentik lebih mudah didekati. Alur kerja adminnya berfokus pada aplikasi, penyedia, grup, dan kebijakan tanpa memaparkan kerumitan IAM sebanyak itu sekaligus.

Keycloak lebih masuk akal ketika Anda secara khusus membutuhkan federasinya yang lebih dalam, model realm, atau Authorization Services. Authentik adalah default yang lebih kuat untuk SSO self-hosted yang lebih sederhana; Keycloak cocok untuk lingkungan yang membutuhkan kontrol tambahan tersebut.

Apakah ZITADEL Lebih Baik daripada Keycloak?

ZITADEL lebih cocok ketika Anda membangun produk dan menginginkan identitas yang digerakkan API, organisasi, dan multi-tenancy. Keycloak lebih cocok ketika Anda membutuhkan model otorisasinya yang lebih dalam, kontrol federasi yang luas, atau lingkungan yang sudah dibangun di sekitar Keycloak.

Apa Perbedaan Antara Authentik dan Authelia?

Authentik adalah penyedia identitas penuh yang dibangun di sekitar pengguna, grup, aplikasi, penyedia, alur, dan kebijakan. Aplikasi dapat berintegrasi langsung dengannya melalui protokol seperti OIDC dan SAML.

Authelia berpusat pada autentikasi dan kontrol akses di reverse proxy. Ia juga menyertakan penyedia OIDC, tetapi perlindungan reverse proxy tetap menjadi kasus penggunaan utamanya.

Pilih Authentik ketika aplikasi berintegrasi langsung dengan IdP. Pilih Authelia ketika autentikasi terutama perlu terjadi sebelum lalu lintas mencapai aplikasi.

Bisakah Saya Menjalankan Authentik di VPS 1 GB?

Tidak sebagai titik awal yang didukung. Dokumentasi Docker Compose Authentik saat ini mewajibkan setidaknya 2 inti CPU dan RAM 2 GB. Penerapan inti saat ini menggunakan server Authentik, worker, dan PostgreSQL; Redis dihapus sepenuhnya pada Authentik 2025.10.

Gunakan 2 GB sebagai titik awal minimum untuk instalasi kecil dan tambahkan ruang ketika layanan lain berbagi mesin.

Apakah Vaultwarden Mendukung SSO OIDC?

Ya. Vaultwarden menambahkan dukungan SSO OpenID Connect pada versi 1.35.0 pada Desember 2025. Ia membutuhkan penyedia OIDC eksternal seperti Authentik, Keycloak, atau ZITADEL.

Konfigurasi persisnya bergantung pada penyedia. Dengan rilis Authentik saat ini, integrasi yang terdokumentasi mencakup pemetaan scope email terverifikasi kustom, offline_access, kredensial klien, dan URL issuer aplikasi Authentik.

Haruskah Saya Menjalankan IdP di VPS yang Sama dengan Aplikasi Saya?

Untuk homelab di mana downtime dapat diterima, menempatkannya bersama bisa masuk akal. Untuk aplikasi yang kritis bagi bisnis, VPS terpisah memberi penyedia identitas anggaran sumber dayanya sendiri dan mengeluarkan server aplikasi dari domain kegagalan bersama.

Itu tidak menciptakan ketersediaan tinggi dengan sendirinya, tetapi mulai ulang server aplikasi, masalah sumber daya, atau penyusupan tidak lagi otomatis menjatuhkan IdP bersamanya.

SSO Self-Hosted Mana yang Paling Mudah Digunakan?

Authentik adalah titik awal termudah bagi kebanyakan orang yang menghubungkan aplikasi self-hosted yang sudah ada. UI adminnya membuat aplikasi, penyedia, grup, dan kebijakan lebih mudah didekati daripada model realm dan otorisasi Keycloak yang lebih luas.

Authelia bisa lebih sederhana ketika Anda hanya membutuhkan autentikasi reverse proxy. ZITADEL lebih masuk akal ketika orang yang mengonfigurasi identitas adalah developer yang bekerja terutama lewat API.