Self-hosted software में SSO टैक्स क्या है?

SSO टैक्स क्या है

Self-hosted software में SSO टैक्स वह पैटर्न है जहाँ एप्लिकेशन तो मुफ्त होती है, लेकिन Single Sign-On (SSO) वह एकमात्र फीचर होता है जिसके लिए आपको भुगतान करना पड़ता है। आप बिना किसी licence key या seat count के पूरी एप्लिकेशन को अपने VPS पर चला सकते हैं। फिर आप documentation में authentication पेज खोलते हैं और पाते हैं कि OpenID Connect (OIDC) या SAML (Security Assertion Markup Language) किसी पेड प्लान के अंतर्गत आते हैं।

यह किसी सामान्य paywalled फीचर से कहीं अधिक महत्वपूर्ण है, क्योंकि SSO ही वह चीज है जो कई self-hosted services को एक सिस्टम की तरह काम करने में मदद करती है। एक Identity Provider (IdP) आपको प्रति व्यक्ति एक अकाउंट, एक पासवर्ड पॉलिसी, multi-factor authentication (MFA) चालू करने के लिए एक जगह, और किसी को एक्सेस से हटाने के लिए एक ही स्थान प्रदान करता है। इसके बिना, हर ऐप का अपना एक छोटा user database होता है, और आपको हर एक को मैन्युअल रूप से मैनेज करना पड़ता है।

यह पैटर्न इतना पुराना है कि इसका एक सार्वजनिक स्कोरबोर्ड भी है। sso.tax पर मौजूद SSO Wall of Shame उन वेंडर्स की सूची देता है जो Single Sign-On के लिए भारी प्रीमियम वसूलते हैं। इसमें 2018 से लेकर अब तक की एंट्रीज शामिल हैं, और इसके लेखक ने एक उचित मानक तय किया है: "यदि आपका SSO सपोर्ट 10% मूल्य वृद्धि है, तो आप इस सूची में नहीं हैं।" उस सूची का अधिकांश हिस्सा closed software है। अब यही मूल्य निर्धारण तर्क उन open source प्रोजेक्ट्स में भी दिखाई दे रहा है जिन्हें आप स्वयं होस्ट करते हैं।

मेंटेनर्स सिंगल साइन-ऑन (SSO) को पेड टियर के पीछे क्यों रखते हैं

इसके दो कारण हैं और दोनों ही ईमानदार हैं। SSO को सपोर्ट करना महंगा है, और यह उन चुनिंदा फीचर्स में से एक है जिसके लिए एक बड़ा संगठन भुगतान करने को तैयार रहता है।

सपोर्ट की लागत वास्तविक है क्योंकि आइडेंटिटी इंटीग्रेशन कभी पूरा नहीं होता। हर IdP अपने क्लेम्स (claims) को थोड़ा अलग तरीके से फॉर्मेट करता है। ग्रुप मैपिंग, सेशन लाइफटाइम, रीडायरेक्ट URLs और क्लॉक स्क्यू (clock skew) के कारण लॉगिन बग्स पैदा होते हैं, और एक लॉगिन बग एक साथ सभी यूजर्स को लॉक कर देता है, इसलिए ये टिकट्स बहुत जरूरी होते हैं। इसके बाद अन्य अनुरोध आते हैं: नेस्टेड ग्रुप्स, रोल मैपिंग, SCIM (system for cross-domain identity management) के साथ ऑटोमैटिक प्रोविजनिंग, और ऑडिट लॉग्स जिन्हें कंप्लायंस टीम पढ़ती है।

राजस्व का पक्ष दुर्भावना के बजाय गणितीय है। जो कंपनी ऐप को अपने IdP से कनेक्ट नहीं कर सकती, वह इसे बिल्कुल भी डिप्लॉय नहीं करेगी, इसलिए SSO भुगतान करने वाले यूजर और भुगतान न करने वाले यूजर के बीच एक स्पष्ट रेखा खींचता है। एक ओपन कोर प्रोजेक्ट को वह रेखा कहीं न कहीं खींचनी पड़ती है। SSO उस रेखा पर लगभग किसी भी अन्य फीचर की तुलना में अधिक सटीकता से बैठता है, यही कारण है कि इतने सारे प्रोजेक्ट्स इसे चुनते हैं।

