سوالات متداول سامانه SSO

SSO (Single Sign-On) نتیجه‌ای از بهره‌گیری از پروتکل‌هایی مانند OAuth است؛ به این معنا که کاربران با یک‌بار احراز هویت در یک درگاه مرکزی (Identity Provider)، می‌توانند بدون نیاز به ورود مجدد و حفظ چندین رمز عبور مختلف، به تمامی سرویس‌ها و برنامه‌های سازمان به‌صورت یکپارچه دسترسی پیدا کنند. این رویکرد، علاوه بر افزایش امنیت، تجربه کاربری را نیز بهبود می‌بخشد؛ زیرا دیگر نیازی نیست کاربران آدرس‌های متعدد و متفاوت سامانه‌ها را به خاطر بسپارند و تنها با استفاده از یک پنجره واحد، به همه سرویس‌ها متصل می‌شوند.

پروتکل‌های استاندارد OAuth، OpenID Connect (OIDC) و SAML در لایه هویت و دسترسی (Identity & Access Management) فعال هستند و اساس فنی و زیرساختی لازم برای پیاده‌سازی و اجرای راهکار SSO را فراهم می‌کنند.

OAuth (Open Authorization) یک پروتکل مجوزدهی است که به سرویس‌ها امکان می‌دهد بدون نیاز به اشتراک‌گذاری رمز عبور، به منابع کاربر در سرویس‌های دیگر دسترسی محدود (scope) پیدا کنند. فرایند کار به این صورت است که:

1. کاربر در سرویس/ اپلیکیشن/ نرم افزار، “در پروتکل OAuth، مشتری گفته می‌شود” (Client) درخواست دسترسی می‌دهد.

2. سرویس مشتری، کاربر را به “سرور مجوزدهی که در اینجا SSO پلاس هست” (Authorization Server) هدایت می‌کند.

3. پس از تأیید هویت کاربر، سرور مجوزدهی یک توکن دسترسی (Access Token) صادر می‌کند.

4. مشتری با استفاده از آن توکن، درخواست‌های محدودشده را به “سرور منابع” (Resource Server) ارسال می‌کند.
   این جداسازی نقش‌ها، از لو رفتن مستقیم رمز عبور جلوگیری کرده و کنترل دقیق‌تری روی سطوح دسترسی فراهم می‌آورد.

OIDC یک لایهٔ احراز هویت مبتنی بر OAuth 2.0 است که امکان تأیید هویت کاربر و دریافت اطلاعات پروفایل (Claims) را فراهم می‌کند. در OIDC علاوه بر توکن دسترسی (Access Token)، یک ID Token به‌صورت JWT صادر می‌شود که شامل اطلاعات هویتی کاربر مانند شناسه، ایمیل و تاریخ انقضاست. مزایای OIDC عبارت‌اند از:

• استانداردسازی فرآیند ورود یکپارچه (SSO)

• پشتیبانی بومی از JSON Web Token (JWT)

• قابلیت تأیید آنی (instant validation) و دریافت پروفایل غنی کاربر

1. تعریف یک پروتکل واحد برای احراز هویت

   • OIDC روی پروتکل OAuth 2.0 سوار می‌شود و دقیقا مشخص می‌کند که برای «ورود» چه پیام‌هایی بین مشتری (Relying Party) و ارائه‌دهندهٔ هویت (Identity Provider) رد و بدل شود.

   • بدون OIDC، هر سرویس‌دهنده ممکن است روش و فرمت متفاوتی برای تأیید هویت پیشنهاد دهد؛ اما OIDC این کار را یک‌سان می‌کند.

2. استانداردسازی توکنِ هویتی (ID Token)

   • OIDC یک ID Token به‌صورت JWT (JSON Web Token) تعریف می‌کند که در آن میدان‌های استاندارد (Claims) مانند sub (شناسهٔ کاربر)، iss (آدرس IdP)، aud (نشانی سرویس‌گیرنده) و exp (تاریخ انقضا) وجود دارد.

   • همهٔ کلاینت‌ها و کتابخانه‌ها می‌دانند چه فیلدهایی را باید بررسی و اعتبارسنجی کنند.

