Self-hosted software میں SSO ٹیکس سے پہلے کیا جانیں

SSO ٹیکس کیا ہے

self-hosted software میں SSO ٹیکس اس صورت کو کہتے ہیں جب application مفت ہو، لیکن single sign-on (SSO) وہ واحد feature ہو جسے خریدنا پڑے۔ آپ اسے مکمل طور پر اپنے VPS پر چلا سکتے ہیں، اس کے لیے کسی licence key یا seat count کی ضرورت نہیں ہوتی۔ پھر آپ documentation میں authentication page کھولتے ہیں اور دیکھتے ہیں کہ OpenID Connect (OIDC) یا SAML (security assertion markup language) paid plan کے تحت دستیاب ہے۔

یہ عام paywalled feature سے زیادہ اہم ہے، کیونکہ SSO ہی self-hosted services کے مجموعے کو ایک نظام کی طرح کام کرنے کے قابل بناتا ہے۔ identity provider (IdP) ہر شخص کے لیے ایک account، password policy کے لیے ایک مرکزی جگہ، multi-factor authentication (MFA) فعال کرنے کے لیے ایک جگہ، اور کسی شخص کی رسائی بند کرنے کے لیے بھی ایک جگہ فراہم کرتا ہے۔ اس کے بغیر ہر app اپنا الگ user database برقرار رکھتی ہے، اور آپ کو ہر database دستی طور پر manage کرنا پڑتا ہے۔

یہ رجحان اتنا پرانا ہے کہ اس کا عوامی scoreboard بھی موجود ہے۔ sso.tax پر موجود SSO Wall of Shame ان vendors کی فہرست دیتا ہے جو single sign-on کے لیے بھاری اضافی قیمت وصول کرتے ہیں۔ اس میں 2018 تک کی entries شامل ہیں، اور اس کے مصنف نے ایک مناسب معیار مقرر کیا ہے: "اگر آپ کی SSO support کی قیمت میں 10% اضافہ ہے، تو آپ اس فہرست میں شامل نہیں ہیں۔" اس فہرست کا زیادہ تر حصہ closed software پر مشتمل ہے۔ اب یہی pricing logic ان open source projects میں بھی نظر آتی ہے جنہیں آپ خود host کرتے ہیں۔

منتظمین single sign-on کو paid tier کے تحت کیوں رکھتے ہیں

اس کی دو وجوہات ہیں، اور دونوں حقیقت پر مبنی ہیں۔ SSO کو support کرنا مہنگا ہوتا ہے، اور یہ ان چند features میں شامل ہے جن کے لیے بڑی organization ادائیگی کرے گی۔

Support کی لاگت واقعی ہوتی ہے، کیونکہ identity integration کبھی مکمل نہیں ہوتی۔ ہر IdP اپنے claims کو کچھ مختلف انداز میں format کرتا ہے۔ Group mapping، session lifetime، redirect URLs اور clock skew، ہر ایک login bugs پیدا کر سکتا ہے۔ Login bug بیک وقت ہر user کو لاگ آؤٹ کر دیتا ہے، اس لیے ایسے tickets فوری نوعیت کے ہوتے ہیں۔ اس کے بعد اضافی requests آتی ہیں: nested groups، role mapping، SCIM (system for cross-domain identity management) کے ذریعے automatic provisioning، اور ایسے audit logs جنہیں compliance team پڑھے گی۔

آمدنی کا معاملہ بدنیتی کے بجائے حساب کا ہے۔ جو company app کو اپنے IdP سے connect نہیں کر سکتی، وہ اسے deploy ہی نہیں کرے گی۔ اس لیے SSO، ادائیگی کرنے والے user اور ادائیگی نہ کرنے والے user کے درمیان واضح حد قائم کرتا ہے۔ Open core project کو یہ حد کہیں نہ کہیں قائم کرنا ہوتی ہے۔ SSO اس مقصد کے لیے تقریباً ہر دوسرے feature کے مقابلے میں زیادہ موزوں ہے، اسی لیے بہت سے projects اسے منتخب کرتے ہیں۔

