2013-03-05 5 views
14

"प्राधिकरण-कोड" प्राधिकरण अनुदान में, OAuth 2.0 का उपयोग करके, मैं पहले "/ अधिकृत" करने के लिए कॉल करता हूं, कोड प्राप्त करता हूं, और फिर एक्सेस-टोकन प्राप्त करने के लिए "/ टोकन" पर कॉल के भीतर इस कोड का उपयोग करता हूं।oAuth2.0: "प्राधिकरण-कोड" और केवल तभी टोकन की आवश्यकता क्यों है?

मेरा प्रश्न: यह प्रवाह क्यों है? मुझे लगता है कि यह एक सुरक्षा कारण से है, लेकिन मैं इसे समझ नहीं सकता। कार्यान्वयन इस तरह क्यों है, और पहली कॉल ("/ अधिकृत") के तुरंत बाद एक्सेस-टोकन नहीं प्राप्त कर रहा है?

हमें इस कोड की आवश्यकता क्यों है?

+1

http://stackoverflow.com/questions/13387698/why-is-there-an-authorization-code-flow-in-oauth2-when-implicit-flow-works-s –

उत्तर

9

प्राधिकरण कोड प्रवाह उन परिदृश्यों के लिए है जहां 3 पार्टियां शामिल हैं।

इन पार्टियों हैं:

  • ग्राहक

    अपने वेब ब्राउज़र के साथ उपयोगकर्ता। वह आपके आवेदन का उपयोग करना चाहता है।

  • प्रदाता

    उपयोगकर्ता के बारे में जानकारी है। अगर कोई इस डेटा तक पहुंचना चाहता है, तो उपयोगकर्ता को पहले सहमत होना होगा।

  • आपका (वेब) आवेदन

    प्रदाता से उपयोगकर्ता के बारे में जानकारी पहुंच चाहता है।

अब अपने अनुप्रयोगउपयोगकर्ता (/authorize समाप्ति बिंदु को अपने ब्राउज़र रीडायरेक्ट करना) करने के लिए कहते हैं:

अरे उपयोगकर्ता, यहाँ मेरी ग्राहक आईडी है। कृपया प्रदाता से बात करें और उसे सीधे मुझसे बात करने दें।

तो उपयोगकर्ता प्रदाता को वार्ता (प्राधिकरण कोड का अनुरोध करता है और उसके ब्राउज़र में अपने कॉलबैक URL खोलने के द्वारा अपने अनुप्रयोग को वापस करती):

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

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

अन्य एप्लिकेशन प्रकारों के मामले में जहां आपका ऐप क्लाइंट साइड (जैसे आईफोन/एंड्रॉइड ऐप्स या जावास्क्रिप्ट क्लाइंट) पर सीधे चल रहा है, मध्यवर्ती चरण अनावश्यक है।

+5

क्यों उपयोगकर्ता देना नहीं बल्ले से सीधे पहुंच/रीफ्रेश टोकन? कोड के साथ मध्यवर्ती कदम क्यों है? – user2316667

+3

सहमत हैं, यह सवाल का जवाब नहीं देता है। सवाल है * क्यों *। – stickfigure

+0

@stickfigure क्या आप कृपया मेरा जवाब जांच सकते हैं और देख सकते हैं कि यह आपके संदेह को साफ़ करता है या नहीं। यदि नहीं तो कृपया मुझे बताएं। – ksht

5

क्या यह भी हो सकता है कि यह मध्यवर्ती कदम ग्राहक को पहुंच टोकन देखने से रोकता है?

ओ रेली किताब से

:

प्राधिकरण कोड यह अनुदान प्रकार सर्वर साइड वेब अनुप्रयोगों के लिए सबसे उपयुक्त है। पुन: स्रोत मालिक के पास उनके डेटा तक अधिकृत पहुंच के बाद, उन्हें एप्लिकेशन पर URL में क्वेरी पैरामीटर के रूप में प्राधिकरण कोड के साथ रीडायरेक्ट किया गया है। इस कोड को क्लाइंट एप्लिकेशन द्वारा एक्सेस टोकन के लिए आदान-प्रदान किया जाना चाहिए। यह पूर्व-परिवर्तन सर्वर-टू-सर्वर किया जाता है और दोनों क्लाइंट_आईडी और क्ली ent_secret की आवश्यकता होती है, संसाधन को स्वामी को एक्सेस टोकन प्राप्त करने से रोकता है। यह अनुदान प्रकार रीफ्रेश टोकन का उपयोग कर एपीआई के लिए लंबे समय तक पहुंच के लिए अनुमति देता है। ब्राउज़र आधारित क्लाइंट-साइड अनुप्रयोगों के लिए

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

अद्यतन - हाँ वास्तव में:

जब प्राधिकरण कोड प्रवाह का उपयोग किया जाना चाहिए? प्राधिकरण कोड प्रवाह जब

  • लांग रहता पहुंच आवश्यक है किया जाना चाहिए।

  • ओएथ क्लाइंट एक वेब अनुप्रयोग सर्वर है। API कॉल के लिए

  • जवाबदेही बहुत महत्वपूर्ण है और OAuth टोकन ब्राउज़र है, जहां उपयोगकर्ता यह की पहुँच हो सकती करने के लिए नहीं लीक किया जाना चाहिए।

अधिक:

शायद

