هوية الذكاء الاصطناعي: تسجيل دخول الإنسان ووصول الوكيل

تتوقف عن استعارة الهوية وتبدأ بإصدارها · تبني ذلك بتوجيه وكيل، مواصفة واحدة في كل مرة

تخيّل موظفك الرقمي بدوام كامل يعمل عند الثانية بعد منتصف الليل وأنت نائم. يرفع مصروفاً، ويحجز مورداً، ويرسل رداً. سؤال واحد يحدد هل هذا آمن أم كارثة تنتظر الحدوث: هوية من استخدم؟

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

هذه الدورة هي المكان الذي تتوقف فيه الهوية عن كونها مستعارة. تبنيها في نصفين. أولاً تمتلك تسجيل الدخول: بدلاً من استئجار تسجيل دخول من طرف ثالث، تنشئ مصادقة جاهزة للإنتاج وخادم OAuth/OIDC يصدر tokens حقيقية. ثم تمنح الوكيل هوية خاصة به: credential محددة النطاق ومؤقتة وقابلة للإلغاء وبموافقة بشرية، كي يستطيع العامل إنجاز عمل حقيقي نيابة عن شخص من دون أن ينتحل شخصيته أبداً.

بنهاية الدورة ستكون قد شحنت تطبيقاً عاملاً واحداً، وهو مشروع Next.js حقيقي على جهازك، ويكون بالترتيب:

• تسجيل دخول بالبريد الإلكتروني وكلمة المرور تملكه أنت، مع جلسات حقيقية ولوحة محمية؛
• مُصدِر OAuth/OIDC يصدر رموزاً موقّعة وينشر مفاتيحه (JWKS) لكي يستطيع الآخرون التحقق منها؛
• تطبيق ثانٍ منفصل يتيح للناس تسجيل الدخول عبر مُصدِرك من دون أن يحتفظ بأي أسرار لك؛
• خادم موارد يتحقق من تلك الرموز دون اتصال، ولا يقبل إلا الأساور الصادرة له؛
• وبيانات اعتماد تجريبية للوكيل: سوار محدود الصلاحية، مؤقت، قابل للإلغاء، وموافق عليه بشرياً، يحمله عامل ذكاء اصطناعي باسمه هو.

المتطلب السابق: التطوير بالمواصفات

هذه دورة بناء، وتفترض أنك تملك حلقة التطوير بالمواصفات: اتفق على ماذا، ثم وجّه الوكيل لينتج كيف. وعلى خلاف دورة SDD، الأداة الرئيسية هنا ليست claude.ai. هذه دورة مبنية على المستودع: تعمل في Claude Code أو OpenCode على تطبيق Next.js حقيقي. لن تكتب TypeScript بيدك؛ ستوجّه وكيلاً عاماً، وهو يكتب الكود، بالحركة نفسها التي تستخدمها في كل دورة بناء على مسار Manufacturing. لكن هذه دورة أمنية أيضاً، لذلك لا يكون الكود إلا نصف العمل: ما يبقى ملكك هو أن تحدد ما سيُبنى، ثم تفحص وتختبر وتثبت أن كل خاصية أمنية تعمل. وهذا ما تدرّبه تعليمات الفهم غير المعتمدة على مواصفة طوال هذه الدورة: تفك رمزاً، تعبث بقيمة audience، تعيد تشغيل الرمز، وتشاهد الخادم يرفض.

📚 وسيلة تعليمية

افتح العرض الكامل

اعرض العرض الكامل — هوية الذكاء الاصطناعي: تسجيل دخول الإنسان ووصول الوكيل

السؤال الواحد الذي تجيب عنه هذه الدورة

كل نظام تبنيه بعد ذلك تستطيع اختباره بسؤال واحد:

هوية من هذه، وكيف تنتقل السلطة من إنسان إلى وكيل؟

هذا السؤال هو العمود الفقري. ستتغير الأدوات المحددة مع استقرار معايير هوية الوكلاء. السؤال لا يتغير.

صورة واحدة: المكان والسوار

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

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

هذه هي طبقة الهوية كلها، بمصطلح واحد لكل جزء من المشهد:

نموذج واحد يُستخدم في كل مكان: الباب هو تسجيل الدخول، والكشك هو المُصدِر، والسوار هو token، والنادل هو المُحقِّق. عند الحافة الجديدة، يتوقف الوكيل عن استعارة سوارك ويحصل على سوار خاص به، أحياناً مختوماً كي يتصرف لشخص ما ضمن حدود ضيقة.

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

Tokens والجلسات من الصفر