عام شکایت کی ایک اصلاح ضروری ہے: کسی feature کو ختم کیا گیا سمجھنے سے پہلے changelog دیکھیں، کیونکہ removal release notes میں ظاہر ہو جاتی ہے۔ اس post کے لیے جن projects کا میں نے جائزہ لیا، ان میں paid SSO features ابتدا ہی سے paid tier کے لیے بنائے گئے تھے۔ مجھے ایسا کوئی case نہیں ملا جس میں working free SSO واپس لیا گیا ہو۔ Grafana اس کی عام مثال ہے۔ اس کے SAML page پر ایک سطری نوٹ درج ہے، "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، اس لیے ایک reused password ہر اس app میں security hole بن جاتا ہے جہاں وہ استعمال ہوتا ہے۔
• یادداشت پر انحصار کرتے ہوئے offboarding۔ آپ کو یاد رکھنا پڑتا ہے کہ کسی شخص نے کون کون سی services استعمال کی تھیں، اور جس service کو آپ بھول جائیں، عموماً وہی اہم ثابت ہوتی ہے۔
• MFA کو app بہ app configure کرنا، اگر app یہ سہولت فراہم بھی کرتی ہو۔
• Shared logins، جو اس دباؤ میں چھوٹی teams میں عملاً رائج ہو جاتے ہیں۔

آخری نکتے کے لیے الگ وضاحت ضروری ہے۔ جب کوئی team document manager میں ایک administrator account مشترکہ طور پر استعمال کرتی ہے تو audit trail ہر کارروائی کے لیے ایک ہی نام record کرتا ہے۔ اس لیے آپ معلوم نہیں کر سکتے کہ invoice کس نے delete کی۔ Per-user permissions بھی کام کرنا بند کر دیتی ہیں، کیونکہ وہاں صرف ایک user ہوتا ہے۔ SSO ٹیکس کا اصل نقصان یہی ہے: یہ چھوٹی teams کو ایک ہی shared account استعمال کرنے کی طرف دھکیلتا ہے، جو کسی بھی متبادل سے بدتر ہے۔

اپنانے سے پہلے چلائی جانے والی چیک لسٹ

یہ چیک لسٹ docker compose up سے پہلے چلائیں، اس کے بعد نہیں کہ ایپ میں 400 دستاویزات محفوظ ہو جائیں۔

1. docs میں authentication صفحہ کھولیں اور اوپر دیا گیا tier note پڑھیں۔ Paid features کے ساتھ badge یا دستیابی سے متعلق ایک سطری جملہ موجود ہوتا ہے۔
2. تصدیق کریں کہ ایپ کسی مقررہ public providers کی فہرست کے بجائے آپ کے اپنے issuer کے ساتھ OIDC یا SAML استعمال کرتی ہے۔
3. role اور group mapping چیک کریں۔ user بنانا کام کا نصف حصہ ہے، اور 10 ایپس میں permissions ہاتھ سے assign کرنا وہ نصف ہے جو سب سے زیادہ مشکل پیدا کرتا ہے۔
4. چیک کریں کہ آیا ایپ کسی trusted proxy کی طرف سے header میں authenticated username قبول کرتی ہے، اور کیا آپ یہ مقرر کر سکتے ہیں کہ وہ کس proxy پر اعتماد کرے۔
5. git میں licence history پڑھیں، اور چیک کریں کہ آیا contributors CLA (contributor licence agreement) پر دستخط کرتے ہیں۔
6. offboarding چیک کریں۔ معلوم کریں کہ IdP account disabled ہونے پر API (application programming interface) tokens اور فعال sessions کے ساتھ کیا ہوتا ہے۔

