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 آمده است.
