الانتقال إلى المحتوى الرئيسي
يُجري Didit MCP المصادقة باستخدام تسجيل الدخول باستخدام Didit (OAuth 2.1). ويعمل بصفته مستخدمًا لدى Didit، بصلاحيات دورك في وحدة التحكم، ولا يوجد وضع لاستخدام مفتاح API.

​
تسجيل الدخول باستخدام Didit

يعمل الخادم المستضاف (https://mcp.didit.me/mcp) كـخادم موارد وفق OAuth 2.1. أما Didit Business Console (business.didit.me) فهو خادم التفويض الذي يستضيف شاشة الموافقة ويصدر الرموز. يتولى عميل MCP لديك تنفيذ التدفق القياسي تلقائياً:
1

الاكتشاف

يرسل العميل طلباً إلى /mcp دون رمز، فيتلقى الاستجابة 401 مع ترويسة WWW-Authenticate: Bearer يشير حقل resource_metadata فيها إلى بيانات وصف المورد المحمي (RFC 9728):
يحدد هذا المستند المورد (https://mcp.didit.me/mcp) وخادم التفويض (https://business.didit.me) والنطاقات المدعومة. ويُقدَّم المستند نفسه أيضاً في جذر النطاق https://mcp.didit.me/.well-known/oauth-protected-resource، للعملاء الذين يتحققون من هذا المسار أولاً.
2

التسجيل (تسجيل العميل الديناميكي)

يقرأ العميل بيانات وصف خادم التفويض من https://business.didit.me/.well-known/oauth-authorization-server، وإذا لم يكن لديه معرّف عميل بعد، يسجّل نفسه عند registration_endpoint (RFC 7591). لا يلزمك تهيئة أي شيء مسبقاً: يسجّل بهذه الطريقة العملاء المحليون الذين يستخدمون رابط استدعاء محلياً (loopback) أو أصلياً (Claude Code وCursor وMCP Inspector)، والعملاء المستضافون على السحابة الذين يستخدمون رابط استدعاء مُراجَعاً (Claude). يُرفض رابط الاستدعاء البعيد الذي لم تراجعه Didit مع الخطأ invalid_redirect_uri، ويحتاج ذلك العميل إلى أن يسجّله المشغّل أولاً.
3

التفويض (PKCE)

يفتح العميل https://business.didit.me/authorize مع تحدي PKCE بطريقة S256. تسجّل دخولك (أو تنشئ حساباً) وترى بدقة الأذونات المطلوبة. العملاء عموميون: نقطة endpoint الخاصة بالرموز لا تقبل سرّ عميل (قيمة token_endpoint_auth_methods_supported هي none)، لذلك فإن PKCE هو ما يربط الرمز بالعميل.
4

الموافقة

توافق. يُنشئ الكونسول جلسة لهذا التطبيق مرتبطة بالنطاقات التي وافقت عليها، ويعيد رمز تفويض يستبدله العميل عند token_endpoint برمز وصول ورمز تحديث.
5

استدعاء الأدوات

يرسل العميل رمز الوصول مع كل طلب. يتحقق MCP منه عبر فحص الرمز وفق RFC 7662 لدى خدمة المصادقة في Didit (الرموز غير شفافة، وليست JWT)، ويقرأ أذونات مؤسستك من استجابة الفحص، ويعمل نيابةً عنك طوال مدة ذلك الطلب.

​
النطاقات

تعلن بيانات وصف المورد عن ثلاثة نطاقات. تعرض شاشة الموافقة النطاقات التي يطلبها العميل بلغة واضحة: يتضمّن النطاقان analytics. إدارة lists تتطلب didit:management، والوصول إلى blocklist يتطلب didit:verification. يذكر مرجع الأدوات النطاق الذي تنتمي إليه كل أداة. تُدمج النطاقات التي توافق عليها ضمن الرمز، وتُفرض على الخادم، لذلك يُرفض التطبيق المتصل بـdidit:verification وحده على واجهة الإدارة حتى لو كان دورك يسمح بذلك. كما يعرف خادم التفويض نطاقات OpenID (openid profile email)؛ والاتصال الذي يطلب هذه النطاقات فقط يستطيع أن يعرف هويتك ولا شيء آخر. الأذونات الفعلية للتطبيق هي تقاطع النطاقات المعتمدة مع دورك في الكونسول، ولا تكون أبداً أوسع من أيٍّ منهما. لإنشاء جلسة تحقق باستخدام didit_session_create تحتاج إلى النطاق didit:verification و دور يتضمن create:sessions أو write:sessions. يتضمن الدور المطوّر الإذن create:sessions. الموافقة على didit:management وحده لا تتيح إنشاء الجلسات، حتى لو كان دورك يملك الإذن المطلوب.

​
الأدوار والأذونات

يمثّل الرمز المستضاف إياك، لذلك يستطيع الوكيل العمل عبر كل مؤسسة تنتمي إليها في اتصال واحد؛ إذ تجمع الأدوات العابرة للتطبيقات (didit_session_search، وdidit_analytics، وdidit_context_get، وبقية أدوات *_search) النتائج من جميعها تلقائياً. تفرض الواجهة الخلفية لـDidit دورك دائماً، لكل مؤسسة على حدة. تقابل كل أداة سلسلة إذن واحدة في الخلفية (مثلاً write:sessions للأداة didit_session_update_status، وdelete:sessions للأداة didit_session_delete)، ويعرض مرجع الأدوات الإذن الخاص بكل أداة. ويتحقق الخادم أيضاً من هذا الإذن قبل إرسال الطلب، مستخدماً الأذونات التي تحملها استجابة الفحص لمؤسستك:
  • في وضع enforce تُستبعد من tools/list الأداةُ التي لا يستطيع دورك تشغيلها، وإذا استُدعيت رغم ذلك يُعاد خطأ missing_scope يذكر الإذن ("Your role in this organization does not include the permission 'delete:sessions' that didit_session_delete requires.").
  • في وضع shadow (وهو الوضع الافتراضي للخادم) تُدرج كل الأدوات في القائمة، ويُمرَّر الاستدعاء إلى الواجهة الخلفية، فتجيب بـ403 إذا كان الدور يفتقر إلى الإذن؛ ولا يُسجَّل الحكم إلا في سجل التدقيق الخاص بالخادم.
وفي الحالتين لا يمنح MCP أكثر مما يسمح به دورك في الكونسول أصلاً. يستطيع READER أن يعرض ويقرأ، أما OWNER أو ADMIN فيستطيعان الكتابة والحذف.

​
مدة صلاحية الرمز

يحصل التطبيق المعتمد على جلسة خاصة به، منفصلة عن جلسة المتصفح التي وافقت عبرها. رموز الوصول قصيرة الأجل؛ ويجدّدها العميل بصمت باستخدام رمز التحديث (يتضمن grant_types_supported القيمة refresh_token)، ويحتفظ التجديد بنطاقات التطبيق ويبقى مرتبطاً بذلك التطبيق. وإذا فشل التجديد (مثلاً بعد أن تفصل التطبيق)، يعيد العميل تشغيل تسجيل الدخول باستخدام Didit عند الاستدعاء التالي. تسجيل الخروج من وحدة التحكم لا يسجّل الخروج من التطبيقات المتصلة، وقطع اتصال أي تطبيق لا يسجّل خروجك في أي مكان.

​
قطع اتصال تطبيق

1

من وحدة التحكم

Settings → Authentication → Connected apps تعرض كل تطبيق وافقت عليه، مع اسمه المسجّل والأذونات التي مُنحت له. قطع الاتصال ينهي وصول ذلك التطبيق فورًا: يتوقف عن العمل كلٌّ من رمز الوصول ورمز التحديث، ولا يتأثر أي شيء آخر.
2

من التطبيق (RFC 7009)

يمكن للعميل أن يتخلى عن وصوله بإرسال الـ token إلى revocation_endpoint الخاص بخادم التفويض، المنشور في البيانات الوصفية عند https://business.didit.me/.well-known/oauth-authorization-server. وكما يقتضي RFC 7009، يُرجع الاستدعاء الناجح الاستجابة 200 سواء كان الـ token ما زال فعالًا أم لا، لذلك لا تكشف الاستجابة أبدًا إن كان الـ token صالحًا. تعني الاستجابة 503 أن الإلغاء لم يُطبَّق: اعتبر الـ token ما زال صالحًا وأعد المحاولة.
لماذا لا يوجد مفتاح API؟ تستدعي كل أداة MCP نقاط نهاية وحدة التحكم المخصّصة لنطاق المستخدم (/organization/{org}/application/{app}/…)، والتي تُصادق على Bearer token مع صلاحيات لكل دور، وترفض x-api-key. مفتاح API الخاص بالتطبيق مخصص لاستدعاء REST API مباشرةً من الخادم الخلفي الخاص بك (مثل إنشاء الجلسات)، وليس لهذا الـ MCP. تعرض didit_org_list_api_keys بيانات المفاتيح مع إخفاء قيمها، والأداة التي تكشف المفتاح الخام مخفية على الموصل المستضاف.

​
الربط من كل عميل

يتبع كل عميل التدفق نفسه، والفرق الوحيد هو الطريقة التي تمرّر بها الرابط إليه.
استخدم الرابط المباشر الذي تعرضه وحدة التحكم للشركات في صفحة التكامل. يفتح claude.ai مع نافذة Add custom connector معبّأة مسبقًا:
أكّد، ثم أكمل تسجيل الدخول باستخدام Didit. يستخدم Claude Desktop الرابط نفسه تحت Settings → Connectors → Add custom connector. التفاصيل في ربط Claude.

​
أخطاء المصادقة

يعني الرد 401 من /mcp أن الـ token مفقود أو منتهي الصلاحية أو تم إلغاؤه، وينبغي للعميل حينها أن يجدّد الـ token أو يعيد تشغيل تسجيل الدخول باستخدام Didit. الرد 403 أو خطأ missing_scope على أداة محددة يعني غالبًا أحد أمرين: إما أن دورك لا يملك الإذن المطلوب لتلك الأداة (مثل أن يحاول READER تنفيذ عملية كتابة)، أو أن الاتصال وُوفق عليه دون النطاق الذي تحتاجه تلك الأداة، وليس أن الاتصال كله معطّل. إعادة الاتصال والموافقة على النطاقين تحل الحالة الثانية، أما الحالة الأولى فتحتاج إلى تغيير الدور. إذا فشلت كل الأدوات، تحقق من Settings → Authentication → Connected apps في وحدة التحكم: التطبيق الذي قُطع اتصاله هناك يجب أن يُوافَق عليه من جديد.

مرجع الأدوات

ما تفعله كل أداة، ونطاقها، وإذن الدور الخاص بها.

متقدم

الأدوار، والسلوك بين التطبيقات، والاستضافة الذاتية.
آخر تعديل في ٧ نوفمبر ٢٠٢٦