165

OAuth 2.0 में कई वर्कफ़्लोज़ हैं। दोनों के संबंध में मेरे कुछ सवाल हैं।

प्राधिकरण कोड प्रवाह - क्लाइंट ऐप से उपयोगकर्ता लॉग, प्राधिकरण सर्वर ऐप में एक प्राधिकरण कोड देता है। ऐप फिर एक्सेस टोकन के लिए प्राधिकरण कोड का आदान-प्रदान करता है।
इम्प्लिक्ट ग्रांट फ्लो - क्लाइंट ऐप से यूजर लॉग, ऑथराइजेशन सर्वर क्लाइंट ऐप से सीधे टोकन एक्सेस जारी करता है।

सुरक्षा के संदर्भ में दोनों दृष्टिकोणों में क्या अंतर है? कौन सा अधिक सुरक्षित है और क्यों?

मुझे एक कारण नहीं दिखता है कि एक अतिरिक्त कदम (टोकन के लिए विनिमय प्राधिकरण कोड) एक काम के प्रवाह में क्यों जोड़ा जाता है जब सर्वर सीधे एक्सेस टोकन जारी कर सकता है।

विभिन्न वेबसाइटों का कहना है कि प्राधिकरण कोड प्रवाह का उपयोग तब किया जाता है जब क्लाइंट ऐप क्रेडेंशियल्स को सुरक्षित रख सकता है। क्यों?

oauth oauth-2.0

— divyanshm
स्रोत

एक गाइड OAuth 2.0 अनुदान के लिए

— अलेक्जेंड्रू मारकुलस्कु

204

वह access_tokenहै जिसे आपको एक संरक्षित संसाधन (एक एपीआई) कॉल करने की आवश्यकता है। प्राधिकरण कोड प्रवाह में इसे प्राप्त करने के लिए 2 चरण हैं:

उपयोगकर्ता को codeएपीआई उपभोक्ता (जिसे "क्लाइंट" कहा जाता है) को प्रमाणित और वापस करना होगा ।
एपीआई का "क्लाइंट" (आमतौर पर आपका वेब सर्वर) codeएक के लिए # 1 में प्राप्त, का आदान-प्रदान करता access_tokenहैclient_id औरclient_secret
इसके बाद एपीआई को कॉल कर सकते हैं access_token ।

तो, एक दोहरी जांच है: जो उपयोगकर्ता संसाधनों का मालिक है वह एपीआई और क्लाइंट का उपयोग करता है जो एपीआई का उपयोग करता है (उदाहरण के लिए एक वेब ऐप)। दोनों को मान्य किया जाना चाहिए। यहाँ OAuth के "प्राधिकरण" प्रकृति पर ध्यान दें: उपयोगकर्ता अपने संसाधन तक पहुँच प्राप्त करता है (के माध्यम से)code प्रमाणीकरण के बाद लौटे) के से एक ऐप को प्राप्त करता है access_token, ऐप को उपयोगकर्ता की ओर से कॉल और मिलता है ।

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

निहित प्रवाह आमतौर पर उन परिदृश्यों में उपयोग किया जाता है जहां भंडारण client idऔर client secretअनुशंसित नहीं है (उदाहरण के लिए एक उपकरण, हालांकि कई इसे वैसे भी करते हैं)। यही अस्वीकरण का मतलब है। लोगों के पास क्लाइंट कोड तक पहुंच है और इसलिए वे क्रेडेंशियल प्राप्त कर सकते हैं और संसाधन ग्राहक बनने का दिखावा कर सकते हैं। निहित प्रवाह में सभी डेटा अस्थिर है और ऐप में कुछ भी संग्रहीत नहीं है।

— यूजेनियो पेस
स्रोत

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

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

खैर ... यह है कि प्रोटोकॉल कैसे काम करता है। आप एक और दूसरे की सुरक्षा खूबियों पर अधिक विस्तृत संदर्भ के लिए विशिष्ट खतरे के विश्लेषण को पढ़ना चाह सकते हैं।

— यूजीनियो पेस

