بقي المستخدم داخل التطبيق، فدخل التطبيق نفسه في حدود الثقة

الخلاصة

• تعرّف المراجعة 04 من OAuth for First-Party Applications نقطة HTTPS قد تصدر رمز تفويض أو تطلب من التطبيق مدخلاً آخر أو تفرض العودة إلى المتصفح. اختفاء التحويل يجعل binary المثبت ودليل الناشر والواجهة والالتزام بالـfallback أجزاء من قرار الثقة.
• تستطيع auth_session وPKCE وDPoP ربط الاستمرارية بمثيل ومفتاح، لكنها لا تثبت أن التطبيق first-party فعلاً أو أن المستخدم رأى التحدي الصحيح أو أن التطبيقات الشقيقة تعرض إشارات متماثلة أو أن الانتقال حدث عند ارتفاع الخطر أو أن النتيجة الخارجية اكتملت.

أدخل المستخدم رمزاً لمرة واحدة داخل تطبيق البنك، وأرسله التطبيق إلى الخادم، فعاد authorization code عبر قناة خلفية. لم يُفتح متصفح. اختفى انتقال في الواجهة، لكن الثقة لم تختف؛ انتقلت سلطة العرض.

تعرّف المراجعة 04 نقطة Authorization Challenge Endpoint. يمكن للعميل إرسال login hint أو signed passkey challenge أو MFA code. يستطيع الخادم إصدار الرمز، أو إعادة insufficient_authorization لمواصلة الحوار، أو redirect_to_web ليستعيد العرض في المتصفح.

الوثيقة Internet-Draft نشط لفريق OAuth بتاريخ 1 يوليو 2026 وينتهي في 2 يناير 2027، ومقصود به Standards Track. ليس RFC، ولا يثبت إكمال IANA أو interoperable profile أو deployment أو attestation coverage أو انخفاض phishing أو نتيجة عمل.

انتقلت واجهة المصادقة إلى التطبيق

في code flow التقليدي يسيطر authorization server على صفحة إدخال الأسرار. هنا يقود client موثوق جزءاً من المراسم، ويرسل OAuth parameters وما جمعه. بعض extensions الخاصة بالويب لا تحمل معنى أصلياً واضحاً، ويظل التعامل معها خارج النطاق.

يقرر الخادم كفاية المعلومات، لكن التطبيق قد يختار شكل prompt والمكوّن الذي يقرأ السر ولغة الخطأ وproprietary endpoint للخطوات الوسطى. صيغ تلك الخطوات وchallenge schemas وترتيبها ليست موحدة؛ يحتاج التشغيل إلى profiles لتحقيق interop.

ينبغي حفظ build والمثيل والprofile ونوع الإدخال من دون السر وscopes وpolicy version والنتيجة والخطوة التالية. code صحيح يثبت أن الخادم أصدر grant artifact، لا ما شاهده المستخدم.

first-party علاقة وليست قيمة في الطلب

يجب على AS التحقق من “first-partyness” قبل المتابعة: التطبيق والخادم تحت سيطرة entity واحدة والمستخدم يفهم أنهما لها. لكن طريقة التحقق ليست محددة.

قد توفر platform/app-store attestation وAttestation-Based Client Authentication وDynamic Client Registration أدلة. لا يدمج أي منها corporate control وdistribution custody وbinary integrity وkey possession وbrand recognition في حقيقة واحدة.

قد يكون package صحيح التوقيع قديماً أو مخترقاً، وقد يعرض تطبيق شرعي prompt مضللاً. وقد تنتمي DPoP key إلى نسخة غير مقصودة إذا لم يحدد enrollment المثيل. يمكن تقليد مظهر العلامة.

يجب فصل publisher وdistributor وattester وfreshness وnonce وpolicy وinstance عن client_id وauth_session وcode. “first-party verified” استنتاج يعتمد على أدلة.

auth_session سياق يحمله التطبيق

auth_session قيمة opaque تربط طلبات المثيل نفسه وتشبه cookie. يخزنها التطبيق ويعرضها، ويقبل rotation، ويحتفظ بها بعد code، ويحذفها عند logout. يحمي الخادم محتواها.

يجب أن تكون unique؛ وإذا كانت random توصى 256-bit entropy. ينبغي ربطها بالجهاز. لا تفرض المواصفة lifetime، ويمكن invalidation بالوقت أو risk أو revocation، ولا يجوز للعميل افتراض مدة.

يسجل التدقيق generation وpredecessor وinstance وcontext وDPoP key وstage وrotation وlogout وterminal state، لا القيمة نفسها. قبول session يعني استمرار context فقط، لا صدق الواجهات السابقة أو استمرار الشخص نفسه.

DPoP يربط المفتاح لا الشاشة

تصف المراجعة DPoP عبر challenge وcode وtoken وresource وauth_session. يمكن للخادم فرض public key نفسها منذ البداية والتحقق من private-key possession لاحقاً.

يقلل ذلك replay لsession أو code مسروق. لكنه لا يثبت provenance: من أجاز enrollment، أي package رسم الشاشة، هل المثيل سليم، هل policy ما زالت تثق به، أو هل قصد المستخدم scope.

يجب فصل DPoP match وattestation وregistration وfirst-party policy وprompt profile وuser authorization.

redirect_to_web انتقال أمني

يمكن للخادم إرجاع redirect_to_web عند high risk أو method غير مدعوم أو recovery أو exception. يبدأ العميل code flow جديداً في external user agent، وربما يستخدم PAR request_uri.

إذا لم يحمل الطلب الأول PKCE code_challenge فلا يجوز إرجاع request_uri. يجب الحفاظ على native-app practice وOAuth Security BCP وissuer identification.

احفظ trigger وrisk band وPKCE وissuer والمرجع والمتصفح وreturn URI وstate وcallback. فتح المتصفح لا يثبت الوصول الصحيح، والبقاء native لا يثبت انخفاض الخطر. تجاهل fallback أو استخدام embedded webview يخالف السياسة.

تعدد التطبيقات يكرر قرار الثقة

يفرض المشروع تجربة متطابقة بين first-party apps. المسألة ليست ألواناً: تعدد أماكن إدخال الأسرار يدرب المستخدم على قبول مزيد من التقليد. وكل implementation يضيف parser وstorage وaccessibility وSDK وأخطاء.

يقلل common SDK التباين لكنه يصبح dependency مشتركة. version وsignature وrollout وemergency withdrawal تدخل control surface. يجب أن يغطي التطابق prompt وorigin cues وsecret handling وscreenshots وaccessibility وfallback وerrors وsession storage وredaction.

على AS ربط كل client وattestation policy بالentity وpublisher وchannel وbuilds وSDK وprofile وretirement. لا ترث app ضعيفة الثقة من العلامة وحدها.

code ليس النتيجة

authorization code وPKCE وDPoP وauth_session وstep-up وaccess token إحداثيات مختلفة. لا يثبت أي منها أن resource server سمح أو أن عملية لاحقة اكتملت. قد تفشل معاملة أو تُعكس، وقد لا تُثبت credential بعد إصدارها. يأتي outcome receipt بعد OAuth.