ما الذي تغيَّر وما لم يتغيَّر في التوثيق والهوية في التطبيقات العاملية

لقد قمت مؤخرًا بمراجعة هذه المقالة، وتم ذكر توثيق الهوية للعاملين:

نرى بوادر كيف يمكن أن يبدو هذا. تتضمن أحدث مواصفات MCP، على سبيل المثال، إطارًا تفويضيًا مبنيًا على نموذج OAuth 2.1، مما يشير إلى إمكانية منح وكلاء الذكاء الاصطناعي رموزًا قابلة للإلغاء بدلاً من الأسرار الخام. يمكننا تصور سيناريو حيث لا يحصل وكيل الذكاء الاصطناعي على مفاتيح AWS الفعلية الخاصة بك، لكنه يحصل بدلاً من ذلك على اعتماد قصير الأمد أو رمز قدرة يسمح له بأداء نشاط محدد بدقة.

https://a16z.com/nine-emerging-developer-patterns-for-the-ai-era/

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

عندما تقوم بربط حسابك على Google بتطبيق خارجي مثل Notion أو Zoom، يستخدم OAuth لطلب الصلاحيات الضرورية فقط، مثل الوصول إلى التقويم أو جهات الاتصال الخاصة بك، دون الكشف عن كلمة مرور Google الفعلية الخاصة بك. يمكنك إلغاء هذا الوصول في أي وقت عن طريق إعدادات حساب Google الخاص بك. هذا النمط من الوصول المفوض هو بالضبط ما تم تصميم OAuth من أجله وهو نفس الأساس الذي يتم توسيعه ليشمل التطبيقات الحسابية اليوم.

ما الذي لم يتغير في العالم الحسابي#

التوثيق ليس جديدًا، لا يزال يعتمد على OAuth 2.1#

تظهر برتوكولان رئيسيان: MCP و A2A.

• يركز MCP على التفاعل بين LLMs وأدوات التطبيق وسياقه.
• يركز A2A على تمكين تبادل المهام بين الوكلاء.

لكن عند التطرق إلى التوثيق والصلاحية، كلاهما لا يزال يعتمد على المعايير الصناعية المؤسَّسة مثل OAuth.

يجب على خوادم مصادقة MCP تنفيذ OAuth 2.1 مع اتخاذ التدابير الأمنية المناسبة لكل من العملاء السريين والعموميين.

يكون عميل A2A مسؤولًا عن الحصول على المواد الاعتمادية اللازمة (مثل رموز OAuth 2.0، مفاتيح API، JWTs) من خلال عمليات خارجية عن البروتوكول نفسه. وهو ما يمكن أن يشمل تدفقات OAuth (رمز التفويض، أوراق اعتماد العميل)، توزيع المفاتيح الآمن، إلخ.

كما تضع جوجل:

بدلاً من ابتكار معايير جديدة خاصة للأمان والعمليات، يهدف A2A إلى الاندماج بسلاسة مع البنية التحتية الحالية للشركات وأفضل الممارسات المنتشرة على نطاق واسع.

هل يحتاج الوكيل إلى هوية فريدة؟#

الكثير من محتوى الهوس والخوف من الفوات يدفع فكرة أننا، مع انتشار وكلاء الذكاء الاصطناعي، نحتاج إلى نظام لإدارة هويات الوكلاء.

الإجابة هي: نعم ولا.

نعم، لأننا نقدم طبقة جديدة بين البشر والآلات. هناك احتياجات حقيقية ل:

• إدارة وتحديد هوية الوكلاء
• تخصيص معرفات فريدة
• تتبع السجلات
• تدقيق الأفعال (لمعرفة ما إذا كانت المهمة قد نُفِّذت بواسطة بشري أو وكيل)

ولكن في معظم الحالات التقنية، لا يوجد حاجة لإنشاء مفهوم رسمي لـ “هوية الوكيل”.

الوكيل ≠ المستخدم، ≠ حساب الخدمة.

خلف كل وكيل، هناك لا يزال مستخدم والهوية المستخدمة عادةً ما تكون كافية.

