ओपनिंग कनेक्ट 1.0 ऑन फिंगर्स

OpenID कनेक्ट में एक विनिर्देश है , हब पर ट्यूटोरियल, लेख हैं और हब पर नहीं यह एक और कदम-दर-चरण निर्देश को मूर्त रूप देने के लिए व्यर्थ है, जो प्राधिकरण के माध्यम से काम करने और प्रमाणीकरण के लिए गहरी आत्मीयता से अग्रणी है। नीचे दिए गए पाठ का कार्य अलग-अलग है, विशिष्टताओं से संबंधित विचारों का वर्णन करने के लिए (एक से अधिक हैं)।

मैं तुरंत लेख के विषय पर नहीं कूदूंगा, लेकिन मैं सरल चीजों और कई स्पष्ट चीजों के साथ शुरू करूंगा। मैं जिस तरह से विकसित हुआ और ग्राहकों की आवश्यकताओं के अनुसार उनके साथ लिपटा रहा, उस तरह से जारी रखूंगा। मैं उससे ऐतिहासिक रूप से संपर्क करूंगा, यानी वह उसी तरह से जिस तरह वह पैदा हुआ था।

1।

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

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

एक कुंजी के साथ सत्र - घटना, परिभाषा के अनुसार, अस्थायी हैं, सत्र के जीवनकाल के लिए सुनहरा अनुपात लगभग "ब्राउज़र टैब खुला है, लेकिन एक दिन से अधिक नहीं है"

2।

वे किसी को भी अंदर जाने देते हैं - यह अच्छा है। अब आपको यह समझने की जरूरत है कि हम किसे जाने दें। और न केवल कटौती करने के लिए कि उसने ऊपरी दाएं कोने में एक नाम के रूप में क्या दर्ज किया, बल्कि यह भी तय करने के लिए कि उसे अंदर जाने के लिए और क्या नहीं।

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

3।

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

4।

SSO , एकल साइन ऑन - कार्यान्वयन, Microsoft Kerberos, SAML, या कुछ OAuth 2.0 , जिसके ऊपर OpenID कनेक्ट बनाया गया है, जिसके बारे में मैं आपको यहां लिख रहा हूं, वास्तव में, हुड के नीचे हमेशा एक ही चीज होती है: एक अलग सर्वर होता है प्राधिकरण , और जो कोई भी उपयोगकर्ता को अधिकृत करना चाहता है वह उपयोगकर्ता को इसे पुनर्निर्देशित करता है। यदि उपयोगकर्ता पहले से ही अधिकृत है, तो सत्र उठाया जाता है, और वह तुरंत प्राधिकरण सर्वर से वापस उड़ जाता है और जहां वह चाहता था, वहां पहुंच जाता है। यदि यह अधिकृत नहीं है, तो प्राधिकरण सर्वर इस समस्या को हल कर सकता है, एक नियम के रूप में, पासवर्ड के साथ उपयोगकर्ता नाम का अनुरोध करके, और यदि समाधान सफल होता है, तो यह उपयोगकर्ता को वापस भेज देता है।

इसके अलावा, SAML इस समय समाधान, इसलिए बोलने के लिए, पुराना है। और केर्बरोस आम तौर पर एक पूरी तरह से अलग Microsoft जादू है जो HTTP प्रोटोकॉल के दायरे से बहुत आगे जाता है। खैर, हम इस पर ध्यान केंद्रित करेंगे। और फिर हम अगली समस्या पर आते हैं।

पहले से ही एक समझने योग्य कार्य परिदृश्य है - किसी भी असंगत स्थिति में, उपयोगकर्ता को प्राधिकरण सर्वर पर भेजें, उसे यह तय करने दें कि उसके साथ क्या करना है और एक तैयार जवाब वापस करना है। लेकिन प्राधिकरण सर्वर वास्तव में यह कैसे बताता है कि उपयोगकर्ता अधिकृत है? यहाँ हम पैराग्राफ के विचारों पर फिर से लौटते हैं, अर्थात् सत्र कुंजी के लिए। आइए मूल बातों पर वापस जाएं: सत्र कुंजी की उपस्थिति प्राधिकरण का संकेत है, सत्र कुंजी स्वयं उपयोगकर्ता की जानकारी के लिए दरवाजे को अनलॉक करती है, और आप इसे विश्वास नहीं करते हैं, सत्र जानकारी के लिए। इसलिए प्राधिकरण सर्वर अधिकृत करता है और सत्र की कुंजी दूसरे सर्वर को देता है।

हालाँकि, अब इसे सत्र कुंजी नहीं, बल्कि एक टोकन कहा जाता है।
अधिक सटीक रूप से, ( OAuth 2.0 प्रोटोकॉल के अनुसार, जिसके ऊपर OpenID कनेक्ट लिखा है), ये एक ही बार में दो टोकन हैं - टोकन तक सभी अनुरोधों को हुक करने के लिए, जैसे कि दादा-दादी सत्र कुंजियाँ, और रिफंड टोकन को एक्सेस करते समय पहुँच टोकन को अपडेट करने के लिए।

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

मोबाइल और डेस्कटॉप एप्लिकेशन ऐसा कर सकते हैं। किसी कारण से वे वेब से अधिक सुरक्षित माने जाते हैं, लेकिन वेब में अधिक जटिल जीवन है।

6।

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

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

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

इसी कारण से, किसी भी स्वाभिमानी कॉर्स प्राधिकरण सर्वर पर, POST अनुरोध प्रतिबंधित हैं।

7।

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

क्या आपको OAuth 2.0 याद है? मैंने इसे कई बार ऊपर उल्लेख किया है, ओपनआईडी कनेक्ट के लिए किसी प्रकार की नींव के रूप में।

क्या आपको OpenID कनेक्ट याद है? यह लेख सिर्फ उसे गूंगा है।

तो, OAuth 2.0 प्रमाणीकरण है। तीन प्रतिभागियों, एक पासवर्ड, एक कोड और एक टोकन के साथ पूरी तरह से पहले वर्णित पूरी तरह से भ्रमित करने वाली प्रक्रिया प्रमाणीकरण के बारे में है, बस किसी को कहीं चलने देने के बारे में है। OAuth 2.0 प्रोटोकॉल।

OpenID कनेक्ट प्राधिकरण है। यही है, वह OAuth में उन हिस्सों को जोड़ता है जहां यह पता चलता है कि वे किसको जाने देते हैं।

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

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

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

8।

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

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

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

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

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

अन्य पैरामीटर हैं, जैसे कि प्राधिकरण अनुरोध और टोकन जीवनकाल के प्रकार, लेकिन यह समझने के लिए कि आपको उनकी आवश्यकता क्यों नहीं है।

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

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

इस तथ्य के लिए जेएम के लिए धन्यवाद कि आपने जो पाठ पढ़ा था, वह मेरे द्वारा लिखे गए लेखों से बहुत बेहतर था।

सौभाग्य, और समय पर अपने प्रमाण पत्र को नवीनीकृत करने के लिए मत भूलना।