اتصال خودکار ابزارها در Claude؛ راهکار جدید Anthropic برای حذف ورودهای تکراری به سرویس‌ها

شرکت Anthropic قابلیت جدیدی به نام احراز هویت مدیریت‌شده سازمانی (EMA) را معرفی کرده است که به مدیران سیستم امکان می‌دهد اتصال‌دهنده‌های مجاز پروتکل MCP را مستقیماً از طریق ارائه‌دهنده هویت سازمانی پیکربندی کنند. اعضای مشمول این خط‌مشی می‌توانند با استفاده از همان نشست ورود یکپارچه (SSO) خود در Claude به ابزارها متصل شوند و دیگر نیازی به طی‌کردن مراحل تأیید هویت جداگانه OAuth برای تک‌تک سرویس‌ها نخواهند داشت.

پروتکل زمینه مدل (MCP) به کلاینت‌های هوش مصنوعی اجازه می‌دهد ابزارهای خارجی را فراخوانی کنند و اطلاعات مورد نیاز را از سرویس‌هایی نظیر Linear، Notion، Figma و Datadog بازیابی نمایند. پیش از این، احراز هویت جداگانه برای هر کاربر دردسرهای پیکربندی مکرر به‌همراه داشت و مدیران سیستم را ناچار می‌کرد دسترسی‌ها را در برنامه‌ها و سرویس‌های گوناگون به‌صورت پراکنده مدیریت کنند. سازوکار جدید EMA تعیین صلاحیت اتصال را به یک خط‌مشی متمرکز واگذار می‌کند و استانداردی یکپارچه برای تبادل توکن در سرورهای احراز مجوز فراهم می‌آورد.

یک خط‌مشی، یک مسیر تبادل توکن

هنگامی که کاربری مجاز قصد دسترسی به یک اتصال‌دهنده حفاظت‌شده را داشته باشد، Claude یک توکن وب امضاشده JSON (موسوم به JWT) را که گواهی بر هویت کاربر است به سرور احراز مجوز ارائه می‌دهد. این تبادل طبق مراحل زیر انجام می‌شود:

1. کاربر از طریق سیستم ورود یکپارچه سازمان به حساب Claude خود وارد می‌شود.
2. سرویس Claude یک مجوز احراز هویت مبتنی بر توکن وب (ID-JAG) از صادرکننده مورد اعتماد درخواست می‌کند.
3. صادرکننده هویت، عضویت کاربر در گروه‌ها، قوانین دسترسی مشروط و سایر خط‌مشی‌های سازمانی را بررسی می‌کند.
4. سپس Claude ادعانامه امضاشده را با استفاده از مجوز حامل JWT به سرور احراز هویت اتصال‌دهنده ارسال می‌نماید.
5. سرور احراز هویت پس از اعتبارسنجی ادعانامه، توکن دسترسی نهایی را برای برقراری ارتباط با سرور MCP صادر می‌کند.

این تبادل داده به‌طور کامل از طریق درخواست‌های پس‌زمینه (Back-channel) صورت می‌پذیرد؛ بنابراین کاربر با هیچ تغییر مسیر ناخواسته‌ای در مرورگر یا صفحه دریافت تأییدیه مواجه نمی‌شود. با این حال، اتصال‌دهنده پس از اتمام احراز هویت همچنان دامنه‌های دسترسی را محاسبه کرده و مجوزهای سطح برنامه را با دقت اعمال می‌کند.

دو مدل صدور گواهی، یک ساختار تبادل

سازوکار EMA از دو مدل اعتمادسازی پشتیبانی می‌کند و به سازمان‌ها امکان می‌دهد یا از ارائه‌دهنده هویت سازگار خود استفاده کنند یا صدور گواهی هویت را به Claude بسپارند.

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

نخستین فهرست ابزارهای سازگار در نسخه آزمایشی

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

• تحلیل داده و بازاریابی: Amplitude، Mixpanel، Semrush
• برنامه‌ریزی و مستند‌سازی: Atlassian، Linear، Notion
• پایش سیستم و مدیریت حوادث: Datadog، PagerDuty
• فایل‌ها، طراحی و یادداشت‌ها: Dropbox، Figma، Granola
• مدیریت ارتباط با مشتری و فروش: HubSpot و Apollo.io
• زیرساخت بک‌اند: Supabase

جزئیات فنی پروتکل در بستر شبکه