اليوم، معظم الوكلاء:

• يتصرفون بناءً على تفويض المستخدم (مثل رموز OAuth)
• ينفذون منطقًا أو يقومون بإجراء استدعاء API
• يؤدون مهام قصيرة الأمد، مرة واحدة (دون حاجة للتتبع)

بهذا المعنى، يعتبر الوكيل مجرد وظيفة-كأداة ولا يحتاج إلى هوية فريدة على مستوى العالم.

على سبيل المثال:

• إذا كان وكيل GPT يتصل بـ API التقويم الخاص بك، فإنه يحتاج فقط إلى الوصول الذي منحت له.
• لا يحتاج وكيل LangChain إلى هوية طالما يمكنه استدعاء الأدوات الصحيحة.

حتى قبل الذكاء الاصطناعي، كان لدينا مفهوم المصادقة بين الآلات (M2M).

تضمن M2M تبادل البيانات تلقائياً بين الخدمات، دون الحاجة إلى تدخُّل بشري.

في هذا السياق، غالباً ما يشمل المصادقة تطبيق عميل أو حساب خدمة.

إذا كنت تريد حقًا أن يكون لوكيلك هوية (للتحقق وما إلى ذلك)، يمكنك استخدام معرف التطبيق وهذا سيكون كافيًا.

لا تزال بحاجة إلى تحديد بنية منتجك#

هذا لم يتغير. سواء كان منتجك يشمل الوكلاء أم لا، فإن بنية نظام الهوية الخاص بك يعتمد على هوية مستخدميك وكيف يتفاعل النظام الخاص بك معهم.

إذا كنت تقوم ببناء منتج يستهدف المستهلكين ويكون عماليًا: ستحتاج إلى طرق تسجيل دخول خفيفة (البريد الإلكتروني، الهاتف، تسجيل الدخول الاجتماعي)، ومجموعات مستخدمين موحدة لإدارة الأفراد الذين يتفاعلون مع تطبيقك ووكلائه. يعمل الوكلاء نيابة عن هؤلاء المستخدمين باستخدام الرموز المفوضة (مثل عبر OAuth).

مثال:

تخيل أنك تقوم ببناء مساعد جدولة قائم على الذكاء الاصطناعي، أو بوت للتقويم مدفوعاً بالذكاء الاصطناعي.

كل مستخدم يقوم بتسجيل الدخول باستخدام حساب Google الشخصي الخاص به. يستخدم نظامك OAuth للحصول على الإذن بالوصول إلى تقويمه. الوكيل ليس لديه هويته الخاصة، بل يستخدم رمز المستخدم لجدولة الاجتماعات، التحقق من التوفر، أو إرسال التذكيرات. بنية الهوية بسيطة: مجموعة مستخدمين عالمية واحدة، تخزين الرموز، وتتبع الموافقات لكل مستخدم.

إذا كنت تبني منصة عملك للعلاقات بين الشركات (B2B):

ستحتاج إلى دعم الهوية على مستوى المنظمة، وليس فقط المستخدمين الأفراد. يتضمن ذلك:

1. تسجيل الدخول الموحد للعملاء المؤسسيين
2. فصل المساحات أو المستأجرين
3. سياسات التفويض للوكلاء على مستوى المنظمة (مثل السيطرة على ما يمكن للوكلاء القيام به عبر الفرق)
4. رؤية ومسجلات على مستوى الإدارة لجميع الأنشطة الوكيلية نيابة عن الموظفين

مثال:

تخيل أنك تقوم ببناء منصة توفر وكلاء ذكاء اصطناعي لأتمتة سير العمل الداخلي - مثل بوت محلل أمني يرصد السجلات ويرسل التنبيهات أو مساعد مبيعات يكتب الرسائل الإلكترونية من بيانات CRM.

كل شركة تستخدم منصتك تريد:

