OAuth क्या है? भूमिकाएँ, बहाव, टोकन, और सुरक्षा की बुनियादी बातें

Scrapeless Scraping API x-api-token हेडर में एक खाता API कुंजी का उपयोग करता है, जो OAuth के प्रतिनिधि प्राधिकरण मॉडल के साथ एक ठोस विपरीत प्रदान करता है।

OAuth क्या है?

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

RFC 6749 OAuth 2.0 प्राधिकरण ढांचे को परिभाषित करता है।यह भूमिकाओं, प्रोटोकॉल एンドपॉइंट्स, प्राधिकरण अनुदान, एक्सेस टोकन, और नवीकरण टोकन का वर्णन करता है। बाद के दस्तावेज़ ढांचे को अद्यतन करते हैं और वर्तमान तैनात के लिए सुरक्षा मार्गदर्शिका प्रदान करते हैं।

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

चार OAuth भूमिकाएँ

एक संगठन प्राधिकरण सर्वर और संसाधन सर्वर दोनों का संचालन कर सकता है, लेकिन वे अलग-अलग प्रोटोकॉल भूमिकाएँ बने रहते हैं। भूमिकाओं को स्पष्ट रखना टीमों को सही सीमा पर मान्यता और नीति रखने में मदद करता है।

प्राधिकरण कोड प्रवाह कैसे काम करता है

1. क्लाइंट एक प्राधिकरण अनुरोध बनाता है। यह एक क्लाइंट पहचानकर्ता, अनुरोधित स्कोप, रीडायरेक्ट URI, राज्य, और PKCE चुनौती के साथ प्राधिकरण अंत बिंदु पर ब्राउज़र भेजता है।
2. प्राधिकरण सर्वर उपयोगकर्ता इंटरएक्शन को संभालता है। यह आवश्यकतानुसार उपयोगकर्ता को प्रमाणित करता है और अनुरोधित पहुंच का प्रदर्शन करता है।
3. संसाधन स्वामी पहुंच की अनुमति देता है या अस्वीकार करता है। सहमति और नीति यह निर्धारित करती है कि क्या प्राधिकरण कोड जारी किया जाता है।
4. ब्राउज़र पंजीकृत रीडायरेक्ट URI पर लौटता है। प्रतिक्रिया में प्राधिकरण कोड और राज्य मान शामिल हैं।
5. क्लाइंट प्रतिक्रिया को सत्यापित करता है। यह प्रारंभिक ब्राउज़र सत्र से बंधे मान के साथ स्थिति की तुलना करता है।
6. क्लाइंट कोड का विनिमय करता है। यह कोड और PKCE सत्यापनकर्ता के साथ टोकन अंत बिंदु को कॉल करता है; एक गोपनीय क्लाइंट अपनी स्वीकृत प्रमाणीकरण विधि का भी उपयोग करता है।
7. प्राधिकरण सर्वर टोकन जारी करता है। प्रतिक्रिया आमतौर पर एक एक्सेस टोकन शामिल करती है और सर्वर की नीति के तहत एक रिफ्रेश टोकन भी शामिल कर सकती है।
8. क्लाइंट संसाधन सर्वर को कॉल करता है। संसाधन सर्वर टोकन को मान्य करता है और दायरे, दर्शक, और संसाधन-स्तरीय नीति को लागू करता है।

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

PKCE क्या है?

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

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

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

ऐक्सेस टोकन और रिफ्रेश टोकन

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

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

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

दायरे, दर्शक और सहमति

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

दर्शक अपेक्षित संसाधन सर्वर या संसाधन सेट की पहचान करता है। एक API के लिए जारी किया गया टोकन केवल इसलिए स्वीकार नहीं किया जाना चाहिए क्योंकि इसका हस्ताक्षर मान्य है जब यह असंबंधित API द्वारा हो। संसाधन सर्वरों को अपेक्षित दर्शक और प्रमाता को मान्य करना चाहिए।

सहमति नीति का स्थान नहीं लेती हैं। एक उपयोगकर्ता को ऐसा अधिकार देने में सक्षम नहीं होना चाहिए जो उपयोगकर्ता के पास नहीं है। प्राधिकरण सर्वर और संसाधन सर्वर अब भी किरायेदार, भूमिका, स्वामित्व, जोखिम और संसाधन-स्तरीय सीमाएं लागू करते हैं।