आम शिकायतों में एक सुधार: यह मानने से पहले कि कोई फीचर हटा दिया गया है, changelog जरूर देखें, क्योंकि किसी भी फीचर को हटाए जाने की जानकारी release notes में दिखाई देती है। इस पोस्ट के लिए मैंने जिन प्रोजेक्ट्स की जांच की, उनमें पेड SSO फीचर्स शुरुआत से ही पेड टियर के लिए बनाए गए थे। मुझे ऐसा कोई मामला नहीं मिला जहाँ काम करने वाला फ्री SSO वापस लिया गया हो। Grafana इसका एक सामान्य उदाहरण है। इसके SAML पेज पर एक लाइन का नोट है, "Available in Grafana Enterprise and Grafana Cloud", जबकि आपके अपने इश्यूअर (issuer) के खिलाफ जेनेरिक OAuth ओपन सोर्स बिल्ड में काम करता है।

SSO टैक्स की वास्तविक लागत

पैसों का नुकसान तो बस एक छोटा हिस्सा है। Paid tiers प्रति उपयोगकर्ता के हिसाब से बेचे जाते हैं, इसलिए जैसे-जैसे आपकी टीम बढ़ती है, बिल भी बढ़ता जाता है, जबकि होस्टिंग और अपग्रेड की जिम्मेदारी आपकी ही बनी रहती है।

बड़ी लागत मैन्युअल पहचान प्रबंधन (manual identity work) की है, जो चार क्षेत्रों में समस्या पैदा करती है:

• हर ऐप के लिए एक अलग पासवर्ड स्टोर, इसलिए एक बार इस्तेमाल किया गया पासवर्ड उन सभी ऐप्स के लिए खतरा बन जाता है जो उसे साझा करते हैं।
• याददाश्त के आधार पर offboarding करना। आपको हर उस सर्विस को याद रखना पड़ता है जिसे किसी व्यक्ति ने इस्तेमाल किया था, और जिसे आप भूल जाते हैं, वही सबसे महत्वपूर्ण साबित होती है।
• MFA को हर ऐप के लिए अलग से कॉन्फ़िगर करना, बशर्ते वह ऐप इसे सपोर्ट करता हो।
• साझा लॉगिन (shared logins), जो इस दबाव के कारण छोटी टीमों में वास्तव में होता है।

अंतिम बिंदु एक अलग चर्चा का हकदार है। जब कोई टीम किसी डॉक्यूमेंट मैनेजर में एक ही एडमिनिस्ट्रेटर अकाउंट साझा करती है, तो ऑडिट ट्रेल में हर गतिविधि के लिए एक ही नाम दर्ज होता है, जिससे यह पता नहीं चल पाता कि इनवॉइस किसने डिलीट किया। प्रति-उपयोगकर्ता अनुमतियाँ (per-user permissions) भी काम करना बंद कर देती हैं, क्योंकि उपयोगकर्ता केवल एक ही होता है। SSO टैक्स से होने वाला वास्तविक नुकसान यही है: यह छोटी टीमों को एक साझा अकाउंट इस्तेमाल करने के लिए मजबूर करता है, जो अन्य सभी विकल्पों से कहीं अधिक बुरा है।

किसी भी चीज़ को अपनाने से पहले की चेकलिस्ट

इसे docker compose up से पहले चलाएं, न कि तब जब ऐप में 400 दस्तावेज़ हो जाएं।