मुझे पता है कि मूल उत्तर 5 साल से अधिक पुराना है, लेकिन यह सबसे सरल और सबसे स्पष्ट विवरण है जिसे मैंने कभी पढ़ा है। साभार @EugenioPace

— Taha Ahmad

1

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

— डैनियल लैंगडन

धन्यवाद! हां, 3 संचार हो रहे हैं: ब्राउज़र और एएस 9e.g. फेसबुक)। यही /authorizeनिवेदन है। ब्राउज़र और वेब साइट एपीआई (उर्फ क्लाइंट) को कॉल करने की कोशिश कर रही है। यही कारण है redirect_uri+ codeसफल प्रमाणीकरण के बाद के रूप में से लौट आए। अंत में, ग्राहक ने दृश्यों के पीछे AS को कॉल किया, codeएक के बदले access_token। यही token endpointसाहित्य में है। सामान्य तौर पर एएस कभी किसी को नहीं बुलाता है। यह हमेशा जवाब देता है।

— यूजेनियो पेस

52

मैं यहाँ कुछ जोड़ूंगा जो मुझे नहीं लगता कि उपरोक्त उत्तरों में स्पष्ट किया गया है:

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

tl; डॉ अगर आप पकड़ टोकन के लिए उपयोगकर्ताओं को मशीन पर भरोसा नहीं करते निहित प्रवाह का उपयोग नहीं है, लेकिन आप कर अपने खुद के सर्वर पर भरोसा है।

— जॉर्ज पॉवेल
स्रोत

12

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

— चेसो

हाँ, एक कुकी। इस प्रकार, आपको क्रॉस-साइट अनुरोध जालसाजी से बचाने के लिए अपना सर्वर और ब्राउज़र क्लाइंट सेट करना चाहिए।

— Marcel

@ मार्सेल मैं यह जानना चाहूंगा कि एक बार कोड प्राप्त करने के बाद, वास्तविक access_tokenकी मदद से वास्तविक प्राप्त करने के लिए विनिमय कैसे और कहाँ होता है authorization code।

— चिराग सोनी

14

दोनों में अंतर यह है कि:

इम्प्लिक्ट फ्लो में, टोकन को सीधे "#" साइन के साथ रीडायरेक्ट URL के माध्यम से लौटाया जाता है और इसका उपयोग ज्यादातर ऐसे जावास्क्रिप्ट क्लाइंट या मोबाइल एप्लिकेशन में किया जाता है, जिनके पास सर्वर साइड नहीं होता है, और क्लाइंट को कुछ विवरणों में अपना सीक्रेट प्रदान करने की आवश्यकता नहीं होती है। ।
प्राधिकरण कोड प्रवाह में, कोड "के साथ वापस आ गया है?" सर्वर की ओर से पठनीय होने के लिए तब सर्वर साइड को ऑथराइजेशन सर्वर से जन्स ऑब्जेक्ट के रूप में टोकन प्राप्त करने के लिए इस बार टोकन यूआरएल में क्लाइंट सीक्रेट प्रदान करना होता है। यह उस स्थिति में उपयोग किया जाता है जब आपके पास एप्लिकेशन सर्वर होता है जो इसे संभाल सकता है और अपने स्वयं के सिस्टम पर अपने प्रोफ़ाइल के साथ उपयोगकर्ता टोकन को स्टोर कर सकता है, और ज्यादातर आम मोबाइल अनुप्रयोगों के लिए उपयोग किया जाता है।

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

— बासेम रेडा ज़ोहदी
स्रोत

प्राधिकरण कोड फेसबुक के लिए 10 मिनट के लिए सर्वर साइड में संग्रहीत किया जाता है। यह उनके दिसंबर 5,2012 परिवर्तन में जारी किया गया था। मेरा प्रश्न मुख्य रूप से यह है कि सुरक्षा / प्रदर्शन के मामले में 2 में क्या अंतर है। मुझे पता है कि दोनों प्रवाह क्या करते हैं - लेकिन प्राधिकरण कोड का उपयोग करने का क्या फायदा है - वर्कफ़्लो में एक और कदम जोड़ना।

— दिव्यांशु

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

