چرا قابلیت SSO در نرم‌افزارهای Self-hosted پولی است؟

مالیات SSO چیست

مالیات SSO در نرم‌افزارهای self-hosted به الگویی گفته می‌شود که در آن برنامه رایگان است، اما Single Sign-On (SSO) تنها قابلیتی است که باید برای آن هزینه پرداخت کنید. شما می‌توانید کل برنامه را روی VPS شخصی خود بدون نیاز به لایسنس یا محدودیت تعداد کاربر اجرا کنید. سپس وقتی صفحه احراز هویت را در مستندات باز می‌کنید، متوجه می‌شوید که OpenID Connect (OIDC) یا SAML (زبان نشانه‌گذاری ادعای امنیتی) در طرح‌های پولی قرار گرفته‌اند.

این موضوع از یک قابلیت معمولی که پشت دیوار پرداخت (paywall) قرار دارد اهمیت بیشتری دارد، زیرا SSO همان چیزی است که باعث می‌شود مجموعه‌ای از سرویس‌های self-hosted مانند یک سیستم واحد عمل کنند. یک Identity Provider (IdP) به شما امکان می‌دهد برای هر شخص یک حساب کاربری، یک سیاست رمز عبور، یک نقطه مرکزی برای فعال‌سازی احراز هویت چندعاملی (MFA) و یک نقطه واحد برای غیرفعال کردن دسترسی افراد داشته باشید. بدون آن، هر برنامه پایگاه داده کاربری کوچک و اختصاصی خود را حفظ می‌کند و شما باید هر کدام را به‌صورت دستی مدیریت کنید.

این الگو آن‌قدر قدیمی است که یک جدول امتیازات عمومی دارد. «دیوار شرم SSO» در sso.tax فهرستی از فروشندگانی را ارائه می‌دهد که برای Single Sign-On هزینه‌های گزافی دریافت می‌کنند؛ ورودی‌های این فهرست به سال 2018 بازمی‌گردد و نویسنده آن معیار منصفانه‌ای تعیین کرده است: «اگر پشتیبانی شما از SSO باعث افزایش 10 درصدی قیمت شود، در این فهرست قرار نمی‌گیرید.» بیشتر موارد این فهرست نرم‌افزارهای متن‌بسته هستند. اکنون همین منطق قیمت‌گذاری در پروژه‌های متن‌بازی که خودتان میزبانی می‌کنید نیز دیده می‌شود.

چرا نگهدارندگان پروژه، قابلیت Single Sign-On را در لایه پولی قرار می‌دهند

دو دلیل برای این کار وجود دارد و هر دو صادقانه هستند. پشتیبانی از SSO هزینه‌بر است و این یکی از معدود قابلیت‌هایی است که سازمان‌های بزرگ بابت آن هزینه پرداخت می‌کنند.

هزینه پشتیبانی واقعی است، زیرا یکپارچه‌سازی هویت هرگز تمام نمی‌شود. هر IdP ادعاهای (claims) خود را کمی متفاوت قالب‌بندی می‌کند. نگاشت گروه‌ها، طول عمر نشست، URLهای بازگشت (redirect URLs) و اختلاف زمانی (clock skew) هر کدام باعث بروز باگ‌های ورود به سیستم می‌شوند و یک باگ در ورود به سیستم، دسترسی همه کاربران را به‌طور هم‌زمان مسدود می‌کند؛ بنابراین این تیکت‌ها بسیار فوری هستند. سپس درخواست‌های بعدی از راه می‌رسند: گروه‌های تو در تو، نگاشت نقش‌ها، تأمین خودکار با استفاده از SCIM (سیستم مدیریت هویت بین دامنه‌ای) و لاگ‌های حسابرسی که تیم‌های انطباق (compliance) آن‌ها را بررسی می‌کنند.

جنبه درآمدی این موضوع بیشتر یک محاسبه ریاضی است تا بدخواهی. شرکتی که نتواند برنامه را به IdP اختصاصی خود متصل کند، اصلاً آن را مستقر نخواهد کرد؛ بنابراین SSO یک مرز مشخص بین کاربری که هزینه پرداخت می‌کند و کاربری که پرداخت نمی‌کند، ایجاد می‌کند. یک پروژه open core باید این مرز را در جایی تعیین کند. SSO تقریباً بهتر از هر قابلیت دیگری در این جایگاه قرار می‌گیرد و به همین دلیل است که پروژه‌های بسیاری آن را انتخاب می‌کنند.

