Self-hosted software میں SSO tax کیا ہے؟

SSO tax کیا ہے

Self-hosted software میں SSO tax اس طریقۂ کار کو کہتے ہیں جس میں application مفت ہوتی ہے، لیکن 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 کے مجموعے کو ایک نظام کی طرح کام کرنے کے قابل بناتا ہے۔ identity provider (IdP) ہر شخص کے لیے ایک account، ایک password policy، multi-factor authentication (MFA) فعال کرنے کے لیے ایک مرکزی مقام، اور کسی صارف کی رسائی بند کرنے کے لیے ایک مرکزی مقام فراہم کرتا ہے۔ اس کے بغیر ہر application اپنا الگ user database رکھتی ہے، اور آپ کو ہر database کو دستی طور پر maintain کرنا پڑتا ہے۔

یہ طریقہ اتنا پرانا ہے کہ اس کا public scoreboard بھی موجود ہے۔ sso.tax پر موجود SSO Wall of Shame ان vendors کی فہرست پیش کرتی ہے جو single sign-on کے لیے بہت زیادہ اضافی قیمت لیتے ہیں۔ اس میں 2018 تک کی entries شامل ہیں، اور اس کے author نے ایک مناسب معیار مقرر کیا ہے: "اگر آپ کی 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 کو access سے محروم کر دیتا ہے، اس لیے ایسی tickets فوری نوعیت کی ہوتی ہیں۔ اس کے بعد متعلقہ requests آتی ہیں: nested groups، role mapping، SCIM (system for cross-domain identity management) کے ذریعے automatic provisioning، اور audit logs جنہیں compliance team پڑھے گی۔

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

عام شکایت کی ایک اصلاح ضروری ہے: کسی feature کو ہٹا دیا گیا ہے، یہ فرض کرنے سے پہلے changelog دیکھیں، کیونکہ removal release notes میں ظاہر ہوتی ہے۔ اس post کے لیے جن projects کا میں نے جائزہ لیا، ان میں paid SSO features ابتدا ہی سے paid tier کے لیے بنائے گئے تھے۔ مجھے ایسا کوئی case نہیں ملا جس میں working free SSO بعد میں واپس لیا گیا ہو۔ Grafana اس کی عام مثال ہے۔ اس کے SAML page پر ایک سطری note ہے، "Available in Grafana Enterprise and Grafana Cloud"، جبکہ اپنے issuer کے خلاف generic OAuth، open source build میں کام کرتا ہے۔

SSO tax کی حقیقی لاگت

رقم اس لاگت کا چھوٹا حصہ ہے۔ Paid tiers فی user فروخت کیے جاتے ہیں، اس لیے آپ کی team کے ساتھ bill بڑھتا رہتا ہے، جبکہ hosting اور upgrades کی ذمہ داری آپ ہی کی رہتی ہے۔

بڑی لاگت identity کے دستی کام کی ہے، اور یہ چار جگہوں پر ظاہر ہوتی ہے۔

• ہر app کے لیے الگ password store، اس لیے ایک reused password ہر اس app میں خطرہ بن جاتا ہے جہاں وہ استعمال ہوا ہو۔
• یادداشت کی بنیاد پر offboarding۔ آپ کو یاد رکھنا پڑتا ہے کہ کسی شخص نے کون کون سی services استعمال کی تھیں، اور جس service کو آپ بھول جاتے ہیں، عموماً وہی اہم ہوتی ہے۔
• MFA کو ہر app میں الگ configure کرنا، اور یہ بھی صرف اس صورت میں جب app اسے support کرتی ہو۔
• Shared logins، جو اس دباؤ کے تحت چھوٹی teams میں حقیقتاً رائج ہو جاتے ہیں۔

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

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

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