زیادہ تر مایوسی item 2 میں ہوتی ہے۔ "Sign in with Google" button آپ کے 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 سے 3 URLs واپس آتے ہیں۔ خالی result یا 404 عموماً اس بات کی علامت ہے کہ discovery path غلط ہے، اور یہ path provider کے مطابق مختلف ہوتا ہے: Keycloak اسے /realms/<realm>/.well-known/openid-configuration کے تحت publish کرتا ہے۔ اگر ایپ میں issuer URL کے لیے کوئی field ہی نہیں ہے تو feature list کچھ بھی کہے، ایپ آپ کے IdP سے بات نہیں کر سکتی۔

Item 6 کسی شخص کے ادارہ چھوڑنے کے کئی ہفتے بعد مسئلہ سامنے لاتا ہے۔ IdP میں account disabled کرنے سے نئے logins رک جاتے ہیں۔ اس سے API token revoke نہیں ہوتا جو ایپ نے پہلے جاری کیا تھا، کیونکہ ایپ اس token کی خود تصدیق کرتی ہے اور اس کے بارے میں IdP سے کبھی نہیں پوچھتی۔ اس لیے offboarding کے 2 مراحل ہیں: پہلے IdP میں account disabled کریں، پھر ہر ایپ کے اندر user یا اس کے tokens حذف کریں۔

What the tier badges actually say

These are checked against each project's own documentation in August 2026. Start with the paid side.

Grafana publishes SAML as "Available in Grafana Enterprise and Grafana Cloud", along with team sync and SCIM provisioning. Generic OAuth, GitHub OAuth, LDAP (lightweight directory access protocol) and the auth proxy are all in the open source build, so a small self-hoster can still log in through their own provider. The paid line falls at SAML rather than at single sign-on as a whole, which is the nuance the phrase "SSO tax" tends to flatten.

Metabase is blunter. Its documentation says, "SAML authentication is only available on Pro and Enterprise plans (both self-hosted and on Metabase Cloud)." The open source edition keeps password login and LDAP.

Passbolt marks its SSO documentation Pro and Cloud, so the community edition does not have it. The documented providers include Keycloak and Entra ID.

n8n is the same shape, with the self-hosted community edition free under a fair-code licence while SAML and LDAP login sit behind an enterprise key, which is one entry in the longer list of what the free n8n edition leaves out.

Now the other side, because this pattern is far from universal.

• GitLab Self-Managed carries "Tier: Free, Premium, Ultimate" on its SAML page, so SAML against your own GitLab costs nothing.
• Paperless-ngx configures OIDC through django-allauth with PAPERLESS_SOCIALACCOUNT_PROVIDERS, hides the local login form with PAPERLESS_DISABLE_REGULAR_LOGIN, and maps claims onto groups with PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS.
• Planka takes OIDC_ISSUER, OIDC_CLIENT_ID and OIDC_CLIENT_SECRET, defaults its scopes to openid profile email, and promotes administrators from a role claim with OIDC_ADMIN_ROLES.
• BookStack switches over with AUTH_METHOD=oidc, then maps provider groups onto its own roles with OIDC_USER_TO_GROUPS=true and OIDC_GROUPS_CLAIM.
• Vaultwarden shipped "support for SSO with OpenID Connect" in 1.35.0 on 27 December 2025, from a pull request by a contributor who had carried the feature in a fork.
• listmonk has had OIDC login alongside its user roles since v4.0.0.

Use that when you are choosing rather than after you have committed. A Planka kanban board and the other self-hosted Trello alternatives do not all treat identity the same way, and neither do BookStack, Wiki.js and Outline. Free OIDC is a feature you can weigh like storage limits or mobile clients. If you are still drawing up the list, what to self-host in 2026 is a reasonable starting point, and both the Paperless-ngx document manager and Vaultwarden give you free OIDC today.

ایپ کے سامنے reverse proxy ہونا single sign-on نہیں ہے

عام workaround forward auth ہے۔ reverse proxy ہر request کو عارضی طور پر روکتا ہے، authentication service سے پوچھتا ہے کہ آیا یہ browser signed in ہے، اور پھر ہی request کو ایپ تک پہنچاتا ہے۔ authentik اسے proxy provider کہتا ہے۔ اس میں ایک application کے لیے forward auth mode اور پورے domain کے لیے دوسرا mode ہوتا ہے۔ Authelia اور oauth2-proxy بھی یہی کام کرتے ہیں۔