یک اصلاح برای شکایت‌های معمول: پیش از آنکه فرض کنید قابلیتی حذف شده است، changelog را بررسی کنید، زیرا حذف یک قابلیت در release notes ذکر می‌شود. در پروژه‌هایی که برای این مطلب بررسی کردم، قابلیت‌های پولی SSO از همان ابتدا برای لایه پولی ساخته شده بودند. من موردی پیدا نکردم که در آن SSO رایگانِ فعال، حذف شده باشد. Grafana در این مورد نمونه است. صفحه SAML آن شامل یک یادداشت یک‌خطی است: "Available in Grafana Enterprise and Grafana Cloud"، در حالی که OAuth عمومی برای issuer اختصاصی شما در نسخه open source کار می‌کند.

هزینه واقعی مالیات SSO برای شما چیست

بخش مالی تنها نیمی از ماجراست. طرح‌های پولی بر اساس هر کاربر فروخته می‌شوند، بنابراین با بزرگ‌تر شدن تیم، صورت‌حساب شما افزایش می‌یابد، در حالی که میزبانی و ارتقا همچنان بر عهده خودتان باقی می‌ماند.

هزینه بزرگ‌تر، کار دستی مدیریت هویت است که در چهار حوزه خود را نشان می‌دهد:

• یک مخزن رمز عبور برای هر برنامه؛ بنابراین یک رمز عبور تکراری، حفره‌ای امنیتی در تمام برنامه‌هایی است که از آن استفاده می‌کنند.
• خروج از سیستم بر اساس حافظه. شما باید تمام سرویس‌هایی که یک فرد با آن‌ها کار کرده است را به خاطر بسپارید و موردی که فراموش می‌کنید، همان موردی است که اهمیت دارد.
• پیکربندی MFA به صورت جداگانه برای هر برنامه، البته در صورتی که برنامه اصلاً از آن پشتیبانی کند.
• ورودهای اشتراکی، که در واقع همان چیزی است که در تیم‌های کوچک تحت این فشار رخ می‌دهد.

نکته آخر شایسته توجه ویژه‌ای است. وقتی یک تیم از یک حساب کاربری مدیر در یک سیستم مدیریت اسناد استفاده می‌کنند، ردپای حسابرسی (audit trail) برای همه فعالیت‌ها یک نام را ثبت می‌کند؛ بنابراین نمی‌توانید تشخیص دهید چه کسی فاکتور را حذف کرده است. مجوزهای مبتنی بر کاربر نیز از کار می‌افتند، زیرا تنها یک کاربر وجود دارد. این آسیب واقعی مالیات SSO است: تیم‌های کوچک را به سمت استفاده از یک حساب اشتراکی سوق می‌دهد که از هر گزینه دیگری بدتر است.

چک‌لیست پیش از به‌کارگیری هر سرویس

این موارد را پیش از docker compose up اجرا کنید، نه زمانی که برنامه حاوی 400 سند است.

1. صفحه احراز هویت را در مستندات باز کرده و یادداشت مربوط به سطوح دسترسی (tier) را در بالای صفحه بخوانید. قابلیت‌های پولی دارای نشان یا یک جمله کوتاه درباره وضعیت دسترسی هستند.
2. تأیید کنید که برنامه از OIDC یا SAML برای اتصال به صادرکننده (issuer) اختصاصی شما پشتیبانی می‌کند، نه فقط یک لیست ثابت از ارائه‌دهندگان عمومی.
3. نگاشت نقش‌ها و گروه‌ها را بررسی کنید. ایجاد کاربر تنها نیمی از کار است؛ تخصیص دستی مجوزها در ده برنامه مختلف، نیمه دشوار و خسته‌کننده کار است.
4. بررسی کنید که آیا برنامه نام کاربری احراز هویت‌شده را از طریق یک هدر (header) از یک پروکسی مورد اعتماد می‌پذیرد یا خیر، و آیا می‌توانید مشخص کنید که به کدام پروکسی اعتماد دارد.
5. تاریخچه لایسنس را در git بخوانید و بررسی کنید که آیا مشارکت‌کنندگان، CLA (توافق‌نامه لایسنس مشارکت‌کننده) را امضا می‌کنند یا خیر.
6. فرآیند خروج (offboarding) را بررسی کنید. ببینید وقتی حساب کاربری در IdP غیرفعال می‌شود، چه اتفاقی برای توکن‌های API (رابط برنامه‌نویسی اپلیکیشن) و نشست‌های فعال می‌افتد.