1. دستاویزات میں authentication صفحہ کھولیں اور اوپر موجود tier نوٹ پڑھیں۔ Paid features کے ساتھ badge یا دستیابی سے متعلق ایک سطری جملہ دیا ہوتا ہے۔
2. تصدیق کریں کہ ایپ آپ کے اپنے issuer کے ساتھ OIDC یا SAML استعمال کرتی ہے، نہ کہ public providers کی کسی مقررہ فہرست کے ساتھ۔
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 disable ہونے پر 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 disable کرنے سے نئے logins رک جاتے ہیں۔ اس سے app کے پہلے جاری کیے گئے API token کو revoke نہیں کیا جاتا، کیونکہ ایپ خود اس token کی توثیق کرتی ہے اور اس کے بارے میں IdP سے کبھی نہیں پوچھتی۔ اس لیے offboarding کے 2 مراحل ہیں: IdP میں account disable کریں، پھر ہر ایپ کے اندر user یا اس کے tokens delete کریں۔

ٹائر بیجز دراصل کیا بتاتے ہیں

ان کی جانچ اگست 2026 میں ہر project کی اپنی documentation کے خلاف کی گئی ہے۔ پہلے paid پہلو سے شروع کریں۔

Grafana، team sync اور SCIM provisioning کے ساتھ SAML کو "Available in Grafana Enterprise and Grafana Cloud" کے طور پر پیش کرتا ہے۔ Generic OAuth، GitHub OAuth، LDAP (lightweight directory access protocol) اور auth proxy سب open source build میں شامل ہیں، اس لیے ایک چھوٹا self-hoster اب بھی اپنے provider کے ذریعے login کر سکتا ہے۔ Paid حد مکمل single sign-on پر نہیں بلکہ SAML پر آتی ہے۔ یہی وہ باریک نکتہ ہے جسے "SSO tax" کی اصطلاح عموماً سادہ بنا دیتی ہے۔

Metabase کی documentation زیادہ واضح ہے۔ اس میں لکھا ہے، "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 documentation کو Pro اور Cloud کے لیے مخصوص کرتا ہے، اس لیے community edition میں یہ سہولت موجود نہیں۔ Documentation میں درج providers میں Keycloak اور Entra ID شامل ہیں۔

اب دوسرے پہلو کو دیکھیں، کیونکہ یہ طریقہ ہر جگہ رائج نہیں ہے۔

• GitLab Self-Managed کے SAML صفحے پر "Tier: Free, Premium, Ultimate" درج ہے، اس لیے اپنے GitLab کے خلاف SAML استعمال کرنے کی کوئی لاگت نہیں۔
• Paperless-ngx، django-allauth کے ذریعے OIDC کو PAPERLESS_SOCIALACCOUNT_PROVIDERS کے ساتھ configure کرتا ہے، PAPERLESS_DISABLE_REGULAR_LOGIN کے ذریعے local login form چھپاتا ہے، اور claims کو PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS کے ذریعے groups سے map کرتا ہے۔
• Planka، OIDC_ISSUER، OIDC_CLIENT_ID اور OIDC_CLIENT_SECRET لیتا ہے، اپنے scopes کو بطور default openid profile email پر مقرر کرتا ہے، اور OIDC_ADMIN_ROLES کے ذریعے role claim سے administrators بناتا ہے۔
• BookStack، AUTH_METHOD=oidc کے ذریعے authentication تبدیل کرتا ہے، پھر OIDC_USER_TO_GROUPS=true اور OIDC_GROUPS_CLAIM کے ذریعے provider groups کو اپنے roles سے map کرتا ہے۔
• Vaultwarden نے 27 December 2025 کو 1.35.0 میں "support for SSO with OpenID Connect" جاری کیا۔ یہ feature ایک ایسے contributor کی pull request سے شامل ہوا جس نے اسے ایک fork میں برقرار رکھا تھا۔
• listmonk میں v4.0.0 سے user roles کے ساتھ OIDC login بھی موجود ہے۔