فناوری EMA از افزونه باز پروتکل MCP با شناسه اختصاصی io.modelcontextprotocol/enterprise-managed-authorization استفاده می‌کند. این افزونه بر پایه پیش‌نویس استاندارد کارگروه IETF برای صدور مجوز مبتنی بر گواهی هویت JWT و هم‌چنین چارچوب حامل JWT تعریف‌شده در استاندارد RFC ۷۵۲۳ بنا شده است.

گواهی ID-JAG به‌عنوان مدرک دیجیتال امضاشده‌ای از هویت کاربر و زمینه سازمانی او عمل می‌کند. سرور احراز هویت اتصال‌دهنده، پیش از صدور توکن دسترسی اختصاصی خود، صحت این مدرک را بررسی می‌کند؛ توکنی که در نهایت به‌عنوان کلید مجاز برای فراخوانی سرور MCP به کار می‌رود.

کلاینت اطلاعات مربوط به گواهی، شناسه ثبت‌شده برنامه، دامنه‌های درخواستی و منبع MCP را به نقطه پایانی توکن در سرور اتصال‌دهنده می‌فرستد:

POST /token HTTP/1.1
Host: auth.example.com
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=eyJhbGciOi...
&client_id=claude-client-id
&scope=openid+profile
&resource=https://mcp.example.com

چک‌لیست فنی برای توسعه‌دهندگان اتصال‌دهنده‌ها

توسعه‌دهندگان اتصال‌دهنده‌ها برای هماهنگی با احراز هویت مدیریت‌شده Claude باید سرور احراز هویت، پیکربندی‌های چندمستأجری و الگوی ثبت کلاینت خود را به‌روزرسانی کنند:

1. اعلام پشتیبانی از نوع مجوز: عبارت urn:ietf:params:oauth:grant-type:jwt-bearer باید به فیلد grant_types_supported در متادیتای سرور احراز هویت افزوده شود.
2. پیکربندی صادرکنندگان معتبر برای هر مستأجر: فهرستی از نشانی‌های معتبر صادرکننده نگهداری شود، کلیدهای امضا از طریق متادیتای صادرکننده مجاز دریافت گردد، کلیدهای JWKS ذخیره موقت شوند و فرایند تعویض دوره‌ای کلیدها پیاده‌سازی شود.
3. اعتبارسنجی دقیق هر گواهی: امضای دیجیتال و الگوریتم مورد انتظار بررسی شوند و سپس مقادیر iss، aud، exp، sub و client_id به‌دقت ارزیابی گردند. در صورت دریافت درخواست از صادرکنندگان غیرمجاز، خطای invalid_grant صادر شود.
4. تطبیق هویت با سطوح دسترسی: شناسه کاربر تأییدشده به یک حساب محلی نگاشت شود و دامنه‌های مجاز مطابق با خط‌مشی‌های جاری سیستم محاسبه گردند.
5. ثبت Claude با شناسه ثابت: ثبت کلاینت با اطلاعات شناسایی متعلق به شرکت Anthropic یا از طریق سند متادیتای شناسه کلاینت انجام پذیرد. ثبت پویای کلاینت در این فرایند پشتیبانی نمی‌شود؛ چراکه ارائه‌دهنده هویت یک client_id ثابت در هر گواهی قرار می‌دهد.

سرورها می‌توانند سازوکار احراز هویت تنبل (Lazy Authorization) را حفظ کنند. بدین‌ترتیب، چنانچه فراخوانی یک ابزار با خطای 401 و سربرگ معتبر WWW-Authenticate روبه‌رو شود، Claude می‌تواند تبادل توکن را در پس‌زمینه و بدون جلب توجه کاربر تکرار کند. در صورت شکست بررسی‌های امنیتی یا نامعتبر بودن تبادل توکن، ارتباط اتصال‌دهنده غیرفعال باقی خواهد ماند.

تبدیل ارائه‌دهنده هویت به دروازه اصلی خط‌مشی‌ها

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

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

زیست‌بوم این فناوری سرویس‌های شناخته‌شده‌ای هم‌چون Okta Cross App Access، Auth0، Ping Identity، Descope، WorkOS AuthKit، Stytch، Scalekit، Keycloak و Janssen را در بر می‌گیرد. البته میزان سازگاری بسته به نسخه محصول و قابلیت صدور یا پذیرش گواهی متفاوت است. محیط آزمایشی Okta به مدیران اجازه می‌دهد این سازوکار را بدون وابستگی به سازمان Claude آزمایش کرده و توکن‌های رمزگشایی‌شده را به‌دقت بازبینی نمایند.

محدودیت‌ها و شرایط نسخه آزمایشی

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

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