Oauthlib: क्लाइंट वेब एप्लिकेशन अब क्लाइंट_आईडी नहीं भेजता है

मेरी पहली सोच prepare_request_body में परिवर्तनों को वापस करना है, डिफ़ॉल्ट रूप से, WebApplicationClient कंस्ट्रक्टर में self.client_id सेट का उपयोग करें।
फिर, &client_id=xx को prepare_request_body आउटपुट में जोड़ने के लिए इनलाइन डॉक्स को पर्याप्त रूप से बदला जाना चाहिए।

अंत में, मूल सुधार को बदलने के लिए, मैं args से client_id को हटाने का सुझाव दूंगा, और prepare_request_body एक नया तर्क जोड़ूंगा जैसे include_client=True/False दोनों को जोड़ने के लिए client_id शरीर में client_secret , या उन दोनों को शामिल न करें।

विचार?

प्रहार @Diaoul @skion @thedrow

व्हाट अबाउट:

मैं args से client_id को हटाने का सुझाव दूंगा, और तैयार करने के लिए एक नया तर्क जोड़ूंगा जैसे कि include_client=True/False दोनों में client_id और client_secret जोड़ें, या उन दोनों को शामिल न करें।

धन्यवाद

मैंने वास्तव में अपने परीक्षणों में से एक में इसी मुद्दे को ट्रिगर किया, लेकिन इसे यहां अनुरोधों/oauthlib के खिलाफ दायर किया: https://github.com/requests/requests-oauthlib/issues/330

मेरा मानना ​​है कि समस्या वास्तव में request_oauthlib की गलती है। जब आप पृष्ठ लोड करते हैं तो उनके दस्तावेज़ - वास्तव में उनके पूरे दस्तावेज़ों में पहला उदाहरण - OAuth2Session कन्स्ट्रक्टर में client_id निर्दिष्ट करने का समर्थन। लाइन 200 पर तर्क kwargs से client_id खींचता है, लेकिन इसे पहले से निर्मित WebApplicationClient इंस्टेंस से खींचने के लिए फॉलबैक नहीं है।

@jvanasco , मौजूदा अंक #585 को केवल request-oauthlib में, या oauthlib के PR #505 को वापस करके ठीक किया जा सकता है। हालांकि, कोई भी समाधान https://github.com/oauthlib/oauthlib/pull/505#issuecomment -351221107 पर अपनी टिप्पणी में @skion द्वारा उल्लिखित व्यवहार को ठीक नहीं करेगा।

कल्पना के अनुसार, क्लाइंट_आईडी पैरामीटर को अनधिकृत ग्राहकों के लिए भेजा जाना चाहिए, लेकिन गोपनीय ग्राहकों के लिए टोकन अनुरोध निकाय में अधिमानतः नहीं भेजा जाता है, क्योंकि उस स्थिति में क्लाइंट को प्रमाणित करने के लिए पसंदीदा तंत्र HTTP बेसिक ऑथ के माध्यम से होता है। हालाँकि, WebApplication वर्ग में हमेशा इसे शामिल किया जाता है (जो कुछ सर्वरों को तोड़ता है) साथ ही इसे हटाने के लिए कोई तंत्र प्रदान नहीं करता है।

Oauthlib को अनुरोधों के लिए एक सुंदर और सरल तरीका प्रदान करना चाहिए-oauthlib समस्या को हल करने के लिए। यदि हम इस चर्चा में कोई समाधान ढूंढ सकें तो यह बहुत अच्छा होगा; क्योंकि यह एक बहुत बड़ा अवरोधक है।

क्या client_id=False को prepare_request_body() में यह इंगित करने में मदद करेगा कि कोई client_id नहीं भेजा जाना है? हालांकि अगर ऐसा है, तो यह इस कुरूपता को लाइन 126 के पास ले जाएगा:

client_id = None if client_id=False else self.client_id

ओह समझा।