3. استانداردسازی نقاط انتهایی (Endpoints)

   • OIDC مجموعه‌ای از endpointهای مشخص را معرفی می‌کند:

     • /authorize برای درخواست ورود

     • /token برای دریافت توکن‌ها

     • /userinfo برای دریافت اطلاعات پروفایل کاربر

     • /.well-known/openid-configuration برای Discovery خودکار تنظیمات IdP

   • این یعنی کلاینت می‌تواند بدون پیکربندی دستیِ جداگانه، آدرس‌ها و قابلیت‌های IdP را کشف و استفاده کند.

4. مدیریت scope و claims

   • با تعریف scope=openid به‌وضوح می‌گوییم که هدف «احراز هویت» است نه صرفاً «دسترسی به API».

   • لیست استانداردی از claims (مثلاً email, name, preferred_username) وجود دارد که همهٔ IdPها می‌توانند بر اساس تنظیمات سرویس، آنها را بازگردانند.

5. تضمین سازگاری و تسهیل توسعه

   • هر ارائه‌دهندهٔ هویت و هر کتابخانهٔ OIDC حساب‌شده عمل می‌کند، چون از یک Specification (مستند استاندارد) پیروی می‌کنند.

   • توسعه‌دهندگان نیازی به یادگیری چندین روش مخفی و اختصاصی ندارند، بلکه با پیاده‌سازی یک استاندارد باز (Open Standard) کار را پیش می‌برند.

مثال ساده از جریان SSO با OIDC:

1. کاربر روی کلاینت (وب‌اپ یا موبایل) روی «ورود با OIDC» کلیک می‌کند.

2. کلاینت کاربر را به https://idp.example.com/authorize?scope=openid%20email&client_id=… هدایت می‌کند.

3. پس از لاگین و MFA، IdP کاربر را به مسیر callback کلاینت با یک Authorization Code ارجاع می‌دهد.

4. کلاینت با آن کد، یک درخواست POST به /token می‌فرستد و ID Token و Access Token دریافت می‌کند.

5. با بررسی امضای ID Token و مقادیر iss, aud, exp، هویت کاربر تأیید و نشست SSO برقرار می‌شود.

با این سازوکار واحد و تعریف‌شده، پیاده‌سازی ورود یکپارچه برای همهٔ پلتفرم‌ها (وب، موبایل، SPA و حتی سرویس‌های سرور-به-سرور) یکسان، امن و قابل اطمینان خواهد بود.

SAML (Security Assertion Markup Language) یک استاندارد XML-محور برای تبادل ادعاهای هویتی بین ارائه‌دهندهٔ هویت (IdP) و سرویس‌گیرنده (SP) است. ساختار اصلی SAML شامل موارد زیر است:

• Assertion: اطلاعات هویتی (مانند نام کاربری، نقش‌ها و زمان صدور)

• Protocol: نحوهٔ ارسال و دریافت Assertion (معمولاً از طریق مرورگر و POST یا Redirect)

• Bindings: روش حمل پیام‌ها (HTTP-Redirect, HTTP-POST)

• Profiles: تعریف موارد استفاده (مثلاً Web Browser SSO Profile)
  SAML به‌خصوص در محیط‌های سازمانی بزرگ برای ورود یکپارچه بین دامین‌های مختلف، بسیار پرکاربرد است.

سؤال:
روش یکپارچه‌سازی سامانه سازمانی با «دولت من» از طریق SSO چگونه است؟

پاسخ:
برای یکپارچه‌سازی سامانه‌های سازمانی با «دولت من» از طریق SSO، ابتدا باید یک سامانه احراز هویت یکپارچه (SSO سازمانی) در سازمان خود پیاده‌سازی کنید. در گام بعد، SSO پلاس به‌عنوان سامانه مرکزی مدیریت هویت، مطابق استانداردهای امنیتی از جمله OAuth 2.0 به‌سادگی به «پنجره خدمات دولت الکترونیکی» متصل می‌شود.

فرایند فنی بسیار ساده است:

