Mengapa SSO Dikenakan Bayaran dalam Perisian Open Source?

Apakah itu cukai SSO

Cukai SSO dalam perisian yang dihoskan sendiri (self-hosted) ialah corak di mana aplikasi diberikan secara percuma, namun single sign-on (SSO) merupakan satu-satunya ciri yang perlu dibeli. Anda boleh menjalankan keseluruhan aplikasi pada VPS sendiri tanpa kunci lesen dan tanpa had bilangan pengguna. Kemudian, apabila anda membuka halaman pengesahan dalam dokumentasi, anda mendapati OpenID Connect (OIDC) atau SAML (security assertion markup language) diletakkan di bawah pelan berbayar.

Perkara ini lebih penting daripada ciri berbayar biasa, kerana SSO adalah elemen yang menjadikan sekumpulan servis yang dihoskan sendiri berfungsi sebagai satu sistem. Identity provider (IdP) memberikan anda satu akaun bagi setiap orang, satu polisi kata laluan, satu tempat untuk mengaktifkan multi-factor authentication (MFA), dan satu tempat untuk menyahaktifkan akses seseorang. Tanpanya, setiap aplikasi menyimpan pangkalan data pengguna kecilnya sendiri, dan anda perlu menyelenggara setiap satu secara manual.

Corak ini sudah cukup lama sehingga mempunyai papan skor awam. SSO Wall of Shame di sso.tax menyenaraikan vendor yang mengenakan premium tinggi untuk single sign-on, dengan entri yang bermula sejak tahun 2018, dan penulisnya menetapkan penanda aras yang adil: "Jika sokongan SSO anda hanya menyebabkan kenaikan harga sebanyak 10%, anda tidak tersenarai dalam senarai ini." Kebanyakan daripada senarai tersebut adalah perisian tertutup. Logik harga yang sama kini muncul dalam projek sumber terbuka yang anda hoskan sendiri.

Mengapa penyelenggara meletakkan single sign-on di sebalik tier berbayar

Terdapat dua sebab dan kedua-duanya adalah jujur. SSO mahal untuk disokong, dan ia merupakan salah satu daripada beberapa ciri yang akan dibayar oleh organisasi besar.

Kos sokongan adalah nyata kerana integrasi identiti tidak pernah selesai. Setiap IdP memformat tuntutan (claims) mereka dengan sedikit perbezaan. Pemetaan kumpulan, jangka hayat sesi, URL ubah hala (redirect URLs) dan perbezaan masa (clock skew) masing-masing menghasilkan pepijat log masuk, dan pepijat log masuk akan menyekat semua pengguna sekaligus, jadi tiket tersebut adalah mendesak. Kemudian muncul permintaan susulan: kumpulan bersarang (nested groups), pemetaan peranan, peruntukan automatik dengan SCIM (system for cross-domain identity management), dan log audit yang akan dibaca oleh pasukan pematuhan.

Dari segi hasil, ia adalah aritmetik dan bukannya berniat jahat. Syarikat yang tidak dapat menyambungkan aplikasi ke IdP mereka sendiri tidak akan menggunakannya langsung, jadi SSO menandakan garis pemisah yang jelas antara pengguna yang membayar dan pengguna yang tidak membayar. Projek open core perlu meletakkan garis itu di suatu tempat. SSO terletak di atas garis itu dengan lebih kemas berbanding hampir mana-mana ciri lain, itulah sebabnya banyak projek memilihnya.

Satu pembetulan terhadap aduan biasa: semak changelog sebelum anda membuat andaian bahawa sesuatu ciri telah ditarik balik, kerana penyingkiran akan muncul dalam nota keluaran (release notes). Merentas projek yang saya semak untuk catatan ini, ciri SSO berbayar dibina untuk tier berbayar sejak awal lagi. Saya tidak menemui kes di mana SSO percuma yang berfungsi telah ditarik balik. Grafana adalah contoh tipikal di sini. Halaman SAML mereka mengandungi nota satu baris, "Available in Grafana Enterprise and Grafana Cloud", manakala OAuth generik terhadap pengeluar (issuer) anda sendiri berfungsi dalam binaan open source.

