Pajak SSO pada Software Self-Hosted: Panduan Memilih

Pajak SSO

Pajak SSO pada perangkat lunak self-hosted adalah pola ketika aplikasinya gratis, tetapi single sign-on (SSO) menjadi satu-satunya fitur yang harus dibeli. Anda dapat menjalankan seluruh aplikasi pada VPS milik sendiri tanpa license key dan tanpa batas jumlah seat. Kemudian, saat membuka halaman autentikasi dalam dokumentasi, Anda menemukan OpenID Connect (OIDC) atau SAML (security assertion markup language) hanya tersedia pada paket berbayar.

Hal ini lebih penting daripada fitur biasa yang dikunci di balik pembayaran, karena SSO membuat sekumpulan service self-hosted berperilaku seperti satu sistem. Identity provider (IdP) menyediakan satu akun untuk setiap orang, satu kebijakan password, satu tempat untuk mengaktifkan multi-factor authentication (MFA), dan satu tempat untuk menonaktifkan akses seseorang. Tanpa SSO, setiap aplikasi tetap memiliki database user kecilnya sendiri, dan Anda harus mengelola masing-masing secara manual.

Pola ini sudah cukup lama hingga memiliki papan peringkat publik. SSO Wall of Shame di sso.tax mencantumkan vendor yang mengenakan biaya premium besar untuk single sign-on, dengan entri sejak 2018. Penulisnya menetapkan batas yang wajar: "Jika dukungan SSO Anda hanya menaikkan harga sebesar 10%, Anda tidak masuk daftar ini." Sebagian besar entri dalam daftar tersebut adalah perangkat lunak closed source. Logika penetapan harga yang sama kini juga muncul pada proyek open source yang Anda host sendiri.

Mengapa maintainer menempatkan single sign-on di tier berbayar

Ada dua alasan, dan keduanya masuk akal. SSO mahal untuk didukung, dan ini merupakan salah satu dari sedikit fitur yang bersedia dibayar oleh organisasi besar.

Biaya dukungannya nyata karena integrasi identitas tidak pernah benar-benar selesai. Setiap IdP memformat claim dengan cara yang sedikit berbeda. Pemetaan grup, masa berlaku sesi, URL pengalihan, dan perbedaan waktu masing-masing dapat menimbulkan bug login. Bug login dapat mengunci semua pengguna sekaligus, sehingga tiket tersebut harus segera ditangani. Setelah itu, muncul permintaan lanjutan: grup bertingkat, pemetaan peran, provisioning otomatis dengan SCIM (system for cross-domain identity management), serta audit log yang akan dibaca oleh tim kepatuhan.

Sisi pendapatannya lebih berkaitan dengan perhitungan daripada niat buruk. Perusahaan yang tidak dapat menghubungkan aplikasi ke IdP miliknya sendiri tidak akan menerapkannya sama sekali. Karena itu, SSO menjadi pembatas yang jelas antara pengguna yang membayar dan pengguna yang tidak membayar. Proyek open core harus menempatkan pembatas tersebut di suatu tempat. SSO lebih tepat untuk tujuan itu daripada hampir semua fitur lain. Karena itu, banyak proyek memilihnya.

Ada satu hal yang perlu diluruskan dari keluhan yang umum disampaikan: periksa changelog sebelum berasumsi bahwa sebuah fitur telah dihapus, karena penghapusan akan tercantum dalam release notes. Dari proyek-proyek yang saya periksa untuk tulisan ini, fitur SSO berbayar sejak awal memang dibuat untuk tier berbayar. Saya tidak menemukan kasus SSO gratis yang sebelumnya berfungsi kemudian dihentikan. Grafana adalah contoh yang umum. Halaman SAML-nya memuat catatan satu baris, "Available in Grafana Enterprise and Grafana Cloud", sedangkan OAuth generik terhadap issuer milik Anda sendiri tetap berfungsi pada build open source.

Biaya nyata yang ditimbulkan SSO