1. ابتدا یک «کلاینت اختصاصی» در پنجره ملی خدمات دولت الکترونیکی (دولت من) برای سازمان خود ثبت می‌کنید.

2. سپس این کلاینت از طریق استاندارد OAuth 2.0 به سامانه SSO پلاس متصل می‌شود.

3. پس از آن، تمام سامانه‌های الکترونیکی سازمانی شما در سمت SSO پلاس تعریف و مدیریت می‌شوند.

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

سؤال:
IAM (مدیریت هویت و دسترسی) چیست و ارتباط آن با SSO چگونه است؟

پاسخ:
مدیریت هویت و دسترسی (IAM – Identity and Access Management) مجموعه‌ای از سیاست‌ها، فناوری‌ها و فرآیندهایی است که برای مدیریت هویت دیجیتال کاربران و کنترل دقیق دسترسی آن‌ها به منابع و سیستم‌ها در یک سازمان به کار می‌رود. IAM تعیین می‌کند که «چه کسی»، «به چه منابعی»، «در چه زمانی» و «با چه سطح دسترسی» می‌تواند وارد شود.

سامانه احراز هویت یکپارچه (SSO) بخش مهمی از راهکار IAM است. در واقع، SSO به عنوان جزئی کلیدی در IAM، به کاربران اجازه می‌دهد تنها با یک بار احراز هویت در یک سامانه مرکزی (Identity Provider)، بدون نیاز به ورود مجدد، به همه سامانه‌ها و سرویس‌های مجاز دسترسی پیدا کنند.

به عبارت دیگر:

• IAM چارچوب کلان مدیریت هویت، احراز هویت، و مجوزدهی در سازمان است.

• SSO یکی از قابلیت‌ها و امکاناتی است که در این چارچوب به منظور راحتی کاربران، افزایش امنیت و ساده‌سازی فرآیند ورود مورد استفاده قرار می‌گیرد.

با پیاده‌سازی IAM و استفاده از SSO، سازمان‌ها علاوه بر افزایش امنیت، کاهش هزینه‌های پشتیبانی و افزایش بهره‌وری کاربران را تجربه می‌کنند.

سؤال:
تفاوت SSO (ورود یکپارچه) با KYC (شناسایی مشتری) چیست و چه ارتباطی بین آن‌ها وجود دارد؟

پاسخ:
سامانه ورود یکپارچه (SSO – Single Sign-On) و فرایند شناسایی مشتری (KYC – Know Your Customer) دو مفهوم متفاوت اما مکمل یکدیگر هستند که هر دو در مسیر احراز هویت و دسترسی کاربران اهمیت دارند:

۱. KYC – شناسایی مشتری (Know Your Customer)
فرآیند KYC مجموعه‌ای از مراحل و دستورالعمل‌هاست که برای شناسایی دقیق هویت کاربران از طریق بررسی مدارک هویتی، اعتبارسنجی اطلاعات فردی، و حتی تطبیق هویت بیومتریک انجام می‌شود. هدف اصلی KYC اطمینان از اصالت هویت حقیقی کاربر، رعایت مقررات امنیتی و جلوگیری از سوءاستفاده‌های احتمالی است.
به زبان ساده‌تر:

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

• این بررسی معمولاً یک بار و در ابتدای ارتباط کاربر با سازمان یا کسب‌وکار صورت می‌گیرد.

۲. SSO – ورود یکپارچه (Single Sign-On)
در مقابل، SSO مکانیزمی است که به کاربران اجازه می‌دهد تنها با یک‌بار وارد کردن نام کاربری و رمز عبور (یا احراز هویت چندعاملی) در یک سامانه مرکزی (Identity Provider)، به تمام سرویس‌ها و منابع مجاز سازمان دسترسی یابند. در SSO، هویت کاربر قبلاً بررسی و تأیید شده است و اکنون تنها نیاز به ورود یکباره برای استفاده از خدمات مختلف دارد.

ارتباط بین KYC و SSO چگونه است؟

فرایند KYC مقدم بر SSO است؛ یعنی:

• ابتدا هویت کاربران در یک پروسه دقیق (KYC) مورد بررسی و تأیید قرار می‌گیرد.

