Oauthlib: يجب إرسال Client_secret و code_verifier (PKCE) بشكل آمن

مرحبًا polamayster ، أنت محق تمامًا.

أقوم بإضافة أقسام RFC التي تحدد كيفية تنفيذها:

قسم OAuth2.0 RFC:

https://tools.ietf.org/html/rfc6749#section -2.3.1

2.3.1.  Client Password
   Clients in possession of a client password
   MAY use the HTTP Basic authentication scheme (..) 

   Alternatively, the authorization server
   MAY support including the client credentials in the request-body (..)

   The parameters can only be transmitted in the request-body and
   MUST NOT be included in the request URI.

قسم PKCE RFC:

https://tools.ietf.org/html/rfc7636#section -4.5

4.5.  Client Sends the Authorization Code and the Code Verifier to the
      Token Endpoint
    In addition to the parameters defined in the OAuth 2.0 Access
    Token Request (Section 4.1.3 of [RFC6749]), it sends the following parameter:

   code_verifier
      REQUIRED.  Code verifier

https://tools.ietf.org/html/rfc6749#section -4.1.3

4.1.3.  Access Token Request

   The client makes a request to the token endpoint by sending the
   following parameters (..) in the HTTP request entity-body:

لذلك ليس لدي شك في مدى ملاءمة هذه القضية. نرحب بأي علاقات عامة!

أنا مهتم بالحصول على هذا. سوف يقدم طلب سحب قريبا.

هل يجب فرض هذا السلوك فقط للطلبات التي تتوقع بيانات اعتماد أو أي طلب بشكل عام؟

إلى بلدي فهم oauthlib.common.Request الدرجة ديه __getattr__ طريقة و _params القاموس (المحدثة من سلسلة الاستعلام والمعلمات الجسم) وأي طلب أن يحاول الوصول / الحصول على client_secret يجب أن يبحث code_verifier فقط في النص الأساسي و / أو الرؤوس (ربما يكون وجود خاصية منفصلة للبحث عن البيانات الحساسة أمرًا منطقيًا)

أرى ، سأقوم بتقديم العلاقات العامة لذلك اليوم

في السبت ، 20 أبريل 2019 ، 12:38 مساءً كتب بوهدان < [email protected] :

على حد علمي ، فإن oauthlib.common.Request فئة لديها __getattr__
الأسلوب وقاموس _params (محدث من سلسلة الاستعلام والجسم
المعلمات) وأي طلب يحاول الوصول / الحصول على client_secret أو
يجب أن يبحث code_verifier فقط في النص الأساسي و / أو الرؤوس (ربما يحتوي على
خاصية منفصلة للبحث عن البيانات الحساسة ستكون منطقية)

-
أنت تتلقى هذا لأنك علقت.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/oauthlib/oauthlib/issues/666#issuecomment-485157051 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/ABKEVQNFJUFGDB5X24JBOJDPRNWKBANCNFSM4HHD7NNQ
.

إلى بلدي فهم oauthlib.common.Request الدرجة ديه __getattr__ طريقة و _params القاموس (المحدثة من سلسلة الاستعلام والمعلمات الجسم) وأي طلب أن يحاول الوصول / الحصول على client_secret يجب أن يبحث code_verifier فقط في النص الأساسي و / أو الرؤوس (ربما يكون وجود خاصية منفصلة للبحث عن البيانات الحساسة أمرًا منطقيًا)

لذا يجب أن تتم عمليات التحقق في وقت وصول السمة بدلاً من وقت تعيين عنوان url؟ إذا تم تعيين سمات الطلب مرة واحدة فقط عند التهيئة ، فيمكننا إجراء عمليات التحقق في ذلك الوقت بدلاً من الوصول إلى كل سمة. يُرجى إعلامي إذا كنت تعتقد أنه يجب علينا الاستمرار في إجراء عمليات التحقق عند وصول كل سمة.

أدرك أن هذه المشكلة أكبر وتنطبق على نقطة النهاية /token بأكملها. يجب ألا تقبل نقطة النهاية هذه أي معلمات في عنوان URL. لا يجب السماح بذلك.