1. दस्तावेज़ों में authentication पेज खोलें और सबसे ऊपर दिए गए टियर नोट को पढ़ें। सशुल्क सुविधाओं (paid features) पर एक बैज या उपलब्धता बताने वाली एक पंक्ति होती है।
2. पुष्टि करें कि ऐप आपके अपने issuer के साथ OIDC या SAML का उपयोग करता है, न कि केवल सार्वजनिक प्रदाताओं (public providers) की एक निश्चित सूची के साथ।
3. Role और group mapping की जाँच करें। उपयोगकर्ता बनाना आधा काम है, और दस ऐप्स में मैन्युअल रूप से अनुमतियाँ (permissions) असाइन करना वह आधा हिस्सा है जो परेशानी पैदा करता है।
4. जाँचें कि क्या ऐप किसी विश्वसनीय प्रॉक्सी से हेडर में authenticated username स्वीकार करता है, और क्या आप यह निर्धारित कर सकते हैं कि वह किस प्रॉक्सी पर भरोसा करता है।
5. git में लाइसेंस इतिहास पढ़ें, और जाँचें कि क्या योगदानकर्ता CLA (contributor licence agreement) पर हस्ताक्षर करते हैं।
6. Offboarding की जाँच करें। पता लगाएँ कि जब IdP खाता अक्षम (disable) किया जाता है, तो API (application programming interface) टोकन और लाइव सत्रों (live sessions) का क्या होता है।

बिंदु 2 वह जगह है जहाँ सबसे अधिक निराशा होती है। "Sign in with Google" बटन आपके identity provider के साथ OIDC नहीं है: यह एक विक्रेता के साथ एक निश्चित एकीकरण (fixed integration) है। वास्तविक समर्थन आपसे एक issuer URL मांगता है, और बाकी सब कुछ discovery से आता है। आप एक कमांड में अपने प्रदाता की ओर से इसकी पुष्टि कर सकते हैं।

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

एक स्वस्थ प्रदाता से तीन URL वापस आते हैं। खाली परिणाम या 404 का मतलब आमतौर पर यह होता है कि discovery पथ गलत है, और वह पथ प्रदाता-विशिष्ट होता है: Keycloak इसे /realms/<realm>/.well-known/openid-configuration के अंतर्गत प्रकाशित करता है। यदि ऐप में issuer URL के लिए कोई फ़ील्ड नहीं है, तो वह आपके IdP से बात नहीं कर सकता, चाहे फीचर सूची में कुछ भी लिखा हो।

बिंदु 6 किसी के जाने के हफ़्तों बाद लोगों को मुसीबत में डालता है। IdP में खाते को अक्षम करने से नए लॉगिन रुक जाते हैं। यह ऐप द्वारा पहले जारी किए गए API टोकन को रद्द नहीं करता है, क्योंकि ऐप उस टोकन को स्वयं मान्य करता है और इसके बारे में IdP से कभी नहीं पूछता है। इसलिए offboarding के दो चरण होते हैं: IdP में खाते को अक्षम करें, फिर प्रत्येक ऐप के अंदर उपयोगकर्ता या उसके टोकन को हटा दें।

टियर बैज का वास्तविक अर्थ

अगस्त 2026 में प्रत्येक प्रोजेक्ट के अपने दस्तावेज़ीकरण के आधार पर इनकी जाँच की गई है। भुगतान वाले पक्ष से शुरुआत करते हैं।

Grafana, SAML को "Grafana Enterprise और Grafana Cloud में उपलब्ध" के रूप में प्रकाशित करता है, साथ ही टीम सिंक और SCIM प्रोविजनिंग भी इसमें शामिल है। जेनेरिक OAuth, GitHub OAuth, LDAP (लाइटवेट डायरेक्टरी एक्सेस प्रोटोकॉल) और ऑथ प्रॉक्सी सभी ओपन सोर्स बिल्ड में मौजूद हैं, इसलिए एक छोटा सेल्फ-होस्टर अभी भी अपने स्वयं के प्रदाता के माध्यम से लॉग इन कर सकता है। भुगतान की सीमा SAML पर तय होती है, न कि समग्र रूप से सिंगल साइन-ऑन पर, यही वह सूक्ष्म अंतर है जिसे "SSO टैक्स" वाक्यांश अक्सर नजरअंदाज कर देता है।

Metabase अधिक स्पष्ट है। इसका दस्तावेज़ीकरण कहता है, "SAML प्रमाणीकरण केवल Pro और Enterprise प्लान पर उपलब्ध है (सेल्फ-होस्टेड और Metabase Cloud दोनों के लिए)।" ओपन सोर्स संस्करण में पासवर्ड लॉगिन और LDAP की सुविधा बनी रहती है।