Kos sebenar cukai SSO kepada anda

Wang hanyalah sebahagian kecil daripada kos tersebut. Pelan berbayar dijual mengikut pengguna, jadi bil akan meningkat seiring dengan saiz pasukan anda, manakala tugas pengehosan dan naik taraf tetap menjadi tanggungjawab anda.

Kos yang lebih besar ialah kerja pengurusan identiti secara manual, yang memberi kesan dalam empat perkara berikut.

• Satu stor kata laluan bagi setiap aplikasi, jadi satu kata laluan yang digunakan semula menjadi kelemahan pada setiap aplikasi yang berkongsi kata laluan tersebut.
• Proses offboarding yang bergantung pada ingatan. Anda perlu mengingati setiap servis yang pernah diakses oleh seseorang, dan servis yang terlupa itulah yang paling kritikal.
• MFA yang dikonfigurasikan secara berasingan bagi setiap aplikasi, sekiranya aplikasi tersebut menyokongnya.
• Log masuk dikongsi, yang sebenarnya berlaku dalam pasukan kecil akibat tekanan kos ini.

Perkara terakhir itu memerlukan penjelasan lanjut. Apabila satu pasukan berkongsi satu akaun pentadbir dalam pengurus dokumen, jejak audit hanya merekodkan satu nama untuk semua tindakan, jadi anda tidak dapat mengenal pasti siapa yang memadamkan invois tersebut. Kebenaran mengikut pengguna juga tidak lagi berfungsi kerana hanya terdapat seorang pengguna. Itulah kerosakan sebenar akibat cukai SSO: ia mendorong pasukan kecil untuk menggunakan satu akaun yang dikongsi, yang mana lebih buruk daripada mana-mana alternatif lain.

Senarai semak untuk dilaksanakan sebelum anda menggunakan sebarang aplikasi

Jalankan langkah ini sebelum docker compose up, bukan selepas aplikasi tersebut menyimpan 400 dokumen.

1. Buka halaman pengesahan dalam dokumentasi dan baca nota peringkat (tier) di bahagian atas. Ciri berbayar mempunyai lencana atau satu baris ayat mengenai ketersediaan.
2. Pastikan aplikasi tersebut menyokong OIDC atau SAML untuk penyedia identiti (issuer) anda sendiri, bukannya terhad kepada senarai penyedia awam yang tetap.
3. Semak pemetaan peranan dan kumpulan. Mencipta pengguna hanyalah separuh daripada tugas; menetapkan kebenaran secara manual dalam sepuluh aplikasi adalah bahagian yang membebankan.
4. Semak sama ada aplikasi menerima nama pengguna yang disahkan melalui header daripada proksi yang dipercayai, dan sama ada anda boleh menetapkan proksi mana yang dipercayai olehnya.
5. Baca sejarah lesen dalam git, dan semak sama ada penyumbang menandatangani CLA (perjanjian lesen penyumbang).
6. Semak prosedur offboarding. Ketahui perkara yang berlaku kepada token API (application programming interface) dan sesi aktif apabila akaun IdP dinyahaktifkan.

Perkara 2 adalah punca utama kekecewaan. Butang "Sign in with Google" bukanlah OIDC dengan penyedia identiti anda: ia adalah integrasi tetap dengan satu vendor. Sokongan sebenar memerlukan URL issuer, dan maklumat lain diperoleh melalui discovery. Anda boleh mengesahkan bahagian penyedia anda dalam satu arahan.

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

Tiga URL akan dipaparkan daripada penyedia yang berfungsi dengan baik. Hasil kosong atau ralat 404 biasanya bermaksud laluan discovery adalah salah, dan laluan tersebut adalah khusus untuk penyedia: Keycloak menerbitkannya di bawah /realms/<realm>/.well-known/openid-configuration. Jika aplikasi tidak mempunyai medan untuk URL issuer, ia tidak boleh berhubung dengan IdP anda, tidak kira apa yang dinyatakan dalam senarai ciri.