Caddy کا site block authentik کی اپنی مثال کے مطابق اس طرح دکھائی دیتا ہے۔

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 اہم ہے، کیونکہ نام میں فرق ہو تو وہ خالی موصول ہوتا ہے۔ ہر منظور شدہ request پر outpost X-authentik-username، X-authentik-email، X-authentik-groups اور چند دیگر headers set کرتا ہے۔

اس سے یہ فائدہ ہوتا ہے۔ کوئی بھی شخص پہلے آپ کے identity provider سے گزرے بغیر ایپ تک نہیں پہنچ سکتا۔ اس لیے unpatched login form اب internet کے سامنے exposed نہیں رہتا، اور proxy کے پیچھے موجود ہر چیز پر ایک ہی وقت میں MFA لاگو ہو جاتی ہے۔

اس سے یہ فائدہ نہیں ہوتا: ایپ کے اندر identity management۔ ایپ کے اپنے accounts اور signed-in صارف کی اپنی شناخت برقرار رہتی ہے۔ اگر سب لوگ proxy سے گزر کر ایک مشترکہ administrator account میں داخل ہوں تو آپ کے پاس مضبوط بیرونی دروازہ اور اس کے پیچھے ایک anonymous session رہ جاتا ہے۔ Audit log میں اب بھی صرف ایک نام دکھائی دیتا ہے۔ لوگوں کے درمیان permissions اب بھی مختلف نہیں کی جا سکتیں۔ اس arrangement کو SSO کہنا security mistake ہے، کیونکہ offboarding کا دعویٰ صرف آدھا درست ہے: اپنے IdP سے شخص کو ہٹانے سے بیرونی دروازہ بند ہو جاتا ہے، لیکن اس شخص کا ایپ کے اندر بنایا ہوا API token ہر اس شخص کے لیے کام کرتا رہتا ہے جو ایپ تک براہ راست پہنچ سکتا ہو۔

ہیڈر authentication کو محفوظ بنانا

کچھ ایپس proxy سے username قبول کرتی ہیں۔ اس سے paid SSO کے بغیر ہر user کی شناخت دستیاب ہو جاتی ہے۔ ہر project میں اس setting کا نام مختلف ہوتا ہے۔

Grafana اسے auth proxy کہتا ہے اور اسے disabled حالت میں release کرتا ہے۔ ہیڈر کا default نام X-WEBAUTH-USER ہے، اور آپ اسے اپنے proxy کے set کردہ کسی بھی ہیڈر کی طرف point کر سکتے ہیں۔