• پس از موفقیت در تأیید هویت، کاربر به‌عنوان یک یوزر معتبر به سامانه SSO اضافه می‌شود.

• حالا این کاربر معتبر شده، می‌تواند به سادگی و به کمک SSO، به کلیه منابع و سرویس‌های سازمان دسترسی یکپارچه و راحت داشته باشد.

به عبارت دیگر، KYC نقطه شروع برای تأیید اصالت هویت کاربر است، و SSO راه‌حلی برای آسان‌تر کردن دسترسی‌های بعدی آن کاربر به منابع و خدمات سازمان است.

SSO پلاس به عنوان يک راهکار احراز هويت يکپارچه (Single Sign-On) به گونه‌اي طراحي شده که به‌راحتي بتواند با مخازن مختلف هويت کاربران، به ويژه Active Directory (AD)، اتصال برقرار کند و مديريت دسترسي‌ها را به‌طور متمرکز انجام دهد.

اتصال به Active Directory و فراتر از آن

 Active Directory همچنان به عنوان يکي از پراستفاده‌ترين منابع هويتي (Identity Repositories) در سازمان‌ها شناخته مي‌شود. SSO پلاس به صورت کاملاً يکپارچه مي‌تواند به Active Directory متصل شود و احراز هويت کاربران را مبتني بر ساختار و سياست‌هاي سازمان انجام دهد. اما قابليت‌هاي SSO پلاس به Active Directory محدود نمي‌شود و امکان اتصال به ساير مخازن نيز وجود دارد، از جمله:

• LDAP Servers مانند OpenLDAP
• پايگاه‌هاي داده (Databases) مانند Oracle و MySQL
• ارائه‌دهندگان هويت ابري (Cloud Identity Providers) مانند Azure AD و Google Identity
• اتصال مبتني بر Agent براي سامانه‌هاي داخلي بدون تغيير معماري
• ادغام از طريق APIهاي سفارشي براي اپليکيشن‌ها و سيستم‌هاي قديمي (Legacy Systems)

روش‌هاي اتصال SSO پلاس به Active Directory

1. اتصال مستقيم از طريق LDAP/LDAPS: ارتباط امن از طريق پروتکل LDAP يا نسخه رمزگذاري‌شده‌ي آن (LDAPS) با سرور Active Directory.
2. استفاده از Agent بومي: در مواردي که اتصال مستقيم امکان‌پذير نباشد، از Agentهاي بومي SSO پلاس براي برقراري ارتباط رمزگذاري‌شده و امن استفاده مي‌شود.
3. همگام‌سازي کاربران و گروه‌ها (User Sync): قابليت سينک خودکار کاربران و گروه‌هاي موجود در Active Directory براي مديريت يکپارچه دسترسي‌ها.
4. احراز هويت ترکيبي (Hybrid Authentication): امکان مديريت هم‌زمان منابع هويتي داخلي مانند Active Directory و منابع ابري مانند Azure AD.

مزاياي اتصال SSO پلاس به Active Directory و ساير مخازن

• ✅ استفاده از زيرساخت‌هاي موجود بدون نياز به تغييرات اساسي
• ✅ احراز هويت سريع، امن و مطابق با سياست‌هاي امنيتي سازمان
• ✅ کاهش چشمگير هزينه‌ها و پيچيدگي‌هاي مديريت کاربران
• ✅ قابليت گسترش آسان به فضاي ابري، موبايل و دسترسي‌هاي راه دور (Remote Access)

نتيجه‌گيري

اتصال SSO پلاس به Active Directory يا ساير منابع هويتي، سازمان‌ها را قادر مي‌سازد تا احراز هويت کاربران خود را به شکلي متمرکز، يکپارچه و امن مديريت کنند. اين يکپارچگي نه تنها امنيت سازمان را افزايش مي‌دهد بلکه مسير را براي توسعه‌هاي آتي مانند مهاجرت به سرويس‌هاي ابري و گسترش دسترسي‌هاي موبايلي نيز هموار مي‌کند.

