SSD Nodes Learn 🎉 VPS $5.50/महिन्यापासून
मार्गदर्शक Matt Connorद्वारे Matt Connor

Self-hosted software मध्ये SSO कर म्हणजे काय?

OIDC किंवा SAML paid plan मध्ये का ठेवले जाते, maintainers अशी किंमत का ठरवतात आणि software install करण्यापूर्वी कोणती checklist तपासावी हे जाणून घ्या.

SSO कर म्हणजे काय

self-hosted software मधील SSO कर ही अशी पद्धत आहे की अॅप्लिकेशन विनामूल्य असते आणि single sign-on (SSO) हे खरेदी करावे लागणारे एकमेव feature असते. तुम्ही संपूर्ण software स्वतःच्या VPS वर licence key किंवा seat count शिवाय चालवू शकता. त्यानंतर documentation मधील authentication page उघडल्यावर OpenID Connect (OIDC) किंवा SAML (security assertion markup language) हे paid plan अंतर्गत दिलेले आढळते.

हे सामान्य paywalled feature पेक्षा अधिक महत्त्वाचे आहे, कारण SSO मुळे self-hosted services चा संच एकाच system प्रमाणे कार्य करतो. identity provider (IdP) प्रत्येक व्यक्तीसाठी एक account, एक password policy, multi-factor authentication (MFA) सुरू करण्यासाठी एक ठिकाण आणि एखाद्याचा access बंद करण्यासाठी एक ठिकाण उपलब्ध करून देतो. IdP नसल्यास प्रत्येक app स्वतःचा छोटा user database ठेवतो आणि तुम्हाला प्रत्येक database हाताने व्यवस्थापित करावा लागतो.

ही पद्धत इतकी जुनी आहे की तिच्यासाठी सार्वजनिक scoreboard उपलब्ध आहे. sso.tax वरील SSO Wall of Shame मध्ये single sign-on साठी मोठा अतिरिक्त शुल्क आकारणाऱ्या vendors ची यादी आहे. त्यातील entries 2018 पर्यंत मागे जातात. त्याचा लेखक योग्य मर्यादा स्पष्ट करतो: "तुमच्या SSO support मुळे किंमत 10% ने वाढत असेल, तर तुमचे नाव या यादीत नाही." त्या यादीतील बहुतेक software closed software आहे. आता हीच pricing logic तुम्ही स्वतः host करत असलेल्या open source projects मध्येही दिसते.

देखभाल करणारे SSO सशुल्क स्तरामागे का ठेवतात

यामागे दोन कारणे आहेत आणि दोन्ही प्रामाणिक आहेत. SSO ला समर्थन देणे खर्चिक असते. तसेच मोठी संस्था ज्या मोजक्या वैशिष्ट्यांसाठी पैसे देईल, त्यापैकी हे एक आहे.

समर्थनाचा खर्च खरा आहे, कारण identity integration कधीही पूर्ण होत नाही. प्रत्येक IdP आपले claims थोडे वेगळ्या पद्धतीने format करतो. Group mapping, session lifetime, redirect URLs आणि clock skew यांपैकी प्रत्येकामुळे login bugs निर्माण होऊ शकतात. Login bug मुळे सर्व वापरकर्ते एकाच वेळी प्रवेशाबाहेर पडतात. त्यामुळे अशा tickets वर तातडीने काम करावे लागते. त्यानंतरच्या मागण्याही येतात: nested groups, role mapping, SCIM (system for cross-domain identity management) द्वारे automatic provisioning आणि compliance team तपासणार असलेले audit logs.

महसुलाच्या दृष्टीने हे द्वेषामुळे नव्हे, तर साध्या गणितामुळे घडते. एखादी कंपनी अॅपला तिच्या स्वतःच्या IdP शी जोडू शकत नसेल, तर ती अॅप तैनातच करणार नाही. त्यामुळे SSO देणारा आणि न देणारा वापरकर्ता यांच्यात स्पष्ट रेषा आखते. Open core प्रकल्पाला ही रेषा कुठेतरी आखावीच लागते. जवळजवळ इतर कोणत्याही वैशिष्ट्यापेक्षा SSO या उद्देशासाठी अधिक योग्य ठरते. म्हणून अनेक प्रकल्प ते निवडतात.