Biaya uang adalah bagian yang lebih kecil. Paket berbayar dijual berdasarkan jumlah pengguna, sehingga tagihan bertambah seiring pertumbuhan tim, sementara hosting dan upgrade tetap menjadi tanggung jawab Anda.

Biaya yang lebih besar adalah pekerjaan identitas manual. Dampaknya muncul di empat hal berikut.

• Satu penyimpanan kata sandi untuk setiap aplikasi. Satu kata sandi yang digunakan ulang menjadi celah pada setiap aplikasi yang menggunakannya.
• Proses offboarding yang mengandalkan ingatan. Anda harus mengingat setiap layanan yang pernah diakses seseorang. Layanan yang terlupakan justru dapat menjadi masalah.
• MFA yang dikonfigurasi satu per satu untuk setiap aplikasi, jika aplikasi tersebut mendukungnya.
• Login bersama. Inilah yang benar-benar terjadi pada tim kecil yang menghadapi tekanan seperti ini.

Poin terakhir perlu dijelaskan secara khusus. Jika sebuah tim menggunakan satu akun administrator bersama dalam document manager, audit trail mencatat satu nama untuk semua aktivitas. Akibatnya, Anda tidak dapat mengetahui siapa yang menghapus invoice. Izin per pengguna juga tidak berfungsi karena hanya ada satu pengguna. Inilah dampak sebenarnya dari biaya SSO: tim kecil terdorong menggunakan satu akun bersama, yang lebih buruk daripada semua alternatif tersebut.

Daftar periksa sebelum Anda mengadopsi apa pun

Jalankan ini sebelum docker compose up, bukan setelah aplikasi menyimpan 400 dokumen.

1. Buka halaman autentikasi dalam dokumentasi dan baca catatan tingkat layanan di bagian atas. Fitur berbayar memiliki lencana atau kalimat satu baris yang menjelaskan ketersediaannya.
2. Pastikan aplikasi mendukung OIDC atau SAML ke issuer milik Anda sendiri, bukan hanya ke daftar tetap penyedia publik.
3. Periksa pemetaan peran dan grup. Membuat pengguna baru baru menyelesaikan separuh pekerjaan. Menetapkan izin secara manual di sepuluh aplikasi adalah separuh pekerjaan yang paling merepotkan.
4. Periksa apakah aplikasi menerima username yang telah diautentikasi dalam header dari proxy tepercaya, serta apakah Anda dapat menetapkan proxy mana yang dipercaya.
5. Baca riwayat lisensi di git, dan periksa apakah kontributor menandatangani CLA (contributor licence agreement).
6. Periksa proses offboarding. Cari tahu apa yang terjadi pada token API (application programming interface) dan sesi aktif ketika akun IdP dinonaktifkan.

Item 2 adalah penyebab kekecewaan yang paling sering. Tombol "Sign in with Google" bukan OIDC dengan penyedia identitas Anda. Tombol itu adalah integrasi tetap dengan satu vendor. Dukungan yang sebenarnya meminta URL issuer dari Anda. Informasi lainnya diperoleh melalui discovery. Anda dapat mengonfirmasi sisi penyedia Anda dengan satu perintah.

curl -s https://id.example.com/.well-known/openid-configuration \
  | jq '.issuer, .authorization_endpoint, .token_endpoint'

Tiga URL akan dikembalikan oleh penyedia yang berfungsi dengan baik. Hasil kosong atau 404 biasanya berarti path discovery salah. Path tersebut bergantung pada penyedia: Keycloak menerbitkannya di bawah /realms/<realm>/.well-known/openid-configuration. Jika aplikasi sama sekali tidak memiliki kolom untuk URL issuer, aplikasi tersebut tidak dapat berkomunikasi dengan IdP Anda, apa pun yang dinyatakan dalam daftar fiturnya.