Permission یا پرمیشن (مجوز دسترسی) به تعیین سطح اختیارات کاربران در یک سامانه گفته می‌شود؛ یعنی مشخص می‌کند چه کسی می‌تواند چه عملیاتی را روی کدام منابع انجام دهد. این مفهومی بنیادی در مدیریت امنیت اطلاعات و کنترل دسترسی (Access Control) است.

مثال ساده:
در یک سیستم، مدیر ممکن است مجوز داشته باشد که کاربران جدید ایجاد کند، پروژه‌ها را مدیریت کند یا تنظیمات سامانه را تغییر دهد، اما یک کاربر عادی تنها اجازه مشاهده اطلاعات یا ثبت درخواست را داشته باشد.

چگونه Permissionها در سامانه‌ها تعریف و مدیریت می‌شوند؟

1. تعریف نقش‌ها (Roles):
ابتدا نقش‌ها (مانند مدیر، کاربر عادی، اپراتور) تعریف می‌شود.

2. تخصیص مجوز به نقش‌ها (Role-Based Access Control – RBAC):
به هر نقش مجموعه‌ای از مجوزهای دسترسی اختصاص داده می‌شود. مثلاً:

• مدیر: ویرایش کاربران، مشاهده گزارش‌ها، تغییر تنظیمات

• کاربر: مشاهده پروفایل، ارسال درخواست پشتیبانی

3. مدیریت پویا (Dynamic Permission Management):
گاهی نیاز است این مجوزها پویا باشند؛ یعنی مدیر سیستم یا بخش منابع انسانی بتواند در محیط عملیاتی (بدون تغییر کد برنامه) مشخص کند که یک نقش خاص چه محدوده‌ای از اختیارات داشته باشد.
مثلاً:

• تعریف سطوح دسترسی جدید از طریق پنل مدیریت

• اضافه یا حذف مجوزها از یک نقش بدون نیاز به برنامه‌نویسی

• اعمال تغییرات آنی در دسترسی‌ها بر اساس سیاست‌های جدید سازمان

4. ارتباط Permission با کاربر:
کاربران می‌توانند مستقیم یا از طریق نقش‌هایی که به آن‌ها نسبت داده شده، مجوزهای مشخصی دریافت کنند.

نمونه‌ای از یک ساختار پویا برای Permission در سامانه:

چرا مدیریت پویا مهم است؟

✅ افزایش انعطاف‌پذیری سازمان در پاسخ به تغییرات
✅ عدم نیاز به تغییر ساختار نرم‌افزار برای تغییر دسترسی‌ها
✅ ارتقاء امنیت با کمینه‌سازی دسترسی‌های غیرضروری
✅ ساده‌سازی فرآیند انطباق با استانداردهای امنیتی و ممیزی‌ها

نتیجه:
Permissionها ساختار حیاتی در کنترل دسترسی سامانه‌ها هستند. با پیاده‌سازی سیستم مدیریت پویا برای مجوزها، سازمان‌ها می‌توانند به راحتی اختیارات نقش‌ها را تغییر دهند، امنیت را بهبود بخشند و تجربه بهتری برای کاربران خود فراهم کنند.

Access Token یک توکن دیجیتال کوتاه‌عمر است که برای دسترسی به منابع محافظت‌شده مانند APIها پس از احراز هویت کاربر استفاده می‌شود.

Refresh Token یک توکن بلندمدت است که پس از انقضای Access Token، امکان دریافت یک توکن جدید را بدون نیاز به ورود مجدد فراهم می‌کند.

Access Token برای دسترسی مستقیم به منابع استفاده می‌شود و عمر کوتاهی دارد، در حالی که Refresh Token پشت‌صحنه برای تمدید Access Token به کار می‌رود و معمولاً عمر طولانی‌تری دارد.

Refresh Token چه زمانی استفاده می‌شود؟ زمانی که Access Token منقضی می‌شود، کلاینت با استفاده از Refresh Token می‌تواند بدون نیاز به ورود مجدد، توکن جدیدی دریافت کند.