Perkara 6 sering menjadi masalah beberapa minggu selepas seseorang berhenti kerja. Menyahaktifkan akaun dalam IdP hanya menghalang log masuk baharu. Ia tidak membatalkan token API yang dikeluarkan oleh aplikasi sebelum itu, kerana aplikasi tersebut mengesahkan token itu sendiri dan tidak pernah merujuk kepada IdP. Oleh itu, offboarding mempunyai dua langkah: nyahaktifkan akaun dalam IdP, kemudian padam pengguna atau tokennya di dalam setiap aplikasi.

Maksud sebenar lencana peringkat

Perkara ini disemak berdasarkan dokumentasi setiap projek pada Ogos 2026. Mulakan dengan bahagian berbayar.

Grafana menerbitkan SAML sebagai "Tersedia dalam Grafana Enterprise dan Grafana Cloud", bersama-sama dengan penyelarasan pasukan dan peruntukan SCIM. Generic OAuth, GitHub OAuth, LDAP (lightweight directory access protocol) dan auth proxy semuanya terdapat dalam binaan sumber terbuka, jadi pengguna self-host kecil masih boleh log masuk melalui penyedia mereka sendiri. Garis berbayar terletak pada SAML dan bukannya pada single sign-on secara keseluruhan, iaitu nuansa yang sering diabaikan oleh frasa "cukai SSO".

Metabase lebih terus terang. Dokumentasinya menyatakan, "Pengesahan SAML hanya tersedia pada pelan Pro dan Enterprise (kedua-duanya untuk self-hosted dan pada Metabase Cloud)." Edisi sumber terbuka mengekalkan log masuk kata laluan dan LDAP.

Passbolt menandakan dokumentasi SSO-nya sebagai Pro dan Cloud, jadi edisi komuniti tidak mempunyainya. Penyedia yang didokumenkan termasuk Keycloak dan Entra ID.

Sekarang bahagian yang satu lagi, kerana corak ini jauh daripada bersifat universal.

• GitLab Self-Managed membawa "Peringkat: Free, Premium, Ultimate" pada halaman SAML-nya, jadi SAML terhadap GitLab anda sendiri tidak dikenakan bayaran.
• Paperless-ngx mengkonfigurasi OIDC melalui django-allauth dengan PAPERLESS_SOCIALACCOUNT_PROVIDERS, menyembunyikan borang log masuk tempatan dengan PAPERLESS_DISABLE_REGULAR_LOGIN, dan memetakan tuntutan (claims) kepada kumpulan dengan PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS.
• Planka mengambil OIDC_ISSUER, OIDC_CLIENT_ID dan OIDC_CLIENT_SECRET, menetapkan skop lalainya kepada openid profile email, dan mempromosikan pentadbir daripada tuntutan peranan dengan OIDC_ADMIN_ROLES.
• BookStack bertukar dengan AUTH_METHOD=oidc, kemudian memetakan kumpulan penyedia kepada peranannya sendiri dengan OIDC_USER_TO_GROUPS=true dan OIDC_GROUPS_CLAIM.
• Vaultwarden mengeluarkan "sokongan untuk SSO dengan OpenID Connect" dalam 1.35.0 pada 27 Disember 2025, daripada pull request oleh penyumbang yang telah membawa ciri tersebut dalam fork.
• listmonk telah mempunyai log masuk OIDC bersama-sama dengan peranan penggunanya sejak v4.0.0.

Gunakan maklumat ini semasa anda membuat pilihan dan bukannya selepas anda membuat komitmen. Papan kanban Planka dan alternatif Trello self-hosted yang lain tidak semuanya melayan identiti dengan cara yang sama, begitu juga dengan BookStack, Wiki.js dan Outline. OIDC percuma ialah ciri yang boleh anda pertimbangkan seperti had storan atau klien mudah alih. Jika anda masih menyenaraikan pilihan, apa yang perlu di-self-host pada 2026 ialah titik permulaan yang munasabah, dan kedua-dua pengurus dokumen Paperless-ngx serta Vaultwarden memberikan anda OIDC percuma hari ini.

