OIDC (OpenID Connect) روی OAuth 2.0 ساخته شده و توکن‌هایش JSON هستند؛ SAML 2.0 پروتکلی قدیمی‌تر و مستقل است که ادعاهای هویت را با XML امضاشده رد و بدل می‌کند. برای ERPی که هم باید مرورگر کاربر را وارد کند و هم به یک کلاینت هوش مصنوعی (MCP) توکن بدهد، این تفاوت فرمت مستقیماً روی معماری اثر می‌گذارد: توکن OIDC را همان کتابخانه‌ای می‌فهمد که توکن OAuth سرور MCP را می‌فهمد؛ توکن SAML را نه.
فرق فنی OIDC و SAML دقیقاً کجاست؟
OIDC یک لایه‌ی هویت روی OAuth 2.0 است — بعد از ورود موفق، یک id_token با فرمت JWT صادر می‌شود که ادعاهای هویت (نام، ایمیل، subject) در آن امضا شده‌اند، دقیقاً همان مکانیزم امضایی که access token های OAuth از آن استفاده می‌کنند. SAML یک استاندارد قدیمی‌تر و کاملاً جدا (متعلق به OASIS، نه IETF) است که ادعاها را در یک XML Assertion امضاشده حمل می‌کند و اصلی‌ترین کاربردش هنوز ورود مرورگری به اپلیکیشن‌های سازمانی است، نه صدور توکن برای یک کلاینت API یا عامل هوش مصنوعی.
چرا این تفاوت برای MCP اهمیت دارد؟
یک سرور MCP طبق مشخصات پروتکل باید OAuth 2.1 را به‌عنوان لایه‌ی مجوزدهی پیاده کند — همان خانواده‌ای که OIDC از آن آمده. اگر ارائه‌دهنده‌ی هویت سازمان شما SAML باشد، برای اتصال دستیار هوش مصنوعی به همان حساب کاربری، یا باید یک پل SAML-to-OAuth جداگانه بسازید، یا کاربر باید دو حساب مجزا (یکی برای ورود مرورگری با SAML، یکی برای MCP با کلید API) داشته باشد. وقتی ارائه‌دهنده‌ی هویت از ابتدا OIDC باشد، یک تأیید کاربر همان لحظه هم id_token ورود به سایت را صادر می‌کند و هم توکن دسترسی به /mcp را — دقیقاً همان مسیری که سرور OAuth 2.1 خودِ ابرک (که قبلاً برای اتصال کلاینت‌های MCP آزموده شده بود) برای SSO اودو هم استفاده شد.
آیا SAML همیشه بد است؟
نه. سازمان‌های بزرگ با زیرساخت هویت قدیمی (Active Directory Federation Services، Okta کلاسیک) اغلب SAML را از قبل دارند و تعویض آن هزینه‌ی مهاجرت واقعی دارد. اگر ERP فقط برای ورود مرورگری کاربران انسانی استفاده می‌شود و هیچ کلاینت API/MCPای در نقشه‌ی راه نیست، SAML همچنان گزینه‌ی معتبری است. مسئله وقتی پیش می‌آید که هر دو نیاز — ورود انسانی و توکن برای عامل هوش مصنوعی — هم‌زمان روی یک ارائه‌دهنده‌ی هویت قرار می‌گیرد.
ابرک این را چطور حل کرده؟
اودو ابرک به‌عنوان ارائه‌دهنده‌ی هویت OIDC عمل می‌کند، روی همان سرور OAuth 2.1 که برای سرور MCP ساخته شده بود — نه یک سرویس هویت جدا. یک تأیید کاربر هم id_token ورود به چت را می‌دهد و هم توکن /mcp را؛ جزئیات پیاده‌سازی OAuth 2.1 (PKCE، DCR، چرخش refresh token) در مقاله‌ی احراز هویت MCP آمده است.
جدول تصمیم: کدام پروتکل برای کدام سناریو
| سناریو | پیشنهاد | دلیل |
|---|---|---|
| اپ موبایل یا SPA | OIDC | مبتنی بر JSON و JWT؛ SAML در مرورگر موبایل دست‌وپاگیر است |
| ورود کارمندان از اکتیودایرکتوری قدیمی | SAML | پشتیبانی بومی در بیشتر IdPهای سازمانی موجود |
| دسترسی ایجنت هوش مصنوعی یا MCP | OIDC | توکن قابل حمل روی هدر، بدون وابستگی به نشست مرورگر |
| یکپارچه‌سازی با سرویس ابری مدرن | OIDC | استاندارد رایج امروز |
| سازمان با الزام انطباق مبتنی بر SAML | SAML | تصمیم انطباقی، نه فنی |
سه اشتباه رایج در پیاده‌سازی ورود یکپارچه
- نداشتن مسیر خروج اضطراری: اگر IdP از دسترس خارج شود، باید یک حساب مدیر محلی برای ورود باقی بماند؛ وگرنه کل سازمان بیرون می‌ماند.
- نگاشت نقش‌ها به‌صورت دستی: اگر گروه‌های IdP به نقش‌های سیستم نگاشت نشوند، هر کاربر جدید یک کار دستی می‌شود و دسترسی‌های قدیمی پاک نمی‌شوند.
- فراموشی خروج سراسری: خروج از سیستم بدون ابطال نشست IdP یعنی کاربر با یک رفرش دوباره وارد می‌شود.
چه چیزی را پیش از راه‌اندازی تست کنید
سه سناریو معمولاً همه‌ی مشکلات را بیرون می‌کشد: ورود کاربر جدیدی که هنوز در سیستم حساب ندارد (باید ساخته شود یا با پیام روشن رد شود)، ورود کاربری که در IdP غیرفعال شده (باید بلافاصله رد شود)، و ورود هم‌زمان از دو دستگاه. اگر هر سه درست کار کنند، بقیهٔ موارد لبه‌ای‌اند.
ارتباط این تصمیم با دسترسی ایجنت‌ها در احراز هویت MCP و مدل تهدید در MCP چقدر امن است توضیح داده شده است.