ثلاث كلمات ستتكرر طوال بقية الدورة. إليك كل واحدة بلغة بسيطة، على الصورة نفسها التي تحملها الآن.

الجلسة هي الطريقة التي يتذكر بها الخادم أنك سجّلت الدخول. بعد أن يفحص الباب هويتك، يضع علامة صغيرة في متصفحك، هي cookie، ويقرأها في كل طلب لاحق، حتى لا تسجّل الدخول من جديد في كل صفحة. الجلسة هي معرفة المكان بأنك دخلت هذه الليلة.

Token هو السوار نفسه: ادعاء موقّع يقول من أنت وماذا يُسمح لك أن تفعل. النوع الشائع هو JWT (JSON Web Token)، ثلاثة أجزاء موصولة بنقاط، header.payload.signature. يحمل payload الادعاءات، أما signature فهو ختم الكشك.

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

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

جرّبها

خذ أي JWT، سواء أصدره تطبيقك بعد دقائق أو كان مثالاً، واطلب من وكيلك: "Decode this JWT. Show me the header and payload as plain JSON, explain what each claim means, and tell me which part anyone can verify with a public key and which part proves it was not tampered with." قراءة جوابه تمنحك فحصاً حدسياً أسرع من إعادة قراءة هذا القسم.

إعداد بيئتك مرة واحدة

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

نزّله مرة واحدة؛ المجلد نفسه يخدم الدورة كلها.

تنزيل ai-identity-base.zip

أو استنسخ مستودع agentfactory-manufacturing وافتح مجلد ai-identity. في كلتا الحالتين، افتح المجلد في وكيلك:

cd ai-identity
claude

cd ai-identity
opencode

ستحتاج أيضاً إلى قاعدة بيانات Neon Postgres مجانية لبيانات تسجيل الدخول، من دون بطاقة ائتمان؛ القاعدة تجهزها لك. أعدّها قبل التعليمة الثانية أدناه.

يأتي الدرس 0 في تعليمتين، حتى ترى الأرضية تُثبت قبل أن يُبنى عليها أي شيء.

الخطوة 1، أثبت البيئة. الصق:

Read specs/00-set-up-the-base/spec.md (Phase 1) and the "Set up the base" section of AGENTS.md. Check my prerequisites (Node, pnpm), install the skills it lists (Better Auth, shadcn, Neon), and confirm the MCP servers in .mcp.json and opencode.json are present and reachable. Don't scaffold anything yet. Just prove the ground and run the Phase 1 acceptance checks.

راقب: قد يسقط npx skills add اسم مهارة بصمت، لذلك يؤكد الوكيل أن كل مهارة وصلت فعلاً. ينتهي العمل عندما: تعرض Node وpnpm إصداراتهما، وتكون مهارات better-auth وshadcn وneon-postgres موجودة، وتجيب خوادم MCP الثلاثة.

ما حدث للتو: وظّفت الطاقم المدرّب ووصلت الهواتف، ولم تبن شيئاً بعد. المهارات هي أدلة تشغيل عامل الكشك: كيف يصدر السوار وكيف يبني الواجهة. وخوادم MCP هي الخطوط المباشرة للوكيل إلى غرفة تحكم Neon وإلى المستندات الحية. الأرضية مثبتة؛ لا يقف عليها شيء بعد.

الخطوة 2، أنشئ هيكل التطبيق. جهّز قاعدة Neon أولاً، ثم الصق:

Now do Phase 2 of specs/00-set-up-the-base/spec.md: scaffold the Next.js + Tailwind + shadcn app here, pin the Better Auth 1.7 stack with the kysely override, add the Neon driver, and create .env from the template. Don't build any auth. Start the dev server and show me the landing page is up, then run the Phase 2 acceptance checks.

راقب: يرفض create-next-app إنشاء مشروع داخل مجلد غير فارغ، لذلك تنشئ وصفة القاعدة المشروع في مجلد مؤقت ثم تدمج النتيجة مرة أخرى، وتربح ملفات القاعدة عند أي تعارض. ينتهي العمل عندما: يخدم pnpm dev صفحة هبوط بسيطة على http://localhost:3000، ويعمل pnpm build وtsc بنجاح.

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

الفوز السريع: سجّل دخولك إلى تطبيقك أنت

بعد أن أصبحت القاعدة جاهزة، تفصلك تعليمة واحدة عن شاشة تسجيل دخول تملكها أنت، مدعومة بقاعدة بيانات حقيقية. انجح أولاً وافهم ثانياً.

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

الدرس 1، امتلك تسجيل الدخول. الصق:

Read specs/01-own-your-sign-in/spec.md and the better-auth-best-practices and email-and-password-best-practices skills. Plan the approach against our constitution, show me the plan, then build it in small steps. Run the spec's acceptance checks, including the security ones, before you call it done.

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

راقب: ترفض نقاط POST في Better Auth أي طلب لا يكون ترويسة Origin فيه موثوقة، لذلك تسجل إعدادات القاعدة أصل التطوير مسبقاً. ينتهي العمل عندما: تنشئ حساباً وتصل إلى لوحة تحكم تعرض اسمك وبريدك، وتُخزَّن كلمة مرورك فقط كتجزئة أحادية الاتجاه، وهو ما تثبته تعليمة الفهم أدناه.

الآن اجعله حقيقياً لنفسك بتعليمة فهم لا مواصفة لها؛ إنها فقط تجعلك ترى ما بنيته:

I just signed up. Show me exactly what got stored in the database for my account, and point out what is NOT there. Where is my password, and why can't you show it to me?

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

مسار البناء: من استئجار تسجيل الدخول إلى إصداره

الدورة عمود من سبع خطوات تطابق المواصفات في القاعدة واحدة بواحدة. تبني كل خطوة بلصق تعليمة قصيرة؛ تحمل المواصفة التفاصيل وتحمل المهارة API الدقيق، لذلك يبقى النص عن الفكرة. هذا هو القوس كله، والمكان الذي يتوقف فيه عن كونه أرضاً مستقرة.

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

0–1. أعدّ القاعدة، ثم امتلك تسجيل الدخول

قابلت هاتين الخطوتين في الفوز السريع. تنشئ الخطوة 0 سلسلة الأدوات، Next.js وshadcn ومكدّس Better Auth 1.7 وNeon. وتقيم الخطوة 1 تسجيل الدخول بالبريد وكلمة المرور مع جلسات حقيقية على الخادم ولوحة تحكم محمية. هذا هو الباب: يثبت مستخدموك من هم، مرة واحدة.

2. صِر المُصدِر، وهي اللوحة الرئيسية

هذه هي الخطوة التي كان المسار كله يشير إليها. في التطبيقات الأصلية للموصلات كنت النادل: كانت بوابتك تتحقق من tokens وقّعها شخص آخر. هنا تمشي خلف المنضدة وتصبح الكشك. عندما يرسل تطبيق آخر شخصاً إليك لتسجيل الدخول، يعيد خادمك token موقّعاً يستطيع التطبيق الآخر التحقق منه وحده بالكامل بمقارنته بصورة ختمك التي تنشرها علناً، من دون رؤية كلمة مرور أو الاتصال بقاعدة بياناتك.

بهذا تُغلق الحلقة: الدورة التي علّمتك فقط النظر إلى الأساور تعلّمك الآن طباعتها.

قبل أن تلصق هذا، تعرّف إلى المصافحة التي سيجريها كشكك. عندما يرسل عميل OAuth، أي مكان آخر يوافق على قبول أساورك، شخصاً لتسجيل الدخول، لا تعيد السوار عبر متصفحه. تشغّل تدفق رمز التفويض: يسجّل الشخص الدخول عند كشكك، وتعطي التطبيق code قصير العمر، كقسيمة استلام، ثم يبدل التطبيق تلك القسيمة بالرمز token الحقيقي بعيداً عن الأنظار، فلا يمر السوار نفسه عبر المتصفح. PKCE هو البرهان ذو السطر الواحد أن التطبيق نفسه الذي بدأ المصافحة هو الذي ينهيها، لذلك لا تنفع القسيمة المسروقة أي شخص آخر. وقبل طباعة أي سوار، يوافق الشخص على ما يمكن للتطبيق رؤيته على شاشة consent. وصورة الختم المنشورة على الحائط من قبل هي ما يسمح لذلك التطبيق بالتحقق من السوار عندما يمسكه.

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

Read specs/02-become-the-issuer/spec.md and the agent-identity-issuer skill. Plan it, show me the plan, then build it in small steps. Build the token verifier as a separate script so the checks are real, and run all the acceptance criteria, especially the adversarial ones.

لن تكتب إعداد OAuth بيدك. تحمل مهارة agent-identity-issuer المرفقة الإعداد الموثق، وتحمل المواصفة فحوص القبول. دورك هو توجيه البناء والتأكد أنه ينجح، بما في ذلك بوابات الأمان التي قد تفشل فيها نسخة تعمل لكنها غير آمنة.

بنيته؛ الآن شاهده وهو آمن فعلاً. لا تملك التعليمات أدناه مواصفة. كل واحدة تجعل خاصية أمان واحدة مرئية على المُصدِر لديك، مرة في كل مرة.

