Oauthlib: Client_secret और code_verifier (PKCE) को सुरक्षित रूप से प्रेषित किया जाना चाहिए

हाय @polamayster , आप बिल्कुल सही कह रहे हैं।

मैं आरएफसी के अनुभागों को जोड़ रहा हूं जो निर्दिष्ट करता है कि इसे कैसे कार्यान्वित किया जाना है:

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.

पीकेसीई आरएफसी की धारा:

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 बजे बोहदान < नोटिफिकेशन @github.com ने लिखा:

मेरी समझ से oauthlib.common.Request वर्ग में एक __getattr__ है
विधि और _params शब्दकोश (क्वेरी स्ट्रिंग और बॉडी से अपडेट किया गया
पैरामीटर) और कोई भी अनुरोध जो क्लाइंट_सेक्रेट या . तक पहुंचने/प्राप्त करने का प्रयास करता है
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 को केवल बॉडी और/या हेडर में देखना चाहिए (शायद संवेदनशील डेटा लुकअप के लिए अलग प्रॉपर्टी होने से कोई मतलब होगा)

तो जब यूआरएल सेट किया जाता है तो चेक विशेषता पहुंच समय पर होना चाहिए? यदि अनुरोध विशेषताएँ आरंभीकरण के समय केवल एक बार सेट की जाती हैं, तो हम प्रत्येक विशेषता पहुँच के बजाय सही जाँच कर सकते हैं। मुझे बताएं कि क्या आपको लगता है कि हमें अभी भी प्रत्येक विशेषता पहुंच पर जांच करनी चाहिए।

मुझे एहसास है कि यह मुद्दा बड़ा है और पूरे /token समापन बिंदु पर लागू होता है। इस समापन बिंदु को URL में किसी भी पैरामीटर को स्वीकार नहीं करना चाहिए। इसकी अनुमति नहीं दी जानी चाहिए।

मुझे लगता है कि आत्मनिरीक्षण समापन बिंदु भी योग्य है। आईआईआरसी, के अनुसार
HTTP विनिर्देश, POST अनुरोधों को हमेशा क्वेरी पैरामीटर को अनदेखा करना चाहिए। अगर
हम इसे लागू करते हैं, हम प्रभावित किए बिना सभी समस्याओं को स्वचालित रूप से हल करते हैं
वैध उपयोग के मामले। मुझे यकीन नहीं है कि अन्य HTTP क्रियाओं को कैसे व्यवहार करना चाहिए
लेकिन मुझे POST वन पर पूरा यकीन है। क्या कोई पुष्टि कर सकता है कि क्या यह सही है
दिशा की ओर जाना है?

>

सभी पोस्ट के लिए सभी क्वेरी पैरामीटर को अस्वीकार करना एक अच्छा शॉर्टकट है जो आकर्षक है! हालांकि मैं oauthlib के ResourceEndpoint और इस तथ्य के बारे में चिंतित हूं कि कुछ उपयोगकर्ता अभी भी URL में क्वेरी तर्क जोड़ सकते हैं (इसके बावजूद इसकी अनुशंसा नहीं की जाती है, यह तकनीकी रूप से अभी भी संभव है)।

क्या आप संसाधन समापन बिंदु के साथ अपनी चिंताओं पर थोड़ा और विस्तार कर सकते हैं?

जिस तरह से मैं इसे देखता हूं, पोस्ट अनुरोध या तो फॉर्म सबमिशन या एपीआई के माध्यम से किए जाते हैं
कॉल (स्पष्ट कोड लिखना)। मैं नहीं देखता कि कोई आंशिक क्यों जोड़ेगा
क्वेरी पैरामीटर के रूप में डेटा और पोस्ट डेटा के रूप में आंशिक। वास्तव में, यह आसान है
या तो पूरी तरह से प्रतिबद्ध।
वास्तव में यदि आप अनुरोध करने के लिए पुस्तकालय का उपयोग कर रहे हैं, तो यह कहीं अधिक आसान है
चीजों को विभाजित करने के बजाय पोस्ट बॉडी के रूप में सब कुछ जोड़ें।

व्याख्यात्मक त्रुटि के साथ प्रस्तुत किए जाने पर POST में क्वेरी पैराम जोड़ने वाले उपयोगकर्ता,
जल्दी से स्वयं को ठीक करने में सक्षम होना चाहिए।

