مع تطور قدرات الات الذكاء الاصطناعي وتزايد اتصالها، يتطلب بناء منتجات عاملية آمنة وقابلة للتوسعة أساسًا قويًا في التوثيق والهوية. هذه الدليل يشرح ما الذي تغيَّر وما لم يتغيَّر وما يجب أن يعرفه كل مُنشئ للتنقل في المشهد الجديد.
لقد قمت مؤخرًا بمراجعة هذه المقالة، وتم ذكر توثيق الهوية للعاملين:
نرى بوادر كيف يمكن أن يبدو هذا. تتضمن أحدث مواصفات 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 من أجله وهو نفس الأساس الذي يتم توسيعه ليشمل التطبيقات الحسابية اليوم.
تظهر برتوكولان رئيسيان: MCP و A2A.
لكن عند التطرق إلى التوثيق والصلاحية، كلاهما لا يزال يعتمد على المعايير الصناعية المؤسَّسة مثل OAuth.
يجب على خوادم مصادقة MCP تنفيذ OAuth 2.1 مع اتخاذ التدابير الأمنية المناسبة لكل من العملاء السريين والعموميين.
يكون عميل A2A مسؤولًا عن الحصول على المواد الاعتمادية اللازمة (مثل رموز OAuth 2.0، مفاتيح API، JWTs) من خلال عمليات خارجية عن البروتوكول نفسه. وهو ما يمكن أن يشمل تدفقات OAuth (رمز التفويض، أوراق اعتماد العميل)، توزيع المفاتيح الآمن، إلخ.
كما تضع جوجل:
بدلاً من ابتكار معايير جديدة خاصة للأمان والعمليات، يهدف A2A إلى الاندماج بسلاسة مع البنية التحتية الحالية للشركات وأفضل الممارسات المنتشرة على نطاق واسع.
الكثير من محتوى الهوس والخوف من الفوات يدفع فكرة أننا، مع انتشار وكلاء الذكاء الاصطناعي، نحتاج إلى نظام لإدارة هويات الوكلاء.
الإجابة هي: نعم ولا.
نعم، لأننا نقدم طبقة جديدة بين البشر والآلات. هناك احتياجات حقيقية ل:
ولكن في معظم الحالات التقنية، لا يوجد حاجة لإنشاء مفهوم رسمي لـ “هوية الوكيل”.
الوكيل ≠ المستخدم، ≠ حساب الخدمة.
خلف كل وكيل، هناك لا يزال مستخدم والهوية المستخدمة عادةً ما تكون كافية.
اليوم، معظم الوكلاء:
بهذا المعنى، يعتبر الوكيل مجرد وظيفة-كأداة ولا يحتاج إلى هوية فريدة على مستوى العالم.
على سبيل المثال:
حتى قبل الذكاء الاصطناعي، كان لدينا مفهوم المصادقة بين الآلات (M2M).
تضمن M2M تبادل البيانات تلقائياً بين الخدمات، دون الحاجة إلى تدخُّل بشري.
في هذا السياق، غالباً ما يشمل المصادقة تطبيق عميل أو حساب خدمة.
إذا كنت تريد حقًا أن يكون لوكيلك هوية (للتحقق وما إلى ذلك)، يمكنك استخدام معرف التطبيق وهذا سيكون كافيًا.
هذا لم يتغير. سواء كان منتجك يشمل الوكلاء أم لا، فإن بنية نظام الهوية الخاص بك يعتمد على هوية مستخدميك وكيف يتفاعل النظام الخاص بك معهم.
إذا كنت تقوم ببناء منتج يستهدف المستهلكين ويكون عماليًا: ستحتاج إلى طرق تسجيل دخول خفيفة (البريد الإلكتروني، الهاتف، تسجيل الدخول الاجتماعي)، ومجموعات مستخدمين موحدة لإدارة الأفراد الذين يتفاعلون مع تطبيقك ووكلائه. يعمل الوكلاء نيابة عن هؤلاء المستخدمين باستخدام الرموز المفوضة (مثل عبر OAuth).
مثال:
تخيل أنك تقوم ببناء مساعد جدولة قائم على الذكاء الاصطناعي، أو بوت للتقويم مدفوعاً بالذكاء الاصطناعي.
كل مستخدم يقوم بتسجيل الدخول باستخدام حساب Google الشخصي الخاص به. يستخدم نظامك OAuth للحصول على الإذن بالوصول إلى تقويمه. الوكيل ليس لديه هويته الخاصة، بل يستخدم رمز المستخدم لجدولة الاجتماعات، التحقق من التوفر، أو إرسال التذكيرات. بنية الهوية بسيطة: مجموعة مستخدمين عالمية واحدة، تخزين الرموز، وتتبع الموافقات لكل مستخدم.
إذا كنت تبني منصة عملك للعلاقات بين الشركات (B2B):
ستحتاج إلى دعم الهوية على مستوى المنظمة، وليس فقط المستخدمين الأفراد. يتضمن ذلك:
مثال:
تخيل أنك تقوم ببناء منصة توفر وكلاء ذكاء اصطناعي لأتمتة سير العمل الداخلي - مثل بوت محلل أمني يرصد السجلات ويرسل التنبيهات أو مساعد مبيعات يكتب الرسائل الإلكترونية من بيانات CRM.
كل شركة تستخدم منصتك تريد:
في هذه الحالة، تحتاج بنية هويتك إلى دعم التصميم متعدد المستأجرين، وأذونات الوكلاء المحددة، والسياسات الخاصة بالمنظمة. لا يزال الوكلاء يتصرفون نيابة عن المستخدمين، لكن الأذونات وحدود الهوية تفرض لكل مستأجر تجاري.
في كلتا الحالتين، يعرّف نموذج الهوية كيفية عمل الوكلاء، وما يمكنهم الوصول إليه، وكيف يضمن النظام الخاص بك المسؤولية.
استخدم هذا الدليل لمساعدتك في تخطيط هويتك وبنية منتجك.
https://docs.logto.io/introduction/plan-your-architecture/b2c
https://docs.logto.io/introduction/plan-your-architecture/b2b
سواء كان تطبيقًا للوكيل أم لا، فإن هذه الطبقات الأمنية الأساسية ضرورية لحماية مستخدميك ونظامك:
المصادقة المتعددة العوامل (MFA)
تمنع الوصول غير المصرح به حتى إذا تم الكشف عن بيانات الاعتماد.
مثال: إذا كان الوكيل يساعدك في تنفيذ إجراء ذي خطورة عالية، مثل إجراء معاملة أو تغيير إعدادات الهوية، فيجب أن يبقي إنسانًا في الحلقة ويستخدم MFA لتأكيد الإجراء قبل المضي قدمًا.
يعيق الإساءة الآلية مثل تعبئة بيانات الاعتماد أو تسجيل الدخول بواسطة الروبوتات.
مثال: عرض CAPTCHA بعد 3 محاولات فاشلة لتسجيل الدخول لمنع هجمات القوة الغاشمة.
التحكم في الوصول على أساس الدور (RBAC)
يضمن أن المستخدمين والوكلاء يصلون فقط إلى ما يُسمح لهم به.
مثال: يمكن لمساعد الذكاء الاصطناعي في مساحة العمل الخاصة بالشركة قراءة الأحداث في التقويم، لكنه لا يمكنه الوصول إلى بيانات الفواتير ما لم يتم منحه دورًا أعلى صراحةً.
يحسن تجربة المستخدم ويقلل من خطر وجود كلمات مرور ضعيفة.
مثال: دع المستخدمين يسجلون الدخول باستخدام رابط سحري مرسل إلى بريدهم الإلكتروني أو مطالبة بيومترية مثل Face ID.
تنطبق هذه الميزات على التطبيقات التقليدية والتطبيقات المستندة إلى الوكلاء، خاصةً مع بدء تشغيل الوكلاء عبر البيانات والأنظمة الحساسة.
مع ظهور الوكلاء وتدفقات العمل متعددة الوكلاء، نرى حالات استخدام جديدة حيث يتفاعل المستخدمون والوكلاء وواجهة برمجة التطبيقات وخوادم MCP جميعها معًا. يتزايد عدد وتنوع هذه السيناريوهات بسرعة، أكثر من الماضي.
عندما تحدث هذه الاتصالات، تصبح الصلاحية أكثر بروزًا من أي وقت مضى. يجب على المستخدمين تقديم موافقة واضحة، ويجب إدارة الأذونات بعناية عبر الأنظمة. هذا هو السبب في أن الجميع يتحدث الآن عن الحفاظ على “الإنسان في الحلقة” للتأكد من أن المستخدمين لديهم ما يكفي من التحكم والرؤية حيال ما يمكن لوكلاء القيام به، وما هي القدرات التي لديهم تصريح بها.
يتوسع نظام MCP البيئي، وهذا يعني أن تطبيقك لم يعد مجرد خدمة مستقلة: إنه جزء من شبكة أكبر متصلة.
لتوفير سياق غني ومفيد لـ LLMs، قد يتعين على وكلائك:
الوصول إلى العديد من خوادم MCP
مثال: تخيل مدير مشروع ذكاء اصطناعي يستخلص تحديثات من Jira، وتوافر فريق من Google Calendar، وبيانات مبيعات من Salesforce ويمكن لكل منها أن يكون مدفوعًا بواسطة خادم MCP مختلف. لإنشاء ملخص أسبوعي واحد، يجب على الوكيل التفاعل بأمان مع مصادر بيانات متعددة. هنا يأتي دور التوثيق والتصريح، لحماية كل اتصال والتحكم في كيفية مشاركة البيانات.
الاتصال بواجهات برمجة التطبيقات والأدوات الخارجية
مثال: قد يحتاج وكيل دعم العملاء إلى استرداد تاريخ الطلب من Shopify، تحديث التذاكر في Zendesk، وإطلاق سير العمل في Slack. بدون تكامل، يصبح الوكيل معزولًا وغير فعال.
مع تحمل الوكلاء المزيد من المسؤوليات، يصبح التكامل مفتاح الاستخدام. لم يعد منتج الذكاء الاصطناعي الخاص بك مجرد ما يمكنه فعله بمفرده، بل ما يمكنه الوصول إليه، تنسيقه، والاستدلال عليه في نظام متصل. لهذا السبب، أصبح بناء القابلية للتشغيل البيني، بأمان ومرونة، أكثر أهمية من أي وقت مضى.
في عصر الذكاء الاصطناعي، تتزايد الحاجة إلى التكامل الآمن والمرن. هذا يجعل OAuth 2.0 و OIDC أكثر أهمية من أي وقت مضى.
تشمل الحالات الاستخدام الرئيسية:
توفر هذه البروتوكولات الوصول الآمن على أساس الرموز المميزة والموافقة عليها من قبل المستخدم.
هذا أمر حاسم في عالم الأنظمة المتصلة العاملية. تحقق من هذه المقالة لمعرفة لماذا تعتمد أهمية OAuth و OIDC
مع تطور المنتجات العاملية، تظل المبادئ الأساسية للهويات والتوثيق ثابتة ولكن السياق يتغير. يُدخل الوكلاء أسطحًا جديدة للتفويض والموافقة والوصول. لذلك فإن الالتزام بالمعايير المفتوحة مثل OAuth، وبناء بنية واضحة، وفرض ممارسات الأمان الصارمة ليس مجرد أفضل الممارسات، بل هو الأجزاء الأساسية. التصميم بعناية الآن يعني أن النظام الخاص بك سيتوسع بثقة ومرونة وثقة في مستقبل مدفوع بالذكاء الاصطناعي.