1. تسجيل الدخول باستخدام SSO الخاص بهم
2. التحكم في ما يمكن للوكلاء الوصول إليه (مثل الأدوات الداخلية، أنظمة الوثائق)
3. رؤية أي وكيل قام بأي مهمة، تحت تفويض أي موظف

في هذه الحالة، تحتاج بنية هويتك إلى دعم التصميم متعدد المستأجرين، وأذونات الوكلاء المحددة، والسياسات الخاصة بالمنظمة. لا يزال الوكلاء يتصرفون نيابة عن المستخدمين، لكن الأذونات وحدود الهوية تفرض لكل مستأجر تجاري.

في كلتا الحالتين، يعرّف نموذج الهوية كيفية عمل الوكلاء، وما يمكنهم الوصول إليه، وكيف يضمن النظام الخاص بك المسؤولية.

استخدم هذا الدليل لمساعدتك في تخطيط هويتك وبنية منتجك.

https://docs.logto.io/introduction/plan-your-architecture/b2c

https://docs.logto.io/introduction/plan-your-architecture/b2b

لا تزال بحاجة إلى طبقات الأمان للحفاظ على تطبيقاتك القائمة على الوكلاء آمنة#

سواء كان تطبيقًا للوكيل أم لا، فإن هذه الطبقات الأمنية الأساسية ضرورية لحماية مستخدميك ونظامك:

• المصادقة المتعددة العوامل (MFA)

  تمنع الوصول غير المصرح به حتى إذا تم الكشف عن بيانات الاعتماد.

  مثال: إذا كان الوكيل يساعدك في تنفيذ إجراء ذي خطورة عالية، مثل إجراء معاملة أو تغيير إعدادات الهوية، فيجب أن يبقي إنسانًا في الحلقة ويستخدم MFA لتأكيد الإجراء قبل المضي قدمًا.

• CAPTCHA

  يعيق الإساءة الآلية مثل تعبئة بيانات الاعتماد أو تسجيل الدخول بواسطة الروبوتات.

  مثال: عرض CAPTCHA بعد 3 محاولات فاشلة لتسجيل الدخول لمنع هجمات القوة الغاشمة.

• التحكم في الوصول على أساس الدور (RBAC)

  يضمن أن المستخدمين والوكلاء يصلون فقط إلى ما يُسمح لهم به.

  مثال: يمكن لمساعد الذكاء الاصطناعي في مساحة العمل الخاصة بالشركة قراءة الأحداث في التقويم، لكنه لا يمكنه الوصول إلى بيانات الفواتير ما لم يتم منحه دورًا أعلى صراحةً.

• تسجيل الدخول بدون كلمة مرور

  يحسن تجربة المستخدم ويقلل من خطر وجود كلمات مرور ضعيفة.

  مثال: دع المستخدمين يسجلون الدخول باستخدام رابط سحري مرسل إلى بريدهم الإلكتروني أو مطالبة بيومترية مثل Face ID.

تنطبق هذه الميزات على التطبيقات التقليدية والتطبيقات المستندة إلى الوكلاء، خاصةً مع بدء تشغيل الوكلاء عبر البيانات والأنظمة الحساسة.

ماذا تغيَّر في العالم الحسابي#

التوثيق أصبح أكثر أهمية من أي وقت مضى#

مع ظهور الوكلاء وتدفقات العمل متعددة الوكلاء، نرى حالات استخدام جديدة حيث يتفاعل المستخدمون والوكلاء وواجهة برمجة التطبيقات وخوادم MCP جميعها معًا. يتزايد عدد وتنوع هذه السيناريوهات بسرعة، أكثر من الماضي.

عندما تحدث هذه الاتصالات، تصبح الصلاحية أكثر بروزًا من أي وقت مضى. يجب على المستخدمين تقديم موافقة واضحة، ويجب إدارة الأذونات بعناية عبر الأنظمة. هذا هو السبب في أن الجميع يتحدث الآن عن الحفاظ على “الإنسان في الحلقة” للتأكد من أن المستخدمين لديهم ما يكفي من التحكم والرؤية حيال ما يمكن لوكلاء القيام به، وما هي القدرات التي لديهم تصريح بها.