क्या क्लाइंट_आईडी को बनाम नहीं भेजा जाना चाहिए, इसके लिए कोई मौजूदा यूनिट-टेस्ट है? यदि नहीं, तो क्या किसी के पास एक सूची है जिसका उपयोग एक बनाने के लिए किया जा सकता है? मुझे इसे ठीक करने में खुशी होगी और अनुरोध-oauthlib, क्योंकि यह अभी मेरे कुछ काम को रोक रहा है।

@JonathanHuot

मैं args से client_id को हटाने का सुझाव दूंगा, और तैयार करने के लिए एक नया तर्क जोड़ूंगा जैसे कि include_client=True/False दोनों में client_id और client_secret जोड़ें, या उन दोनों को शामिल न करें।

इसे वापस पढ़कर, मुझे वास्तव में आपका सुझाव बहुत अच्छा लगा। हम शायद इसे गैर-ब्रेकिंग तरीके से करने से दूर हो सकते हैं, क्योंकि फ़ंक्शन पहले से ही **kwargs लेता है।

एक नोट:

क्लाइंट_आईडी और क्लाइंट_सेक्रेट दोनों को शरीर में जोड़ने के लिए

चूंकि यह सार्वजनिक ग्राहकों IIUC के बारे में है, मुझे नहीं लगता कि इसमें client_secret शामिल है; यह सिर्फ client_id को शरीर में जोड़ा जा रहा है? उस स्थिति में मैं नए पैरामीटर का नाम बदलकर include_client_id=True/False करने पर भी विचार करूंगा।

उस स्थिति में मैं नए पैरामीटर का नाम बदलकर include_client_id=True/False करने पर भी विचार करूंगा।

वास्तव में ! client_secret शामिल नहीं है क्योंकि यह WebApplicationClient में मौजूद नहीं है।

@jvanasco , अगर आप पीआर करना चाहते हैं तो मुझे लगता है कि बदलाव होना चाहिए:
१) https://github.com/oauthlib/oauthlib/pull/505 . को वापस लाएं
2) के हस्ताक्षर बदलें prepare_request_body() दूर करने के लिए client_id और जोड़ने include_client_id=True/False ( True (डिफ़ॉल्ट): यह कहते हैं self.client_id )

फिर, request-oauthlib के पास https://github.com/requests/requests-oauthlib/blob/master/requests_oauthlib/oauth2_session.py#L196-L211 में से किसी एक में विकल्प होगा:
ए) शरीर में अकेले client_id शामिल करें

self._client.prepare_request_body(..)

बी) client_id और client_secret को auth में शामिल करें और उन्हें बॉडी में शामिल न करें (आरएफसी पसंदीदा समाधान)

self._client.prepare_request_body(include_client_id=False, ..)
auth = requests.auth.HTTPBasicAuth(client_id, client_secret)

सी) शरीर में client_id और client_secret (आरएफसी वैकल्पिक समाधान)

self._client.prepare_request_body(client_secret=client_secret, ..)

मैं आज दोनों परियोजनाओं के लिए जनसंपर्क उत्पन्न करूंगा।

मेरे पास OAuthlib के लिए काफी पीआर और परीक्षण किए गए हैं। हालांकि हमारे पास एक सवाल है...

क्या client_id अभी भी क्वार्ग के रूप में अनुमति दी जानी चाहिए? यह पश्चगामी संगतता के लिए है, लेकिन किनारे के मामलों के लिए भी है। चूंकि यह विधि कुछ हद तक टूट गई थी, मुझे लगता है कि यह या तो इसे इरादे से काम करने के लायक हो सकता है (जैसा कि इसे prepare_request_body में self.client_id को ओवरराइड करने की इजाजत देने में) या गलत उपयोग पर अपवाद बढ़ाने के लिए (जैसा कि बढ़ाने में है) एक त्रुटि अगर client_id प्रदान की जाती है लेकिन self.client_id मेल नहीं खाती)।

यह नहीं देख पाएंगे कि आप किसी भिन्न मान के साथ कभी भी client_id को कैसे ओवरराइड करना चाहते हैं,

क्या हमें, इसके अलावा, एक DeprecationWarning लॉग करना चाहिए यदि client_id एक kwarg के रूप में प्रदान किया गया था?