أولاً، انظر إلى الصورة على الحائط. نقطة JWKS endpoint لديك هي ذلك الحائط بالضبط: الصورة العامة لختم كشكك، المنشورة كي يفحص أي شخص السوار عليها. أما الختم الذي يضغط العلامة، أي مفتاح التوقيع الخاص، فيبقى مقفلاً في الكشك ولا يظهر في تلك الصورة.

Fetch my JWKS endpoint and show me what's there. Is my private signing key in it? Prove it, and explain why a stranger can verify my tokens but can't forge one.

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

بعد ذلك، اقرأ سواراً طبعته للتو، ثم اكسره بتغيير حرف واحد:

Take an ID token you just issued, decode it, and walk me through every claim, iss, aud, sub, exp, in plain English. Then change the aud by one character and show me the verifier rejecting it.

أخيراً، ادفع سواراً بعد وقت الإغلاق:

Issue a token, then move the clock past its expiry and try to use it. Show me the exact rejection.

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

3. النطاقات والموافقة

ينبغي أن يقول token بالضبط ما يجوز له فعله، لا أكثر. تضيف الخطوة 3 scope، أي ما يُسمح للسوار فعله، مثل سوار ملوّن مختوم مشروبات فقط بدلاً من مشروبات ومطبخ، وتضيف شاشة consent يرى فيها الشخص القائمة الدقيقة قبل الموافقة. أقل صلاحية صارت حقيقية: يحمل السوار أضيق سلطة تؤدي المهمة، ويفحصها النادل عند كل طلب، لا مرة واحدة عند الباب.

لقد شغّلت هذه الحلقة مرتين الآن. ها هي مرة أخرى، بفكرة جديدة واحدة، scope، فوق المُصدِر الذي بنيته. الصق:

Read specs/03-scopes-and-consent/spec.md and the agent-identity-issuer skill. Plan the approach against our constitution, show me the plan, then build it in small steps. Run the spec's acceptance checks, especially the adversarial ones, before you call it done.

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

أولاً، أعط نفسك سواراً ضيقاً وحاول أن تتجاوزه:

Issue me a token that has only notes.read. Now use it to try the write action and show me the exact refusal. Then explain in plain English why a token that signs fine can still be turned away here.

ثم انظر إلى شاشة الموافقة التي يراها الشخص فعلاً:

Walk me through the /consent screen for a client asking for notes.read and notes.write. Where do those two lines come from? Prove the screen can only show what the signed request actually asks for, not whatever it likes.

وأخيراً، حاول أخذ سلطة أكبر مما سجّلت لأجله:

Register a client for notes.read only, then have it ask for notes.write anyway. Show me the granted scope in the token it gets back and point out what is missing, and why.

ما حدث للتو: صارت أساورك تأتي بألوان. يحمل كل واحد أضيق سلطة تؤدي المهمة، ورأى الشخص القائمة الدقيقة قبل طباعة أي سوار.

4. صِل تطبيقاً حقيقياً

الآن أثبت أن الكشك يعمل لشخص غيرك. تطبيق العميل هو مكان منفصل يسجّل الناس الدخول من خلالك من دون مشاركة أي من أسرارك. سمِّ المُصدِر لديك AuthCo والتطبيق الجديد Notes. عندما يسجّل شخص الدخول إلى Notes، يرسله إلى كشك AuthCo، فيحصل على سوار، ويفحص ختم السوار بنفسه بالكامل مقابل الصورة التي ينشرها AuthCo على الحائط. لا يرى Notes كلمة مرور ولا يلمس قاعدة بياناتك.

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

Read specs/04-connect-a-real-app/spec.md and the agent-identity-issuer skill (the register-a-client and verify-a-token sections). Plan the approach against our constitution, show me the plan, then build it in small steps. Keep Notes a fully separate process. Run the spec's acceptance checks, especially the adversarial ones, before you call it done.

الآن أقنع نفسك أن الفصل حقيقي. تجعل كل تعليمة جزءاً منه مرئياً:

أولاً، أثبت أن Notes لا يحمل أياً من أسرارك:

Show me everything Notes knows about AuthCo. Prove it has no copy of BETTER_AUTH_SECRET and no path into AuthCo's database, then explain how it can still verify my tokens.

الجواب هو الصورة مرة أخرى: لا يحتاج Notes إلا إلى الصورة العامة لختم AuthCo كي يفحص السوار، لا إلى الختم نفسه، فيستطيع التحقق من كل token وهو لا يحمل أياً من أسرار AuthCo.

ثم اكسر ختم الجمهور بحرف واحد:

Take a token Notes just verified and change its aud by one character. Show me Notes's verifier rejecting it, and explain why that one character is the whole point.

وأخيراً، اقطع السوار من الكشك وشاهد النداء التالي يفشل:

Sign me in through Notes, then revoke the client at AuthCo. Make Notes's next call and show me it fails. Explain what "revocable" actually buys me here.

ما حدث للتو: سجّل مكان لا تسيطر عليه شخصاً من خلال كشكك ووثق بالسوار وحده، من دون حمل أي من أسرارك. الكشك يعمل للغرباء، لا لك وحدك.

5. صِل خادم موارد

خادم الموارد هو بار لا يفعل إلا فحص الأساور ولا يسجّل دخول أحد. هذا بالضبط هو النادل الذي لعبت دوره في التطبيقات الأصلية للموصلات، لكنه الآن يقف على أرضك أنت. يأخذ bearer token، أي أن من يحمل السوار يقدمه ولا يبرز هوية أخرى، ويقرأ ختم audience على السوار، صالح لهذا البار، فيرفض فوراً سواراً طبع لبار آخر. الختم هنا مصنوع بخوارزمية توقيع محددة، RS256، وأي سوار مختوم بطريقة أخرى يُرفض أيضاً. يفحص كل ختم مقابل صورة AuthCo المنشورة ولا يتصل بالكشك، وهذا بالضبط معنى التحقق دون اتصال عبر JWKS في تعليمة البناء أدناه.

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

Read specs/05-connect-a-resource-server/spec.md and the agent-identity-issuer skill (sections 1 and 3). Plan it, show me the plan, then build it in small steps. Configure AuthCo to sign RS256 tokens audience-bound to my API, stand up a tiny protected resource that verifies offline via JWKS, and run all the acceptance checks including the adversarial ones.

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

أولاً، ضع نوعي السوار جنباً إلى جنب:

Show me two tokens side by side: the ID token from the login flow (lesson 4) and the access token a resource server gets. Point at the aud on each and explain in plain English why they're different.

ثم قدّم سواراً مختوماً بالطريقة الخاطئة:

Sign a token with EdDSA and present it to my RS256-only verifier. Show me the exact rejection, then explain why the issuer's signing algorithm has to match what the consumer expects.

وأخيراً، وجّه سواراً صالحاً إلى البار الخطأ:

Change the audience on a valid token to a different API's URL and show my resource server refusing it, even though AuthCo's signature is genuine.

ما حدث للتو: أقمت النادل من Connector-Native Apps على أرضك. يفحص كل سوار، ويخدم فقط الشخص المسمى داخله، ويرفض أي سوار طُبع لبار مختلف أو خُتم بالطريقة الخاطئة.

6. هوية العميل مع CIMD، الحافة

الخطوات من 0 إلى 5 أرض مستقرة وجاهزة للإنتاج. في الخطوة 6 تخرج عنها. حتى الآن كان التطبيق يثبت من هو عبر تسجيل العميل: يحصل مسبقاً على مكان في قائمة شركائك المعتمدين. مع CIMD، أي Client ID Metadata Document، يتجاوز التطبيق القائمة. يعلّق لافتة عامة على URL تصف نفسه، ويقرأ كشكك تلك اللافتة عند الطلب في أول مرة يظهر فيها التطبيق، من دون تسجيل مسبق. هذا هو الاتجاه الذي يسير إليه عالم MCP، لكنه يعمل على plugin قبل الإصدار الرسمي من Better Auth وعلى معيار IETF مسودة، لذلك تطلب منك الدورة تأكيد API الحي قبل البناء.

هذا هو الموضع الوحيد الذي تبحث فيه قبل أن تبني، لأن الأرض أحدث. تمهل؛ تطلب التعليمة نفسها من الوكيل فحص المستندات الحية أولاً، وهذه هي الغريزة الصحيحة مع معيار يتحرك. الصق:

Read specs/06-client-identity-with-cimd/spec.md and section 2 of the agent-identity-issuer skill. Before writing anything, query the live Better Auth docs MCP at https://mcp.better-auth.com/mcp and show me the current @better-auth/cimd API, whether I add cimd() or pass cimdClientDiscovery() to oauthProvider, and the exact discovery key. Then plan it, show me the plan, move us to the Better Auth 1.7 pre-release channel, and build it in small steps. Run the acceptance checks including the adversarial ones.

ثم شاهد ما الذي فعّله هذا التغيير الواحد. تجعل كل تعليمة السلوك الجديد مرئياً:

أولاً، شاهد السطر الجديد يظهر على لافتتك العامة:

Show me my discovery document before and after this change, and point at the one new line that tells a client "you can identify yourself by URL." Explain in plain English what that flips on.

ثم شاهد الكشك يقرأ لافتة بدلاً من قائمة:

Walk me through what happens when a client hands you an HTTPS URL as its client_id: what do you fetch, what do you read in that document, and how is that different from looking up a row in my database?

وأخيراً، أعطه لافتة سيئة وشاهد الرفض:

Hand my issuer a client_id that is a plain http:// URL, and one with a #fragment on the end. Show me each one being refused, and explain why the draft insists on a clean HTTPS URL.

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

علامة ~50%: أول مشروع تقوده أنت

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

🔐Project 12-3 hoursقوِّ تسجيل الدخول لديكتسجيل الدخول يعمل. الآن اجعله صعب السرقة وسهل الدخول.

لديك بالفعل تسجيل دخول عامل. وتسجيل الدخول العامل هدف أيضاً: كلمة مرور مسربة واحدة ويدخل شخص ما. لذلك ترفع مستوى الحماية من الجانبين، باستخدام مواصفتي 2fa وsocial-login المستقرتين في القاعدة.

تحمل فكرتان جديدتان هذا الجزء. العامل الثاني هو برهان ثانٍ بعد كلمة المرور: يفحص حارس الباب أيضاً رمزاً لا يستطيع عرضه إلا هاتفك، فلا يكفي نسخ الهوية وحدها للدخول. وتسجيل الدخول الاجتماعي باب ثانٍ فقط، مدخل Continue with Google ينتهي إلى العضوية نفسها في الداخل.

Read specs/projects/2fa/spec.md and specs/projects/social-login/spec.md. Plan both, show me the plan, then build them in small steps. Harden the sign-in you already own with a second factor, and add a "Continue with Google" door. Run every acceptance check, including the adversarial security ones.

ينتهي العمل عندما تُرفض كلمة مرور صحيحة مع عامل ثانٍ خاطئ، ويعمل رمز احتياطي مرة واحدة بالضبط، ويصل "Continue with Google" إلى لوحة التحكم نفسها التي يصل إليها مستخدم البريد وكلمة المرور، ولا يظهر أي سر في جسم استجابة أو سجل.

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

frontier: هوية الوكلاء

الآن النصف الثاني، وسبب وجود الدورة. كل token حتى الآن كان يمثل إنساناً: سجّلت الدخول، وحصلت على سوار، ووثقت به التطبيقات والبوابات. لكن مسار Manufacturing يدور حول وكلاء يتصرفون بأنفسهم. لذلك يتحول السؤال: عندما يفعل وكيل شيئاً، سوار من يرتدي؟ إذا أعاد استخدام تسجيل دخولك، تقول السجلات إن أنت فعلت ذلك، ويستطيع فعل أي شيء تستطيع فعله، ولا يمكنك إلغاء الوكيل من دون إقفال نفسك خارجاً. هذه إجابة خاطئة، وإصلاحها هو frontier كله.

إليك الصورة نفسها، هذه المرة بوصفها المشكلة والحل:

الصورة نفسها، مشكلة وحل: اليوم يرتدي كل وكيل نسخة من سوارك الرئيسي الواحد، لذلك لا يستطيع الحارس تمييزهم أو قص واحد فقط. مع agent auth، يعمل كل وكيل تحت مضيف موثوق ويرتدي سواراً خاصاً به، ويقرأ الخادم بالضبط من يتصرف ويقص واحداً من دون لمس البقية.

هذا هو لماذا. أما كيف فهو تدفق قصير يجريه كل وكيل ليحصل على سواره ويستخدمه:

تعمل هذه الخطوات الثلاث على plugin في Better Auth اسمه @better-auth/agent-auth، وهو beta، وتنفيذ لبروتوكول Agent Auth Protocol. الصياغة الصادقة، الموضوعة في المقدمة: تعامل مع API المحدد كتمثيل قابل للاستبدال للمبادئ المتينة، وثبّت النسخة التي تصل إليها. ما لا يتحرك هو الصورة، فاحتفظ بها: الوكيل على وشك الحصول على سوار خاص به.

أنت لا تبدأ من لا شيء. تشحن القاعدة مثالاً عملياً موثقاً للخطوات الثلاث أدناه، وهو مفتاح الإجابة في worked-examples/ai-identity/، وكل خطوة مواصفة تقودها أنت، بالحركة نفسها التي كررتها ست مرات.

يحصل الوكيل على سوار خاص به