Item 6 sering baru diketahui beberapa minggu setelah seseorang meninggalkan organisasi. Menonaktifkan akun di IdP menghentikan login baru. Tindakan itu tidak mencabut token API yang sebelumnya diterbitkan aplikasi, karena aplikasi memvalidasi token tersebut sendiri dan tidak pernah menanyakannya kepada IdP. Oleh karena itu, offboarding memiliki dua langkah: nonaktifkan akun di IdP, lalu hapus pengguna atau tokennya di setiap aplikasi.

Isi sebenarnya dari lencana tier

Informasi ini diverifikasi berdasarkan dokumentasi masing-masing proyek pada Agustus 2026. Mulailah dari sisi berbayar.

Grafana mencantumkan SAML sebagai "Available in Grafana Enterprise and Grafana Cloud", bersama sinkronisasi tim dan penyediaan SCIM. Generic OAuth, GitHub OAuth, LDAP (lightweight directory access protocol), dan auth proxy semuanya tersedia dalam build open source. Jadi, pengguna self-hosting skala kecil tetap dapat login melalui provider mereka sendiri. Batas fitur berbayar berada pada SAML, bukan pada single sign-on secara keseluruhan. Inilah nuansa yang sering dihilangkan oleh istilah "SSO tax".

Metabase lebih tegas. Dokumentasinya menyatakan, "SAML authentication is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud)." Edisi open source tetap menyediakan login dengan kata sandi dan LDAP.

Passbolt menandai dokumentasi SSO-nya sebagai Pro dan Cloud. Jadi, edisi community tidak memiliki fitur tersebut. Provider yang didokumentasikan mencakup Keycloak dan Entra ID.

Sekarang sisi lainnya, karena pola ini sama sekali tidak berlaku secara universal.

• GitLab Self-Managed mencantumkan "Tier: Free, Premium, Ultimate" pada halaman SAML-nya. Jadi, penggunaan SAML terhadap GitLab Anda sendiri tidak dikenai biaya.
• Paperless-ngx mengonfigurasi OIDC melalui django-allauth dengan PAPERLESS_SOCIALACCOUNT_PROVIDERS, menyembunyikan formulir login lokal dengan PAPERLESS_DISABLE_REGULAR_LOGIN, dan memetakan claims ke groups dengan PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS.
• Planka menerima OIDC_ISSUER, OIDC_CLIENT_ID, dan OIDC_CLIENT_SECRET, menggunakan scope openid profile email secara default, serta menjadikan pengguna sebagai administrator berdasarkan role claim dengan OIDC_ADMIN_ROLES.
• BookStack beralih menggunakan AUTH_METHOD=oidc, kemudian memetakan groups dari provider ke roles miliknya sendiri dengan OIDC_USER_TO_GROUPS=true dan OIDC_GROUPS_CLAIM.
• Vaultwarden merilis "support for SSO with OpenID Connect" pada 1.35.0 tanggal 27 December 2025, melalui pull request dari kontributor yang sebelumnya membawa fitur tersebut dalam sebuah fork.
• listmonk telah menyediakan login OIDC bersama user roles sejak v4.0.0.

Gunakan informasi ini saat memilih, bukan setelah Anda terlanjur berkomitmen. Papan kanban Planka dan alternatif Trello yang dapat di-host sendiri lainnya tidak memperlakukan identity dengan cara yang sama. Hal yang sama berlaku untuk BookStack, Wiki.js, dan Outline. OIDC gratis adalah fitur yang dapat Anda pertimbangkan seperti batas penyimpanan atau mobile clients. Jika Anda masih menyusun daftar, apa yang sebaiknya di-host sendiri pada 2026 adalah titik awal yang wajar. Document manager Paperless-ngx dan Vaultwarden juga menyediakan OIDC gratis saat ini.

Mengapa reverse proxy di depan aplikasi bukan single sign-on

Solusi yang umum digunakan adalah forward auth. Reverse proxy menahan setiap permintaan, menanyakan kepada layanan autentikasi apakah browser ini sudah login, lalu hanya meneruskan permintaan ke aplikasi jika jawabannya ya. authentik menyebutnya sebagai proxy provider, dengan mode forward auth untuk satu aplikasi dan mode lain untuk seluruh domain. Authelia dan oauth2-proxy menjalankan fungsi yang sama.