مورد 2 جایی است که بیشترین ناامیدی رخ می‌دهد. دکمه "Sign in with Google" به معنای OIDC با ارائه‌دهنده هویت شما نیست: این یک ادغام ثابت با یک فروشنده خاص است. پشتیبانی واقعی از شما یک URL صادرکننده (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 منتشر می‌کند. اگر برنامه هیچ فیلدی برای URL صادرکننده نداشته باشد، نمی‌تواند با IdP شما ارتباط برقرار کند، فارغ از اینکه لیست قابلیت‌ها چه چیزی را نشان می‌دهد.

مورد 6 معمولاً هفته‌ها پس از ترک یک فرد توسط تیم‌ها کشف می‌شود. غیرفعال کردن حساب در IdP از ورودهای جدید جلوگیری می‌کند. این کار توکن API که برنامه قبلاً صادر کرده را باطل نمی‌کند، زیرا برنامه خودش آن توکن را اعتبارسنجی می‌کند و هرگز از IdP درباره آن سوال نمی‌کند. بنابراین فرآیند خروج دو مرحله دارد: غیرفعال کردن حساب در IdP و سپس حذف کاربر یا توکن‌های آن در داخل هر برنامه.

معنای واقعی نشان‌های سطح‌بندی (Tier)

این موارد در اوت 2026 بر اساس مستندات هر پروژه بررسی شده‌اند. با بخش پولی شروع می‌کنیم.

Grafana قابلیت SAML را تحت عنوان «موجود در Grafana Enterprise و Grafana Cloud» به همراه همگام‌سازی تیم (team sync) و تأمین SCIM معرفی می‌کند. قابلیت‌های Generic OAuth، GitHub OAuth، LDAP (پروتکل سبک دسترسی به دایرکتوری) و auth proxy همگی در نسخه متن‌باز (open source) موجود هستند، بنابراین یک کاربر کوچک که سرویس را روی سرور شخصی میزبانی می‌کند، همچنان می‌تواند از طریق ارائه‌دهنده خود وارد شود. مرز پرداخت در اینجا روی SAML قرار دارد، نه کل قابلیت Single Sign-On؛ این همان ظرافتی است که عبارت «مالیات SSO» معمولاً آن را نادیده می‌گیرد.

Metabase صریح‌تر عمل می‌کند. مستندات آن می‌گوید: «احراز هویت SAML فقط در طرح‌های Pro و Enterprise (هم برای نسخه self-hosted و هم در Metabase Cloud) موجود است.» نسخه متن‌باز همچنان ورود با رمز عبور و LDAP را حفظ کرده است.

Passbolt مستندات SSO خود را با برچسب Pro و Cloud مشخص کرده است، بنابراین نسخه community فاقد این قابلیت است. ارائه‌دهندگان مستندشده شامل Keycloak و Entra ID هستند.

حالا به سراغ سمت دیگر می‌رویم، زیرا این الگو به هیچ وجه فراگیر نیست.

• نسخه GitLab Self-Managed در صفحه SAML خود عبارت «سطح: Free، Premium، Ultimate» را درج کرده است، بنابراین استفاده از SAML در برابر GitLab شخصی شما هیچ هزینه‌ای ندارد.
• سرویس Paperless-ngx تنظیمات OIDC را از طریق django-allauth با PAPERLESS_SOCIALACCOUNT_PROVIDERS انجام می‌دهد، فرم ورود محلی را با PAPERLESS_DISABLE_REGULAR_LOGIN مخفی می‌کند و claimها را با PAPERLESS_SOCIAL_ACCOUNT_SYNC_GROUPS به گروه‌ها نگاشت می‌کند.
• سرویس Planka از OIDC_ISSUER، OIDC_CLIENT_ID و OIDC_CLIENT_SECRET استفاده می‌کند، اسکوپ‌های پیش‌فرض خود را روی openid profile email تنظیم می‌کند و مدیران را از طریق یک role claim با OIDC_ADMIN_ROLES ارتقا می‌دهد.
• سرویس BookStack با AUTH_METHOD=oidc سوئیچ می‌کند و سپس گروه‌های ارائه‌دهنده را با OIDC_USER_TO_GROUPS=true و OIDC_GROUPS_CLAIM به نقش‌های داخلی خود نگاشت می‌کند.
• سرویس Vaultwarden در تاریخ 27 دسامبر 2025 و در نسخه 1.35.0، «پشتیبانی از SSO با OpenID Connect» را عرضه کرد؛ این قابلیت از طریق یک pull request توسط یکی از مشارکت‌کنندگانی اضافه شد که قبلاً این ویژگی را در یک fork نگهداری می‌کرد.
• سرویس listmonk از نسخه v4.0.0 به بعد، ورود با OIDC را در کنار نقش‌های کاربری خود داشته است.

هنگام انتخاب سرویس، پیش از آنکه خود را متعهد به استفاده از آن کنید، این موارد را در نظر بگیرید. یک تخته کانبان Planka و سایر جایگزین‌های Trello برای میزبانی شخصی همگی با هویت به یک شکل برخورد نمی‌کنند؛ این موضوع در مورد BookStack، Wiki.js و Outline نیز صادق است. OIDC رایگان قابلیتی است که می‌توانید آن را مانند محدودیت‌های ذخیره‌سازی یا کلاینت‌های موبایل ارزیابی کنید. اگر هنوز در حال تهیه لیست هستید، چه چیزی را در سال 2026 میزبانی کنیم نقطه شروع مناسبی است و هر دو سرویس مدیریت اسناد Paperless-ngx و Vaultwarden امروزه OIDC رایگان را در اختیار شما قرار می‌دهند.

چرا استفاده از reverse proxy در مقابل برنامه به معنای single sign-on نیست

راهکار رایج برای این موضوع، forward auth است. در این حالت، reverse proxy هر درخواست را متوقف می‌کند، از یک سرویس احراز هویت می‌پرسد که آیا این مرورگر وارد سیستم شده است یا خیر، و تنها در صورت تأیید، درخواست را به برنامه ارسال می‌کند. authentik این قابلیت را proxy provider می‌نامد که دارای یک حالت forward auth برای یک برنامه واحد و حالتی دیگر برای کل دامنه است. Authelia و oauth2-proxy نیز همین وظیفه را انجام می‌دهند.

یک بلاک site در Caddy، با پیروی از مثال خودِ 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 اهمیت دارند، زیرا نام‌های ناهماهنگ به‌صورت خالی دریافت می‌شوند. در هر درخواستی که تأیید می‌شود، outpost مقادیر X-authentik-username، X-authentik-email، X-authentik-groups و چند مورد دیگر را تنظیم می‌کند.

این روش مزایای زیر را برای شما به همراه دارد: هیچ‌کس بدون عبور از ارائه‌دهنده هویت (IdP) شما به برنامه دسترسی پیدا نمی‌کند؛ بنابراین یک فرم ورود وصله‌نشده دیگر در معرض اینترنت نیست و MFA به‌طور هم‌زمان برای تمام سرویس‌های پشت پروکسی اعمال می‌شود.

اما این روش مزایای زیر را به همراه ندارد: هویت در داخل برنامه. برنامه همچنان حساب‌های کاربری خاص خود و درک مستقل خود را از اینکه چه کسی وارد سیستم شده است، دارد. اگر همه از پروکسی عبور کنند و به یک حساب کاربری مشترک مدیر (administrator) برسند، شما یک درب ورودی مستحکم دارید که پشت آن یک نشست ناشناس قرار گرفته است. لاگ حسابرسی (audit log) همچنان تنها یک نام را نشان می‌دهد. مجوزها همچنان نمی‌توانند بین افراد متفاوت باشند. نامیدن این ساختار به عنوان SSO یک اشتباه امنیتی است، زیرا داستان خروج کاربر (offboarding) تنها نیمی از حقیقت است: حذف فرد از IdP، درب ورودی را می‌بندد، اما توکن API که او در داخل برنامه ایجاد کرده است، همچنان برای هر کسی که بتواند مستقیماً به برنامه دسترسی پیدا کند، کار خواهد کرد.

ایمن‌سازی احراز هویت مبتنی بر هدر

برخی برنامه‌ها نام کاربری را از پروکسی می‌پذیرند که بدون نیاز به SSO پولی، هویت کاربر را مشخص می‌کند. نام این تنظیمات در هر پروژه متفاوت است.

Grafana این قابلیت را auth proxy می‌نامد و به‌صورت پیش‌فرض آن را غیرفعال عرضه می‌کند. نام هدر به‌طور پیش‌فرض X-WEBAUTH-USER است و می‌توانید آن را به هر هدری که پروکسی شما تنظیم می‌کند، ارجاع دهید.

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

whitelist خطی است که کاربران معمولاً از آن غافل می‌شوند. مستندات Grafana به‌صراحت بیان می‌کند که این تنظیم برای جلوگیری از جعل هدر توسط کاربران است، بنابراین باید فقط شامل آدرس پروکسی شما باشد و نه هیچ چیز دیگر. Gitea همین قابلیت را با نام‌های متفاوتی دارد و با تنظیمات پیش‌فرض ایمن‌تری عرضه می‌شود.

[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 به‌طور پیش‌فرض روی 127.0.0.0/8,::1/128 تنظیم شده است و REVERSE_PROXY_LIMIT تعداد پروکسی‌هایی است که Gitea در زنجیره به آن‌ها اعتماد می‌کند. تنظیم این محدودیت روی صفر، پردازش هدر را به‌طور کامل غیرفعال می‌کند.

Paperless-ngx قابلیت PAPERLESS_ENABLE_HTTP_REMOTE_USER را با PAPERLESS_HTTP_REMOTE_USER_HEADER_NAME ارائه می‌دهد و مستندات آن هشداری را بیان می‌کند که برای تمام این تنظیمات صادق است:

این کار اجازه می‌دهد احراز هویت صرفاً با افزودن یک هدر Remote-User: <username> به درخواست انجام شود. با احتیاط استفاده کنید!

دو قانون برای ایمن نگه داشتن احراز هویت مبتنی بر هدر وجود دارد که هر دو مربوط به دسترسی‌پذیری هستند. اول، برنامه نباید از هیچ مسیری جز پروکسی در دسترس باشد، زیرا هر کسی که بتواند یک سوکت به آن باز کند، می‌تواند آن هدر را ارسال کرده و به هر کاربری تبدیل شود. در Docker، دستور ports: ["8000:8000"] برنامه را روی تمام اینترفیس‌ها منتشر می‌کند، بنابراین آن را با ports: ["127.0.0.1:8000:8000"] به آدرس loopback محدود کنید یا پورت منتشر شده را حذف کرده و پروکسی را در همان شبکه Docker قرار دهید. دوم، پروکسی باید هر نسخه‌ای از هدر که از سمت کلاینت می‌رسد را حذف کند تا تنها مقداری که برنامه می‌بیند، همان مقداری باشد که پروکسی شما پس از احراز هویت تنظیم کرده است.

هر دو مورد را بررسی کنید. دستور اول را از ماشینی خارج از VPS خود و دستور دوم را روی خود سرور اجرا کنید.

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

دستور curl باید در اتصال ناموفق باشد و ss باید به جای 0.0.0.0:8000، مقدار 127.0.0.1:8000 را چاپ کند. مشاهده HTTP/1.1 302 Found در خط اول به این معنی است که برنامه مستقیماً به اینترنت عمومی پاسخ می‌دهد، بنابراین هر کسی می‌تواند با نام بردن از کاربران در یک هدر، به عنوان آن‌ها وارد سیستم شود.

وقتی SSO رایگان وجود ندارد، به‌جای شکایت تصمیم بگیرید

چهار گزینه، به ترتیبی که من آن‌ها را امتحان می‌کنم:

1. برنامه‌ای را انتخاب کنید که شامل OIDC باشد. وقتی دو پروژه کار مشابهی انجام می‌دهند و یکی از آن‌ها به‌صورت رایگان با Identity Provider شما ارتباط برقرار می‌کند، این یک تفاوت واقعی در هزینه‌های جاری است.
2. صادقانه از forward auth استفاده کنید. برای یک ابزار مدیریتی با یک حساب کاربری و یک اپراتور، وجود یک proxy در مقابل آن کافی است و احراز هویت برای هر کاربر در داخل برنامه، مزیتی ایجاد نمی‌کند.
3. هزینه پرداخت کنید. اگر برنامه برای کار شما حیاتی است و قیمت به ازای هر کاربر با اندازه تیم شما متناسب است، این پول صرف نگهداری پروژه می‌شود و جایگزین آن، صرف کردن وقت آزاد شما در شب‌ها خواهد بود.
4. پس از جستجو در issue tracker، از توسعه‌دهندگان اصلی (upstream) درخواست کنید. پشتیبانی OIDC در Vaultwarden از طریق fork یک مشارکت‌کننده و یک pull request طولانی‌مدت اضافه شد؛ بنابراین یک درخواست قابلیت (feature request) که پیاده‌سازی عملی به همراه داشته باشد، گاهی اوقات به نسخه رایگان راه پیدا می‌کند.

هیچ‌کدام از این موارد بدون داشتن یک Identity Provider اختصاصی کار نمی‌کنند؛ این همان قطعه‌ای است که باید ابتدا بسازید. اجرای authentik روی یک VPS به شما یک ارائه‌دهنده OIDC و SAML به همراه outpost مربوط به forward auth که در بالا ذکر شد می‌دهد، و مقایسه Keycloak، authentik و Zitadel در صورتی که هنوز نمی‌خواهید تصمیم نهایی را بگیرید، تفاوت‌ها و اولویت‌ها را بررسی می‌کند.

تاریخچه مجوز و دلیل گنجاندن آن در چک‌لیست

آخرین مورد چک‌لیست به آینده مربوط است، زیرا ساختار فعلی لایه‌ها تنها تصویری از وضعیت کنونی است. دو مورد مستند به‌خوبی نشان می‌دهند که شرایط با چه سرعتی در هر دو جهت تغییر می‌کند. شرکت HashiCorp در تاریخ 10 August 2023 مجوز Business Source License 1.1 را برای تمامی نسخه‌های آتی خود اتخاذ کرد، در حالی که نسخه‌های پیشین تحت مجوز 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) عرضه می‌شود.

هر دو مورد را به عنوان شواهدی از یک سازوکار در نظر بگیرید، نه انگیزه‌های پشت آن. مجوزی که امروز مطالعه می‌کنید، تنها برای نسخه‌ای که امروز نصب می‌کنید معتبر است و پروژه‌ای که تمام حقوق کپی‌رایت خود را در اختیار دارد، می‌تواند شرایط نسخه بعدی را به‌طور مستقل تغییر دهد. به همین دلیل است که پرسش مربوط به CLA در چک‌لیست قرار دارد؛ چرا که واگذاری گسترده کپی‌رایت، همان عاملی است که تغییر یک‌جانبه مجوز را ممکن می‌سازد.

پیش از آنکه پروژه‌ای را مبنای کار خود قرار دهید، تاریخچه آن را شخصاً بررسی کنید.

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

فهرست کوتاهی از کامیت‌ها، که عمدتاً مربوط به اولین import پروژه باشد، نشانه مثبتی است. بازنویسی‌های متعدد فایل مجوز به این معناست که باید پیش از برنامه‌ریزی بر اساس شرایط فعلی، پیام هر کامیت را مطالعه کنید.

FAQ

مالیات SSO چیست؟

مالیات SSO به رویه‌ای گفته می‌شود که در آن قابلیت Single Sign-on (ورود یکپارچه) به‌عنوان یک ویژگی ممتاز (Premium) فروخته می‌شود، در حالی که سایر بخش‌های محصول رایگان یا ارزان هستند. در نرم‌افزارهای self-hosted، این موضوع به شکل یک برنامه متن‌باز دیده می‌شود که می‌توانید بدون کلید لایسنس اجرا کنید، اما قابلیت ورود از طریق OIDC یا SAML در نسخه پولی قرار دارد. این نام از «دیوار شرم SSO» در وب‌سایت sso.tax گرفته شده است که فروشندگانی را که برای این قابلیت هزینه گزافی دریافت می‌کنند، ردیابی می‌کند. پیامد این موضوع برای کسی که سرویس‌ها را روی سرور شخصی میزبانی می‌کند این است که هر برنامه پایگاه داده کاربری مستقل خود را حفظ می‌کند و در نتیجه، حساب‌های کاربری باید به‌صورت دستی ایجاد یا حذف شوند.

آیا reverse proxy با forward auth همان SSO است؟

خیر. Forward auth از ورودی اصلی محافظت می‌کند: پروکسی شما پیش از آنکه هر درخواستی به برنامه برسد، آن را با Identity Provider بررسی می‌کند. برنامه‌ای که پشت این پروکسی قرار دارد همچنان از حساب‌های کاربری خودش استفاده می‌کند؛ بنابراین اگر همه کاربران به یک صفحه ورود مشترک هدایت شوند، شما یک نشست (session) ناشناس واحد خواهید داشت و لاگ‌های حسابرسی (audit log) تنها یک نام را ثبت می‌کنند. این سیستم تنها زمانی به هویت واقعی برای هر کاربر تبدیل می‌شود که برنامه، نام کاربری را از یک header بخواند؛ کاری که auth proxy در Grafana، احراز هویت reverse proxy در Gitea و PAPERLESS_ENABLE_HTTP_REMOTE_USER در Paperless-ngx همگی قادر به انجام آن هستند. این تنظیمات تنها زمانی امن هستند که برنامه به‌جز از طریق پروکسی در دسترس نباشد، زیرا header یک رشته متنی ساده است که هر کلاینتی می‌تواند آن را ارسال کند.

کدام برنامه‌های self-hosted قابلیت OIDC را در نسخه رایگان دارند؟

بر اساس مستندات پروژه‌ها در اوت 2026: برنامه‌های Paperless-ngx، Planka، BookStack، Gitea، listmonk و Vaultwarden همگی در نسخه‌های رایگان خود از OIDC پشتیبانی می‌کنند و GitLab Self-Managed نیز SAML را در رده Free ارائه می‌دهد. نسخه متن‌باز Grafana از OAuth عمومی در برابر issuer شخصی شما پشتیبانی می‌کند، در حالی که SAML در آنجا یک ویژگی Enterprise محسوب می‌شود. پیش از نصب، حتماً در صفحه احراز هویت پروژه مربوطه بررسی کنید، زیرا این لیست‌ها با انتشار نسخه‌های جدید تغییر می‌کنند.

آیا باید برای رده‌ای که قفل Single Sign-on را باز می‌کند هزینه پرداخت کنم؟

این تصمیم را با دو عدد بسنجید: چند نفر به حساب کاربری نیاز دارند و چند برنامه را باید در غیر این صورت به‌صورت دستی مدیریت کنید. برای یک یا دو مدیر سیستم، استفاده از forward auth در مقابل یک حساب کاربری محلی کافی است و نسخه پولی مزیت چندانی ندارد. برای تیمی که افراد در آن عضو می‌شوند یا آن را ترک می‌کنند، یک حساب کاربری که هنگام خروج فرد فراموش شود، هزینه‌ای بیش از قیمت لایسنس دارد و این پرداخت، هزینه‌های نگهداری سرویسی که به آن وابسته هستید را تأمین می‌کند. اگر قیمت مناسب نیست، راهکار عملی این است که برنامه‌ای را انتخاب کنید که شامل OIDC باشد، به‌جای آنکه بخواهید محدودیت‌های برنامه‌ای که فاقد آن است را دور بزنید.