सबसे महत्वपूर्ण बात-क्योंकि पहुँच टोकन ब्राउज़र- के माध्यम से कभी नहीं भेजा जाता वहाँ कम जोखिम है कि पहुँच टोकन माध्यम से दुर्भावनापूर्ण कोड में लीक हो जाएगा ब्राउज़र इतिहास, रेफरर हेडर, जावास्क्रिप्ट, और इसी तरह।

+0

यह पुस्तक क्या है –

+0

तो मुख्य बिंदु यह है कि कॉलबैक यूआरएल में एक्सेस टोकन नहीं दिया गया है, यह किसी भी रूप में कभी भी क्लाइंट पक्ष पर खुलासा नहीं किया गया है। क्यूं कर? यह एसएसएल है। केवल कुछ कारणों के बारे में मैं सोच सकता हूं कि कुछ मैलवेयर यूआरएल तक पहुंचने से रोकने के लिए हैं और उसके बाद ऐप उपयोगकर्ता द्वारा अधिकृत उपयोगकर्ता डेटा तक जीवन समय तक पहुंच है। –

+0

लेकिन सर्वर_secret_key + authorization_code के साथ एपीआई क्यों नहीं है। केवल access_token के बजाय। इस तरह से प्रमाणीकरण कोड चोरी से जोखिम नहीं होगा क्योंकि सर्वर में अभी भी गुप्त कुंजी है कि मैलवेयर के पास –

0

एक महत्वपूर्ण बिंदु

शायद सबसे महत्वपूर्ण बात-क्योंकि पहुँच टोकन ब्राउज़र- वहाँ कम जोखिम है कि पहुँच टोकन ब्राउज़र इतिहास के माध्यम से दुर्भावनापूर्ण कोड में लीक हो जाएगा के माध्यम से कभी नहीं भेज दिया जाता है, संदर्भित है शीर्षलेख, जावास्क्रिप्ट, और पसंद है।

+0

नहीं है लेकिन फेसबुक ओथ में, एक्सेस टोकन ब्राउज़र [लिंक] (https://developers.facebook.com/docs/facebook) पर पास हो गया है -login/वेब # टोकन) – Qiang

4

क्लाइंट पक्ष पर डेटा आम तौर पर असुरक्षित माना जाता है। अंतर्निहित कॉल के मामले में जहां टोकन प्रारंभिक चरण में ही दिया जाता है, access_token वाला कोई भी व्यक्ति डेटा के लिए अनुरोध कर सकता है, एपीआई नहीं जानता कि कौन सी एपीआई कॉल कर रहा है।

लेकिन, वेब-सर्वर ऐप्स के मामले में जहां एप्लिकेशन स्वयं को पहचानना चाहता है, क्लाइंट_सेक्रेट के साथ क्लाइंट_इड को accessization टोक़ को access_token प्राप्त करने के लिए भेजा जाता है, जिसे भविष्य में स्वतंत्र रूप से भेजा जा सकता है।

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

वर्तमान परिदृश्य में, access_token प्राप्त करने के बाद, क्लाइंट_सेक्रेट की आवश्यकता के बिना और अनुरोध स्वतंत्र रूप से किए जा सकते हैं।

0

मुझे लगता है कि यह ऐसा है;

जब हम प्राधिकरण कोड का उपयोग करते हैं, तो हमारे पास 2 सत्यापन भाग होते हैं;

  • 1; उपयोगकर्ता के स्वामित्व को सत्यापित करने के लिए, क्योंकि वह
  • 2 में लॉग इन करता है; हम जानते हैं कि ग्राहक, वास्तव में वह कहता है कि वह ऐसा इसलिए है क्योंकि ग्राहक अपना क्लाइंट_सेक्रेट भेज रहा है।

तो अगर हम समय पर पहुँच टोकन वापसी होगी उपयोगकर्ता प्राधिकरण कोड के बजाय प्रमाणित करता है जब हम जानते हैं कि यह अनुरोध करने वाले उपयोगकर्ता है लेकिन हम जानते हैं न कि यह पंजीकृत ग्राहक के लिए इस्तेमाल किया जाएगा। तो उदाहरण के लिए आपका वेबपैप।

जब हम 'निहित अनुदान' का उपयोग करते हैं; (या प्राधिकरण कोड के बजाय एक्सेस टोकन वापस करें)

  • 1; हम जानते हैं कि यह उपयोगकर्ता है जो एक्सेस टोकन प्राप्त कर रहा है, लेकिन प्राधिकरण कोड प्राप्त करने की कोई आवश्यकता नहीं है क्योंकि 'उपयोगकर्ता-एजेंट' आधारित एप्लिकेशन चेक करने योग्य नहीं है। यह जांच योग्य है, अगर आप इसके बारे में सोचते हैं लेकिन यह हर किसी के लिए उपयोग योग्य है। क्लाइंट_सेक्रेट 'उपयोगकर्ता-एजेंट' आधारित एप्लिकेशन के स्रोत कोड में सार्वजनिक रूप से देखने योग्य है, इसलिए हर कोई केवल 'स्रोत कोड देख सकता है' और क्लाइंट_सेक्रेट की प्रतिलिपि बना सकता है और क्लाइंट के स्वामित्व को सत्यापित करने के लिए इस विधि का उपयोग कर सकता है।
संबंधित मुद्दे