قد يحتاج التطبيق الخاص بك إلى التكامل مع العديد من الخدمات الخارجية#

يتوسع نظام MCP البيئي، وهذا يعني أن تطبيقك لم يعد مجرد خدمة مستقلة: إنه جزء من شبكة أكبر متصلة.

لتوفير سياق غني ومفيد لـ LLMs، قد يتعين على وكلائك:

• الوصول إلى العديد من خوادم MCP

  مثال: تخيل مدير مشروع ذكاء اصطناعي يستخلص تحديثات من Jira، وتوافر فريق من Google Calendar، وبيانات مبيعات من Salesforce ويمكن لكل منها أن يكون مدفوعًا بواسطة خادم MCP مختلف. لإنشاء ملخص أسبوعي واحد، يجب على الوكيل التفاعل بأمان مع مصادر بيانات متعددة. هنا يأتي دور التوثيق والتصريح، لحماية كل اتصال والتحكم في كيفية مشاركة البيانات.

• الاتصال بواجهات برمجة التطبيقات والأدوات الخارجية

  مثال: قد يحتاج وكيل دعم العملاء إلى استرداد تاريخ الطلب من Shopify، تحديث التذاكر في Zendesk، وإطلاق سير العمل في Slack. بدون تكامل، يصبح الوكيل معزولًا وغير فعال.

مع تحمل الوكلاء المزيد من المسؤوليات، يصبح التكامل مفتاح الاستخدام. لم يعد منتج الذكاء الاصطناعي الخاص بك مجرد ما يمكنه فعله بمفرده، بل ما يمكنه الوصول إليه، تنسيقه، والاستدلال عليه في نظام متصل. لهذا السبب، أصبح بناء القابلية للتشغيل البيني، بأمان ومرونة، أكثر أهمية من أي وقت مضى.

تحتاج إلى تبني المعايير المفتوحة: OAuth/OIDC أكثر أهمية من أي وقت مضى#

في عصر الذكاء الاصطناعي، تتزايد الحاجة إلى التكامل الآمن والمرن. هذا يجعل OAuth 2.0 و OIDC أكثر أهمية من أي وقت مضى.

تشمل الحالات الاستخدام الرئيسية:

• خوادم MCP البعيدة: اسمح للوكلاء الخارجيين بالوصول بأمان إلى منتجك باستخدام رموز مفوضة.
• التكاملات الخارجية: اسمح لأدوات أو وكلاء آخرين بالاتصال بتطبيقك (مثل منصة إدارة المشاريع) دون الحاجة إلى بيانات اعتماد خام.
• تطوير الوكلاء: إنشاء وكلاء ذكاء اصطناعي يتصرفون بأمان نيابة عن المستخدمين عبر الخدمات.
• الأجهزة الذكية: استخدام OAuth/OIDC لتسجيل دخول المستخدمين والوصول إلى السحابة - خاصة مع واجهة مستخدم محدودة.

توفر هذه البروتوكولات الوصول الآمن على أساس الرموز المميزة والموافقة عليها من قبل المستخدم.

هذا أمر حاسم في عالم الأنظمة المتصلة العاملية. تحقق من هذه المقالة لمعرفة لماذا تعتمد أهمية OAuth و OIDC

التصميم للثقة والقدرة على التوسع في عصر البرمجيات العاملية#

مع تطور المنتجات العاملية، تظل المبادئ الأساسية للهويات والتوثيق ثابتة ولكن السياق يتغير. يُدخل الوكلاء أسطحًا جديدة للتفويض والموافقة والوصول. لذلك فإن الالتزام بالمعايير المفتوحة مثل OAuth، وبناء بنية واضحة، وفرض ممارسات الأمان الصارمة ليس مجرد أفضل الممارسات، بل هو الأجزاء الأساسية. التصميم بعناية الآن يعني أن النظام الخاص بك سيتوسع بثقة ومرونة وثقة في مستقبل مدفوع بالذكاء الاصطناعي.