ट्विटर एपीआई का उपयोग करते समय, मैं oauth_signature पर आया जो मूल रूप से हैश (अनुरोध निकाय + अनुरोध पैरामीटर + nonces/timestamps + consumer_secret) का हैश है। consumer_secret केवल अनुरोध भेजने वाले एप्लिकेशन के लिए जाना जाता है।एसएसएल व्हील reinventing oauth_signature नहीं है?
ट्विटर के मामले में:
- सभी संचार SSL पर होना चाहिए।
- ट्विटर प्रत्येक अधिकृत एप्लिकेशन में
consumer_secretको समस्या देता है।
के बाद से oauth_signature का प्राथमिक उपयोग MITMs (यानी कोई स्तन (पारगमन में छेड़छाड़) :) रोकने के लिए है, मुझे लगता है कि इस विशेष उपयोग के मामले म्युचुअल SSL के माध्यम से हल किया जा सकता
- ट्विटर,
consumer_secretजारी करने के बजाय, प्रत्येक एप्लिकेशन के लिए SSL प्रमाणपत्र जारी कर सकता है।
हालांकि क्लाइंट एसएसएल-सर्टिफिकेट्स का यह विचार 1 99 0 के इंटरनेट आर्काना जैसा प्रतीत हो सकता है, यह क्लाइंट प्रमाण पत्र के लिए ट्रस्ट की श्रृंखला को सत्यापित करने में परेशानी के कारण काफी हद तक सफल नहीं था। यह समस्या यहां उत्पन्न नहीं होती है क्योंकि ट्विटर प्रमाण पत्र का एकमात्र जारीकर्ता और सत्यापनकर्ता होगा। प्रारंभिक एप्लिकेशन/क्लाइंट एसएसएल प्रमाण पत्र तैयार करने के लिए ट्विटर की ओर से दोष अधिक प्रयास शामिल होगा, लेकिन भुगतान आरईएसटी एपीआई की सादगी में होगा, जो कि गारंटी देता है कि ग्राहक वह कहता है कि वह कौन है।
ध्यान दें कि ट्विटर इस मामले में सिर्फ एक उदाहरण है। AFAIK, अधिकांश अन्य औथ कार्यान्वयनकर्ता एक समान रणनीति का उपयोग करते हैं, और यहां दिए गए मुद्दे किसी भी बड़े पैमाने पर OAuth कार्यान्वयन पर लागू होते हैं जो पहले से ही SSL को अनिवार्य करता है।
मुझे यहां क्या याद आ रही है? इंटरनेट जड़ता?
आप सवाल खो रहे हैं। मैं यह नहीं कह रहा हूं कि आपसी-SSL-certs समस्या को हल करेंगे जो OAuth हल करता है। मैं कह रहा हूं कि 'oauth_signature' तंत्र मूल रूप से दो तरह के प्रमाणीकरण को पुन: पेश कर रहा है जो पारस्परिक-SSL-certs पहले से ही प्रदान करता है। – Manav
लेकिन पारस्परिक एसएसएल कर्ट केवल आधे समस्या (एप्लिकेशन टोकन पक्ष) को हल करते हैं और उपभोक्ता टोकन पक्ष के लिए कुछ भी नहीं करते हैं। और यदि आप OAuth 2.0 को देखते हैं, तो वे उस दिशा में चले गए हैं। –