Blok situs Caddy terlihat seperti ini, mengikuti contoh dari authentik sendiri.

app.example.com {
  forward_auth http://authentik-outpost:9000 {
    uri /outpost.goauthentik.io/auth/caddy
    copy_headers X-Authentik-Username X-Authentik-Email X-Authentik-Groups
    trusted_proxies private_ranges
  }
  reverse_proxy app:8000
}

Kapitalisasi nama header tersebut penting di Caddy karena nama yang tidak cocok akan diterima sebagai nilai kosong. Pada setiap permintaan yang disetujui, outpost menetapkan X-authentik-username, X-authentik-email, X-authentik-groups, dan beberapa header lainnya.

Berikut manfaatnya. Tidak ada yang dapat mengakses aplikasi tanpa melewati penyedia identitas Anda terlebih dahulu. Dengan demikian, formulir login yang belum ditambal tidak lagi terekspos ke Internet, dan MFA berlaku sekaligus untuk semua layanan di belakang proxy.

Namun, hal yang tidak diberikan adalah identitas di dalam aplikasi. Aplikasi tetap memiliki akun sendiri dan definisinya sendiri tentang siapa yang sedang login. Jika semua orang melewati proxy lalu masuk ke satu akun administrator bersama, Anda memiliki pintu masuk yang kuat, tetapi hanya satu sesi anonim di baliknya. Log audit tetap menampilkan satu nama. Hak akses tetap tidak dapat dibedakan antar pengguna. Menyebut pengaturan ini sebagai SSO merupakan kesalahan keamanan karena proses pencabutan akses hanya benar sebagian: menghapus pengguna dari IdP Anda menutup pintu masuk, sedangkan token API yang dibuatnya di dalam aplikasi tetap dapat digunakan oleh siapa pun yang dapat mengakses aplikasi secara langsung.

Membuat autentikasi header tetap aman

Beberapa aplikasi menerima username dari proxy. Dengan demikian, Anda mendapatkan identitas per pengguna tanpa SSO berbayar. Nama pengaturannya berbeda-beda di setiap proyek.

Grafana menyebutnya auth proxy dan menonaktifkannya secara default. Nama header default-nya adalah X-WEBAUTH-USER. Anda dapat mengarahkannya ke header apa pun yang ditetapkan oleh proxy Anda.

[auth.proxy]
enabled = true
header_name = X-authentik-username
header_property = username
auto_sign_up = true
whitelist = 10.0.0.5

whitelist adalah baris yang sering dilewati. Dokumentasi Grafana menjelaskan bahwa pengaturan ini ada untuk mencegah pengguna memalsukan header. Karena itu, nilainya harus berisi alamat proxy Anda saja. Gitea memiliki fitur yang sama dengan nama yang berbeda dan menggunakan default yang lebih aman.

[security]
ENABLE_REVERSE_PROXY_AUTHENTICATION = true
REVERSE_PROXY_AUTHENTICATION_USER = X-WEBAUTH-USER
REVERSE_PROXY_TRUSTED_PROXIES = 10.0.0.5/32
REVERSE_PROXY_LIMIT = 1

REVERSE_PROXY_TRUSTED_PROXIES secara default bernilai 127.0.0.0/8,::1/128. REVERSE_PROXY_LIMIT menentukan jumlah proxy yang akan dipercaya oleh Gitea dalam rantai tersebut. Jika batas ini diatur ke nol, penanganan header akan dinonaktifkan sepenuhnya.

Paperless-ngx menyediakan PAPERLESS_ENABLE_HTTP_REMOTE_USER dengan PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME. Dokumentasinya juga mencantumkan peringatan yang berlaku untuk semua pengaturan ini:

Pengaturan ini memungkinkan autentikasi hanya dengan menambahkan header Remote-User: <username> ke suatu permintaan. Gunakan dengan hati-hati!