सार्वजनिक और गोपनीय क्लाइंट

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

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

OAuth बनाम API कुंजी

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

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

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

OAuth बनाम OpenID कनेक्ट

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

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

वर्तमान OAuth सुरक्षा मार्गदर्शिका

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

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

सामान्य OAuth गलतियाँ

• OAuth प्रमाणीकरण करना। OAuth API पहुंच को अधिकृत करता है; मानकीकृत लॉगिन पहचान परत के लिए OpenID कनेक्ट का उपयोग करें।
• ढीला रीडायरेक्ट URI मिलान। प्रोफ़ाइल के नियमों के तहत केवल सटीक पंजीकृत रीडायरेक्ट URIs को स्वीकार करें।
• राज्य सत्यापन को छोड़ना। प्रतिक्रिया को आरंभिक ब्राउज़र सत्र से बांधें और असामान्यताएं अस्वीकार करें।
• PKCE को छोड़ना। प्राधिकरण कोड ग्राहक को प्रत्येक अनुरोध के लिए एक ताज़ा सत्यापनकर्ता और सुरक्षित चुनौती का उपयोग करना चाहिए।
• कोई भी हस्ताक्षरित टोकन स्वीकार करना। संसाधन सर्वरों को जारीकर्ता, दर्शक, प्रकार या प्रोफ़ाइल, समय, हस्ताक्षर, और प्राधिकरण दावों की जांच करनी चाहिए।
• अत्यधिक व्यापक दायरे। सबसे छोटे उपयोगी प्राधिकरण का अनुरोध करें और जारी करें।
• URL में टोकन रखना। HTTPS के माध्यम से प्राधिकरण शीर्षलेखों का उपयोग करें ताकि लॉगों और ब्राउज़र सतहों के माध्यम से रिसाव को कम किया जा सके।

OAuth उपयोग के मामलों

कार्यान्वयन चेकलिस्ट

1. ग्राहक और उपयोग के मामले के लिए अनुदान चुनें। इंटरैक्टिव उपयोगकर्ता प्रतिनिधित्व और सेवा पहुंच में अलग-अलग विश्वास सीमाएँ होती हैं।
2. सटीक रीडायरेक्ट URIs को पंजीकृत करें। अलग-अलग वातावरण का उपयोग करें और खुले रीडायरेक्टर्स से बचें।
3. PKCE के साथ प्राधिकरण कोड का उपयोग करें। प्रत्येक प्राधिकरण अनुरोध के लिए एक नया सत्यापनकर्ता और स्थिति मान उत्पन्न करें।
4. हर प्रतिक्रिया को मान्य करें। जहां लागू हो वहां स्थिति, जारीकर्ता मेटाडेटा, कोड बाइंडिंग, और टोकन प्रतिक्रिया क्षेत्रों की जांच करें।
5. टोकनों की रक्षा करें। इन्हें URL और लॉग से बाहर रखें, इन्हें सबसे छोटी आवश्यक अवधि के लिए स्टोर करें, और सुरक्षित ब्राउज़र या सर्वर भंडारण पैटर्न का उपयोग करें।
6. संसाधन सर्वर पर लागू करें। टोकन प्रोफ़ाइल, जारीकर्ता, दर्शक, समाप्ति, दायरे, और संसाधन-स्तरीय नीति की वैधता की जांच करें।
7. प्रवर्तन और घटना प्रबंधन की योजना बनाएं। उपयोगकर्ताओं और प्रशासकों को अनुदान हटाने और समझौता की गई साख को अक्षम करने का एक तरीका चाहिए।

निष्कर्ष

OAuth एक उपयोगकर्ता या सेवा की प्राथमिक साख को उस सीमित टोकन से अलग करता है जिसका ग्राहक API पर उपयोग करता है। इसकी भूमिकाएँ, अनुदान, दायरे और एंडपॉइंट एक मानक प्राधिकरण सीमा बनाते हैं, लेकिन प्रोटोकॉल अभी भी सटीक कार्यान्वयन पर निर्भर करता है। PKCE के साथ प्राधिकरण कोड, सटीक रीडायरेक्ट, संकीर्ण रूप से जारी किए गए टोकन, सही संसाधन-सरवर सत्यापन, और लॉगिन के लिए OpenID कनेक्ट वर्तमान प्रणालियों के लिए एक मजबूत आधार प्रदान करते हैं।