خدمات مشتری
ورود یکپارچه (SSO) در پلتفرم پیامرسانی با مشتری: راهنمای OpenID Connect برای تیمهای پشتیبانی
اپراتوری که تمام روز گفتگوهای مشتریان را میخواند باید با حساب سازمانی خود وارد شود، نه با یک رمز عبور جداگانه. در این راهنما میبینید ورود یکپارچه با OpenID Connect چگونه کار میکند، پیش از فعال کردن آن درباره چه چیزهایی باید تصمیم بگیرید و چگونه آن را روی نصب درونسازمانی (on-premise) MonoChat راهاندازی کنید.
تیم MonoChat بهروزرسانی: 9 دقیقه مطالعه
در این صفحه
- چرا نحوه ورود برای تیم پشتیبانی مهم است
- ورود با OpenID Connect چگونه کار میکند
- پیش از فعال کردن SSO درباره این پنج مورد تصمیم بگیرید
- راهاندازی SSO روی نصب درونسازمانی MonoChat
- اپراتورهای فعلی: حسابها چگونه متصل میشوند
- SSO هویت را تعیین میکند، نقشها دسترسی را
- محدودیتهایی که باید برایشان برنامهریزی کنید
- جایگاه SSO در MonoChat
- منابع
ورود یکپارچه (SSO) در یک پلتفرم پیامرسانی با مشتری یعنی اپراتورهای شما با حساب سازمانی خود در ارائهدهنده هویت شرکت، مانند Microsoft Entra ID، Okta، Keycloak، AD FS یا Google Workspace، وارد میشوند و دیگر رمز عبور جداگانهای ندارند. استاندارد پشت آن OpenID Connect (OIDC) است. در نصب درونسازمانی (on-premise) MonoChat، SSO را یک بار برای کل نصب راهاندازی میکنید، آن را به دامنههای ایمیل شرکت خود محدود میکنید و میتوانید آن را تنها روش ورود قرار دهید.
تیمهای پشتیبانی دلیل ویژهای برای اهمیت دادن به این موضوع دارند. حساب هر اپراتور همه گفتگوهای WhatsApp، Instagram و Messenger را که او میبیند باز میکند: نامها، شماره تلفنها، جزئیات سفارش و گاهی پرسشهای پزشکی یا پرداخت. این حساب باید از همان قوانینی پیروی کند که بقیه حسابهای شرکت دارند و باید همان روزی که فرد از شرکت میرود، از کار بیفتد.
چرا نحوه ورود برای تیم پشتیبانی مهم است
اطلاعات ورود سرقتشده یا سوءاستفادهشده هنوز رایجترین راه نفوذ به یک شرکت است. گزارش بررسی نقض دادههای Verizon در سال 2025 (Data Breach Investigations Report) که 12,195 نقض تأییدشده را تحلیل کرده، نشان داد سوءاستفاده از اطلاعات ورود (22%) و بهرهبرداری از آسیبپذیریها (20%) اصلیترین راههای آغاز حمله بودهاند.
پلتفرم پیامرسانیای که رمزهای عبور خودش را دارد، برای هر اپراتور یک مجموعه اطلاعات ورود دیگر اضافه میکند: یک رمز دیگر که ممکن است تکراری انتخاب شود، یک حساب دیگر که ممکن است هنگام رفتن کسی فراموش شود، و یک ورود دیگر که قوانین احراز هویت چندعاملی (MFA) و دسترسی مشروط شما آن را پوشش نمیدهند. با SSO، پلتفرم هرگز رمز عبور را نمیبیند. ارائهدهنده هویت شما رمز را بررسی میکند، MFA و سیاستهای دسترسی شما را اعمال میکند و به پلتفرم میگوید چه کسی وارد شده است.
ورود با OpenID Connect چگونه کار میکند
OpenID Connect یک لایه هویت روی OAuth 2.0 است. روشی که MonoChat به کار میبرد، جریان کد مجوز (authorization code flow) است:
- اپراتور روی دکمه SSO در صفحه ورود کلیک میکند. MonoChat صفحه ورود ارائهدهنده هویت شما را در یک پنجره بازشو باز میکند.
- اپراتور همانجا، با MFA و سیاستهای شما، وارد میشود.
- ارائهدهنده هویت مرورگر را با یک کد یکبارمصرف به MonoChat برمیگرداند.
- سرور MonoChat این کد را مستقیماً از سرور به سرور با یک ID token مبادله میکند. توکنها هرگز از مرورگر عبور نمیکنند.
- MonoChat ID token را بررسی میکند و اپراتور را وارد میکند.
ID token به تعبیر مشخصات OpenID Connect، «یک توکن امنیتی است که Claimهایی درباره احراز هویت کاربر نهایی در خود دارد» (“a security token that contains Claims about the Authentication of an End-User”). MonoChat فقط در این شرایط آن را میپذیرد:
- با یکی از کلیدهای ارائهدهنده هویت شما امضا شده باشد؛ این کلیدها در هر ورود از سند discovery آن (
<issuer>/.well-known/openid-configuration) خوانده میشوند؛ - issuer آن (
iss) همان issuer شما، audience آن (aud) شناسه کلاینت (client ID) MonoChat باشد و زمان انقضای آن (exp) نگذشته باشد؛ - همان
nonceرا داشته باشد که MonoChat همراه درخواست فرستاده است؛ این مقدار توکن را به همین ورود گره میزند و جلوی استفاده مجدد (replay) را میگیرد؛ - نشانی ایمیل فرد را داشته باشد و ارائهدهنده نگفته باشد که این نشانی تأییدنشده است.
درخواست همچنین از PKCE (S256) و یک مقدار state استفاده میکند، و هر درخواست ورود 10 دقیقه اعتبار دارد و فقط یک بار قابل استفاده است.
پیش از فعال کردن SSO درباره این پنج مورد تصمیم بگیرید
| تصمیم | گزینهها | پیشنهاد ما برای تیم پشتیبانی |
|---|---|---|
| چه کسی میتواند وارد شود | همه دامنهها، یا فقط دامنههای ایمیل شرکت شما | آن را به دامنههای خود محدود کنید |
| در اولین ورود چه اتفاقی میافتد | ساختن حساب، یا پذیرفتن فقط افراد دعوتشده | اگر ارائهدهنده هویت شما از قبل کنترل میکند چه کسی در شرکت کار میکند، حسابها را خودکار بسازید |
| حسابهای موجود | اتصال SSO در اولین ورود وقتی ایمیل تأییدشده است، یا پس از یک بار ورود با رمز عبور | بستگی دارد به اینکه ارائهدهنده شما email_verified را میفرستد یا نه |
| روشهای ورود دیگر | نگه داشتن رمز عبور و ورود با شبکههای اجتماعی، یا فقط SSO | فقط SSO، وقتی همه SSO را به حساب خود متصل کردند |
| چه کسی میتواند فضای کاری جدید باز کند | هر کسی که حساب دارد، یا فقط افرادی با نقش مناسب | در نصب سازمانی، ساختن آزاد فضای کاری را خاموش کنید |
پیش از تغییر هر تنظیمی، پاسخ این موارد را بنویسید. اینها همان پرسشهایی هستند که تیم امنیت شما مطرح میکند و پاسخها تعیین میکنند به کدام تنظیمات نیاز دارید.
راهاندازی SSO روی نصب درونسازمانی MonoChat
SSO برای کل نصب و در تنظیمات سرور راهاندازی میشود، نه برای هر فضای کاری جداگانه. مرجع کامل، صفحه ورود یکپارچه در مرکز راهنما است؛ اینجا نسخه خلاصه را میخوانید.
1. MonoChat را در ارائهدهنده هویت خود ثبت کنید
یک برنامه وب با client secret بسازید و این موارد را برای آن تعیین کنید:
- نشانی بازگشت (redirect URI)
https://<your MonoChat domain>/api/oauth/oidc/redirect؛ - نوع مجوز authorization code؛
- scopeهای
openid email profile؛ - احراز هویت کلاینت با ارسال secret بهصورت HTTP Basic (
client_secret_basic).
مطمئن شوید ID token شامل claim email است و شناسه کلاینت، client secret و issuer را یادداشت کنید.
2. issuer را دقیقاً کپی کنید
issuer همان مقدار issuer در سند discovery ارائهدهنده شماست. قالبهای رایج:
| ارائهدهنده هویت | Issuer |
|---|---|
| Microsoft Entra ID | https://login.microsoftonline.com/<tenant id>/v2.0 |
| Okta | https://<your Okta domain>/oauth2/default یا https://<your Okta domain> |
| Keycloak | https://<your Keycloak host>/realms/<realm> |
| AD FS 2016 یا جدیدتر | https://<your AD FS host>/adfs |
| Google Workspace | https://accounts.google.com |
نشانی <issuer>/.well-known/openid-configuration را در مرورگر باز کنید و مقدار را نویسه به نویسه کپی کنید، حتی اسلش پایانی اگر وجود دارد. اگر این دو مقدار با هم فرق داشته باشند، MonoChat همه ورودها را رد میکند؛ این رایجترین دلیل شکست اولین آزمایش است.
3. تنظیمات را اضافه کنید و سرور را دوباره راهاندازی کنید
بخش عمومی (issuer، شناسه کلاینت، مسیر بازگشت، scopeها و متن دکمه) زیر public.oauth.oidc قرار میگیرد؛ client secret زیر oauth.oidc میرود و روی سرور میماند. دو گزینه در آنجا تصمیمهای شما در جدول بالا را اجرا میکنند:
autoCreateAccounts: trueحساب MonoChat را در اولین ورود فرد با SSO میسازد، حتی وقتی ثبتنام فقط با دعوتنامه ممکن است؛allowedEmailDomains: ["yourcompany.com"]هر نشانی از دامنه دیگر را رد میکند. در Google Workspace، MonoChat بهجای نشانی ایمیل، دامنه Workspace حساب (claimhd) را بررسی میکند، چون یک حساب شخصی Google میتواند از نشانیای روی هر دامنهای استفاده کند.
متن دکمه برای هر فرد به زبان خودش نمایش داده میشود (در فارسی «ورود با SSO»)، یا برچسبی که خودتان تعیین میکنید، مانند «ورود با Northwind SSO».
4. SSO را با خیال راحت تنها روش ورود کنید
وقتی همه SSO را به حساب خود متصل کردند، روشهای مجاز ورود (public.auth.methods) را روی ["oidc"] بگذارید. از آن پس صفحه ورود فقط دکمه SSO را نشان میدهد و سرور ورود با رمز عبور و شبکههای اجتماعی را رد میکند. کاربران ارشد ریشه (root super user) همچنان میتوانند با رمز عبور خود از نشانی /auth/signin?fallback=1 وارد شوند، بنابراین قطع شدن ارائهدهنده هویت هرگز دسترسی به نصب را قفل نمیکند. برای اینکه حسابهای جدید SSO نتوانند فضای کاری شخصی باز کنند، public.disableTenantCreation را روی true بگذارید.
5. چهار حالت ورود را آزمایش کنید
- فردی که حساب دارد: پنجره بازشو بسته میشود و وارد میشود.
- فردی که حساب ندارد: حساب ساخته میشود، یا اگر ساختن حساب را روشن نکرده باشید، ورود رد میشود.
- فردی از دامنه دیگر: اگر دامنهها را محدود کرده باشید، رد میشود.
- ورود با رمز عبور وقتی حالت فقط SSO روشن است: رد میشود، در حالی که راه ورود ریشه همچنان کار میکند.
اپراتورهای فعلی: حسابها چگونه متصل میشوند
بیشتر تیمها SSO را زمانی روشن میکنند که اپراتورها از قبل حساب MonoChat دارند. MonoChat به یکی از این دو روش SSO را به حساب موجودی با همان نشانی ایمیل متصل میکند:
- خودکار، در اولین ورود با SSO، وقتی نصب اجازه ادغام حسابها را میدهد و ID token میگوید نشانی تأییدشده است (
email_verified: true). - پس از یک بار ورود با رمز عبور، در همه حالتهای دیگر: MonoChat از فرد میخواهد یک بار با رمز عبور خود وارد شود و همان موقع SSO را متصل میکند. پذیرفتن دعوتنامه یک فضای کاری هم اتصال را انجام میدهد.
Microsoft Entra ID و AD FS مقدار email_verified را نمیفرستند. اگر از آنها استفاده میکنید، پیش از رفتن به حالت فقط SSO، ورود با رمز عبور را تا زمانی که همه SSO را متصل کنند مجاز نگه دارید، یا افراد را دوباره دعوت کنید.
SSO هویت را تعیین میکند، نقشها دسترسی را
ورود به فرد یک حساب میدهد، نه دسترسی به گفتگوهای شما. یک حساب MonoChat میتواند عضو چند فضای کاری باشد و افراد پیش از انتخاب فضای کاری وارد میشوند. هر فرد فقط وقتی یک فضای کاری را میبیند که آن فضای کاری او را دعوت کند و به او نقشی بدهد، و نقش تعیین میکند به کدام کانالها، گفتگوها و تنظیمات دسترسی دارد. برای طراحی این نقشها، نقشها و مجوزهای صندوق ورودی تیم را ببینید.
این جدایی همان چیزی است که ممیز (auditor) میخواهد ببیند:
- ورود به شرکت: ارائهدهنده هویت فرد را میسازد؛ مدیر فضای کاری او را دعوت میکند و نقشش را انتخاب میکند.
- جابهجایی در شرکت: نقش یا گروه کاری را در MonoChat تغییر دهید؛ روش ورود تغییری نمیکند.
- رفتن از شرکت: فرد را در ارائهدهنده هویت غیرفعال کنید و در MonoChat او را از فضای کاری حذف کنید.
محدودیتهایی که باید برایشان برنامهریزی کنید
- اپلیکیشن موبایل. اپلیکیشن Android و iOS شرکت MonoChat هنوز SSO ندارد. اگر SSO تنها روش ورود باشد، اپراتورها نمیتوانند از روی گوشی وارد شوند؛ پس یک روش دیگر را برای کاربران موبایل نگه دارید یا شیفتها را فقط روی دسکتاپ برنامهریزی کنید.
- خروج از حساب. خروج از MonoChat فرد را از ارائهدهنده هویت خارج نمیکند، و خروج از ارائهدهنده هویت هم هنوز او را از MonoChat خارج نمیکند. غیرفعال کردن فردی که رفته در ارائهدهنده هویت جلوی ورودهای جدید را میگیرد؛ او را از فضای کاری هم حذف کنید.
- شبکه. مرورگر افراد باید به
/api/oauth/oidc/authorizeو مسیر بازگشت دسترسی داشته باشد، و سرور MonoChat باید از طریق HTTPS به سند discovery، token endpoint و مجموعه کلیدهای ارائهدهنده شما برسد. اگر دسترسی به نصب را بر اساس IP محدود کردهاید، این مسیرها را در نظر داشته باشید.
جایگاه SSO در MonoChat
SSO در تنظیمات سرور کل یک نصب پیکربندی میشود، بنابراین در حال حاضر مخصوص MonoChat درونسازمانی (on-premise) است: گزینه Enterprise برای تیمهایی که پلتفرم را روی سرورهای خودشان، با LLM و پایگاه داده برداری (vector database) خودشان اجرا میکنند. صفحه Enterprise گزینه نصب درونسازمانی را توضیح میدهد و صفحه امنیت کنترل دسترسی مبتنی بر نقش، جداسازی فضاهای کاری و گواهیها را پوشش میدهد. برای جنبه دادهای راهاندازی هوش مصنوعی، چکلیست حریم خصوصی چتبات هوش مصنوعی را ببینید.
اگر میخواهید ابتدا خود محصول را امتحان کنید، پلن رایگان Basic در app.monochat.ai یک اپراتور و یک کانال در اختیارتان میگذارد.
منابع
- OpenID Connect Core 1.0, OpenID Foundation، مشاهدهشده در 4 نوامبر 2026
- اطلاعیه گزارش Verizon 2025 Data Breach Investigations Report، مشاهدهشده در 4 نوامبر 2026
- مرکز راهنمای MonoChat: Single Sign-On for an On-Premise Installation، مشاهدهشده در 4 نوامبر 2026
- تغییرات نسخه 3.8.43 MonoChat، 2 نوامبر 2026
این را با MonoChat عملی کنید