नेहमीच्या तक्रारीबाबत एक दुरुस्ती: एखादे वैशिष्ट्य काढून घेतले असे गृहीत धरण्यापूर्वी changelog तपासा, कारण काढलेले वैशिष्ट्य release notes मध्ये दिसते. या लेखासाठी मी तपासलेल्या प्रकल्पांमध्ये paid SSO features सुरुवातीपासूनच paid tier साठी तयार करण्यात आले होते. कार्यरत free SSO नंतर काढून घेतल्याचे उदाहरण मला आढळले नाही. Grafana हे याचे नेहमीचे उदाहरण आहे. त्याच्या SAML पृष्ठावर, "Available in Grafana Enterprise and Grafana Cloud" अशी एक ओळीची नोंद आहे. मात्र स्वतःच्या issuer विरुद्ध generic OAuth open source build मध्ये कार्यरत आहे.

SSO कराचा प्रत्यक्ष खर्च

पैशांचा खर्च हा त्यातील लहान भाग आहे. Paid tiers प्रति user या आधारावर विकले जातात. त्यामुळे तुमच्या team सोबत bill वाढत जाते, तर hosting आणि upgrades ची जबाबदारी तुमचीच राहते.

मोठा खर्च manual identity work चा असतो. तो चार ठिकाणी दिसून येतो.

  • प्रत्येक app साठी एक password store ठेवावा लागतो. त्यामुळे एकच पुन्हा वापरलेला password तोच password वापरणाऱ्या प्रत्येक app मध्ये security hole निर्माण करतो.
  • Offboarding स्मरणशक्तीवर अवलंबून राहते. एखाद्या व्यक्तीने वापरलेल्या प्रत्येक service ची आठवण ठेवावी लागते. आणि जी service विसरली जाते, तीच महत्त्वाची ठरते.
  • MFA प्रत्येक app मध्ये स्वतंत्रपणे configure करावे लागते. तेही संबंधित app त्याला support करत असेल तरच.
  • Shared logins वापरले जातात. अशा दबावाखाली small teams मध्ये प्रत्यक्षात हेच घडते.

या शेवटच्या मुद्द्यासाठी स्वतंत्रपणे एक वाक्य आवश्यक आहे. एखाद्या team ने document manager मध्ये एकच administrator account shared केल्यास, audit trail मध्ये प्रत्येक कृतीसाठी एकच नाव नोंदवले जाते. त्यामुळे invoice कोणी delete केले हे समजत नाही. Per-user permissions देखील कार्य करणे थांबवतात, कारण user एकच असतो. SSO करामुळे होणारे खरे नुकसान हेच आहे: तो small teams ना एकाच shared account कडे ढकलतो, आणि हा पर्याय इतर कोणत्याही पर्यायापेक्षा वाईट असतो.

स्वीकारण्यापूर्वी करायची तपासणी यादी

docker compose up करण्यापूर्वी ही तपासणी करा; अॅपमध्ये 400 दस्तऐवज साठल्यानंतर नाही.

  1. दस्तऐवजांमधील authentication पृष्ठ उघडा आणि शीर्षस्थानी असलेली tier संबंधी नोंद वाचा. Paid features साठी badge किंवा उपलब्धतेबद्दल एक ओळीचे विधान दिलेले असते.
  2. अॅप fixed list मधील public providers ऐवजी तुमच्या स्वतःच्या issuer शी OIDC किंवा SAML द्वारे संवाद साधते का ते निश्चित करा.
  3. role आणि group mapping तपासा. user तयार करणे हे कामाच्या अर्धेच आहे; दहा अॅप्समध्ये permissions हाताने देणे हा त्रासदायक अर्धा भाग आहे.
  4. trusted proxy कडून header मध्ये authenticated username स्वीकारण्याची अॅपची क्षमता तपासा. तसेच कोणत्या proxy वर ते विश्वास ठेवते हे निश्चित करता येते का ते तपासा.
  5. git मधील licence history वाचा आणि contributors CLA (contributor licence agreement) वर स्वाक्षरी करतात का ते तपासा.
  6. offboarding तपासा. IdP account disable केल्यावर API (application programming interface) tokens आणि live sessions यांचे काय होते ते शोधा.

बहुतेक निराशा item 2 मध्ये होते. "Sign in with Google" हे बटन तुमच्या identity provider सोबत OIDC असल्याचे दर्शवत नाही; ते एका vendor सोबतचे fixed integration असते. खऱ्या support मध्ये issuer URL विचारला जातो आणि उर्वरित सर्व माहिती discovery मधून मिळते. एका command ने तुमच्या provider च्या बाजूची ही बाब निश्चित करता येते.

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