Mengapa proksi terbalik di hadapan aplikasi bukanlah daftar masuk tunggal (SSO)

Penyelesaian biasa ialah pengesahan hadapan (forward auth). Proksi terbalik anda menahan setiap permintaan, bertanya kepada perkhidmatan pengesahan sama ada pelayar ini telah mendaftar masuk, dan hanya kemudian menghantar permintaan tersebut kepada aplikasi. authentik memanggil ini sebagai penyedia proksi, dengan mod pengesahan hadapan untuk satu aplikasi dan satu lagi untuk keseluruhan domain. Authelia dan oauth2-proxy melakukan tugas yang sama.

Blok tapak Caddy kelihatan seperti ini, mengikut contoh 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
}

Penggunaan huruf besar bagi nama pengepala tersebut penting dalam Caddy, kerana nama yang tidak sepadan akan tiba dalam keadaan kosong. Pada setiap permintaan yang diluluskan, outpost menetapkan X-authentik-username, X-authentik-email, X-authentik-groups dan beberapa lagi.

Inilah kelebihan yang anda perolehi. Tiada sesiapa yang boleh mencapai aplikasi tanpa melalui penyedia identiti anda terlebih dahulu, jadi borang daftar masuk yang tidak ditampal (unpatched) tidak lagi terdedah kepada internet, dan MFA digunakan pada semua perkara di belakang proksi secara serentak.

Inilah perkara yang tidak anda perolehi: identiti di dalam aplikasi. Aplikasi tersebut masih mempunyai akaunnya sendiri dan pemahamannya sendiri tentang siapa yang mendaftar masuk. Jika semua orang melepasi proksi dan mendarat pada satu akaun pentadbir yang dikongsi, anda mempunyai pintu hadapan yang kukuh tetapi satu sesi tanpa nama di belakangnya. Log audit masih menunjukkan satu nama sahaja. Kebenaran masih tidak boleh dibezakan antara individu. Menyebut aturan tersebut sebagai SSO adalah satu kesilapan keselamatan, kerana cerita mengenai penamatan akses hanya separuh benar: membuang orang tersebut daripada IdP anda menutup pintu hadapan, manakala token API yang mereka cipta di dalam aplikasi akan terus berfungsi untuk sesiapa sahaja yang boleh mencapai aplikasi tersebut secara terus.

Menjadikan pengesahan pengepala selamat

Sesetengah aplikasi menerima nama pengguna daripada proksi, yang memberikan anda identiti setiap pengguna tanpa SSO berbayar. Tetapan ini mempunyai nama yang berbeza dalam setiap projek.

Grafana memanggilnya sebagai auth proxy dan ia dihantar dalam keadaan dinyahdayakan. Nama pengepala lalai ialah X-WEBAUTH-USER, dan anda boleh menghalakannya kepada mana-mana pengepala yang ditetapkan oleh proksi anda.

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

whitelist ialah baris yang sering dilangkau oleh pengguna. Dokumentasi Grafana menyatakan dengan jelas bahawa ia wujud untuk menghalang pengguna daripada memalsukan pengepala, jadi ia harus mengandungi alamat proksi anda dan tiada yang lain. Gitea mempunyai ciri yang sama di bawah nama yang berbeza, dan ia dihantar dengan tetapan lalai yang lebih selamat.

