OAuth2 प्रवाह - क्या सर्वर प्रामाणिक सर्वर के साथ मान्य है?


10

मैं OAuth2 पर बहुत कुछ पढ़ रहा हूं, इसके चारों ओर अपना सिर लाने की कोशिश कर रहा हूं, लेकिन मैं अभी भी कुछ के बारे में उलझन में हूं।

मैं समझता हूं कि ग्राहक OAuth प्रदाता (उदाहरण के लिए Google) के साथ अधिकृत है और संसाधन सर्वर को उपयोगकर्ता के प्रोफ़ाइल डेटा तक पहुंचने की अनुमति देता है। तब क्लाइंट एक्सेस टोकन को रिसोर्स सर्वर पर भेज सकता है और संसाधन को वापस दिया जा सकता है।

लेकिन किसी भी दस्तावेज में ऐसा नहीं लगता है कि क्या होता है जब क्लाइंट ऐप किसी संसाधन के लिए संसाधन सर्वर से पूछता है और इसे एक्सेस टोकन पास करता है। मैंने अब तक जो कुछ भी पढ़ा है वह बताता है कि संसाधन सर्वर केवल अनुरोधित संसाधन के साथ प्रतिक्रिया करता है।

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

क्या कोई मुझे OAuth2 के स्पष्टीकरण का पालन करने के लिए एक सरल बिंदु पर बता सकता है क्योंकि अभी तक मैंने जो पढ़ा है वह अधूरा महसूस करता है।

जवाबों:


8

मिल गया। युक्ति में दफन। वे कहते हैं कि संसाधन सर्वर को ऑर्कुट सर्वर के साथ पहुँच को मान्य करना चाहिए लेकिन यह दस्तावेज़ के दायरे से बाहर है। अफ़सोस, मैंने सोचा होगा कि टोकन सत्यापन एक महत्वपूर्ण हिस्सा था।


1
महत्वपूर्ण भागों के बारे में , यह OAuth2 के लिए प्राथमिकताओं पर कुछ पृष्ठभूमि के लिए इस ब्लॉग पोस्ट को पढ़ने के लायक हो सकता है ।
लार्स विकलंड

1
उसके लिए धन्यवाद, एक दिलचस्प पढ़ा। मेरी आवश्यकताएं इतनी सरल हैं कि मैं एक iOS ऐप को Google, ट्विटर, फेसबुक, आदि के साथ प्रमाणित करने की अनुमति देना चाहता हूं, अपने सर्वर पर प्राधिकरण के कुछ फार्म पास करें और मेरे सर्वर को इसे मान्य करें और संसाधनों तक पहुंच सक्षम करें। समस्या यह समझने की जटिलताओं के कारण मुझे अनुमान से अधिक जटिल साबित हुई है कि यह कैसे काम करता है और मुझे क्या करना है।
drekka

अधिक सटीक रूप से, परिशिष्ट A: "अनुरोध पर हस्ताक्षर को मान्य करने के लिए, संरक्षित संसाधन उस टोकन के लिए आवश्यक महत्वपूर्ण जानकारी प्राप्त करने के लिए प्राधिकरण सर्वर के आत्मनिरीक्षण समापन बिंदु पर टोकन पहचानकर्ता को प्रस्तुत करने में सक्षम हो सकता है। इस उपयोग का विवरण बाहर हैं। इस विनिर्देश का दायरा और एक विस्तार [...] में परिभाषित किया जाएगा।
जुलिएनड

2

टोकन सत्यापन को आम तौर पर 2 में से 1 तरीके से नियंत्रित किया जाता है।

1) टोकन को पूर्व साझा कुंजी का उपयोग करके क्रिप्टोग्राफिक रूप से हस्ताक्षरित किया गया है। यह वितरित, प्रोलिफेरिंग सिस्टम में उपयोग के लिए स्पष्ट लघु चित्रण है।

2) प्राधिकरण सर्वर (AS) टोकन सत्यापन या आत्मनिरीक्षण के लिए एक समापन बिंदु प्रदान करता है। इस विधि को अक्टूबर 2015 में IETF RFC 7662 में मानकीकृत किया गया, देखें: https://tools.ietf.org/html/rfc7662

इस स्टैक ओवरफ्लो प्रश्न / उत्तर में Google और Github के उदाहरण शामिल हैं: /programming/12296017/how-to-validate-an-oauth-2-0-access-token-for-a-resource-server


0

आप टोकन को मान्य करने के लिए युक्ति पढ़ें:

https://tools.ietf.org/html/rfc7662

उम्मीद है कि यह मदद करता है - अगर यह आपकी क्वेरी / समस्या का जवाब देता है तो pls इसे उत्तर दें


4
सॉफ्टवेयर इंजीनियरिंग में आपका स्वागत है। अपने वर्तमान रूप में, यह उत्तर हमारे गुणवत्ता दिशानिर्देशों को पूरा नहीं करता है । हम उम्मीद करते हैं कि उत्तर अपने दम पर खड़े होने चाहिए - पाठकों को केवल गहरी समझ हासिल करने या स्रोतों की पुष्टि करने के लिए बाहरी लिंक का पालन करना चाहिए और संबंधित सामग्री यहाँ उद्धृत की जानी चाहिए।
थॉमस ओवेन्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.