सक्षम provider कडून तीन URLs परत मिळतात. रिकामा result किंवा 404 आल्यास discovery path चुकीचा असतो. हा path provider specific असतो: Keycloak तो /realms/<realm>/.well-known/openid-configuration अंतर्गत प्रकाशित करते. अॅपमध्ये issuer URL साठी कोणतेही field नसल्यास, feature list मध्ये काहीही लिहिलेले असले तरी ते तुमच्या IdP शी संवाद साधू शकत नाही.

कोणी नोकरी सोडल्यानंतर अनेक आठवड्यांनी item 6 मुळे समस्या लक्षात येते. IdP मधील account disable केल्याने नवीन logins थांबतात. मात्र अॅपने यापूर्वी issue केलेला API token revoke होत नाही, कारण अॅप तो token स्वतः validate करते आणि त्याबद्दल IdP ला कधीही विचारत नाही. त्यामुळे offboarding चे दोन टप्पे आहेत: IdP मधील account disable करा आणि त्यानंतर प्रत्येक अॅपमध्ये user किंवा त्याचे tokens delete करा.

टियर बॅज प्रत्यक्षात काय सांगतात

ऑगस्ट 2026 मध्ये प्रत्येक प्रकल्पाच्या स्वतःच्या दस्तऐवजीकरणाशी ही माहिती पडताळली आहे. प्रथम सशुल्क पर्याय पाहू.

Grafana मध्ये SAML हे "Available in Grafana Enterprise and Grafana Cloud" असे नमूद केले आहे. यासोबत team sync आणि SCIM provisioning देखील उपलब्ध आहेत. Generic OAuth, GitHub OAuth, LDAP (lightweight directory access protocol) आणि auth proxy हे सर्व open source build मध्ये आहेत. त्यामुळे लहान self-hoster स्वतःच्या provider द्वारे लॉग इन करू शकतो. सशुल्क मर्यादा संपूर्ण single sign-on वर नसून SAML वर लागू होते. "SSO tax" हा शब्द हा फरक अनेकदा अस्पष्ट करतो.

Metabase याबाबत अधिक स्पष्ट आहे. त्याच्या दस्तऐवजीकरणात असे म्हटले आहे: "SAML authentication is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud)." open source edition मध्ये password login आणि LDAP उपलब्ध आहेत.

Passbolt मध्ये SSO चे दस्तऐवजीकरण Pro आणि Cloud साठी आहे. त्यामुळे community edition मध्ये ते उपलब्ध नाही. दस्तऐवजीकरणात Keycloak आणि Entra ID हे provider नमूद केले आहेत.

आता दुसरी बाजू पाहू, कारण हा नमुना सर्वत्र लागू होत नाही.

  • GitLab Self-Managed च्या SAML पृष्ठावर "Tier: Free, Premium, Ultimate" असे नमूद आहे. त्यामुळे स्वतःच्या GitLab विरुद्ध SAML वापरण्यासाठी शुल्क लागत नाही.
  • Paperless-ngx PAPERLESS_SOCIALACCOUNT_PROVIDERS वापरून django-allauth द्वारे OIDC configure करते, PAPERLESS_DISABLE_REGULAR_LOGIN वापरून local login form लपवते आणि PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS वापरून claims चे groups शी mapping करते.
  • Planka OIDC_ISSUER, OIDC_CLIENT_ID आणि OIDC_CLIENT_SECRET स्वीकारते, scopes साठी default म्हणून openid profile email वापरते आणि OIDC_ADMIN_ROLES मधील role claim वरून administrators तयार करते.
  • BookStack AUTH_METHOD=oidc वापरून OIDC वर switch करते. त्यानंतर OIDC_USER_TO_GROUPS=true आणि OIDC_GROUPS_CLAIM वापरून provider groups चे स्वतःच्या roles शी mapping करते.
  • Vaultwarden ने 27 December 2025 रोजी 1.35.0 मध्ये "support for SSO with OpenID Connect" उपलब्ध केले. हे feature एका contributor ने pull request द्वारे आणले होते; त्याने ते यापूर्वी एका fork मध्ये maintain केले होते.
  • listmonk मध्ये v4.0.0 पासून user roles सोबत OIDC login उपलब्ध आहे.