[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 واضح کرتی ہے کہ یہ users کو ہیڈر 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 اس chain میں ان proxies کی تعداد بتاتا ہے جن پر Gitea اعتماد کرے گا۔ اس limit کو zero پر set کرنے سے ہیڈر handling مکمل طور پر بند ہو جاتی ہے۔

Paperless-ngx میں PAPERLESS_ENABLE_HTTP_REMOTE_USER کو PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME کے ساتھ استعمال کیا جا سکتا ہے۔ اس کی documentation وہ warning بھی دیتی ہے جو ان تمام settings پر لاگو ہوتی ہے:

کسی request میں صرف Remote-User: <username> header شامل کر کے authentication کی اجازت مل جائے گی۔ احتیاط سے استعمال کریں!

ہیڈر authentication کو محفوظ رکھنے کے لیے دو اصول ضروری ہیں، اور دونوں کا تعلق network reachability سے ہے۔ اول، ایپ proxy کے علاوہ کسی ذریعے سے قابل رسائی نہیں ہونی چاہیے۔ جو بھی اس سے socket کھول سکتا ہے، وہ یہ ہیڈر بھیج کر کسی بھی user کے طور پر login کر سکتا ہے۔ Docker میں ports: ["8000:8000"] ہر interface پر port publish کرتا ہے۔ اس لیے اسے ports: ["127.0.0.1:8000:8000"] کے ذریعے loopback address سے bind کریں، یا published port ختم کر کے proxy کو اسی Docker network پر رکھیں۔ دوم، proxy کو client سے آنے والی اس ہیڈر کی ہر copy delete کرنی چاہیے۔ اس طرح ایپ کو صرف وہ value نظر آئے گی جو authentication کے بعد آپ کا proxy set کرتا ہے۔

دونوں چیزیں check کریں۔ پہلی 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 کرنا چاہیے۔ HTTP/1.1 302 Found سے شروع ہونے والی پہلی line کا مطلب ہے کہ ایپ public internet کو براہ راست جواب دے رہی ہے۔ اس صورت میں کوئی بھی شخص ہیڈر میں user کا نام دے کر اس کے طور پر sign in کر سکتا ہے۔

جب مفت SSO دستیاب نہ ہو تو شکایت کرنے کے بجائے فیصلہ کریں

چار اختیارات ہیں۔ میں انہیں اسی ترتیب سے آزماؤں گا۔

1. وہ ایپ منتخب کریں جس میں OIDC شامل ہو۔ جب دو projects ایک ہی کام کرتے ہوں اور ان میں سے ایک آپ کے identity provider سے مفت رابطہ کر سکے، تو یہ operating cost میں حقیقی فرق ہے۔
2. forward auth ایمانداری سے استعمال کریں۔ ایک ایسی admin tool کے لیے جس میں ایک account اور ایک operator ہو، سامنے موجود proxy کافی ہے؛ ایپ کے اندر ہر user کی identity رکھنے سے کوئی فائدہ نہیں ہوتا۔
3. ادائیگی کریں۔ اگر ایپ آپ کے کام کے لیے مرکزی حیثیت رکھتی ہے اور per-seat قیمت آپ کی team size کے مطابق ہے، تو یہ رقم project کی maintenance جاری رکھتی ہے۔ متبادل صورت میں یہ کام آپ کو اپنی شاموں میں کرنا پڑے گا۔
4. issue tracker تلاش کرنے کے بعد upstream سے درخواست کریں۔ Vaultwarden کی OIDC support ایک contributor کے fork اور طویل عرصے تک زیرِ التوا pull request کے ذریعے شامل ہوئی۔ اس لیے working implementation کے ساتھ feature request کبھی کبھار free edition میں شامل ہو جاتی ہے۔

اپنے identity provider کے بغیر یہ میں سے کوئی طریقہ کام نہیں کرے گا، اور یہی وہ جزو ہے جسے پہلے بنانا چاہیے۔ VPS پر authentik چلانا آپ کو OIDC اور SAML provider کے ساتھ اوپر استعمال ہونے والا forward auth outpost بھی فراہم کرتا ہے، جبکہ Keycloak، authentik اور Zitadel کا تقابلی جائزہ ان کے باہمی trade-offs بیان کرتا ہے، اگر آپ ابھی کسی ایک انتخاب کو حتمی شکل نہیں دینا چاہتے۔

لائسنس کی تاریخ، اور یہ چیک لسٹ میں کیوں شامل ہے

چیک لسٹ کا آخری آئٹم مستقبل سے متعلق ہے، کیونکہ آج کی tier layout صرف ایک snapshot ہے۔ دو اچھی طرح documented cases دکھاتے ہیں کہ حالات دونوں سمتوں میں کتنی تیزی سے بدل سکتے ہیں۔ HashiCorp نے 10 August 2023 کو تمام future 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) کے تحت بھی ship ہوتا ہے۔

دونوں مثالوں کو motive کے بجائے mechanism کے ثبوت کے طور پر دیکھیں۔ آج آپ جو licence پڑھتے ہیں، وہ آج install کیے جانے والے version پر لاگو ہوتا ہے، اور جو project اپنے تمام copyright کا مالک ہو وہ اگلے release کی شرائط خود تبدیل کر سکتا ہے۔ اسی لیے CLA کا سوال چیک لسٹ میں شامل ہے، کیونکہ وسیع copyright assignment ہی یک طرفہ relicence کو ممکن بناتا ہے۔

