الخلاصة
- رمز الاستمرار في GNAP مرتبط بمفتاح العميل، ووظيفته متابعة طلب تفويض محدد عند خادم التفويض، لا استدعاء خادم مورد محمي.
- ما دام الطلب في حالة انتظار، تمنع RFC 9635 إصدار رموز API أو إرجاع معلومات عن الموضوع. وحتى بعد إتمام التفاعل، يعيد خادم التفويض تقييم الطلب كله.
من السهل أن يحوّل لوح مراقبة إتمام المستخدم لصفحة الموافقة إلى نتيجة نهائية. لكن ذلك قد يعني فقط عودة المتصفح إلى العميل، أو حصول العميل على URI للاستمرار، أو إثباته السيطرة على مفتاح بتوقيع. كل ذلك معلومات مفيدة، لكنه لا يجيب وحده: هل يملك هذا العميل الآن حق تنفيذ هذه الدعوة على واجهة API هذه؟
تبني RFC 9635 بروتوكول GNAP كي لا يقع هذا الخلط. يبدأ العميل طلب منح عند خادم التفويض. فإذا بقيت موافقة مالك المورد أو تفاعل المستخدم مطلوبة، يدخل الطلب حالة pending. يجوز للخادم عندئذ أن يعيد معلومات الاستمرار، لكنه لا يجوز أن يمنح رموز وصول لواجهة API أو يطلق معلومات الموضوع. فما يجري هو تفاوض على الوصول، لا وصول تم منحه.
ولاعتماد الاستمرار مهمة ضيقة عمداً. يجب أن يرتبط بمفتاح مثيل العميل، وألا يكون bearer token، وأن يُقدَّم مع دليل ذلك المفتاح إلى URI الاستمرار. يتحقق خادم التفويض من التوقيع ومن صلته بالمفتاح المناسب. هذا يحمي من يحق له متابعة المحادثة نفسها؛ ولا يحوّل المحادثة إلى إذن عند خادم الموارد.
والفصل مكتوب كقاعدة في الاتجاهين. لا يجوز لرمز وصول عادي أن يعمل عند نقطة الاستمرار. وبالعكس، لا يجوز لرمز الاستمرار أن يُستخدم لطلب مفوّض إلى خادم مورد، حتى لو كان خادم المورد مشاركاً خادم التفويض موضع النشر نفسه. تشابه شكل قيمتين لا يمنحهما المتحقق نفسه ولا النطاق نفسه ولا الأثر المسموح نفسه.
ولا تنهي نهاية التفاعل القرار تلقائياً. بعد التفاعل، يعيد خادم التفويض الطلب إلى المعالجة ويقيّم سياقه الكامل من جديد، سواء وافق مالك المورد أم رفض. لا يمكن إلا للطلب الموافق عليه أن يعيد رموز API أو معلومات الموضوع. أما الطلب الذي صار finalised فلا يصدر رموزاً جديدة ولا يعيد معلومات ولا يستأنف تفاعلاً؛ والوصول اللاحق يحتاج طلباً جديداً.
إدارة الرمز سطح ثالث. قد يحمل رمز API URI مستقلاً واعتماد إدارة للتدوير أو الإلغاء. يحافظ التدوير على حقوق الرمز الأصلي وخصائصه ولا يوسّعها. ولطلب حقوق مختلفة، يحتاج العميل إلى تحديث عبر الاستمرار وإعادة تقييم، أو إلى طلب جديد. الاستمرارية الإدارية ليست توسعاً في السلطة.
ويبقى لخادم المورد حد تحقق خاص به. يقدَّم رمز GNAP الخاص بواجهة API مع دليل المفتاح المطلوب، ويمكن للخادم تحدي طلب بلا رمز أو برمز غير صالح. لكن حتى هذا لا يثبت أن الغرض التشغيلي ما زال مرغوباً، أو أن الشروط الحالية تسمح بالفعل، أو أن الأثر المطلوب وقع.
لذلك ينبغي حفظ سلسلة أدلة مكوّنة من وقائع منفصلة: هوية الطلب والوصول المطلوب، حالة الانتظار، URI الاستمرار ودليل المفتاح، نتيجة التفاعل، إعادة التقييم، نطاق رمز API الصادر، تحقق خادم المورد، استلام الطلب والأثر المرصود. اختزالها كلها في كلمة «مفوّض» يمحو الحدود التي وضعها البروتوكول قصداً.
المصادر
- RFC 9635 — Grant Negotiation and Authorization Protocol
- سجل نشر RFC 9635
- IETF Datatracker — RFC 9635
- RFC 9396 — OAuth 2.0 Rich Authorization Requests
- RFC 8707 — Resource Indicators for OAuth 2.0
- RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession
- RFC 9470 — OAuth 2.0 Step Up Authentication Challenge Protocol
- Heng Lu — Minimum Initial Specification, Localized Future Decision and Voluntary Adoption
- Heng Lu — Running-Code Primacy
- Heng Lu — Reality Layers, Symbolic Power and Clarity
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