तुम्ही निवड करताना ही माहिती वापरा; निवड निश्चित केल्यानंतर नव्हे. Planka kanban board आणि इतर self-hosted Trello alternatives identity बाबत एकसारखी वागणूक देत नाहीत. BookStack, Wiki.js आणि Outline यांच्यातही हा फरक आहे. Free OIDC चे मूल्यमापन storage limits किंवा mobile clients प्रमाणे करता येते. तुम्ही अजून यादी तयार करत असाल, तर 2026 मध्ये काय self-host करावे हा योग्य प्रारंभबिंदू आहे. तसेच Paperless-ngx document manager आणि Vaultwarden दोन्हीमध्ये आज free OIDC उपलब्ध आहे.

अॅपच्या पुढे reverse proxy ठेवणे हे single sign-on का नाही

सामान्य उपाय म्हणजे forward auth. reverse proxy प्रत्येक विनंती थांबवतो, हा browser authentication service मध्ये signed in आहे का ते विचारतो आणि त्यानंतरच विनंती अॅपकडे पाठवतो. authentik याला proxy provider म्हणते. त्यात एका अॅप्लिकेशनसाठी forward auth mode आणि संपूर्ण domain साठी दुसरा mode असतो. Authelia आणि oauth2-proxy हेही समान काम करतात.

authentik च्या स्वतःच्या उदाहरणानुसार Caddy site block असा दिसतो.

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 मध्ये त्या header names चे Capitalisation महत्त्वाचे असते, कारण name जुळले नाही तर ते रिकामे पोहोचते. मान्य केलेल्या प्रत्येक विनंतीवर outpost X-authentik-username, X-authentik-email, X-authentik-groups आणि आणखी काही headers सेट करतो.

यातून तुम्हाला पुढील लाभ मिळतो. तुमच्या identity provider मधून पडताळणी न करता कोणीही अॅपपर्यंत पोहोचू शकत नाही. त्यामुळे unpatched login form इंटरनेटसमोर उघडे राहत नाही. तसेच proxy मागील सर्व गोष्टींवर MFA एकाच वेळी लागू होते.

यातून पुढील लाभ मिळत नाही: अॅपमधील identity. अॅपची स्वतःची accounts असतात आणि कोण signed in आहे याबद्दलची त्याची स्वतःची संकल्पना असते. प्रत्येकजण proxy पार करून एका shared administrator account मध्ये पोहोचत असेल, तर तुमच्याकडे मजबूत प्रवेशद्वार आणि त्यामागे एक anonymous session असते. Audit log मध्ये अजूनही एकच name दिसते. वेगवेगळ्या लोकांसाठी permissions वेगळ्या ठेवता येत नाहीत. या रचनेला SSO म्हणणे ही security mistake आहे, कारण offboarding ची प्रक्रिया फक्त अर्धवट कार्य करते: तुमच्या IdP मधून व्यक्ती काढल्यावर प्रवेशद्वार बंद होते, पण त्या व्यक्तीने अॅपमध्ये तयार केलेला API token अॅपपर्यंत थेट पोहोचू शकणाऱ्या कोणासाठीही कार्यरत राहतो.

हेडर प्रमाणीकरण सुरक्षित करणे

काही अॅप्स proxy कडून username स्वीकारतात. त्यामुळे paid SSO शिवाय प्रत्येक वापरकर्त्याची ओळख मिळते. प्रत्येक project मध्ये या setting चे नाव वेगळे असते.

Grafana मध्ये याला auth proxy म्हणतात आणि ते default ने disabled असते. Header चे नाव default ने X-WEBAUTH-USER असते. तुमचा proxy सेट करत असलेला कोणताही header तुम्ही त्यासाठी वापरू शकता.

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

whitelist ही ओळ अनेक जण वगळतात. Header ची बनावट value वापरून users ने स्वतःची ओळख बदलू नये म्हणून ही setting आहे, असे Grafana च्या documentation मध्ये स्पष्ट केले आहे. त्यामुळे येथे फक्त तुमच्या 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 असते. Gitea ने chain मधील किती proxies वर विश्वास ठेवावा हे REVERSE_PROXY_LIMIT ठरवते. ही मर्यादा zero केल्यास header handling पूर्णपणे बंद होते.

Paperless-ngx मध्ये PAPERLESS_ENABLE_HTTP_REMOTE_USER हे PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME सह उपलब्ध आहे. या सर्व settings साठी लागू होणारी सूचना त्याच्या documentation मध्ये दिली आहे:

Request मध्ये Remote-User: <username> header जोडून authentication करता येईल. हे काळजीपूर्वक वापरा!