Dua aturan menjaga autentikasi header tetap aman. Keduanya berkaitan dengan keterjangkauan jaringan. Pertama, aplikasi harus tidak dapat dijangkau selain melalui proxy. Siapa pun yang dapat membuka socket ke aplikasi tersebut dapat mengirim header itu dan masuk sebagai pengguna mana pun. Di Docker, ports: ["8000:8000"] memublikasikan port pada semua interface. Karena itu, ikat port tersebut ke alamat loopback dengan ports: ["127.0.0.1:8000:8000"], atau hapus port yang dipublikasikan dan tempatkan proxy pada jaringan Docker yang sama. Kedua, proxy harus menghapus setiap salinan header yang datang dari client. Dengan demikian, satu-satunya nilai yang dilihat aplikasi adalah nilai yang ditetapkan proxy setelah autentikasi.

Periksa keduanya. Jalankan perintah pertama dari mesin di luar VPS Anda dan perintah kedua langsung pada server.

curl -si -H "Remote-User: admin" http://203.0.113.10:8000/ | head -n 1
ss -ltnp | grep 8000

Perintah curl seharusnya gagal terhubung. Selain itu, ss seharusnya menampilkan 127.0.0.1:8000, bukan 0.0.0.0:8000. Baris pertama yang berisi HTTP/1.1 302 Found berarti aplikasi merespons Internet publik secara langsung. Dengan demikian, siapa pun dapat masuk sebagai pengguna mana pun dengan mencantumkan nama pengguna tersebut dalam header.

Tentukan pilihan ketika tidak ada SSO gratis

Empat opsi berikut saya coba dalam urutan ini.

1. Pilih aplikasi yang menyertakan OIDC. Jika dua proyek menjalankan fungsi yang sama dan salah satunya dapat terhubung ke identity provider Anda secara gratis, itu merupakan perbedaan nyata dalam biaya operasional.
2. Gunakan forward auth secara tepat. Untuk alat administrasi dengan satu akun dan satu operator, proxy di depannya sudah cukup, dan identitas per pengguna di dalam aplikasi tidak memberikan manfaat tambahan.
3. Bayar. Jika aplikasi tersebut penting bagi pekerjaan Anda dan harga per pengguna sesuai dengan ukuran tim, biaya itu membantu proyek tetap dipelihara, sementara alternatifnya adalah membayar dengan waktu luang Anda.
4. Hubungi upstream setelah mencari di issue tracker. Dukungan OIDC Vaultwarden hadir melalui fork milik kontributor dan pull request yang berlangsung lama. Jadi, permintaan fitur yang disertai implementasi yang berfungsi terkadang dapat masuk ke edisi gratis.

Semua ini tidak akan berfungsi tanpa identity provider milik Anda sendiri. Komponen itulah yang perlu dibangun terlebih dahulu. Menjalankan authentik pada VPS menyediakan provider OIDC dan SAML serta forward auth outpost yang digunakan di atas. perbandingan Keycloak, authentik, dan Zitadel menjelaskan komprominya jika Anda belum ingin menentukan pilihan.

Riwayat lisensi dan alasan item ini ada dalam checklist

Item terakhir dalam checklist membahas masa depan karena susunan tingkat lisensi saat ini hanya merupakan gambaran pada satu waktu. Dua kasus yang terdokumentasi dengan baik menunjukkan betapa cepat kondisinya dapat berubah ke kedua arah. HashiCorp mengadopsi Business Source License 1.1 untuk semua rilis mendatang pada 10 August 2023, sedangkan rilis sebelumnya tetap menggunakan MPL 2.0 (Mozilla Public License). Redis beralih ke SSPL (server side public license) pada March 2024, lalu mengumumkan pada 1 May 2025 bahwa Redis 8 juga dirilis berdasarkan AGPLv3 (GNU Affero General Public License).