Passbolt अपने SSO दस्तावेज़ीकरण को Pro और Cloud के रूप में चिह्नित करता है, इसलिए कम्युनिटी एडिशन में यह सुविधा नहीं है। प्रलेखित प्रदाताओं में Keycloak और Entra ID शामिल हैं।

अब दूसरी तरफ देखते हैं, क्योंकि यह पैटर्न हर जगह समान नहीं है।

• GitLab Self-Managed अपने SAML पेज पर "Tier: Free, Premium, Ultimate" का उल्लेख करता है, इसलिए अपने स्वयं के GitLab पर SAML का उपयोग करने के लिए कोई शुल्क नहीं लगता है।
• Paperless-ngx, PAPERLESS_SOCIALACCOUNT_PROVIDERS के माध्यम से OIDC को कॉन्फ़िगर करता है, PAPERLESS_DISABLE_REGULAR_LOGIN के साथ स्थानीय लॉगिन फ़ॉर्म को छिपाता है, और PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS के साथ क्लेम्स को ग्रुप्स पर मैप करता है।
• Planka, OIDC_ISSUER, OIDC_CLIENT_ID और OIDC_CLIENT_SECRET लेता है, अपने स्कोप को डिफ़ॉल्ट रूप से openid profile email पर सेट करता है, और रोल क्लेम से प्रशासकों को प्रमोट करता है, जैसा कि OIDC_ADMIN_ROLES में है।
• BookStack, AUTH_METHOD=oidc के साथ स्विच करता है, फिर प्रदाता ग्रुप्स को अपने स्वयं के रोल्स पर OIDC_USER_TO_GROUPS=true और OIDC_GROUPS_CLAIM के साथ मैप करता है।
• Vaultwarden ने 27 दिसंबर 2025 को 1.35.0 संस्करण में "OpenID Connect के साथ SSO के लिए समर्थन" जारी किया, जो एक योगदानकर्ता द्वारा किए गए पुल रिक्वेस्ट से आया है, जिसने इस फीचर को एक फोर्क में रखा था।
• listmonk में v4.0.0 के बाद से उपयोगकर्ता रोल्स के साथ OIDC लॉगिन की सुविधा मौजूद है।

जब आप चुनाव कर रहे हों, तो इसका उपयोग करें, न कि प्रतिबद्ध होने के बाद। एक Planka kanban board और अन्य self-hosted Trello विकल्प सभी पहचान (identity) को एक ही तरह से नहीं संभालते हैं, और न ही BookStack, Wiki.js और Outline ऐसा करते हैं। फ्री OIDC एक ऐसा फीचर है जिसे आप स्टोरेज लिमिट या मोबाइल क्लाइंट की तरह तौल सकते हैं। यदि आप अभी भी सूची तैयार कर रहे हैं, तो 2026 में क्या सेल्फ-होस्ट करें एक उचित शुरुआती बिंदु है, और Paperless-ngx document manager तथा Vaultwarden दोनों आज आपको मुफ्त OIDC प्रदान करते हैं।

रिवर्स प्रॉक्सी को ऐप के सामने रखना सिंगल साइन-ऑन क्यों नहीं है

इसका सामान्य समाधान फॉरवर्ड ऑथ (forward auth) है। आपकी रिवर्स प्रॉक्सी प्रत्येक अनुरोध को रोकती है, एक ऑथेंटिकेशन सर्विस से पूछती है कि क्या यह ब्राउज़र साइन-इन है, और केवल तभी अनुरोध को ऐप तक पहुँचाती है। authentik इसे प्रॉक्सी प्रोवाइडर कहता है, जिसमें एक सिंगल एप्लिकेशन के लिए फॉरवर्ड ऑथ मोड और पूरे डोमेन के लिए दूसरा मोड होता है। Authelia और oauth2-proxy भी यही काम करते हैं।

authentik के अपने उदाहरण का पालन करते हुए, एक Caddy साइट ब्लॉक इस तरह दिखता है।

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
}