Header authentication सुरक्षित ठेवण्यासाठी दोन नियम पाळा. दोन्ही नियम reachability शी संबंधित आहेत. पहिला, app केवळ proxy मार्फतच उपलब्ध असावा. App शी थेट socket उघडू शकणारा कोणताही client हा header पाठवून कोणत्याही user च्या नावाने प्रवेश करू शकतो. Docker मध्ये ports: ["8000:8000"] प्रत्येक interface वर port प्रकाशित करते. त्यामुळे ports: ["127.0.0.1:8000:8000"] वापरून त्याला loopback address शी bind करा, किंवा published port काढून टाका आणि proxy ला त्याच Docker network वर ठेवा.

दुसरा, client कडून आलेली header ची कोणतीही copy proxy ने delete केली पाहिजे. Authentication नंतर proxy ने सेट केलेली value एवढीच app ला दिसली पाहिजे.

दोन्ही बाबी तपासा. पहिली command तुमच्या VPS च्या बाहेरील machine वरून चालवा आणि दुसरी server वरच चालवा.

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

curl ला connect होता कामा नये. तसेच ss ने 0.0.0.0:8000 ऐवजी 127.0.0.1:8000 print केले पाहिजे. पहिल्या output line मध्ये HTTP/1.1 302 Found दिसल्यास app थेट public internet ला उत्तर देत आहे. अशा स्थितीत header मध्ये user चे नाव देऊन कोणीही कोणत्याही user च्या नावाने sign in करू शकतो.

मोफत SSO उपलब्ध नसेल, तर तक्रार न करता निर्णय घ्या

मी खालील चार पर्याय याच क्रमाने वापरेन.

  1. OIDC समाविष्ट असलेले अॅप निवडा. दोन प्रकल्प समान काम करत असतील आणि त्यापैकी एक तुमच्या identity provider शी विनामूल्य संवाद साधत असेल, तर चालवण्याच्या खर्चाच्या दृष्टीने हा खरा फरक आहे.
  2. forward auth प्रामाणिकपणे वापरा. एका account आणि एका operator असलेल्या admin tool साठी पुढे ठेवलेला proxy पुरेसा असतो. अॅपमध्ये प्रत्येक वापरकर्त्याची identity ठेवण्याचा अतिरिक्त लाभ नसतो.
  3. पैसे द्या. अॅप तुमच्या कामासाठी महत्त्वाचे असेल आणि per-seat किंमत तुमच्या team size ला परवडत असेल, तर त्या पैशांमुळे प्रकल्पाचे maintenance सुरू राहते. अन्यथा त्याचा खर्च तुमच्या मोकळ्या वेळेत भरावा लागतो.
  4. issue tracker मध्ये शोध घेतल्यानंतर upstream कडे विनंती करा. Vaultwarden चे OIDC support एका contributor च्या fork आणि दीर्घकाळ सुरू असलेल्या pull request द्वारे आले. त्यामुळे त्यामागे कार्यरत implementation असलेली feature request कधीकधी free edition मध्ये समाविष्ट होते.

तुमचा स्वतःचा identity provider नसल्यास यापैकी काहीही कार्य करणार नाही. त्यामुळे प्रथम तो उभारणे आवश्यक आहे. VPS वर authentik चालवणे तुम्हाला OIDC आणि SAML provider तसेच वर वापरलेला forward auth outpost देते. तुम्हाला अद्याप कोणत्याही एका पर्यायाशी बांधील राहायचे नसेल, तर Keycloak, authentik आणि Zitadel यांची तुलना या पर्यायांमधील तडजोडी स्पष्ट करते.

परवान्याचा इतिहास आणि तो तपासणीसूचीत का आहे

शेवटचा तपासणीसूचीतील मुद्दा भविष्यासंबंधी आहे, कारण आजची tier रचना ही केवळ एक snapshot आहे. दोन चांगल्या प्रकारे नोंदवलेल्या उदाहरणांवरून परिस्थिती दोन्ही दिशांनी किती वेगाने बदलू शकते हे दिसते. HashiCorp ने 10 August 2023 रोजी भविष्यातील सर्व releases साठी Business Source License 1.1 स्वीकारला, तर त्यापूर्वीचे releases MPL 2.0 (Mozilla Public License) अंतर्गतच राहिले. Redis ने March 2024 मध्ये SSPL (server side public license) स्वीकारला. त्यानंतर 1 May 2025 रोजी Redis 8 हे AGPLv3 (GNU Affero General Public License) अंतर्गतही उपलब्ध होईल, अशी घोषणा केली.