أعتقد أن نقطة نهاية الاستبطان مؤهلة أيضًا. IIRC ، بحسب
مواصفات HTTP ، يجب أن تتجاهل طلبات POST دائمًا معامِلات الاستعلام. لو
نحن نفرض ذلك ، ونحل جميع المشكلات تلقائيًا دون التأثير
حالات استخدام صالحة. لست متأكدًا من كيفية تصرف أفعال HTTP الأخرى
لكنني متأكد تمامًا من POST one. يمكن لأي شخص أن يؤكد ما إذا كان هذا هو الصحيح
الاتجاه للذهاب نحو؟

>

إن رفض جميع معلمات الاستعلام لجميع POST هو اختصار جميل وجذاب! ومع ذلك ، فإنني قلق بشأن ResourceEndpoint الخاص بـ oauthlib وحقيقة أن بعض المستخدمين لا يزال بإمكانهم إضافة وسيطات استعلام إلى عنوان URL (على الرغم من عدم التوصية بذلك ، إلا أنه لا يزال من الممكن تقنيًا).

هل يمكنك توضيح مخاوفك أكثر بقليل من نقطة نهاية الموارد؟

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

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

أو ربما يمكننا إنشاء خلاط أو ديكور يرتفع عند تطبيقه
أخطاء لطلبات POST مع معلمات الاستعلام.

إليك حل آخر ممكن لها. لنقاط النهاية ( AuthorizationEndpoint ، IntrospectEndpoint ، RevocationEndpoint )؛ إذا كانت طريقة الطلب هي POST يمكننا إضافة التحقق من معلمات الاستعلام في طرق التحقق من صحة الطلب الخاصة بهم. بالنسبة إلى ( TokenEndpoint ، MetadataEndpoint ) يمكننا إضافة الشيك في طرق توليد الاستجابة.
أو يمكننا إضافة آلية التحقق داخل طريقة توليد الاستجابة لكل منهم ، من أجل الاتساق. هل هذا الصوت مثل فكرة جيدة؟

أعتقد أنه من الأفضل استخدام طرق التحقق من _request_.
مع العلم أن POST مخصص فقط لـ TokenEndpoint و IntrospectEndpoint و RevocationEndpoint . البعض الآخر هو GET : AuthorizationEndpoint ، MetadataEndpoint .

تعليق عام على الرغم من ذلك: هل يجب أن نركز على المجالات الحساسة (مثل الاحتفاظ بقائمة سوداء) أم يجب علينا رفض جميع معلمات OAuth2 (نريد أن يكون NONE في URI الاستعلام ، أليس كذلك؟)

من الناحية المثالية ، لا أريد NONE في Query URI. ذهبت للقائمة السوداء لأنني لم أكن كذلك
متأكد مما إذا كنت قد كسرت بعض حالات الاستخدام الحالية. لا يقتصر الأمر على عدم وجود OAuth2
المعلمات مسموح بها ، ولكن لا يُسمح بأي معلمات طلب بحث على الإطلاق.

>

إذا قمت بنقل الشيكات من الطلب إلى نقاط النهاية ، فلا أرى أي مشاكل في تعطيل جميع معلمات الاستعلام لنقاط النهاية هذه!

حسنًا ، سأقوم بتعطيل جميع معلمات الاستعلام على نقاط النهاية الدقيقة هذه. و
نحن أيضًا نقصر طريقة http على POST ، أليس كذلك؟

ثابت في https://github.com/oauthlib/oauthlib/pull/667

على الرغم من أنني أتفهم سبب هذا التغيير ، يبدو أن هذا تغيير فاصل للعملاء الذين يرسلون client_secret كمعامل استعلام. كنت أتوقع التوافق مع الإصدارات السابقة أو نتوء إصدار رئيسي. هل هذا السلوك مقصود؟

نحن نستخدم حاليًا مجموعة أدوات django-oauth ويقوم العملاء بإرسال username و password و client_secret و client_id و grant_type كاستعلام معامل. إذا قاموا بالتبديل إلى إرسال كل شيء كمعامل POST ، فسيحصلون على الخطأ unsupported_grant_type .

يعتبر دعم الاستعلام لـ POST من الآثار الجانبية أكثر من السلوك المطلوب. أتفهم أنه يكسر عميلك ، لذلك أقترح تحديده إلى <3.1
أيضًا ، يُرجى التفكير في الترقية في أسرع وقت ممكن نظرًا لأنها تنطوي على مخاوف أمنية (يتم عرض السر في السجلات ، بالوكالة ، عبر مواقع متعددة غير مقصودة).