حتى الآن كنت أنت الضيف. هنا يدخل ضيف جديد: وكيل ذكاء اصطناعي. الغريزة الأولى هي تعليقه على سوارك، لكن هذه هي مشكلة الانتحال نفسها. بدلاً من ذلك يحصل الوكيل على سوار خاص به، باسمه، سوار agent #7 من الصورة.

ثلاثة أشياء تجعل هذا مختلفاً عن تسجيل دخول الإنسان، وهي الفكرة كلها. أولاً، لا يصل الوكيل وحده؛ يعمل داخل مضيف، runtime أو جهاز يثق به المكان مسبقاً، ويزكيه المضيف للدخول. ثانياً، السوار مختوم ذاتياً وقصير العمر: يوقّع الوكيل سواره بمفتاحه هو، ويصلح السوار لنحو دقيقة، لذلك يصبح السوار المنسوخ قديماً فور تسربه تقريباً، وهذا مختلف جداً عن bearer token طويل العمر في ملف إعدادات. ثالثاً، ما يسمح السوار للوكيل بفعله هو قائمة capabilities مسماة، وهي نسخة الوكيل من scope. لقد شغّلت هذه الحلقة من قبل؛ ها هي مرة أخرى، موجهة إلى نوع جديد من الضيوف:

Read specs/projects/agent-credential/spec.md and .agents/skills/agent-identity-issuer/. Confirm the live agent-auth surface against the Better Auth docs MCP first, it is beta. Plan it, show me the plan, then build in small steps: enable autonomous agent identity, register an agent under a host, have it self-sign its own short-lived credential, and execute a granted capability. Run every acceptance check, including replay and revocation.

الآن اجعل الفكرة الجديدة مرئية. أولاً، انظر إلى الاسم المكتوب على السوار:

Register an autonomous agent and show me the credential it gets. Whose identity is the sub, a person's or the agent's own? Explain in plain English why the agent having its own band is different from it reusing my login.

ثم أثبت أن السوار القصير العمر والمختوم ذاتياً يقاوم السرقة:

Take my agent's credential and replay the exact same signed band twice. Show me the second call being refused. Explain what the one-time marker is doing and why a band good for only a minute is safer than a long-lived token.

ما حدث للتو: توقف الوكيل عن استعارة سوارك وحصل على سوار خاص به. تقول السجلات الآن إن الوكيل فعل ذلك، والسوار باسمه، ولا يحمل إلا capabilities التي مُنحت له.

On-behalf-of: سوار مختوم

هذا هو credential الأهم الذي يجب ضبطه. نادراً ما يتصرف الوكيل لنفسه فقط؛ غالباً يتصرف لشخص، والاختصار الخطر هو السماح له أن يصبح ذلك الشخص. On-behalf-of هو النسخة الصادقة: يذكر السوار الطرفين، الوكيل #7، يتصرف عن Alice، لذلك يُنسب الفعل دائماً إلى زوج الوكيل-عن-Alice، لا إلى Alice وحدها. هذا هو السوار المختوم من الصورة: لصالح Alice، مشروبات فقط، باطل عند منتصف الليل.

ما يجعله آمناً هو الموافقة البشرية داخل الحلقة. لا يستطيع الوكيل سك هذا السوار لنفسه. يطلب، وتتلقى Alice تعليمة موافقة، بتدفق device-code مثل تسجيل التلفاز في حساب البث، وتقول نعم قبل أن توجد أي سلطة. لا موافقة، لا سوار. وبما أن Alice هي مصدر السلطة، تستطيع سحبها: ألغِها، ويفشل نداء الوكيل التالي. الصق:

Read specs/projects/on-behalf-of/spec.md and .agents/skills/agent-identity-issuer/. Confirm the live agent-auth surface against the Better Auth docs MCP first, it is beta. Plan it, show me the plan, then build in small steps: enable delegated mode, have an agent request a scoped capability, gate it behind human device-code approval, and only then let it act. Run every acceptance check, including no-approval-no-grant and revocation.

ثم شاهد بوابة الإنسان تصمد فعلاً. أولاً، توقف قبل الموافقة:

Have my agent request the right to act for me, then stop before I approve. Show me that it has nothing yet, no band, no access. Explain why "human in the loop" means the approval is the thing that mints the authority, not a formality after it.

ثم أثبت أنها تفويض، لا انتحال:

Approve the grant, then show me the band. Point out where it says both the agent and that it is acting on behalf of me. Explain why that pairing matters for an audit trail.

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

شدّد السوار: scope والقيمة وبصمة للأشياء الخطرة

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