آیا استفاده از Refresh Token امنیت را افزایش می‌دهد؟ بله، زیرا Access Token عمر کوتاه‌تری دارد و در صورت سرقت، ریسک سوءاستفاده محدود می‌شود. با Refresh Token می‌توان نشست کاربر را بدون ورود مجدد تمدید کرد.

🔐 تفاوت Access Token و Refresh Token

🔁 ارتباط بین Access Token و Refresh Token

زمانی که کاربر با موفقیت احراز هویت می‌شود:

1. سرور احراز هویت (Authorization Server) دو توکن صادر می‌کند:

   • Access Token: برای دسترسی مستقیم به منابع (APIها)

   • Refresh Token: برای تمدید Access Token بعد از انقضا

2. پس از پایان اعتبار Access Token:

   • به جای ورود مجدد کاربر، کلاینت می‌تواند با ارسال Refresh Token یک Access Token جدید دریافت کند.

🎯 چرا این مکانیزم مهم است؟

• امنیت بالا: چون Access Token عمر کوتاهی دارد، اگر به هر دلیلی فاش شود، زمان سوءاستفاده از آن محدود است.

• UX بهتر: کاربران مجبور نیستند مکرراً لاگین کنند، چون پشت‌صحنه از Refresh Token استفاده می‌شود.

• کنترل‌پذیری: می‌توان Refresh Token را در صورت نیاز باطل کرد (مثلاً در خروج اجباری یا تغییر رمز عبور).

🔐 مثال در معماری SSO

در سامانه‌هایی مثل SSO پلاس:

• Access Token برای دسترسی به پنل‌های کاربری و APIهای داخلی استفاده می‌شود.

• Refresh Token پشت‌صحنه در اختیار کلاینت نگه داشته می‌شود تا نشست را بدون ورود مجدد تمدید کند.

• با اضافه شدن Single Logout، Refresh Token نیز باطل می‌شود تا از ورود مجدد ناخواسته جلوگیری شود.

بله، SSO پلاس علاوه بر ورود یکپارچه (Single Sign-On – SSO)، از خروج یکپارچه (Single Logout – SLO) نیز پشتیبانی می‌کند.
با Single Logout، کاربر پس از خروج از یکی از سامانه‌های متصل، به‌طور خودکار از تمامی سامانه‌ها و سرویس‌های دیگر که از همان نشست استفاده می‌کنند، خارج می‌شود. این ویژگی، ریسک باقی‌ماندن نشست‌های فعال (Active Sessions) را کاهش داده و سطح امنیت سازمان را به شکل چشمگیری افزایش می‌دهد.

با این حال، پیاده‌سازی کامل SLO نیازمند هماهنگی فنی میان سامانه‌های مختلف است؛
یعنی سامانه‌های مقصد باید یک API خروج (Logout Endpoint) مطابق استاندارد به سامانه SSO پلاس معرفی کنند.
در هنگام خروج کاربر، SSO پلاس این APIها را به ترتیب فراخوانی می‌کند تا اطمینان حاصل شود که کاربر از همه سامانه‌ها به‌درستی خارج شده است.
عدم ارائه API خروج توسط هر سامانه ممکن است باعث شود خروج کامل از آن سرویس انجام نشود.

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

مهاجرت کاربران به SSO پلاس کاملاً هوشمند و بدون نیاز به ثبت‌نام دستی (Registerless Migration) انجام می‌شود. فرآیند به این صورت است:

1. کاربر در اولین ورود، کد ملی خود را در درگاه SSO پلاس وارد می‌کند.

2. اگر اطلاعات کاربر در مخزن هویتی (مثلاً Active Directory یا پایگاه داده سازمان) موجود باشد، یک کد تأیید (OTP) برای کاربر ارسال می‌شود و پس از وارد کردن OTP، احراز هویت کامل می‌شود.

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

4. پس از احراز این اطلاعات، کاربر می‌تواند یک رمز عبور جدید تنظیم کند و بلافاصله در سامانه SSO پلاس ثبت و فعال شود.

این فرایند باعث می‌شود کاربران بدون سردرگمی و بدون نیاز به مراحل ثبت‌نام سنتی، به‌سرعت مهاجرت کرده و آماده‌ی استفاده از خدمات سازمانی شوند.