दोन्ही उदाहरणांकडे हेतूऐवजी कार्यपद्धतीचा पुरावा म्हणून पाहा. तुम्ही आज स्थापित करत असलेल्या version ला आज वाचलेला licence लागू होतो. एखाद्या project कडे त्याच्या सर्व copyright चे स्वामित्व असल्यास, तो project पुढील 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

मुख्यतः पहिल्या import मधील commits ची छोटी यादी चांगले लक्षण आहे. licence file मध्ये अनेकदा rewrite झाले असल्यास, सध्याच्या अटींवर आधारित नियोजन करण्यापूर्वी प्रत्येक commit message वाचा.

FAQ

SSO कर म्हणजे काय?

SSO कर म्हणजे single sign-on साठी premium feature म्हणून शुल्क आकारण्याची पद्धत. उर्वरित product विनामूल्य किंवा स्वस्त असतो. Self-hosted software मध्ये हे असे दिसते: licence key शिवाय चालवता येणारे open source application उपलब्ध असते, परंतु OIDC किंवा SAML login paid tier मध्ये असतो. हे नाव sso.tax वरील SSO Wall of Shame वरून आले आहे. त्या ठिकाणी यासाठी मोठे अतिरिक्त शुल्क आकारणाऱ्या vendors ची नोंद ठेवली जाते. Self-hoster साठी याचा परिणाम असा होतो की प्रत्येक app स्वतःचा user database ठेवतो. त्यामुळे accounts हाताने तयार आणि काढावे लागतात.

forward auth असलेला reverse proxy म्हणजे SSOच आहे का?

नाही. Forward auth प्रवेशद्वाराचे संरक्षण करते. कोणतीही request app पर्यंत पोहोचण्यापूर्वी तुमचा proxy identity provider कडे पडताळणी करतो. त्यामागील app मात्र स्वतःची accounts वापरते. त्यामुळे सर्व users एकाच shared login वर गेल्यास एकच anonymous session तयार होते आणि audit log मध्ये एकच नाव दिसते. App header मधून username वाचते तेव्हाच खऱ्या अर्थाने प्रत्येक user ची identity उपलब्ध होते. Grafana's auth proxy, Gitea's reverse proxy authentication आणि Paperless-ngx's PAPERLESS_ENABLE_HTTP_REMOTE_USER हे सर्व असे करू शकतात. App पर्यंत proxy शिवाय पोहोचता येत नाही तोपर्यंतच ही settings सुरक्षित असतात. कारण header ही साधी string असते आणि कोणताही client ती पाठवू शकतो.

कोणत्या self-hosted apps मध्ये free edition मध्ये OIDC समाविष्ट आहे?

August 2026 मध्ये project documentation तपासली असता Paperless-ngx, Planka, BookStack, Gitea, listmonk आणि Vaultwarden यांच्या free builds मध्ये OIDC समर्थित असल्याचे आढळले. GitLab Self-Managed मध्ये SAML ची नोंद Tier: Free अंतर्गत आहे. Grafana's open source build तुमच्या स्वतःच्या issuer विरुद्ध generic OAuth हाताळते. मात्र त्यातील SAML हे Enterprise feature आहे. Install करण्यापूर्वी project च्या स्वतःच्या authentication page वर माहितीची पुष्टी करा. कारण releases नुसार या lists बदलू शकतात.

single sign-on उपलब्ध करून देणाऱ्या tier साठी पैसे द्यावेत का?

दोन संख्यांच्या आधारे निर्णय घ्या: किती लोकांना accounts आवश्यक आहेत आणि अन्यथा किती apps हाताने maintain करावे लागतील. एक किंवा दोन administrators असल्यास local account च्या पुढे forward auth पुरेसे आहे. अशा वेळी paid tier मुळे फारसा लाभ मिळत नाही. लोक team मध्ये येत-जात असतील, तर offboarding वेळी एखादे account काढायचे राहिल्यास त्याची किंमत licence पेक्षा जास्त ठरू शकते. अशा वेळी payment मुळे तुम्ही अवलंबून असलेल्या maintenance ला निधी मिळतो. किंमत परवडत नसेल, तर OIDC समाविष्ट असलेले app निवडणे हा व्यावहारिक पर्याय आहे. OIDC नसलेल्या app वर workaround करण्यापेक्षा हा पर्याय चांगला आहे.

#sso#oidc#saml#licensing#self-hosting#authentik