Capability هي الفعل المسمى: يجوز للوكيل مشاركة ملاحظة. وvalue-constraint يضيّقها إلى قيم مسموحة، لا تشغيل أو إيقاف فقط: ليس "يجوز مشاركة الملاحظات" بل "يجوز مشاركة الملاحظات فقط مع @acme.com." لا يستطيع scope نصي التعبير عن ذلك؛ يستطيع constraint ذلك، ويفحصه الخادم لحظة تصرف الوكيل، لذلك تُرفض مشاركة إلى @evil.com حتى لو كانت capability مفعلة. وstep-up approval يرفع بوابة الإنسان بقدر حجم الضرر: قراءة تُمنح تلقائياً، ومشاركة تحتاج إنساناً مسجلاً، وفعل لا رجعة فيه، احذف كل شيء، يحتاج وجوداً جسدياً، بصمة أو passkey، حتى لا يستطيع وكيل ذكاء اصطناعي لديه متصفح أن ينقر approve على تدميره بنفسه. هذا هو أكثر من $50 يحتاج Alice في الصورة، إلا أن الفعل الأخطر يحتاج بصمة Alice، لا مجرد موافقتها اللفظية. الصق:

Read specs/projects/step-up-approval/spec.md and .agents/skills/agent-identity-issuer/. Confirm the live agent-auth surface against the Better Auth docs MCP first, it is beta. Plan it, show me the plan, then build in small steps: three capabilities across the approval ladder (auto, session, physical-presence), one with a required value-constraint, and a single-use grant. Run every acceptance check, including the adversarial ones.

الآن أثبت أن كل حد يعض. أولاً، value-constraint:

Give my agent the right to share notes, but only with @acme.com. Then have it try to share with @evil.com and show me exactly where the server refuses it. Explain why a value-constraint is stronger than an on-or-off scope.

ثم بوابة step-up على الفعل الخطر:

Try to approve the "delete everything" capability for my agent with just my logged-in session. Show me the server demanding physical presence instead of granting it, and explain what that step-up protects against when the agent itself has a browser.

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

ملاحظة حول النضج: لماذا هذا صادق لا دعاية

تعلّمك الدورة أن ترتكز على المبادئ المتينة، الأجزاء التي تبقى صحيحة بينما تتقلب الأدوات: تسجيل دخول موثق، وcredential خاص بالوكيل، وتفويض on-behalf-of، وscope بأقل صلاحية، وموافقة بشرية. ثم تكون واضحة بشأن مدى استقرار كل طبقة:

• العمود المستقر جاهز للإنتاج اليوم. يعمل تسجيل الدخول، والمُصدِر، والنطاقات والموافقة، وربط تطبيق حقيقي، وخادم الموارد كلها على مكدّس Better Auth الناضج والمفتوح المصدر. تم التحقق حياً من العمود كله، ومعه CIMD، على خط 1.7، وقبلت بوابة Connector-Native Apps tokens وقّعها هذا المُصدِر. النصف الأول شيء تستطيع شحنه.
• CIMD هي الحافة. تعمل، وهي مثبتة ومبرهنة، لكنها تعيش على إصدار ما قبل رسمي من Better Auth وعلى معيار IETF مسودة. توقع أن تتحرك؛ أعد تأكيد API قبل البناء.
• هوية الوكلاء هي frontier. منح الوكيل سلطة خاصة به، محدودة وقابلة للإلغاء وon-behalf-of، هو الاتجاه الذي تتحرك إليه الصناعة. أشارت Anthropic إلى ذلك عبر human-agent teams، ولدى Better Auth plugin مبكر لوكيل Agent Auth، لكن المعايير شابة وما زالت تستقر.

هذا التقسيم هو الهدف من الارتكاز على المبادئ. عندما تستقر المعايير، سيكون النموذج الذهني مناسباً لها بالفعل: credential ما زال سواراً، وscope ما زال ما يسمح به السوار، والانتهاء ما زال وقت الإغلاق، والموافقة البشرية ما زالت الشخص عند الكشك يقول نعم.

إلى أين يقود هذا

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

هذه هي طبقة credentials تحت بقية مسار Manufacturing. بعد ذلك تمنحك بناء وكلاء الذكاء الاصطناعي حلقة ذلك الوكيل، أي الاستدلال والأدوات التي تقرر ماذا يفعل بالسلطة التي تعلمت الآن منحها. وفي فرق الإنسان والوكيل تستخدم هذه الهوية عملياً، فتشغّل قائمة من الوكلاء إلى جانب الناس، وكل واحد يحمل سواراً خاصاً به ولا يملك إلا السلطة التي مُنحت له.

لقد توقفت عن استعارة الهوية. من هنا فصاعداً، أنت تصدرها.

بطاقات المراجعة للدراسة

---

اختبر فهمك

Checking access...