पीआर #593 सबमिट किया गया। जब client_id सबमिट किया जाता है तो यह एक बहिष्करण चेतावनी उठाता है, और एक ValueError अगर यह self.client_id से भिन्न होता है। एक नया परीक्षण भी है जो विस्तृत रूप से @JonathanHuot के तीन परिदृश्यों का अनुपालन सुनिश्चित करता है।

अनुरोधों के साथ मेरी पहली समस्या में भाग गया- oauthlib पीआर उम्मीदवार जैसा कि मैं कुछ परीक्षण लिखता हूं

यह हमेशा prepare_request_body साथ username=username, password=password आह्वान करता है। यह गलत लगता है। मुझे आशा है कि यहां कोई व्यक्ति आरएफसी से अधिक परिचित है और निम्नलिखित के उत्तर जानता है:

1. क्या username + password कभी भी request.body में एक परम होना चाहिए?
2. यदि username + password HTTP बेसिक ऑथेंट हेडर में दिखाई देते हैं, तो क्या उन्हें अनुरोध बॉडी में डुप्लिकेट किया जाना चाहिए?
3. क्या क्लाइंट विवरण के साथ username + password बॉडी पैराम्स और HTTPBasicAuth हेडर दोनों होना संभव है?

इसमें भाग लेने के लिए धन्यवाद।

1. username और password हर बार अनुरोध के शरीर में मौजूद होना चाहिए। उनका उपयोग केवल पासवर्ड अनुदान उर्फ ​​विरासत के लिए किया जाना चाहिए। उनका उपयोग अन्य अनुदानों (अंतर्निहित, कोड, क्लाइंट क्रेडेंशियल) के लिए नहीं किया जाना चाहिए।
2. क्लाइंट क्रेडेंशियल के लिए HTTP बेसिक ऑथ वैकल्पिक है (गोपनीय ग्राहकों के लिए अनुशंसित यानी client_secret )। उपयोगकर्ता क्रेडेंशियल कभी भी HTTP बेसिक ऑथेंटिकेशन में
3. हां

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

1. उपयोगकर्ता नाम और पासवर्ड का उपयोग केवल एक निश्चित प्रकार के अनुदान में किया जाता है जिसके लिए उनकी आवश्यकता होती है। यदि उपयोग किया जाता है तो वे केवल अनुरोध निकाय में उपस्थित हो सकते हैं।

जब तक उन्हें स्पष्ट रूप से निर्दिष्ट नहीं किया जाता है, उन्हें उपस्थित नहीं होना चाहिए, है ना?

1. यदि एचटीपी मूल प्रमाणीकरण केवल क्लाइंट प्रमाण-पत्रों के लिए है, तो मौजूदा अनुरोध-ओथलिब में ब्लॉक नहीं होना चाहिए जो उपयोगकर्ता नाम और पासवर्ड कॉम्बो से मूल प्रमाणीकरण उत्पन्न करता है।

कृपया मुझे इन छोटे विवरणों पर क्रियात्मक और जुनूनी होने के लिए क्षमा करें। मैं सिर्फ यह सुनिश्चित करना चाहता हूं कि जे को सही व्यवहार मिले और परीक्षण लिख सकें जो सुनिश्चित करें कि हमें एक और प्रतिगमन नहीं मिलता है।

@jvanasco , मैं OAuth2 RFC के बारे में बता सकता हूं, हालांकि मुझे यकीन नहीं है कि requests-oauthlib और flask-oauthlib एक साथ कैसे फिट होते हैं।

1. हां

सही।

1. हाँ, AFAIU में यह ब्लॉक नहीं होना चाहिए https://github.com/requests/requests-oauthlib/blob/master/requests_oauthlib/oauth2_session.py#L207 -L211.

यह मेरी समझ है, हालांकि क्षेत्र की वास्तविकता से मेल खाना अच्छा होगा; यानी अनुरोध-oauthlib और सार्वजनिक प्रदाताओं के अनुभवों को अलग करता है। एकाधिक अनुरोध-oauthlib चर्चा https://github.com/requests/requests-oauthlib/issues/218 , https://github.com/requests/requests-oauthlib/issues/211 , https://github.com/requests /requests-oauthlib/issues/264 , पहले ही हो चुका है।