Caddy में उन हेडर नामों का कैपिटलाइजेशन मायने रखता है, क्योंकि नाम मेल न खाने पर वह खाली पहुँचता है। हर उस अनुरोध पर जिसे वह मंजूरी देता है, आउटपोस्ट X-authentik-username, X-authentik-email, X-authentik-groups और कुछ अन्य सेट करता है।

इससे आपको यह लाभ मिलता है। कोई भी व्यक्ति आपके आइडेंटिटी प्रोवाइडर से गुजरे बिना ऐप तक नहीं पहुँच सकता, इसलिए एक अनपैच्ड लॉगिन फॉर्म अब इंटरनेट के लिए एक्सपोज़्ड नहीं रहता है, और MFA प्रॉक्सी के पीछे की हर चीज़ पर एक साथ लागू होता है।

इससे आपको यह लाभ नहीं मिलता: ऐप के अंदर की आइडेंटिटी। ऐप के पास अभी भी अपने स्वयं के अकाउंट और इस बात की अपनी समझ होती है कि कौन साइन-इन है। यदि हर कोई प्रॉक्सी से गुजरता है और एक साझा एडमिनिस्ट्रेटर अकाउंट पर पहुँचता है, तो आपके पास एक मजबूत मुख्य द्वार है लेकिन उसके पीछे एक गुमनाम सत्र है। ऑडिट लॉग अभी भी एक ही नाम दिखाता है। लोगों के बीच अनुमतियाँ अभी भी अलग नहीं हो सकतीं। इस व्यवस्था को SSO कहना एक सुरक्षा संबंधी गलती है, क्योंकि ऑफबोर्डिंग की कहानी केवल आधी सच है: व्यक्ति को आपके IdP से हटाने पर मुख्य द्वार तो बंद हो जाता है, लेकिन उनके द्वारा ऐप के अंदर बनाया गया API टोकन उस किसी भी व्यक्ति के लिए काम करता रहता है जो सीधे ऐप तक पहुँच सकता है।

Header authentication को सुरक्षित बनाना

कुछ apps proxy से प्राप्त username को स्वीकार करते हैं, जिससे आपको बिना किसी paid SSO के प्रति-उपयोगकर्ता (per-user) पहचान मिल जाती है। प्रत्येक project में इस setting का नाम अलग होता है।

Grafana इसे auth proxy कहता है और इसे disabled स्थिति में ship करता है। Header का नाम default रूप से X-WEBAUTH-USER होता है, और आप इसे उस header पर point कर सकते हैं जिसे आपका proxy set करता है।

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

whitelist वह line है जिसे लोग अक्सर छोड़ देते हैं। Grafana का documentation स्पष्ट रूप से बताता है कि यह setting users को header spoof करने से रोकने के लिए है, इसलिए इसमें केवल आपके proxy का address होना चाहिए, कुछ और नहीं। Gitea में भी यही feature अलग नामों से मौजूद है, और यह अधिक सुरक्षित default के साथ आता है।