— बासेम रेडा ज़ोहड़ी

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

— बासेम रेडा ज़ोहदी

2

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

— दिव्यांशु

1

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

— बासेम रेडा ज़ोहड़ी

4

निहित अनुदान दो अलग-अलग मतभेदों के साथ प्राधिकरण कोड अनुदान के समान है।

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

दूसरा, प्राधिकरण सर्वर के बजाय एक ऑथराइजेशन कोड लौटाता है, जिसे एक्सेस टोकन के लिए एक्सचेंज किया जाता है, ऑथराइजेशन सर्वर एक एक्सेस टोकन लौटाता है।

कृपया यहाँ विवरण देखें http://oauth2.thephpleague.com/authorization-server/which-grant/

— Lutfor
स्रोत

1

उस लिंक के लिए धन्यवाद, इससे मुझे प्रत्येक अनुदान प्रकार के बीच अंतर को समझने में मदद मिली और प्रत्येक को कब चुनना है।

— फ्रांस्वा POYER

3

प्रबल प्रवाह

लाभ

लागू करने के लिए सबसे सरल

नुकसान

ब्राउज़र पर दिखाई देने वाले टोकन एक्सेस करें
पहुंच टोकन की उत्पत्ति निर्धारित नहीं की जा सकती
एक्सेस टोकन समाप्त नहीं हो सकता (Google नीति द्वारा)

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

लाभ

सबसे ज्यादा सुरक्षित
टोकन और रिफ्रेश टोकन तक तभी बनाया जा सकता है जब एक साझा रहस्य ज्ञात हो
नई सुरक्षा और UX सुविधाओं के साथ बढ़ाया जा सकता है जब वे उपलब्ध हो जाते हैं

नुकसान

कई सामान्य एंडपॉइंट्स को लागू करना चाहिए

उद्धरण: https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows

— vlazzle
स्रोत

2

मुझे उन बिंदुओं को संक्षेप में प्रस्तुत करना चाहिए जो मैंने उपरोक्त उत्तरों से सीखे हैं और अपनी खुद की कुछ समझ को जोड़ते हैं।

प्राधिकरण कोड प्रवाह !!!

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

निहित अनुदान प्रवाह !!!

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

— अमन तुलाधर
स्रोत

2

कौन सा अधिक सुरक्षित है और क्यों?

वे दोनों सुरक्षित हैं, यह उस वातावरण पर निर्भर करता है जिसका आप उपयोग कर रहे हैं।

मुझे एक कारण नहीं दिखता है कि एक अतिरिक्त कदम (टोकन के लिए विनिमय प्राधिकरण कोड) एक काम के प्रवाह में क्यों जोड़ा जाता है जब सर्वर सीधे एक्सेस टोकन जारी कर सकता है।

यह आसान है। आपका ग्राहक सुरक्षित नहीं है। आइए इसे विवरण में देखें।

इस बात पर विचार करें कि आप किसके खिलाफ एक एप्लिकेशन विकसित कर रहे हैं Instagram API, इसलिए आप अपने एपीपी को पंजीकृत करें Instagramऔर परिभाषित करें कि API'sआपको क्या चाहिए। Instagramआपको client_idऔर प्रदान करेगाclient_secrect

वेब साइट पर आप एक लिंक सेट करते हैं जो कहता है। "आओ और मेरे आवेदन का उपयोग करें"। इस पर क्लिक करके आपके वेब एप्लिकेशन को दो कॉल करने चाहिए Instagram API।

FirstInstagram Authentication Serverनीचे के मापदंडों के साथ एक अनुरोध भेजें ।

1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token.

आप नहीं भेजते हैंclient_secret , आप क्लाइंट (उपयोगकर्ता और उसके ब्राउज़र पर भरोसा नहीं कर सकते हैं जो आपको एप्लिकेशन का उपयोग करने की कोशिश करते हैं)। ग्राहक url या जावा स्क्रिप्ट देख सकता है और client_secrectआसानी से ढूँढ सकता है। यही कारण है कि आपको एक और कदम की आवश्यकता है।