मेरा मानना ​​है कि उन्हें client password और client secret बीच एक भ्रम था जो वास्तव में एक ही चीज़ के लिए दो शब्द हैं।
अगर हम https://github.com/requests/requests-oauthlib/pull/206 के पीछे के तर्क का पालन करते हैं, तो पीआर की सामग्री कभी भी HTTPAuth(username, password) जोड़ने जैसी नहीं होनी चाहिए, लेकिन यह HTTPAuth(client_id, client_secret होनी चाहिए

पोक @Lukasa , @chaosct , @ibuchanan जिसने अनुरोधों में भाग लिया-oauthlib की चर्चा।

महान! बहुत - बहुत धन्यवाद। मैंने सोचा था कि क्या हो रहा था, लेकिन पुष्टि करना चाहता था।

मुझे लगता है कि मुझे पता है कि मैं अब अनुरोध सामग्री को कैसे व्यवस्थित करना चाहता हूं। मेरे पास मुख्य अनुरोध प्रोजेक्ट पर कुछ हद तक काम करता है, इसलिए मुझे पता है कि रखरखाव पीआर और कार्यक्षमता में क्या देखना पसंद करते हैं।

1. उपयोगकर्ता नाम और पासवर्ड का उपयोग केवल एक निश्चित प्रकार के अनुदान में किया जाता है जिसके लिए उनकी आवश्यकता होती है। यदि उपयोग किया जाता है तो वे केवल अनुरोध निकाय में उपस्थित हो सकते हैं।

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

अनुरोध-निकाय में क्लाइंट क्रेडेंशियल सहित
दो मापदंडों का उपयोग करना अनुशंसित नहीं है
और सीधे उपयोग करने में असमर्थ ग्राहकों तक सीमित होना चाहिए
HTTP मूल प्रमाणीकरण योजना...

लेकिन सर्वर के लिए, यह पढ़ता है:

प्राधिकरण सर्वर सहित समर्थन कर सकता है
अनुरोध-निकाय में क्लाइंट क्रेडेंशियल ...

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

मेरा मानना ​​है कि @JonathanHuot दूसरे बिंदु के बारे में सही है।

हाय @ibuchanan , जिन उद्धरणों का आप उल्लेख कर रहे हैं, वे client credentials शब्द का उपयोग कर रहे हैं। हमें क्लाइंट को संसाधन स्वामी (वास्तविक उपयोगकर्ता) के साथ न मिलाने के लिए बहुत सावधान रहना होगा।

भूमिकाओं को यहां स्पष्ट रूप से समझाया गया है rfc6749#1.1 ।
यह client credentials client_id और client_secret को संदर्भित करता है और संसाधन स्वामी username और password को संदर्भित कर रहा है। वे विनिमेय नहीं हैं।

इसलिए, उन भूमिकाओं के साथ RFC को पढ़ने का मतलब है कि एक आज्ञाकारी ग्राहक को HTTP बेसिक में क्लाइंट क्रेडेंशियल ( client_id , client_secret ) भेजना चाहिए और उपयोगकर्ता क्रेडेंशियल ( username , password ) भेजना चाहिए। rfc6749#4.3.2 ।

कुछ सर्वर अनुरोध को अस्वीकार करते हैं (400) यदि क्लाइंट_आईडी अनुरोध में है
तन। मुझे लगता है कि डिफ़ॉल्ट वही होना चाहिए जो युक्ति द्वारा अनुशंसित है।

ठीक। मुझे लगता है कि oauthlib लिए वर्तमान पीआर उपरोक्त चिंताओं को संतुष्ट करता है - include_client_id ध्वज स्पष्ट रूप से client_id को भेजने की अनुमति देता है या नहीं।

requests_oauthlib संदर्भ में, मैं यही सोच रहा हूं:

1. username और password केवल बॉडी में दिखाई देंगे (HTTP बेसिक के रूप में नहीं)। यदि गैर-अनुपालक सर्वर एकीकरण के लिए उस व्यवहार की आवश्यकता है, तो कार्यान्वयनकर्ता auth या headers तर्क को fetch_token() सबमिट कर सकता है।