کسی project پر build کرنے سے پہلے اس کی history خود چیک کریں۔

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

commits کی مختصر فہرست، خاص طور پر پہلی import کے زیادہ تر commits، ایک اچھی علامت ہے۔ licence file میں کئی بار کی گئی rewriting کا مطلب ہے کہ موجودہ شرائط کی بنیاد پر منصوبہ بنانے سے پہلے آپ کو ہر commit message پڑھنا چاہیے۔

FAQ

SSO tax کیا ہے؟

SSO tax سے مراد single sign-on کے لیے premium feature کی حیثیت سے فیس وصول کرنا ہے، جبکہ product کا باقی حصہ مفت یا کم قیمت ہو۔ self-hosted software میں یہ صورت اس وقت نظر آتی ہے جب کوئی open source application بغیر licence key کے چلائی جا سکتی ہو، لیکن OIDC یا SAML login paid tier میں شامل ہو۔ یہ نام sso.tax پر موجود SSO Wall of Shame سے لیا گیا ہے، جہاں اس feature کے لیے بہت زیادہ premium وصول کرنے والے vendors کا ریکارڈ رکھا جاتا ہے۔ self-hoster کے لیے اس کا نتیجہ یہ ہوتا ہے کہ ہر app اپنی user database برقرار رکھتی ہے، اس لیے accounts دستی طور پر create اور remove کرنے پڑتے ہیں۔

کیا forward auth والا reverse proxy، SSO ہی ہوتا ہے؟

نہیں۔ Forward auth بیرونی دروازے کی حفاظت کرتا ہے: آپ کا proxy کسی بھی request کے app تک پہنچنے سے پہلے 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 ایک سادہ string ہوتا ہے جسے کوئی بھی client بھیج سکتا ہے۔

کن self-hosted apps میں free edition میں OIDC شامل ہے؟

August 2026 میں project documentation کے مطابق جانچنے پر معلوم ہوا کہ Paperless-ngx، Planka، BookStack، Gitea، listmonk اور Vaultwarden سب اپنی free builds میں OIDC support کرتے ہیں، جبکہ GitLab Self-Managed میں SAML کو Tier: Free کے تحت درج کیا گیا ہے۔ Grafana کی open source build آپ کے اپنے issuer کے خلاف generic OAuth چلاتی ہے، جبکہ وہاں SAML ایک Enterprise feature ہے۔ install کرنے سے پہلے project کے اپنے authentication page پر تصدیق کریں، کیونکہ یہ فہرستیں releases کے ساتھ تبدیل ہوتی رہتی ہیں۔

کیا مجھے single sign-on فعال کرنے والے tier کے لیے ادائیگی کرنی چاہیے؟

یہ فیصلہ 2 نمبروں کی بنیاد پر کریں: کتنے لوگوں کو accounts درکار ہیں، اور بصورت دیگر کتنی apps کو آپ کو دستی طور پر maintain کرنا ہوگا۔ 1 یا 2 administrators کے لیے local account کے سامنے forward auth کافی ہوتا ہے، اور paid tier سے بہت کم فائدہ ملتا ہے۔ ایسی team میں جہاں لوگ شامل ہوتے اور رخصت ہوتے رہتے ہیں، offboarding کے دوران رہ جانے والا 1 account licence کی لاگت سے زیادہ نقصان دہ ہو سکتا ہے، اور ادائیگی اس maintenance کو fund کرتی ہے جس پر آپ انحصار کر رہے ہیں۔ اگر قیمت مناسب نہ ہو تو عملی راستہ یہ ہے کہ ایسی app منتخب کریں جس میں OIDC شامل ہو، بجائے اس کے کہ ایسی app کے گرد workaround بنائیں جس میں OIDC موجود نہ ہو۔