आप एक प्राप्त codeऔर state। codeयहाँ है temporaryऔर किसी भी जहां सहेजा नहीं गया है।

फिर आप (अपने सर्वर से) secondको कॉल करेंInstagram API

 1. `grant_type` with the value of `authorization_code`
 2. `client_id` with the client identifier
 3. `client_secret` with the client secret
 4. `redirect_uri` with the same redirect URI the user was redirect back to
 5. `code` which we have already received.

जैसा कि कॉल हमारे सर्वर से किया जाता है हम सुरक्षित रूप से उपयोग कर सकते हैं client_secret(जो दिखाता है कि हम कैसे हैं) codeजिसके साथ उपयोगकर्ता ने client_idसंसाधन का उपयोग करने के लिए दी है।

जवाब में हमारे पास होगा access_token

— अलीरज़ा फ़ताही
स्रोत

1

व्यावहारिक दृष्टिकोण से (मुझे क्या समझ में आया), Authz कोड प्रवाह होने का मुख्य कारण है:

ताज़ा टोकन के लिए समर्थन (उपयोगकर्ता की ओर से दीर्घकालिक एक्सेस), निहितार्थ में समर्थित नहीं: संदर्भ: https://tools.ietf.org/html/rfc6749#section-4.2
सहमति पृष्ठ के लिए समर्थन जो एक ऐसा स्थान है जहाँ संसाधन स्वामी प्रदान करने के लिए किस तरह से नियंत्रित कर सकता है (किस प्रकार की अनुमति / प्राधिकरण पृष्ठ जिसे आप Google में देखते हैं)। वही निहितार्थ में नहीं है। अनुभाग देखें: https://tools.ietf.org/html/rfc6749#section-4.1 , बिंदु (B)

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

इसके अलावा, ताज़ा टोकन का उपयोग करके, ऐप उपयोगकर्ता डेटा के लिए दीर्घकालिक पहुंच प्राप्त कर सकते हैं।

— dvsakgec
स्रोत

0

दो प्रमुख बिंदु प्रतीत होते हैं, जिन पर अब तक चर्चा नहीं हुई है, जो बताते हैं कि प्राधिकरण कोड अनुदान प्रकार में चक्कर सुरक्षा क्यों जोड़ता है।

लघु कहानी : प्राधिकरण कोड ग्रांट टाइप ब्राउज़र इतिहास से संवेदनशील जानकारी रखता है, और टोकन का प्रसारण केवल प्राधिकरण सर्वर के HTTPS संरक्षण पर निर्भर करता है।

लंबा संस्करण:

निम्नलिखित में, मैं RFC में परिभाषित OAuth 2 शब्दावली के साथ रहूँगा (यह एक त्वरित रीड है): संसाधन सर्वर , क्लाइंट , प्राधिकरण सर्वर , संसाधन स्वामी ।

कल्पना करें कि आप अपने Google खाते (= संसाधन सर्वर) के कुछ डेटा तक पहुंचने के लिए कुछ तृतीय-पक्ष ऐप (= क्लाइंट) चाहते हैं। चलो मान लेते हैं कि Google OAuth 2 का उपयोग करता है। आप Google खाते के लिए संसाधन स्वामी हैं, लेकिन अभी आप तृतीय-पक्ष ऐप संचालित करते हैं।

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

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

ऑथराइजेशन कोड ग्रांट टाइप के साथ, टोकन को अंततः क्लाइंट से प्राधिकरण सर्वर पर कॉल द्वारा प्राप्त किया जाता है, जहां ट्रांसमिशन सुरक्षा केवल प्राधिकरण सर्वर पर निर्भर करती है , न कि क्लाइंट पर।

— कार्स्टन फुर्रहमान
स्रोत

OAuth ऑथोराइज़ेशन कोड और इम्प्लिक्ट वर्कफ़्लोज़ में क्या अंतर है? हर एक का उपयोग कब करें?

प्रबल प्रवाह

लाभ

नुकसान

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

लाभ

नुकसान

प्राधिकरण कोड प्रवाह !!!

निहित अनुदान प्रवाह !!!