OAuth 2 में निहित अनुदान प्राधिकरण प्रकार का उद्देश्य क्या है?

254

मुझे नहीं पता कि मेरे पास किसी प्रकार का ब्लाइंड स्पॉट है या क्या है, लेकिन मैंने OAuth 2 कल्पना को कई बार पढ़ा है और मेलिंग सूची अभिलेखागार को नष्ट कर दिया है, और मुझे अभी तक इस बारे में अच्छी व्याख्या नहीं मिल पाई है कि इंप्लांट ग्रांट क्यों है पहुँच टोकन प्राप्त करने के लिए प्रवाह विकसित किया गया है। प्राधिकरण कोड ग्रांट की तुलना में, यह बहुत ही आकर्षक कारण के लिए ग्राहक प्रमाणीकरण पर बस देने के लिए लगता है। यह "स्क्रिप्टिंग भाषा का उपयोग करके ब्राउज़र में कार्यान्वित ग्राहकों के लिए अनुकूलित" (विनिर्देशन को उद्धृत करने के लिए) कैसे है?

दोनों प्रवाह समान शुरू होते हैं (स्रोत: http://tools.ietf.org/html/draft-ietf-oauth-vut-22/ :

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

यहाँ जहाँ फूट पड़ती है। दोनों ही मामलों में इस बिंदु पर पुनर्निर्देशन URI क्लाइंट द्वारा होस्ट किए गए कुछ समापन बिंदु पर है:

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

इसलिए मेरा प्रश्न: ग्राहक प्रमाणीकरण कदम को छोड़ कर यहाँ क्या प्राप्त हुआ है?

oauth user-agent oauth-2.0

— डैन टैफ्लिन
स्रोत

: एक पर इस नज़र ibm.com/developerworks/wikis/display/...

— Håvard Geithus

5

पिछली टिप्पणी में लिंक मृत है। यहां एक अपडेट किया गया है

— एंड्रयूआर

3

मैंने सभी उत्तर यहां पढ़े हैं, लेकिन मुझे अभी भी समझ में नहीं आया है कि एक एक्सेस टोकन प्राप्त करने के लिए निजी क्लाइंट को गुप्त की आवश्यकता क्यों नहीं है। मान लें कि TrustedAppDeveloper ने TrustedPopularApp को जारी किया है कि चलो उपयोगकर्ताओं को एक अंतर्निहित अनुदान का उपयोग करके इसे अनुमतियाँ (ट्विटर outh का उपयोग करके) दें। अगर मैं EvilAppDeveloper हूं, तो मुझे एक ऐसा ऐप बनाने से रोकना होगा जो TrustedPopularAppId को ग्राहक के रूप में पास करता है और एक निहित अनुदान अनुरोध में, और फिर उपयोगकर्ता की ओर से क्रिया करना (जैसे एक फ़ीड स्पैमिंग), कि अब ऐसा लगता है कि वे TrustedPopularApp से आ रहे हैं ?

— adevine

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

— मेव

13

@adevine आपके परिदृश्य में EvilApp को ट्विटर पर प्रमाणिकता से विश्वसनीय होने से रोकता है क्योंकि TrustedPopularApp यह है कि यह Twitter से कॉलबैक प्राप्त नहीं कर सकता है, उन्हें हमेशा उस URI को भेजा जाएगा जो क्लाइंट ID को पंजीकृत करते समय परिभाषित किया गया था

— इवान

196

यहाँ मेरे विचार हैं:

प्राधिकरण कोड प्रवाह में ऑर्टिकल कोड + टोकन का उद्देश्य यह है कि टोकन और क्लाइंट सीक्रेट कभी भी संसाधन स्वामी के संपर्क में नहीं आएंगे क्योंकि वे सर्वर-टू-सर्वर यात्रा करते हैं।

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

तो "क्या प्राप्त हुआ है?" "सादगी" है।

— फिलिप पेशीन
स्रोत

4

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

— डैन तफ्लिन

3

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

— PålOliver

2

यह केवल आधा जवाब देता है, और "क्या खो गया है"?

— यूरालप

3

मुझे नहीं लगता कि यह एक व्यापक उत्तर है, निहित प्रवाह का उद्देश्य सादगी पर लाभ प्राप्त करना नहीं है, बल्कि क्लाइंट-साइड ऐप के साथ सुरक्षा चिंताओं से समझौता करना है। Auth codeसाथ में client_idऔर client_secretविश्वसनीय ग्राहकों की पहचान करने के लिए उपयोग किया जाता है जो लंबे समय तक लॉगिन और "ऑफ़लाइन लॉगिन" के लिए टोकन ताज़ा कर सकते हैं । हालांकि एक क्लाइंट-साइड ऐप में, प्रत्येक क्लाइंट को पंजीकृत करने का कोई तरीका नहीं है, इसलिए उपयोगकर्ता जानकारी के लिए अस्थायी पहुंच के लिए "सरलीकृत" निहित अनुदान प्रकार

— चेन Xie

1

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

— अतरक्सिया

94

यह सुरक्षा कारणों से है, सादगी के लिए नहीं।

आपको उपयोगकर्ता एजेंट और ग्राहक के बीच अंतर पर विचार करना चाहिए :

उपयोगकर्ता-एजेंट वह सॉफ़्टवेयर है जिसके द्वारा उपयोगकर्ता ("संसाधन स्वामी") सिस्टम के अन्य भागों (प्रमाणीकरण सर्वर और संसाधन सर्वर) के साथ संचार करता है।

क्लाइंट वह सॉफ्टवेयर है जो रिसोर्स सर्वर पर उपयोगकर्ता के संसाधनों को एक्सेस करना चाहता है।

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

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

— artkoenig
स्रोत

2

मैं देख रहा हूं कि मेरा ब्राउज़र मेरे Google खाते में महीनों से लॉग इन है। तो क्या Google का उपयोग ब्राउज़र पर टोकन या लंबी समाप्ति समय के साथ एक्सेस टोकन है? लंबे समय समाप्ति समय और एक्सेस टोकन के साथ टोकन के उपयोग में क्या अंतर है? कोई अन्य क्लाइंट एक्सेस टोकन को पकड़ सकता है और संसाधन स्वामी के मौजूद न होने पर इसका उपयोग कर सकता है।

— मोहम्मद निकरवन

मुझे लगता है कि आप लंबे समय तक समाप्ति समय के साथ ताज़ा टोकन और पहुंच टोकन के बीच अंतर मानते हैं ? ताज़ा टोकन को असुरक्षित परिदृश्य में नहीं बचाया जाना चाहिए, लेकिन आप अपनी पहुंच टोकन को बचा सकते हैं, हालांकि (जैसे ब्राउज़र के स्थानीय भंडारण में)। आपकी पहुंच टोकन के जीवनकाल को यथासंभव कम रखते हुए सुरक्षा प्राप्त की जाती है, हालांकि अभी भी आपके उपयोगकर्ताओं के लिए आरामदायक है (उदाहरण के लिए आप निष्क्रियता के x मिनट बाद स्वचालित रूप से उन्हें लॉग आउट कर सकते हैं)। यदि आप लंबे समय तक जीवन के टोकन का उपयोग करते हैं, तो आप व्यावहारिक रूप से ताज़ा टोकन अप्रचलित कर सकते हैं।

— आर्टकॉनिग

आपकी व्याख्या के लिए धन्यवाद, लेकिन मुझे एक और भ्रम भी है। मुझे समझ नहीं आ रहा है कि हमें "प्राधिकरण कोड" प्रवाह की आवश्यकता क्यों है। हम अंतर्निहित प्रवाह (access_token) और एक ताज़ा टोकन द्वारा सर्वर पर समान परिणाम तक पहुंच सकते हैं। यह अंतर्निहित प्रवाह का एकमात्र सुरक्षा विचार है कि access_code का जीवन छोटा होना चाहिए ताकि इसे सर्वर से सर्वर पर उपयोग नहीं किया जा सके। ठीक है, लेकिन ताज़ा टोकन इस समस्या को हल करता है। हमें एक SSL_code प्रवाह का उपयोग क्यों करना चाहिए और access_code को प्राप्त करने के लिए एक सर्वर पर उस टोकन द्वारा access_token का अनुरोध करना चाहिए जो हम ताज़े_टोकन के साथ एक ही परिणाम प्राप्त कर सकते हैं?

— मोहम्मद निकरावन

"टोकन को अन्य अनुप्रयोगों द्वारा आसानी से निकाला जा सकता है" कैसे?

— mvmn

@MohammadNikravan ने stackoverflow.com/q/13387698/355438

— Lu55

60

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

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

लेकिन - और यह एक ऐसा बिंदु है जो याद करना आसान है - प्राधिकरण कोड प्रवाह की सुरक्षा केवल तभी काम करती है जब वेब सर्वर को एक सत्र के साथ संरक्षित किया जाता है, जो उपयोगकर्ता प्रमाणीकरण (लॉगिन) के साथ स्थापित होता है। एक सत्र के बिना, एक अविश्वसनीय उपयोगकर्ता क्लाइंट_एड का उपयोग करते हुए वेब सर्वर के लिए केवल अनुरोध कर सकता है, और यह उसी तरह होगा जैसे उपयोगकर्ता के पास टोकन था। एक सत्र जोड़ने का मतलब है कि केवल एक प्रमाणित उपयोगकर्ता संरक्षित संसाधनों तक पहुंच सकता है। Client_id JS webapp की सिर्फ "पहचान" है, उक्त वेबएप का प्रमाणीकरण नहीं।

इसका अर्थ यह भी है कि OAuth टोकन समाप्त होने से पहले आप सत्र को समाप्त कर सकते हैं। पहुँच टोकन को अमान्य करने का कोई मानक तरीका नहीं है। लेकिन अगर आपका सत्र समाप्त हो जाता है, तो टोकन बेकार है, क्योंकि कोई भी इसे जानता नहीं है, लेकिन वेब सर्वर। यदि कोई अविश्वासी उपयोगकर्ता आपके सत्र कुंजी तक पहुँच प्राप्त कर लेता है, तो वे केवल तब तक संरक्षित संसाधनों तक पहुँच प्राप्त कर सकते हैं जब तक कि सत्र वैध था।

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

* संपादित करें: हाल ही में, लोग सिफारिश कर रहे हैं कि आप बिना सर्वर के वेब एप्स पर भी इंप्लिमेंट ग्रांट का इस्तेमाल करने से बचें। इसके बजाय आप PKCE के साथ एक खाली रहस्य के साथ कॉन्फ़िगर किए गए प्राधिकरण कोड अनुदान का उपयोग कर सकते हैं। ऑर्थोर-कोड अनुदान आपके ब्राउज़र के इतिहास में एक्सेस टोकन को संग्रहीत करने से बचता है, और PKCE इसे उजागर करने से बचता है यदि कोई व्यक्ति रीडायरेक्ट URL को हैक करने के लिए ऑरिजनल कोड चोरी करता है। इस मामले में आपको एक ताज़ा टोकन वापस करने से बचने के लिए सर्वर की आवश्यकता होगी, क्योंकि आपका क्लाइंट शायद इसे सुरक्षित रूप से संग्रहीत नहीं कर सकता है। और इसे ऊपर उल्लिखित समान सीमाओं के साथ एक पहुंच टोकन जारी करना चाहिए।

— जेडब्ल्यू।
स्रोत

21

यह उबलता है: यदि कोई उपयोगकर्ता ब्राउज़र-आधारित, या "सार्वजनिक", (जावास्क्रिप्ट) वेब ऐप चला रहा है जिसमें कोई सर्वर साइड घटक नहीं है, तो उपयोगकर्ता निहित रूप से ऐप पर भरोसा करता है (और वह ब्राउज़र जहां यह चलता है, संभवतः अन्य ब्राउज़र के साथ। -बेड ऐप्स ...)।

कोई 3-पार्टी रिमोट सर्वर नहीं है, केवल संसाधन सर्वर है। एक प्राधिकरण कोड का कोई लाभ नहीं है, क्योंकि उपयोगकर्ता की ओर से कार्य करने वाले ब्राउज़र के अलावा कोई अन्य एजेंट नहीं है। उसी कारण से क्लाइंट क्रेडेंशियल का कोई लाभ नहीं है। ( कोई भी ग्राहक इस प्रवाह का उपयोग करने का प्रयास कर सकता है।)

सुरक्षा निहितार्थ, हालांकि, महत्वपूर्ण हैं। से http://tools.ietf.org/html/rfc6749#section-10.3 :

निहित अनुदान प्रकार का उपयोग करते समय, यूआरआई टुकड़ा में पहुंच टोकन प्रसारित किया जाता है, जो इसे अनधिकृत पार्टियों को उजागर कर सकता है।

से http://tools.ietf.org/html/rfc6749#section-10.16 :

एक संसाधन मालिक किसी हमलावर के दुर्भावनापूर्ण क्लाइंट को एक्सेस टोकन देकर संसाधन तक पहुँच को स्वेच्छा से सौंप सकता है। यह फ़िशिंग या किसी अन्य बहाने के कारण हो सकता है ...

— मर्जी
स्रोत

"पब्लिक", (जावास्क्रिप्ट) वेब ऐप का कोई सर्वर साइड घटक के साथ क्या मतलब है? सर्वर के बिना वेब एप्लिकेशन कैसे हो सकता है?

— ज़मी पेज

2

@ZammyPage, यह वही होगा जिसे अक्सर सिंगल पेज ऐप (एसपीए) कहा जाता है। एप्लिकेशन की संपूर्णता एक स्थिर संसाधन से दी जाती है। एप्लिकेशन में जावास्क्रिप्ट तो गतिशील रूप से जो भी संसाधनों की जरूरत है, जो भी संसाधन सर्वर तक पहुंच सकता है, उस तक पहुंचता है। ऐसा कोई सर्वर नहीं है जो क्लाइंट की सामग्री को उत्पन्न करता है: क्लाइंट में जावास्क्रिप्ट उस डोम को संशोधित करता है जो उसके द्वारा एक्सेस किए गए संसाधनों का प्रतिनिधित्व करने के लिए आवश्यक है।

— एलरॉय फ्लिन

13

मुझे यकीन नहीं है कि मैं उत्तर और डैन की टिप्पणी को सही ढंग से समझता हूं। यह मुझे लगता है कि उत्तर ने कुछ तथ्यों को सही बताया है, लेकिन यह ठीक उसी तरह इंगित करता है जैसे ओपी ने पूछा था। अगर मैं सही तरीके से समझूं, तो निहित अनुदान प्रवाह का मुख्य लाभ यह है कि जेएस ऐप (जैसे क्रोम एक्सटेंशन) जैसे ग्राहक को ग्राहक रहस्य को उजागर नहीं करना पड़ता है।

दान टैफ्लिन ने कहा:

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

शायद मैंने आपको गलत समझा, लेकिन क्लाइंट (इस मामले में JS ऐप) को क्लाइंट क्रेडेंशियल (क्लाइंट की और सीक्रेट) को ऑथराइजेशन कोड फ्लो में रिसोर्स सर्वर में पास करना होगा? ग्राहक का रहस्य "जेएस से रखा नहीं जा सकता"।

— tzuchien.chiu
स्रोत

6

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

— 18:18 बजे

सचमुच स्वीकृत उत्तर ने मुझे भ्रमित कर दिया। मुझे लगता है कि मैंने ग्राहक को गलत समझा कि क्या है! यह उत्तर और उपरोक्त टिप्पणी हाजिर है।

— सरसापरिला

9

जबकि इंप्लिमेंट ग्रांट को ऐसे ऐप्स को सपोर्ट करने के लिए डिज़ाइन किया गया था जो क्लाइंट-साइड जावास्क्रिप्ट ऐप सहित किसी क्लाइंट सीक्रेट की सुरक्षा नहीं कर सकते थे, कुछ प्रोवाइडर्स इसके बजाय क्लाइंट सीक्रेट के बिना ऑथराइजेशन कोड का उपयोग कर एक विकल्प लागू कर रहे हैं। OAuth 2.0 IETF RFC-6749 2012 में प्रकाशित किया गया था और वर्तमान सिफारिशें कुछ हालिया चर्चाएं 2017 से हैं।

इन कार्यान्वयनकर्ताओं से IETF OAuth मेलिंग सूची पर 2017 चर्चा उपलब्ध है:

Redhat: https://www.ietf.org/..//uthuth/current/msg16966.html
डॉयचे टेलकम: https://www.ietf.org/..//uthuth/current/msg16968.html
स्मार्ट हेल्थ आईटी: https://www.ietf.org/..//uthuth/current/msg16967.html

यहाँ और पढ़ें:

पहले गुप्त के बिना ग्राहकों के लिए इंप्लिमेंट की सिफारिश की गई थी, लेकिन बिना किसी रहस्य के ऑथराइजेशन कोड ग्रांट का इस्तेमाल करके इसे खत्म कर दिया गया।

...

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

इम्प्लिमेंट ग्रांट से क्लाइंट सीक्रेट के बिना प्रामाणिक कोड में जाना यहां मोबाइल एप्लिकेशन के लिए भी उल्लिखित है:

https://aaronparecki.com/oauth-2-simplified/#mobile-apps

— Grokify
स्रोत

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

— टॉम

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

— 21

काफी हाल ही में (2018) oauth-wg चर्चा यहां पाया जा सकता है ietf.org/mail-archive/web/oauth/current/msg18020.html । RFC 8252 देशी ऐप्स के लिए है क्योंकि शीर्षक "नेटिव ऐप्स के लिए OAuth 2.0" का सुझाव देता है। रेडहैट, डीटी, स्मार्ट हेल्थ आईटी के संदर्भ मेलिंग सूची चर्चा की प्रतिक्रियाएं हैं, न कि आरएफसी, वर्किंग ड्राफ्ट, आदि ...

— टॉम

3

अन्य उत्तरों के अलावा यह महसूस करना भी महत्वपूर्ण है कि इंप्लिमेंट प्रोफ़ाइल एक फ्रंट-चैनल के लिए अनुमति देता है केवल ऑथराइजेशन कोड फ्लो के विपरीत जो ऑथराइजेशन सर्वर को कॉल बैक की आवश्यकता होती है; यह OpenID कनेक्ट में स्पष्ट हो जाता है, जो कि एक SSO प्रोटोकॉल है, जो Auth 2.0 के शीर्ष पर बनाया गया है, जहां इंप्लांटेड फ्लो बहुत लोकप्रिय SAML POST बाइंडिंग जैसा दिखता है और ऑथराइजेशन कोड फ्लो कम व्यापक रूप से तैनात SAML आर्टिफिकेशन बाइंडिंग जैसा दिखता है

— हंस जेड।
स्रोत

3

अंतर्निहित प्रवाह में यदि उपयोगकर्ता का ब्राउज़र दूषित है (बुराई विस्तार / वायरस) तो भ्रष्टाचार उपयोगकर्ता के संसाधनों तक पहुंच जाता है और खराब सामान कर सकता है।

भ्रष्टाचार प्रवाह में भ्रष्टाचार नहीं हो सकता क्योंकि यह ग्राहक को गुप्त नहीं जानता है।

— गति
स्रोत

2

https://tools.ietf.org/html/rfc6749#page-8

अंतर्निहित

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

अंतर्निहित अनुदान प्रवाह के दौरान एक्सेस टोकन जारी करते समय,
प्राधिकरण सर्वर क्लाइंट को प्रमाणित नहीं करता है। कुछ
मामलों में, क्लाइंट की पहचान ग्राहक
तक पहुंच टोकन पहुंचाने के लिए उपयोग किए गए पुनर्निर्देशन URI के माध्यम से सत्यापित की जा सकती है । एक्सेस टोकन संसाधन स्वामी या उपयोगकर्ता-एजेंट के एक्सेस के साथ संसाधन स्वामी या अन्य एप्लिकेशन के संपर्क में हो सकता है।

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

— आरजे रजवान
स्रोत

1

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

— माइक श्वार्ट्ज
स्रोत

1

इंप्लिमेंट ग्रांट प्राधिकरण समापन बिंदु से टोकन प्राप्त करने की अनुमति देता हैGET । इसका मतलब है कि प्राधिकरण सर्वर को कोर का समर्थन नहीं करना है।

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

ऐतिहासिक रूप से निहित प्रवाह को लागू करने के लिए अन्य कारण थे, लेकिन ऐसा लगता है कि वे वर्तमान में सुरक्षा लाभ द्वारा अधिकृत हैं, जो प्राधिकरण कोड अनुदान प्रदान करता है, जिसमें शामिल हैं:

गोपनीय क्लाइंट के लिए टोकन देने और उसका उपयोग करने का विकल्प
सार्वजनिक ग्राहकों के लिए ब्राउज़र इतिहास में टोकन उजागर नहीं करना
टोकन जारी होने से पहले एक अनधिकृत प्रवाह को बाधित करना - PKCE के साथ , "सभी प्रकार के Outh ग्राहक" के लिए

— को ला
स्रोत

0

मैंने अभी OAuth 2.0 के बारे में कुछ लेख का सामना किया है। लेखक का कहना है कि लागू प्रवाह के पीछे का कारण यह है कि JS ऐप्स वहां अनुरोधों में बहुत प्रतिबंधित थे:

यदि आपको आश्चर्य है कि क्यों निहित प्रकार OAuth 2.0 में शामिल किया गया था, तो स्पष्टीकरण सरल है: समान उत्पत्ति नीति। इसके बाद, फ्रंटएंड एप्लिकेशन को कोड का उपयोग करके एक्सेस टोकन प्राप्त करने के लिए विभिन्न मेजबानों को अनुरोध भेजने की अनुमति नहीं थी। आज हमारे पास कोर (क्रॉस-ऑरिजनल रिसोर्स शेयरिंग) है।

https://medium.com/securing/what-is-going-on-with-oauth-2-0-and-why-you-should-not-use-it-for-authentication-5f47597b2611

— Lu55
स्रोत