2. सही जगह पर client_id की आपूर्ति करना थोड़ा कष्टप्रद है, लेकिन मुझे लगता है कि मेरे पास तर्क और उपयोग के मामले नीचे हैं। इसके लिए निश्चित रूप से कुछ समीक्षा की आवश्यकता होगी।

मेरे पास @JonathanHuot और @ibuchanan के लिए एक प्रश्न है:

oauthlib के OAuth2 Client और requests_oauthlib के OAuth2Session में client_secret और बार-बार इसका आह्वान करना चाहिए। OAuth1 में ऐसा नहीं था, और मुझे लगता है कि #370 के पीछे यही वास्तविक मुद्दा था। RFC ने इसकी आवश्यकता का उल्लेख नहीं किया, और मुझे कोई इतिहास नहीं मिला।

मेरे लिए, client_secret को स्टोर करने के साथ क्लाइंट का विस्तार करना समझ में आता है, और client_secret में fetch_token और request पर जाने पर OAuth2Session निर्भरता को कम करना शुरू करें

मैंने उपयोगकर्ता नाम/पासवर्ड और client_id/client_secret के परीक्षण चरों को मानकीकृत करने के लिए oauthlib (#593) के लिए पीआर को थोड़ा बदल दिया है। मुझे लगता है कि भविष्य में दोनों के बीच भ्रम की स्थिति से गलतियों को रोकना चाहिए।

अनुरोध-oauthlib के लिए प्रस्तावित परिवर्तन: https://github.com/requests/requests-oauthlib/compare/master...jvanasco:fix-oauthlib_client_id

यह थोड़ा अधिक कठोर है, क्योंकि कोड और परीक्षणों को देखते हुए, ऐसा लगता है कि पुस्तकालय सभी प्रकार की चीजों को काम करने की कोशिश कर रहा था जो नहीं करना चाहिए।

फिक्स कुछ चीजें करता है:

1. username और password केवल LegacyApplicationClient उदाहरणों के लिए होती है - क्योंकि यह एकमात्र प्रकार की आवश्यकता होनी चाहिए (सही?)। चेक के नीचे एक सेक्शन होता है जो यूजरनेम/पासवर्ड को kwargs dict में मिला देता है। यह वर्तमान में पुराना है, क्योंकि परीक्षण से पता चलता है कि अन्य ग्राहक इस जानकारी को पास करना चाहते हैं।

2. क्लाइंट_आईडी/ऑथ हेडर को संभालने के लिए तर्क को फिर से लिखा गया था ताकि यह सुनिश्चित हो सके कि सही प्रकार के ऑथ डिफ़ॉल्ट रूप से सही जगह पर हों। यदि कोई उपयोगकर्ता किसी अन्य तरीके से क्रेडेंशियल को बाध्य करना चाहता है, तो यह अभी भी संभव है।

3. प्रश्न: क्या ऐसी कोई स्थिति है जहां client_secret पारित नहीं किया जाएगा? मैं किसी के बारे में नहीं सोच सकता, लेकिन कई oAuth प्रवाह हैं।

तो अनुरोध-oauthlib संस्करण में:

| include_client_id | auth | व्यवहार |
| ------------------- | --------------- | -------- |
| कोई नहीं (डिफ़ॉल्ट) | कोई नहीं (डिफ़ॉल्ट) | client_id साथ एक प्रामाणिक वस्तु बनाएं। क्लाइंट_आईडी को मुख्य भाग में न भेजें। यह डिफ़ॉल्ट व्यवहार है, क्योंकि RFC इसकी अनुशंसा करता है। |
| कोई नहीं (डिफ़ॉल्ट) | वर्तमान | प्रामाणिक वस्तु का उपयोग करें। oauthlib के prepare_request_body साथ include_client_id=False |
| झूठा | वर्तमान | प्रामाणिक वस्तु का उपयोग करें। oauthlib के prepare_request_body साथ include_client_id=False |
| सच | वर्तमान | प्रामाणिक वस्तु का उपयोग करें। oauthlib के prepare_request_body साथ include_client_id=True |
| सच | कोई नहीं (डिफ़ॉल्ट) | client_id साथ एक प्रामाणिक वस्तु बनाएं। oauthlib के prepare_request_body साथ include_client_id=True |
| झूठा | कोई नहीं (डिफ़ॉल्ट) | client_id साथ एक प्रामाणिक वस्तु बनाएं। oauthlib के prepare_request_body साथ include_client_id=False |

या अन्यथा कहा गया है:

• एक प्रामाणिक वस्तु बनाएँ
  
  
  
  • क्लाइंट आईडी को मुख्य भाग में न भेजें:
  
  
  • (include_client_id=कोई नहीं, प्रमाणन=कोई नहीं)
  
  
  • (include_client_id=false, auth=कोई नहीं)
  
  
  • शरीर में क्लाइंट आईडी भेजें:
  
  
  • (include_client_id=True, auth=कोई नहीं)
  
  
• एक स्पष्ट ऑथ ऑब्जेक्ट का उपयोग करें
  
  
  
  • क्लाइंट_आईडी को मुख्य भाग में न भेजें:
  
  
  • (include_client_id=कोई नहीं, auth=authObject)
  
  
  • (include_client_id=false, auth=authObject)
  
  
  • क्लाइंट_आईडी को शरीर में भेजें:
  
  
  • (include_client_id=True, auth=authObject)
  
  

@jvanasco : oauthlib और अनुरोध-oauthlib पक्ष पर बहुत अच्छा लग रहा है।

आपके बारे में 3. प्रश्न:

आपके पास क्लाइंट_सेक्रेट के बिना सार्वजनिक क्लाइंट हो सकते हैं (या खाली, जो आरएफसी के दृष्टिकोण के करीब है); इसलिए अजगर एपीआई को "कोई रहस्य नहीं" का समर्थन करना चाहिए।

वास्तविक दुनिया का उपयोग-मामला अक्सर मूल अनुप्रयोगों के लिए होता है जहां आप प्राधिकरण कोड का उपयोग करना पसंद करते हैं, लेकिन आप गुप्त को सुरक्षित रखने के आसपास सुरक्षा की गारंटी नहीं दे सकते हैं, इसलिए, या तो आप client_id स्वीकार करते हैं जिसमें कोई client_secret (या खाली client_secret जो RFC के लिए समान हैं); या आपके पास एक और PKCE RFC भी उपलब्ध है (देखें https://oauth.net/2/pkce/ )। लेकिन बाद वाले को अभी तक oauthlib पक्ष पर लागू नहीं किया गया है।

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

@JonathanHuot मौजूदा कार्यान्वयन client_secret लिए एक खाली स्ट्रिंग भेजने का समर्थन नहीं करता है। इसे इस तर्क में हटा दिया गया है https://github.com/oauthlib/oauthlib/blob/master/oauthlib/oauth2/rfc6749/parameters.py#L90 -L125 - विशेष रूप से लाइन 122

इसका समर्थन करना उस दिनचर्या के ठीक बाद कुछ इस तरह जोड़ना हो सकता है:

if ('client_secret' in kwargs) and ('client_secret' not in params):
    if kwargs['client_secret'] == '':
        params.append((unicode_type('client_secret'), kwargs['client_secret']))

वह client_secret लिए एक खाली स्ट्रिंग भेजेगा जब रहस्य एक खाली स्ट्रिंग है, लेकिन client_secret नहीं भेजें यदि मान None ।

मुझे लगता है कि यह इसका समर्थन करने लायक है, क्योंकि अगर आरएफसी दो प्रकारों में से किसी एक का समर्थन करता है ... ऐसे कई टूटे हुए कार्यान्वयन होने की संभावना है जो केवल एक संस्करण का समर्थन करते हैं।

यह मूल समस्या oauthlib में ठीक की गई है। हालांकि https://github.com/requests/requests-oauthlib/pull/331 तय होने तक व्यवहार अभी भी वहीं है।