Gunakan kedua kasus tersebut sebagai bukti tentang mekanismenya, bukan motifnya. Lisensi yang Anda baca hari ini berlaku untuk versi yang Anda instal hari ini. Proyek yang memiliki seluruh hak cipta atas kodenya dapat mengubah ketentuan untuk rilis berikutnya secara sepihak. Karena itu, pertanyaan tentang CLA ada dalam checklist. Pengalihan hak cipta secara luas memungkinkan relicensing sepihak.

Periksa sendiri riwayat proyek sebelum menjadikannya sebagai dasar.

git clone --filter=blob:none https://github.com/paperless-ngx/paperless-ngx.git
cd paperless-ngx
git log --follow --oneline -- LICENSE

Daftar singkat commit, yang sebagian besar berasal dari import pertama, merupakan pertanda baik. Jika file lisensi telah ditulis ulang beberapa kali, baca pesan setiap commit sebelum Anda menyusun rencana berdasarkan ketentuan saat ini.

FAQ

Apa yang dimaksud dengan pajak SSO?

Pajak SSO adalah praktik mengenakan biaya untuk single sign-on sebagai fitur premium, sementara bagian lain dari produk tersedia gratis atau dengan harga murah. Pada software self-hosted, bentuknya adalah aplikasi open source yang dapat dijalankan tanpa licence key, tetapi login OIDC atau SAML hanya tersedia pada tier berbayar. Istilah ini berasal dari SSO Wall of Shame di sso.tax, yang melacak vendor yang mengenakan biaya premium tinggi untuk fitur tersebut. Bagi pengguna self-hosted, akibatnya setiap aplikasi tetap memiliki database pengguna sendiri, sehingga akun harus dibuat dan dihapus secara manual.

Apakah reverse proxy dengan forward auth sama dengan SSO?

Tidak. Forward auth melindungi pintu masuk: proxy memeriksa identity provider sebelum permintaan apa pun mencapai aplikasi. Aplikasi di belakangnya tetap menggunakan akun sendiri. Jadi, jika semua orang masuk melalui satu login bersama, Anda hanya mendapatkan satu sesi anonim dan access log yang mencatat satu nama. Identitas per pengguna baru dapat diterapkan ketika aplikasi membaca username dari header. Grafana's auth proxy, Gitea's reverse proxy authentication, dan PAPERLESS_ENABLE_HTTP_REMOTE_USER milik Paperless-ngx semuanya dapat melakukannya. Pengaturan tersebut aman hanya selama aplikasi tidak dapat dijangkau selain melalui proxy, karena header itu hanyalah string biasa yang dapat dikirim oleh client mana pun.

Aplikasi self-hosted mana yang menyertakan OIDC dalam edisi gratis?

Diperiksa berdasarkan dokumentasi proyek pada Agustus 2026: Paperless-ngx, Planka, BookStack, Gitea, listmonk, dan Vaultwarden semuanya mendukung OIDC dalam build gratisnya. GitLab Self-Managed mencantumkan SAML dalam Tier: Free. Build open source Grafana mendukung OAuth generik terhadap issuer milik Anda sendiri, sedangkan SAML pada Grafana merupakan fitur Enterprise. Konfirmasikan informasi tersebut pada halaman autentikasi proyek terkait sebelum melakukan instalasi, karena daftar ini dapat berubah seiring rilis baru.

Haruskah saya membayar tier yang membuka fitur single sign-on?

Tentukan berdasarkan 2 angka: berapa banyak orang yang memerlukan akun, dan berapa banyak aplikasi yang harus Anda kelola secara manual jika tidak membayar. Untuk 1 atau 2 administrator, forward auth di depan akun lokal sudah memadai, sehingga tier berbayar hanya memberikan sedikit manfaat. Untuk tim dengan anggota yang sering bergabung dan keluar, 1 akun yang terlewat saat proses pencabutan akses dapat menimbulkan biaya yang lebih besar daripada licence, dan pembayaran tersebut mendanai pemeliharaan yang Anda andalkan. Jika harganya tidak sesuai, langkah praktisnya adalah memilih aplikasi yang menyertakan OIDC, bukan mencari cara untuk mengatasi keterbatasan aplikasi yang tidak menyediakannya.