फेसबुक ओएथ 2.0 "कोड" और "टोकन"

Question

यहां वर्णित फेसबुक ओएथ 2 प्रमाणीकरण प्रवाह में आपको "कोड" और "टोकन" दोनों की आवश्यकता क्यों है: https://developers.facebook.com/docs/authentication/?

आप OAuth संवाद संदर्भ (https://developers.facebook.com/docs/reference/dialogs/oauth/) को देखें, तो ऐसा लगता है जैसे आप ही कभी उपयोगकर्ता के बारे में जानकारी प्राप्त करने में टोकन का उपयोग, और यदि आप token या code,token रूप response_type पैरामीटर निर्दिष्ट है, तो आप टोकन पर मिलता है पहली बार।

आपको "कोड" प्राप्त करने की आवश्यकता क्यों है और फिर टोकन प्राप्त करने के विरोध में "टोकन" प्राप्त करने के लिए कोड का उपयोग क्यों करें?

मुझे लगता है कि ओएथ कैसे काम करता है, इस बारे में कुछ बुनियादी बातों को गलत समझ रहा हूं, लेकिन ऐसा लगता है कि अगर आप संवाद के साथ पहली बार टोकन प्राप्त करते हैं तो आप पूरी तरह से https://graph.facebook.com/oauth/access_token के अनुरोध से बचें।

Answer 1

उपयोगकर्ता लॉग इन करते समय आपको टोकन प्राप्त होता है। लेकिन जब आप अन्य कार्रवाइयां कर रहे हों तो आप टोकन को बदलना चाहेंगे। ईजी आपके ऐप/पेज के रूप में पोस्टिंग या offline_access के साथ उपयोगकर्ता के रूप में पोस्टिंग।

Answer 2

OAuth 2.0 Spec से:

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

तो, मूल रूप से - मुख्य कारण # टोकरों तक पहुंचने वाले कलाकारों को सीमित करना है।

"टोकन" प्रतिक्रिया प्राथमिक रूप से ब्राउज़र में रहने वाले ग्राहकों के लिए है (उदा .: जावास्क्रिप्ट क्लाइंट)।

Answer 3

Salesforce Documentation से बेशर्म उधार:

प्राधिकरण कोड

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

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

Answer 4

मूल रूप से, Lix's answer के विस्तार के रूप में, एक्सेस कोड मार्ग संसाधन उपयोगकर्ता (यानी फेसबुक उपयोगकर्ता) को उनके उपयोगकर्ता एजेंट (यानी उनके ब्राउज़र) के लिए प्राधिकरण को निरस्त करने की अनुमति देता है, उदा। ऑफलाइन क्लाइंट (यानी आपका आवेदन) के लिए प्राधिकरण को रद्द किए बिना लॉग ऑफ करके। यदि यह महत्वपूर्ण नहीं है, तो एक्सेस कोड मार्ग का उपयोग करने की आवश्यकता नहीं है।

इसके अलावा, यह सुनिश्चित करने के लिए एक्सेस कोड प्रदान किया जाता है कि सर्वर को प्रदान किया गया टोकन वास्तव में संसाधन स्वामी (यानी फेसबुक उपयोगकर्ता) में पंजीकृत होता है, न कि उपयोगकर्ता एजेंट (या मैन-इन-द-मध्य) ।

यह या तो अंतर्निहित बनाम प्राधिकरण कोड अनुदान प्रवाह चुनने के सवाल के समान लगता है। In fact, here is what looks like an opposite view point?!।

इसके अलावा, Drew mentioned के रूप में,

जब पहुँच टोकन समाप्त हो रहा है, उपयोग करने के लिए यह असफल हो जायेगी प्रयास करता है, और एक नया पहुँच टोकन एक ताज़ा टोकन के माध्यम से प्राप्त किया जाना चाहिए।

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

यदि मैं सही हूं, तो code%20token एक अनुकूलन है जो उपयोगकर्ता एजेंट को टोकन रखने की अनुमति देता है और सर्वर को टोकन एक्सचेंज प्रक्रिया को एक ही अनुरोध में शुरू करने की इजाजत देता है (क्योंकि नेटवर्क IO पर कुछ भी महंगा माना जाता है, खासकर एक उपयोगकर्ता एजेंट के लिए)।

Answer 5

मिश्रण-अप आया क्योंकि उपयोगकर्ता स्वयं की ओर से और क्लाइंट ऐप प्राधिकरण सर्वर (यानी फेसबुक) के खिलाफ प्रमाणीकृत नहीं है। क्लाइंट ऐप (https के साथ) को सुरक्षित करने के लिए यह बहुत आसान है तो उपयोगकर्ता-एजेंट (ब्राउज़र)।

3.4:

यहाँ IETF-OAuth (http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-08#section-3.4) से मूल निर्माण है। प्रमाणीकरण कोड

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

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

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

Answer 6

प्रमाणीकरण कोड बनाम एक्सेस टोकन को अलग करने के लिए हम एक सरल उदाहरण लेते हैं।

उपयोगकर्ता के रूप में आप हाईजैक नामक एक नया फेसबुक ऐप आज़मा सकते हैं। तो आप एप्लिकेशन और हाईजैक ऐप पर क्लिक करें। आपको अपने फेसबुक खाते में लॉग इन करने के लिए कहता है।जब आप कर लेंगे तो फेसबुक आपके लिए एक प्रमाणीकरण कोड उत्पन्न करता है।

यह कोड तब हाईजैक सर्वर पर भेज दिया जाता है जो एक्सेस टोकन प्राप्त करने के लिए अपने स्वयं के एफबी क्लाइंट आईडी, एफबी गुप्त और आपके प्रमाणीकरण कोड का उपयोग करता है।

उपर्युक्त उदाहरण में प्रमाणीकरण कोड आपको पुष्टि कर रहा है कि उपयोगकर्ता एक वैध एफबी उपयोगकर्ता है। लेकिन दूसरे चरण कहते हैं, "आप एक एफबी उपयोगकर्ता के रूप में कुछ संसाधनों के लिए हाईजैक ऐप तक पहुंच प्रदान कर रहे हैं"।

यदि हाईजैक ऐप निहित अनुदान (यानी प्रत्यक्ष पहुंच टोकन) चाहता था, तो ब्राउजर के साथ आदान-प्रदान होने के बाद एक्सेस टोकन भी आपको दिखाई देगा। इसका मतलब है कि अब आप एक्सेस टोकन का उपयोग कर हाईजैक की तरफ से सभी फेसबुक एपीआई कॉल कर सकते हैं। (आप अपनी व्यक्तिगत जानकारी प्राप्त करने के लिए केवल एक्सेस टोकन का उपयोग कर सकते हैं लेकिन फेसबुक को यह जानने का कोई तरीका नहीं है कि कौन अपना एपीआई कॉल कर रहा है।)

चूंकि हमारे पास 2 पार्टियां (आप और हाईजैक) फेसबुक के साथ प्रमाणीकरण कर रहे हैं, हमारे पास यह 2 गुना तंत्र है ।

1. <user_session_id, client_id> => authorization_code 
2. <client_id, redirect_uri, authorization_code, client_secret> => access_token, refresh_token 

चरण 1 में:

Answer 7

आप flow of Authorization Code OAuth type को देखें, तो हाँ, वहाँ मुंशी के दो चरण हैं उपयोगकर्ता OAuth सर्वर बताता है कि "मैं अपने संसाधन का उपयोग करने के लिए इस cliet (client_id) प्रमाणन करना चाहते हैं यहां मेरा प्रमाणीकरण (user_session_id या और क्या है) "

चरण 2 में: क्लाइंट (क्लाइंट_आईडी) ओएथ सर्वर को बताता है कि" मुझे उपयोगकर्ता को प्रमाणीकरण (प्राधिकरण_code) मिला है, कृपया मुझे बाद में एक्सेस टोकन दें एक्सेस। और यह मेरा प्रमाणीकरण है (client_id & client_secret) "

आप देखते हैं, अगर हम चरण 2 छोड़ देते हैं, तो ग्राहक प्रमाणीकरण की कोई गारंटी नहीं है। कोई भी ग्राहक एक अलग ग्राहक_आईडी के साथ चरण 1 का आह्वान कर सकता है और इसके बजाय उस क्लाइंट_आईडी के लिए एक्सेस टोकन प्राप्त कर सकता है। यही कारण है कि हमें चरण 2 की आवश्यकता है। हम अपने ओपन एपीआई मंच में इस दृष्टिकोण का उपयोग, और हम अभी तक किसी भी सुरक्षा समस्या नहीं मिल रहा है

<client_id, redirect_uri, client_secret> => access_token, refresh_token 

:

तुम सच में step1 और चरण 2 संयोजित करना चाहते हैं, तो आप कुछ इस तरह कर सकते हैं।

BTW, वहाँ वास्तव में है एक Implicit Grant type मौजूद हैं, वह यह है कि:

<client_id, redirect_uri> => access_token, refresh_token 

यह आम तौर पर केवल आवेदन जो कोई सर्वर बैकएंड है ग्राहक के लिए लागू है। उस स्थिति में, ओएथ सर्वर को यह सुनिश्चित करना होगा कि रीडायरेक्ट यूआरआई उस ग्राहक से संबंधित है (उदाहरण के लिए रजिस्टर रीडायरेक्ट_री के साथ)

Answer 8

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