[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 का default मान 127.0.0.0/8,::1/128 होता है, और REVERSE_PROXY_LIMIT यह निर्धारित करता है कि Gitea chain में कितने proxies पर भरोसा करेगा। इस limit को zero पर set करने से header handling पूरी तरह बंद हो जाती है।

Paperless-ngx PAPERLESS_ENABLE_HTTP_REMOTE_USER को PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME के साथ प्रदान करता है, और इसका documentation वह चेतावनी देता है जो इन सभी settings पर लागू होनी चाहिए:

यह केवल request में Remote-User: <username> header जोड़कर authentication की अनुमति देगा। सावधानी से उपयोग करें!

Header authentication को सुरक्षित रखने के लिए दो नियम हैं, और दोनों ही reachability से संबंधित हैं। पहला, app को proxy के अलावा कहीं और से access नहीं किया जाना चाहिए, क्योंकि जो कोई भी इससे socket connection खोल सकता है, वह वह header भेजकर कोई भी user बन सकता है। Docker में, ports: ["8000:8000"] हर interface पर publish होता है, इसलिए इसे ports: ["127.0.0.1:8000:8000"] के साथ loopback address पर bind करें, या published port को हटा दें और proxy को उसी Docker network पर रखें। दूसरा, proxy को client से आने वाले header की किसी भी copy को delete कर देना चाहिए, ताकि app को केवल वही value मिले जिसे आपका proxy authentication के बाद set करता है।

दोनों की जाँच करें। पहली command को अपने VPS के बाहर की किसी machine से चलाएँ और दूसरी को server पर ही चलाएँ।

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

Curl connection विफल होना चाहिए, और ss को 0.0.0.0:8000 के बजाय 127.0.0.1:8000 print करना चाहिए। यदि पहली line HTTP/1.1 302 Found है, तो इसका मतलब है कि app सीधे public internet को जवाब दे रहा है, इसलिए कोई भी व्यक्ति header में नाम लिखकर किसी भी user के रूप में login कर सकता है।

जब कोई मुफ्त SSO उपलब्ध न हो, तो शिकायत करने के बजाय निर्णय लें

चार विकल्प, उसी क्रम में जिसमें मैं उन्हें आज़माऊंगा।

1. वह ऐप चुनें जिसमें OIDC शामिल हो। जहाँ दो प्रोजेक्ट एक ही काम करते हों और एक मुफ्त में आपके identity provider के साथ जुड़ता हो, तो यह परिचालन लागत में एक वास्तविक अंतर है।
2. ईमानदारी से forward auth का उपयोग करें। एक खाते और एक ऑपरेटर वाले एडमिन टूल के लिए, सामने एक proxy पर्याप्त है, और ऐप के भीतर प्रति-उपयोगकर्ता पहचान से कुछ हासिल नहीं होता।
3. भुगतान करें। यदि ऐप आपके काम के लिए केंद्रीय है और प्रति-सीट मूल्य आपकी टीम के आकार के अनुकूल है, तो पैसा प्रोजेक्ट को बनाए रखने में मदद करता है, और इसका विकल्प आपकी शामों की मेहनत है।
4. issue tracker पर खोजने के बाद, upstream से पूछें। Vaultwarden का OIDC सपोर्ट एक contributor के fork और लंबे समय से चल रहे pull request के माध्यम से आया था, इसलिए काम करने वाले implementation के साथ किया गया feature request कभी-कभी free edition में शामिल हो जाता है।

इनमें से कुछ भी आपके स्वयं के identity provider के बिना काम नहीं करता, जिसे सबसे पहले बनाना चाहिए। VPS पर authentik चलाना आपको एक OIDC और SAML provider के साथ-साथ ऊपर उपयोग किया गया forward auth outpost देता है, और Keycloak, authentik और Zitadel की तुलना उन trade-offs को कवर करती है यदि आप अभी प्रतिबद्ध नहीं होना चाहते हैं।

Licence का इतिहास, और यह चेकलिस्ट में क्यों है

चेकलिस्ट का अंतिम बिंदु भविष्य के बारे में है, क्योंकि आज का टियर लेआउट केवल एक स्नैपशॉट है। दो अच्छी तरह से प्रलेखित मामले दिखाते हैं कि जमीन कितनी तेजी से दोनों दिशाओं में खिसकती है। HashiCorp ने 10 August 2023 को सभी भविष्य के releases के लिए Business Source License 1.1 को अपनाया, जबकि शुरुआती releases MPL 2.0 (Mozilla Public License) के अंतर्गत रहे। Redis मार्च 2024 में SSPL (server side public license) पर चला गया, फिर 1 May 2025 को घोषणा की कि Redis 8 भी AGPLv3 (GNU Affero General Public License) के अंतर्गत ships होता है।

दोनों को उद्देश्य के बजाय तंत्र के प्रमाण के रूप में पढ़ें। जो licence आप आज पढ़ते हैं, वह उस version पर लागू होता है जिसे आप आज install करते हैं, और एक project जो अपने सभी copyright रखता है, वह अगली release की शर्तों को अपने आप बदल सकता है। इसीलिए CLA का प्रश्न चेकलिस्ट में है, क्योंकि व्यापक copyright assignment ही वह चीज है जो एकतरफा relicence को संभव बनाती है।

किसी project पर निर्माण करने से पहले उसका इतिहास स्वयं जाँचें।

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

commits की एक छोटी सूची, जो अधिकतर पहले import से है, एक अच्छा संकेत है। licence file को कई बार फिर से लिखने का मतलब है कि वर्तमान शर्तों के आधार पर योजना बनाने से पहले आपको प्रत्येक commit message को पढ़ना चाहिए।

FAQ

SSO tax क्या है?

SSO tax वह प्रक्रिया है जिसमें single sign-on को एक प्रीमियम फीचर के रूप में बेचा जाता है, जबकि उत्पाद का बाकी हिस्सा मुफ्त या सस्ता होता है। self-hosted software के संदर्भ में, यह एक ऐसे open source application जैसा है जिसे आप बिना licence key के चला सकते हैं, लेकिन OIDC या SAML login के लिए भुगतान करना पड़ता है। यह नाम sso.tax पर मौजूद SSO Wall of Shame से आया है, जो उन विक्रेताओं को ट्रैक करता है जो इसके लिए भारी प्रीमियम वसूलते हैं। एक self-hoster के लिए इसका परिणाम यह होता है कि हर app का अपना अलग user database होता है, इसलिए accounts को हाथ से बनाना और हटाना पड़ता है।

क्या forward auth वाला reverse proxy और SSO एक ही हैं?

नहीं। Forward auth मुख्य द्वार की सुरक्षा करता है: कोई भी request app तक पहुँचने से पहले आपका proxy identity provider के साथ जाँच करता है। इसके पीछे मौजूद app अभी भी अपने स्वयं के accounts का उपयोग करता है, इसलिए यदि हर कोई एक साझा login पर पहुँचता है, तो आपको एक ही anonymous session मिलता है और audit log में केवल एक ही नाम दिखाई देता है। यह वास्तविक per-user identity तभी बनता है जब app header से username पढ़ता है, जो Grafana का auth proxy, Gitea का reverse proxy authentication और Paperless-ngx का PAPERLESS_ENABLE_HTTP_REMOTE_USER सभी कर सकते हैं। ये settings तभी सुरक्षित हैं जब app तक केवल proxy के माध्यम से ही पहुँचा जा सके, क्योंकि header एक plain string है जिसे कोई भी client भेज सकता है।

कौन से self-hosted apps के free edition में OIDC शामिल है?

अगस्त 2026 में project documentation के अनुसार जाँच की गई: Paperless-ngx, Planka, BookStack, Gitea, listmonk और Vaultwarden सभी अपने free builds में OIDC का समर्थन करते हैं, और GitLab Self-Managed में SAML, Tier: Free के अंतर्गत सूचीबद्ध है। Grafana का open source build आपके अपने issuer के खिलाफ generic OAuth को संभालता है, जबकि वहाँ SAML एक Enterprise फीचर है। install करने से पहले project के अपने authentication page पर पुष्टि करें, क्योंकि ये सूचियाँ software releases के साथ बदलती रहती हैं।

क्या मुझे उस tier के लिए भुगतान करना चाहिए जो single sign-on को अनलॉक करता है?

इसका निर्णय दो संख्याओं के आधार पर करें: कितने लोगों को accounts की आवश्यकता है, और आप अन्यथा कितने apps को हाथ से manage करेंगे। एक या दो administrators के लिए, local account के सामने forward auth पर्याप्त है और paid tier से बहुत कम लाभ मिलता है। ऐसी टीम के लिए जहाँ लोग जुड़ते और छोड़ते रहते हैं, offboarding के दौरान एक भी account छूट जाना licence की कीमत से अधिक महंगा पड़ता है, और आपका भुगतान उस maintenance को निधि देता है जिस पर आप निर्भर हैं। यदि कीमत आपके बजट में नहीं है, तो व्यावहारिक कदम यह है कि आप ऐसा app चुनें जिसमें OIDC शामिल हो, बजाय इसके कि आप ऐसे app के साथ काम करें जिसमें यह सुविधा नहीं है।