[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 ditetapkan secara lalai kepada 127.0.0.0/8,::1/128, dan REVERSE_PROXY_LIMIT ialah bilangan proksi yang akan dipercayai oleh Gitea dalam rantaian tersebut. Menetapkan had itu kepada sifar akan mematikan pengendalian pengepala sepenuhnya.

Paperless-ngx menawarkan PAPERLESS_ENABLE_HTTP_REMOTE_USER dengan PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME, dan dokumentasinya menyatakan amaran yang perlu ada pada semua tetapan ini:

Ini akan membenarkan pengesahan hanya dengan menambah pengepala Remote-User: <username> pada permintaan. Gunakan dengan berhati-hati!

Dua peraturan memastikan pengesahan pengepala selamat, dan kedua-duanya berkaitan dengan kebolehcapaian. Pertama, aplikasi mestilah tidak boleh dicapai kecuali melalui proksi, kerana sesiapa yang boleh membuka soket kepadanya boleh menghantar pengepala tersebut dan menjadi mana-mana pengguna. Dalam Docker, ports: ["8000:8000"] diterbitkan pada setiap antara muka, jadi ikat ia kepada alamat loopback dengan ports: ["127.0.0.1:8000:8000"], atau gugurkan port yang diterbitkan dan letakkan proksi pada rangkaian Docker yang sama. Kedua, proksi mesti memadamkan sebarang salinan pengepala yang tiba daripada klien, supaya satu-satunya nilai yang dilihat oleh aplikasi ialah nilai yang ditetapkan oleh proksi anda selepas pengesahan.

Semak kedua-duanya. Jalankan arahan pertama dari mesin di luar VPS anda dan yang kedua pada pelayan itu sendiri.

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

Arahan curl tersebut sepatutnya gagal untuk menyambung, dan ss sepatutnya mencetak 127.0.0.1:8000 dan bukannya 0.0.0.0:8000. Baris pertama HTTP/1.1 302 Found bermakna aplikasi tersebut menjawab terus kepada internet awam, jadi sesiapa sahaja boleh mendaftar masuk sebagai mana-mana pengguna dengan menamakan mereka dalam pengepala.

Apabila tiada SSO percuma, buat keputusan dan jangan merungut

Empat pilihan, mengikut urutan yang akan saya cuba.

1. Pilih aplikasi yang menyertakan OIDC. Apabila dua projek melakukan tugas yang sama dan salah satu daripadanya berhubung dengan pembekal identiti anda secara percuma, itu merupakan perbezaan sebenar dalam kos operasi.
2. Gunakan forward auth secara jujur. Bagi alat pentadbiran dengan satu akaun dan seorang pengendali, proksi di hadapan sudah memadai, dan identiti setiap pengguna di dalam aplikasi tidak memberikan sebarang kelebihan.
3. Bayar. Jika aplikasi tersebut penting untuk kerja anda dan harga setiap pengguna sesuai dengan saiz pasukan anda, wang tersebut membantu mengekalkan projek itu, dan alternatifnya adalah masa peribadi anda yang terkorban.
4. Tanya pihak pembangun (upstream), selepas mencari dalam penjejak isu (issue tracker). Sokongan OIDC Vaultwarden hadir melalui fork penyumbang dan pull request yang lama tertangguh, jadi permintaan ciri yang disertakan dengan implementasi berfungsi kadangkala diterima ke dalam edisi percuma.

Tiada satu pun daripada ini akan berfungsi tanpa pembekal identiti anda sendiri, yang merupakan komponen untuk dibina terlebih dahulu. Menjalankan authentik pada VPS memberikan anda pembekal OIDC dan SAML berserta outpost forward auth yang digunakan di atas, dan perbandingan antara Keycloak, authentik dan Zitadel merangkumi pertimbangan (trade-offs) jika anda belum mahu membuat keputusan muktamad.

Sejarah lesen, dan sebab ia berada dalam senarai semak

Item terakhir dalam senarai semak adalah mengenai masa depan, kerana susun atur peringkat hari ini hanyalah satu gambaran sementara. Dua kes yang didokumentasikan dengan baik menunjukkan betapa pantas keadaan berubah, dalam kedua-dua arah. HashiCorp menerima pakai Business Source License 1.1 untuk semua keluaran akan datang pada 10 Ogos 2023, manakala keluaran terdahulu kekal di bawah MPL 2.0 (Mozilla Public License). Redis beralih kepada SSPL (server side public license) pada Mac 2024, kemudian mengumumkan pada 1 Mei 2025 bahawa Redis 8 juga dikeluarkan di bawah AGPLv3 (GNU Affero General Public License).

Baca kedua-duanya sebagai bukti tentang mekanisme dan bukannya motif. Lesen yang anda baca hari ini terpakai pada versi yang anda pasang hari ini, dan sesuatu projek yang memegang semua hak ciptanya boleh menukar terma bagi keluaran seterusnya secara bersendirian. Itulah sebabnya soalan CLA berada dalam senarai semak, memandangkan penyerahan hak cipta yang luas adalah perkara yang membolehkan pelesenan semula secara unilateral dilakukan.

Semak sendiri sejarah sesuatu projek sebelum anda membina sistem di atasnya.

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

Senarai commit yang pendek, kebanyakannya daripada import pertama, adalah petanda yang baik. Beberapa penulisan semula fail lesen bermakna anda perlu membaca setiap mesej commit sebelum anda merancang berdasarkan terma semasa.

FAQ

Apakah cukai SSO?

Cukai SSO ialah amalan mengenakan bayaran untuk ciri daftar masuk tunggal (single sign-on) sebagai ciri premium, sedangkan produk selebihnya adalah percuma atau murah. Dalam perisian yang dihoskan sendiri (self-hosted), ia kelihatan seperti aplikasi sumber terbuka yang boleh dijalankan tanpa kunci lesen, tetapi log masuk OIDC atau SAML diletakkan dalam peringkat berbayar. Nama ini berasal daripada SSO Wall of Shame di sso.tax, yang menjejaki vendor yang mengenakan premium tinggi untuk ciri tersebut. Kesannya kepada pengguna yang menghoskan sendiri ialah setiap aplikasi mengekalkan pangkalan data pengguna masing-masing, jadi akaun perlu dibuat dan dipadamkan secara manual.

Adakah reverse proxy dengan forward auth sama dengan SSO?

Tidak. Forward auth melindungi pintu masuk: proksi anda menyemak dengan penyedia identiti sebelum sebarang permintaan sampai ke aplikasi. Aplikasi di belakangnya masih menggunakan akaun sendiri, jadi jika semua orang mendarat pada satu log masuk yang dikongsi, anda akan mendapat satu sesi tanpa nama dan log audit dengan satu nama sahaja. Ia hanya menjadi identiti per-pengguna yang sebenar apabila aplikasi membaca nama pengguna daripada header, yang mana proksi pengesahan Grafana, pengesahan reverse proxy Gitea dan PAPERLESS_ENABLE_HTTP_REMOTE_USER Paperless-ngx semuanya boleh lakukan. Tetapan tersebut hanya selamat jika aplikasi tidak boleh dicapai kecuali melalui proksi, kerana header tersebut hanyalah rentetan teks biasa yang boleh dihantar oleh mana-mana klien.

Aplikasi self-hosted manakah yang menyertakan OIDC dalam edisi percuma?

Disemak berdasarkan dokumentasi projek pada Ogos 2026: Paperless-ngx, Planka, BookStack, Gitea, listmonk dan Vaultwarden semuanya menyokong OIDC dalam binaan percuma mereka, dan GitLab Self-Managed menyenaraikan SAML di bawah Tier: Free. Binaan sumber terbuka Grafana mengendalikan OAuth generik terhadap pengeluar (issuer) anda sendiri, manakala SAML di sana merupakan ciri Enterprise. Sahkan pada halaman pengesahan projek itu sendiri sebelum anda memasang, kerana senarai ini berubah mengikut keluaran (releases).

Patutkah saya membayar untuk peringkat yang membuka kunci daftar masuk tunggal?

Tentukan dengan dua angka: berapa ramai orang yang memerlukan akaun, dan berapa banyak aplikasi yang perlu anda selenggara secara manual jika tidak berbuat demikian. Bagi seorang atau dua pentadbir, forward auth di hadapan akaun tempatan sudah memadai dan peringkat berbayar tidak memberikan banyak nilai. Bagi pasukan yang mempunyai ahli yang masuk dan keluar, satu akaun yang terlepas semasa proses offboarding menelan kos yang lebih tinggi daripada lesen, dan bayaran tersebut membiayai penyelenggaraan yang anda harapkan. Jika harganya tidak sesuai, langkah praktikalnya ialah memilih aplikasi yang menyertakan OIDC daripada cuba mencari jalan penyelesaian bagi aplikasi yang tidak menyediakannya.