या हो सकता है कि हम एक मिक्सिन या डेकोरेटर बना सकते हैं, जिसे लागू करने पर, बढ़ जाएगा
क्वेरी पैरा के साथ POST अनुरोधों के लिए त्रुटियां।

यहां इसके लिए एक और संभावित समाधान है। अंतिम बिंदुओं के लिए ( AuthorizationEndpoint , IntrospectEndpoint , RevocationEndpoint ); यदि अनुरोध विधि POST तो हम क्वेरी पैरामीटर के लिए उनके संबंधित अनुरोध सत्यापन विधियों में चेक जोड़ सकते हैं। ( TokenEndpoint , MetadataEndpoint ) के लिए हम प्रतिक्रिया पीढ़ी के तरीकों में चेक जोड़ सकते हैं।
या हम निरंतरता के लिए, उन सभी की प्रतिक्रिया पीढ़ी विधि के अंदर जाँच तंत्र को जोड़ सकते हैं। क्या यह एक अच्छे विचार की तरह लगता है?

मुझे लगता है कि _request_ सत्यापन विधियों का उपयोग करना बेहतर है।
यह जानते हुए कि POST केवल TokenEndpoint , IntrospectEndpoint और RevocationEndpoint । अन्य हैं GET : AuthorizationEndpoint , MetadataEndpoint ।

हालांकि एक सामान्य टिप्पणी: क्या हमें संवेदनशील क्षेत्रों पर ध्यान केंद्रित करना चाहिए (उदाहरण के लिए एक ब्लैकलिस्ट बनाए रखना) या क्या हमें सभी OAuth2 मापदंडों से इनकार करना चाहिए (हम चाहते हैं कि कोई भी क्वेरी यूआरआई में न हो, है ना?)

आदर्श रूप से मुझे क्वेरी यूआरआई में कोई नहीं चाहिए। मैं काली सूची में डालने के लिए गया था क्योंकि मैं नहीं था
यकीन है कि अगर मैं कुछ मौजूदा उपयोग के मामलों को तोड़ रहा हूं। न केवल OAuth2 हैं
पैरामीटर की अनुमति है, लेकिन किसी भी क्वेरी पैरामीटर की अनुमति नहीं है।

>

यदि आप चेक को अनुरोध से अंतिम बिंदुओं पर ले जाते हैं, तो मुझे उन समापन बिंदुओं के लिए सभी क्वेरी पैरामीटर को अक्षम करने में कोई समस्या नहीं दिखाई देती है!

ठीक है, तो मैं उन सटीक समापन बिंदुओं पर सभी क्वेरी पैरा को अक्षम कर दूंगा। और
हम http विधि को POST तक सीमित कर रहे हैं, सही?

https://github.com/oauthlib/oauthlib/pull/667 . में फिक्स्ड

जबकि मैं इस परिवर्तन के तर्क को समझता हूं, यह उन ग्राहकों के लिए एक महत्वपूर्ण परिवर्तन प्रतीत होता है जो क्वेरी पैरामीटर के रूप में client_secret भेजते हैं। मुझे पश्चगामी संगतता या एक प्रमुख संस्करण टक्कर की उम्मीद होगी। क्या यह व्यवहार इरादा है?

वर्तमान में हम django-oauth-toolkit का उपयोग कर रहे हैं और क्लाइंट username , password , client_secret , client_id और grant_type को क्वेरी के रूप में भेज रहे हैं। पैरामीटर। यदि वे सब कुछ POST पैरामीटर के रूप में भेजने के लिए स्विच करते हैं, तो उन्हें त्रुटि मिलती है unsupported_grant_type ।

POST के लिए क्वेरी का समर्थन वांछित व्यवहार की तुलना में अधिक दुष्प्रभाव है। मैं समझता हूं कि यह आपके क्लाइंट को तोड़ देता है, इसलिए मैं <3.1 . को इंगित करने का सुझाव दूंगा
साथ ही, कृपया यथाशीघ्र अपग्रेड करने पर विचार करें क्योंकि इसमें सुरक्षा संबंधी चिंताएं शामिल हैं (गुप्त लॉग में, प्रॉक्सी में, कई अनपेक्षित स्थानों पर दिखाए जाते हैं)।