اس معلومات کو انتخاب کے وقت استعمال کریں، commitment کے بعد نہیں۔ ایک Planka kanban board اور دوسری self-hosted Trello alternatives identity کو ایک ہی طرح handle نہیں کرتیں، اور یہی بات BookStack، Wiki.js اور Outline پر بھی لاگو ہوتی ہے۔ Free OIDC ایسی feature ہے جس کا موازنہ storage limits یا mobile clients کی طرح کیا جا سکتا ہے۔ اگر آپ ابھی فہرست تیار کر رہے ہیں تو 2026 میں کیا self-host کرنا ہے ایک مناسب آغاز ہے، اور Paperless-ngx document manager اور Vaultwarden دونوں آج free OIDC فراہم کرتے ہیں۔

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

عام workaround forward auth ہے۔ reverse proxy ہر request کو عارضی طور پر روکتا ہے، authentication service سے پوچھتا ہے کہ آیا یہ browser signed in ہے، اور اس کے بعد ہی request کو ایپ تک پہنچاتا ہے۔ authentik اسے proxy provider کہتا ہے۔ اس میں ایک single 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 کے حروفِ تہجی کا case اہم ہے، کیونکہ غلط نام استعمال ہونے پر وہ خالی موصول ہوتا ہے۔ ہر منظور شدہ request پر outpost X-authentik-username، X-authentik-email، X-authentik-groups اور چند دیگر headers set کرتا ہے۔

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

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

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

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

Grafana اسے auth proxy کہتا ہے اور یہ feature default طور پر disabled ہوتا ہے۔ ہیڈر کا نام default طور پر X-WEBAUTH-USER ہے، اور آپ اسے اس ہیڈر پر set کر سکتے ہیں جو آپ کا proxy بھیجتا ہے۔

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

whitelist وہ سطر ہے جسے لوگ نظرانداز کر دیتے ہیں۔ Grafana کی documentation واضح کرتی ہے کہ یہ users کو ہیڈر کی جعلی قدر بھیجنے سے روکنے کے لیے موجود ہے۔ اس لیے اس میں صرف آپ کے 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 کرنے سے ہیڈر handling مکمل طور پر بند ہو جاتی ہے۔

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

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

ہیڈر authentication کو محفوظ رکھنے کے لیے دو rules ضروری ہیں، اور دونوں کا تعلق network reachability سے ہے۔ اول، ایپ تک proxy کے علاوہ کسی اور راستے سے رسائی نہیں ہونی چاہیے۔ جو شخص ایپ سے socket connection قائم کر سکتا ہے، وہ یہ ہیڈر بھیج کر کسی بھی user کے طور پر داخل ہو سکتا ہے۔ 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 کرتا ہے۔

دونوں چیزوں کی جانچ کریں۔ پہلی 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 کو جواب دے رہی ہے۔ ایسی صورت میں کوئی بھی شخص header میں user کا نام دے کر کسی بھی user کے طور پر sign in کر سکتا ہے۔

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

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

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

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

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

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

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

کسی project پر انحصار کرنے سے پہلے اس کی history خود check کریں۔

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 کی کئی بار کی گئی rewrites کا مطلب ہے کہ موجودہ شرائط کی بنیاد پر منصوبہ بنانے سے پہلے آپ کو ہر 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 کے لیے بہت زیادہ اضافی قیمت وصول کرنے والے vendors کا ریکارڈ رکھا جاتا ہے۔ self-hoster کے لیے اس کا نتیجہ یہ ہوتا ہے کہ ہر app اپنا user database برقرار رکھتی ہے، اس لیے accounts ہاتھ سے بنانا اور حذف کرنا پڑتے ہیں۔

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

نہیں۔ Forward auth بیرونی دروازے کی حفاظت کرتا ہے: proxy ہر request کے app تک پہنچنے سے پہلے identity provider سے تصدیق کرتا ہے۔ اس کے پیچھے موجود app اپنے accounts استعمال کرتی رہتی ہے۔ اس لیے اگر سب لوگ ایک ہی shared 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 کے لیے ادائیگی کرنی چاہیے؟

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