रेस्टफुल ऑथेंटिकेशन

745

रेस्टफुल ऑथेंटिकेशन का क्या मतलब है और यह कैसे काम करता है? मुझे Google पर एक अच्छा अवलोकन नहीं मिल रहा है। मेरी एकमात्र समझ यह है कि आप URL में सत्र कुंजी (रीमर्बल) पास करते हैं, लेकिन यह बहुत गलत हो सकता है।

— जिम कीनर
स्रोत

3

जब मैंने Google रेस्टफुल ऑथेंटिकेशन किया तो मुझे एक दर्जन RoR प्लगइन्स मिले। मैं मान रहा हूँ कि वे नहीं हैं जो आप खोज रहे हैं। अगर आरओआर नहीं है, तो क्या भाषा है? क्या वेब सर्वर?

— S.Lott

2

यदि आप HTTPS का उपयोग करते हैं तो यह बहुत गलत नहीं होगा। URL के साथ पूरा HTTP अनुरोध एन्क्रिप्ट किया जाएगा।

— भरत खत्री

4

@ भारतचत्री: हाँ, यह होगा। मैं उपयोगकर्ता को दिखाई देने वाले URL में संवेदनशील जानकारी कभी नहीं दे पाऊंगा। यह जानकारी व्यावहारिक उद्देश्यों के लिए लीक होने की अधिक संभावना है। HTTPS आकस्मिक रिसाव के लिए मदद नहीं कर सकता।

— जो

2

@jcoffland: वास्तविक वास्तविक प्रमाणीकरण से आपका क्या तात्पर्य है? मुझे दिलचस्पी है क्योंकि मैंने स्वीकार किए गए उत्तर से तीसरे तरीके को लागू किया है, हालांकि मैं इससे खुश नहीं हूं (मुझे URL में अतिरिक्त परम पसंद नहीं है)।

— BlueLettuce16

4

कुछ लोग इसे हल करने के लिए jwt.io/introduction का उपयोग करते हैं .. मैं अपने मामले को हल करने के लिए अभी इस बारे में शोध करता हूं: stackoverflow.com/questions/36974163/… >> >> उम्मीद है कि यह ठीक काम करेगा।

— toha

586

कैसे एक विश्वसनीय क्लाइंट-सर्वर आर्किटेक्चर में प्रमाणीकरण को संभालना बहस का विषय है।

आमतौर पर, इसे HTTP दुनिया में SOA के माध्यम से प्राप्त किया जा सकता है:

एचटीटीपीएस पर एचटीटीपी मूल आधार;
कुकीज़ और सत्र प्रबंधन;
HTTP हेडर में टोकन (जैसे OAuth 2.0 + JWT);
अतिरिक्त हस्ताक्षर मापदंडों के साथ क्वेरी प्रमाणीकरण।

आपको अपने सॉफ़्टवेयर आर्किटेक्चर को सर्वोत्तम रूप से मिलान करने के लिए उन तकनीकों को अनुकूलित करना होगा, या उससे भी बेहतर मिश्रण करना होगा।

आपकी सुरक्षा नीति और सॉफ़्टवेयर आर्किटेक्चर के उद्देश्य के आधार पर प्रत्येक प्रमाणीकरण योजना के अपने PRO और CONs हैं।

एचटीटीपीएस पर एचटीटीपी मूल आधार

यह पहला समाधान, मानक HTTPS प्रोटोकॉल पर आधारित है, जिसका उपयोग अधिकांश वेब सेवाओं द्वारा किया जाता है।

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

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

हम डाइजेस्ट ऑथेंटिकेशन का उपयोग कर सकते हैं , लेकिन इसके लिए HTTPS की भी आवश्यकता होती है, क्योंकि यह MiM या रिप्ले हमलों के लिए असुरक्षित है , और HTTP के लिए विशिष्ट है।

कुकीज़ के माध्यम से सत्र

ईमानदार होने के लिए, सर्वर पर प्रबंधित एक सत्र वास्तव में स्टेटलेस नहीं है।

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

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

कुकी तकनीक स्वयं HTTP-लिंक्ड है, इसलिए यह वास्तव में RESTful नहीं है, जो प्रोटोकॉल-स्वतंत्र, IMHO होना चाहिए। यह MiM या रिप्ले हमलों के लिए असुरक्षित है ।

टोकन के माध्यम से दी गई (OAuth2)

एक विकल्प HTTP हेडर के भीतर एक टोकन डालना है ताकि अनुरोध प्रमाणित हो। यह क्या है OAuth 2.0 करता है, उदाहरण के लिए। RFC 6749 देखें :

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

संक्षेप में, यह कुकी के समान है और समान मुद्दों से ग्रस्त है: स्टेटलेस नहीं है, HTTP ट्रांसमिशन विवरण पर निर्भर है, और बहुत सारी सुरक्षा कमजोरियों के अधीन है - जिसमें MiM और रिप्ले भी शामिल हैं - इसलिए इसका उपयोग केवल HTTPS से अधिक किया जाना है। आमतौर पर, JWT को टोकन के रूप में उपयोग किया जाता है।

क्वेरी प्रमाणीकरण

क्वेरी प्रमाणीकरण यूआरआई पर कुछ अतिरिक्त मापदंडों के माध्यम से प्रत्येक रिस्टफुल अनुरोध पर हस्ताक्षर करने में शामिल है। इस संदर्भ लेख को देखें ।

इसे इस लेख में इस प्रकार परिभाषित किया गया था:

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

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

उदाहरण के लिए, यहां ऊपर दिए गए लिंक से एक सामान्य यूआरआई नमूना है:

GET /object?apiKey=Qwerty2010

इस तरह प्रेषित किया जाना चाहिए:

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

हस्ताक्षर किए जा रहे स्ट्रिंग है /object?apikey=Qwerty2010&timestamp=1261496500और हस्ताक्षर API कुंजी के निजी घटक का उपयोग करके उस स्ट्रिंग का SHA256 हैश है।

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

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

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

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

निष्कर्ष

यह निष्कर्ष के लायक है कि REST केवल HTTP- आधारित नहीं है, भले ही, व्यवहार में, यह ज्यादातर HTTP पर भी लागू होता है। REST अन्य संचार परतों का उपयोग कर सकता है। तो एक RESTful प्रमाणीकरण केवल HTTP प्रमाणीकरण का पर्याय नहीं है, जो भी Google उत्तर देता है। यह भी HTTP तंत्र का उपयोग नहीं करना चाहिए, लेकिन संचार परत से अमूर्त किया जाएगा। और यदि आप HTTP संचार का उपयोग करते हैं, तो लेट्स एनक्रिप्ट की पहल की बदौलत उचित HTTPS का उपयोग नहीं करने का कोई कारण नहीं है, जो किसी भी प्रमाणीकरण योजना के अतिरिक्त आवश्यक है।

— अरनौद बुचेज़
स्रोत

5

यदि आप Cookieएक बेहतर प्रतिस्थापन के रूप में उपयोग HTTP Basic Authकरते हैं, तो प्रमाणीकरण को समाप्त करने और लॉगआउट करने की क्षमता के लिए एक विधि के साथ वास्तव में स्टेटलेस प्रमाणीकरण कर सकते हैं। एक उदाहरण कार्यान्वयन Emulated-HTTP-Basic-Authवास्तविक HTTP बेसिक प्रमाणीकरण के लिए समान मूल्य के साथ बुलाया कुकी का उपयोग कर सकता है और इसके अतिरिक्त समय समाप्त हो सकता है। उस कुकी को हटाने के साथ लॉग आउट किया जा सकता है। मुझे लगता है कि HTTP बेसिक ऑथेंट को समर्थन देने में सक्षम कोई भी ग्राहक इस तरह से किए गए कुकी प्रमाणीकरण का समर्थन कर सकता है।

— मिकको रेंटालिनेन

4

@MikkoRantalainen लेकिन यह कुकी अभी भी सर्वर द्वारा प्रबंधित की जाएगी, जैसा कि मैंने लिखा था। यह किसी प्रकार का स्टेटलेस है, लेकिन "शुद्ध" स्टेटलेस नहीं है। सभी मामलों में, आपको क्लाइंट लॉगिन / लॉगआउट के लिए समर्पित जावास्क्रिप्ट कोड की आवश्यकता होती है, जो कि HTTP डाइजेस्ट ऑथेंट के साथ पूरी तरह से संभव है - अच्छा विचार, लेकिन कोई बड़ा लाभ नहीं, यहां पहिया को सुदृढ़ करने के लिए।

— अरनौद बुचेज़

4

मैं दावा करूंगा कि हेडर को कॉन्फ़िगर करने के लिए सर्वर UI और तर्क को लागू करता है लेकिन हेडर खुद ही स्टेटलेस है। एपीआई के लिए डिज़ाइन किया गया क्लाइंट हेडर को कॉन्फ़िगर करने के लिए सर्वर सहायता का उपयोग कर छोड़ सकता है और बस HTTP बेसिक प्रामाणिक के समान आवश्यक जानकारी पास कर सकता है। मेरा कहना है कि आम यूएएस (ब्राउज़रों) में बेसिक ऑथोर का इतना खराब कार्यान्वयन है कि इसका उपयोग नहीं किया जा सकता है। एक सर्वर किसी अन्य हेडर ( Cookie) में उसी सामान के लिए एमुलेशन प्रदान करता है जिसका उपयोग किया जा सकता है।

— मिक्को रेंटालिनेन

6

मुझे लगता है कि सही जवाब है stackoverflow.com/questions/6068113/...

— graffic

7

HTTP प्राधिकरण के लिए बदसूरत पासवर्ड प्रॉम्प्ट केवल तभी दिखाई देगा जब सर्वर 401 अनधिकृत प्रतिक्रिया को वापस भेजकर अनुरोध करता है। यदि आपको यह पसंद नहीं है, तो इसके बजाय केवल 403 निषिद्ध भेजें। त्रुटि पृष्ठ में लॉगिन करने या उसके लिए एक लिंक शामिल हो सकता है। हालाँकि, कुकीज़ और http प्रमाणीकरण के विरुद्ध सबसे बड़ा तर्क (चाहे राज्य सर्वर साइड हो या क्लाइंट साइड) यह है कि वे क्रॉस-साइट अनुरोध जालसाजी के लिए असुरक्षित हैं। इस कारण से, सबसे अच्छा तरीका एक कस्टम प्राधिकरण योजना, कस्टम प्राधिकरण हेडर या कस्टम GET या POST पैरामीटर है।

— डोबेस वांडरमेर

418

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

एक ब्राउज़र में देखे जाने वाले HTML पृष्ठों का निर्माण करने वाली पुरानी सेवाओं पर HTTP प्रमाणीकरण का उपयोग करने के साथ मुझे जो समस्याएं मिलीं, वे हैं:

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

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

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

सत्रों को केवल निम्नलिखित नियमों के साथ एक समृद्ध संसाधन बनाकर:

एक सत्र उपयोगकर्ता आईडी (और संभवतः टाइमआउट के लिए अंतिम-क्रिया-टाइमस्टैम्प) के लिए एक कुंजी को मैप करता है
यदि कोई सत्र मौजूद है, तो इसका मतलब है कि कुंजी मान्य है।
लॉगिन का मतलब है पोस्ट / सेशन, एक नई कुंजी कुकी के रूप में सेट की गई है
लॉगआउट का अर्थ है DELETEing / session / {key} (अतिभारित POST के साथ, याद रखें, हम एक ब्राउज़र हैं, और HTML 5 अभी तक एक लंबा रास्ता तय करना है)
हर अनुरोध पर कुंजी को कुकी के रूप में भेजकर और जाँच की जाती है कि क्या सत्र मौजूद है और मान्य है

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

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

मुझे लगता है कि यह एक पर्याप्त समाधान है जो ठीक काम करता है, लेकिन मुझे यह स्वीकार करना चाहिए कि मैं इस योजना में संभावित छिद्रों की पहचान करने के लिए एक सुरक्षा विशेषज्ञ के लिए पर्याप्त नहीं हूं - मुझे पता है कि सैकड़ों गैर-उत्साही वेब अनुप्रयोग अनिवार्य रूप से समान का उपयोग करते हैं लॉगिन प्रोटोकॉल (PHP में $ _SESSION, जावा ईई में HttpSession, आदि)। कुकी हेडर सामग्री का उपयोग केवल सर्वर-साइड संसाधन को संबोधित करने के लिए किया जाता है, जैसे अनुवाद-संसाधनों तक पहुंचने के लिए एक स्वीकार-भाषा का उपयोग किया जा सकता है, आदि। मुझे लगता है कि यह वही है, लेकिन शायद दूसरों को नहीं? तुम लोग क्या सोचते हो?

— skrebbel
स्रोत

68

यह एक व्यावहारिक जवाब है और प्रस्तावित समाधान काम करता है। हालांकि, एक ही वाक्य में "Restful" और "सत्र" शब्दों का उपयोग करना सिर्फ गलत है (जब तक कि बीच में "नहीं" भी है;)। दूसरे शब्दों में: सत्रों का उपयोग करने वाली कोई भी वेब सेवा RESTful (परिभाषा के अनुसार) नहीं है। मुझे गलत मत समझो - आप अभी भी इस समाधान (YMMV) का उपयोग कर सकते हैं, लेकिन इसके लिए "RESTful" शब्द का उपयोग नहीं किया जा सकता है। मैं REST पर ओ'रेली पुस्तक की सिफारिश करता हूं जो बहुत पठनीय है और विषय को गहराई से समझाता है।

— जॉन्डोडो

23

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

— जॉन्डोडो

94

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

— स्क्रेबेल

15

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

— मिकको रेंटालिनेन

15

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

— जो फिलिप्स

140

यहाँ पहले से ही अच्छे लोगों द्वारा इस विषय पर पहले से ही कहा गया है। लेकिन यहाँ मेरे 2 सेंट है।

बातचीत के 2 तरीके हैं:

मानव-से-मशीन (HTM)
मशीन से मशीन (एमटीएम)

मशीन सामान्य भाजक है, जिसे REST API के रूप में व्यक्त किया जाता है, और अभिनेता / ग्राहक या तो मनुष्य या मशीन होते हैं।

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

जब हम मानव-टू-मशीन अनुप्रयोगों के संदर्भ में इस पर विचार करते हैं, तो "ब्राउज़र-आधारित" जैसा कि Skrebbel ऊपर इंगित करता है, इसका मतलब है कि ब्राउज़र में चल रहे वेब (वेब) एप्लिकेशन को प्रत्येक अनुरोध के साथ अपने राज्य और प्रासंगिक जानकारी भेजने की आवश्यकता होगी यह बैकस्ट REST API को बनाता है।

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

पहले 2 मामलों में, आपके पास मानव-से-मशीन इंटरैक्शन के लिए एक मामला है, वास्तव में मानव उपयोगकर्ता द्वारा खपत की जा रही जानकारी। अंतिम स्थिति में, आपके पास REST API का उपभोग करने वाला एक मशीन प्रोग्राम है।

प्रमाणीकरण की अवधारणा बोर्ड भर में लागू होती है। आप इसे कैसे डिज़ाइन करेंगे ताकि आपके REST API को एक समान, सुरक्षित तरीके से एक्सेस किया जा सके? जिस तरह से मैं इसे देखता हूं, इसके 2 तरीके हैं:

मार्ग-1:

शुरू करने के लिए कोई लॉगिन नहीं है। हर अनुरोध लॉगिन करता है
ग्राहक अपने पहचान मापदंडों + अनुरोध प्रत्येक अनुरोध के साथ विशिष्ट पैरामीटर भेजता है
REST API उन्हें लेता है, घुमाता है, उपयोगकर्ता के स्टोर (जो कुछ भी है) को पिंग करता है और ऑउटफिट की पुष्टि करता है
यदि सर्वथा स्थापित है, तो अनुरोध को सेवा प्रदान करता है; अन्यथा, उचित HTTP स्थिति कोड से इनकार करता है
अपनी सूची के सभी REST API में प्रत्येक अनुरोध के लिए उपरोक्त को दोहराएं

मार्ग-2:

ग्राहक एक सामान्य अनुरोध के साथ शुरू होता है
एक लॉगिन रीस्ट एपीआई ऐसे सभी अनुरोधों को संभाल लेगा
यह उपयोगकर्ता के स्टोर (LDAP, AD, या MySQL DB इत्यादि) के विरुद्ध स्थिती मापदंडों (API कुंजी, uid / pwd या जो कुछ भी आप चुनते हैं) में लेता है और सत्यापित करता है।
यदि सत्यापित है, तो एक टोकन बनाता है और इसे क्लाइंट / कॉलर को वापस सौंपता है
इसके बाद कॉल करने वाला इस ऑर्किटेक्ट टोकन को रिक्वेस्ट करता है, हर दूसरे रिक्वेस्ट के साथ विशिष्ट परमिशन रिस्ट एपीआई को तब तक भेजता है, जब तक कि लॉग आउट न हो जाए या लीज समाप्त न हो जाए

स्पष्ट रूप से, Way-2 में, REST API को टोकन को मान्य मानने और उस पर भरोसा करने का एक तरीका होगा। लॉग इन एपीआई ने सत्यापन का प्रदर्शन किया, और इसलिए कि "वॉलेट कुंजी" को आपके कैटलॉग में अन्य रीस्ट एपीआई द्वारा भरोसा किया जाना चाहिए।

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

लेकिन मैं पीछे हटा।

मुद्दा यह है, एक "राज्य" (ग्राहक की प्रामाणिक स्थिति के बारे में) को बनाए रखने और साझा करने की आवश्यकता है ताकि सभी रीस्ट एपीआई विश्वास का एक चक्र बना सकें। यदि हम ऐसा नहीं करते हैं, जो कि मार्ग -1 है, तो हमें यह स्वीकार करना चाहिए कि किसी भी / सभी अनुरोधों के प्रमाणीकरण का कार्य किया जाना चाहिए।

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

तो अधिक परतें, अधिक विलंबता।

अब, Way-1 लें और HTM पर लागू करें। क्या आपके (मानव) उपयोगकर्ता को वास्तव में परवाह है अगर आपको हर अनुरोध के साथ uid / pwd / हैश या जो भी भेजना है? नहीं, जब तक कि आप उसे हर सेकंड में ऑर्टिकल / लॉगइन पेज फेंककर परेशान नहीं करते। अगर आप करते हैं तो ग्राहकों का सौभाग्य। इसलिए, आप जो भी करेंगे, वह क्लाइंट की ओर से कहीं न कहीं, लॉगिन जानकारी को स्टोर करने के लिए है, शुरुआत में, और इसे हर अनुरोध के साथ भेजें। (मानव) उपयोगकर्ता के लिए, वह पहले ही लॉग इन कर चुकी है और एक "सत्र" उपलब्ध है। लेकिन वास्तव में, वह हर अनुरोध पर प्रमाणित होता है।

वे -2 के साथ भी। आपका (मानव) उपयोगकर्ता कभी नोटिस नहीं करेगा। इसलिए कोई नुकसान नहीं हुआ।

अगर हम MTM के लिए Way-1 लागू करते हैं तो क्या होगा? इस मामले में, इसकी मशीन के बाद से, हम हर अनुरोध के साथ प्रमाणीकरण जानकारी सबमिट करके पूछकर इस आदमी को नरक से बाहर निकाल सकते हैं। किसी को परवाह नहीं! MTM पर Way-2 का प्रदर्शन कोई विशेष प्रतिक्रिया नहीं देगा; यह एक लानत मशीन है। यह कम देखभाल कर सकता है!

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

अंत में, दर्शन कोई मायने नहीं रखते। क्या वास्तव में मायने रखता है जानकारी की खोज, प्रस्तुति, और खपत अनुभव। यदि लोग आपके API से प्यार करते हैं, तो आपने अपना काम किया है।

— किंग्ज़
स्रोत

3

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

— विष्णु रथ

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

— टॉड बाउर

9

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

— किंग्ज

5

और "स्टेटलेस" सेवा द्वारा, वास्तव में इसका मतलब यह है कि विशेष सर्वर घटक (CRUD APIs) किसी भी राज्य को नहीं ले जाता है। वे एक उपयोगकर्ता को दूसरे से नहीं पहचानते हैं और एक लेनदेन में उपयोगकर्ता के अनुरोध को पूरी तरह से पूरा करते हैं। वह वैराग्य है। लेकिन किसी न किसी को बैठना चाहिए और यह निर्णय लेना चाहिए कि यह उपयोगकर्ता मान्य है या नहीं। ऐसा करने का कोई दूसरा तरीका नहीं है; चाबियाँ या पासवर्ड या जो कुछ भी। उपयोगकर्ता की ओर से पारित कुछ भी प्रमाणित और अधिकृत होना चाहिए।

— किंग्ज

1

आप याद आ रहे हैं Way-3, संकर दृष्टिकोण। क्लाइंट लॉग इन करता है, Way-2लेकिन जैसा कि Way-1, किसी भी सर्वर साइड स्टेट के खिलाफ क्रेडेंशियल्स की जांच नहीं की जाती है। बावजूद, एक टोकन बनाया जाता है और क्लाइंट को वापस भेजा जाता है Way-2। इस टोकन को बाद में किसी भी ग्राहक विशिष्ट स्थिति को देखने के साथ असममित क्रिप्टो का उपयोग करके प्रामाणिकता के लिए जाँच की जाती है।

— 20

50

यहाँ एक सही और पूरी तरह से विश्वसनीय प्रमाणीकरण समाधान है:

प्रमाणीकरण सर्वर पर एक सार्वजनिक / निजी कुंजी जोड़ी बनाएँ।
सभी सर्वरों के लिए सार्वजनिक कुंजी वितरित करें।
जब एक ग्राहक प्रमाणित करता है:

3.1। एक टोकन जारी करें जिसमें निम्नलिखित शामिल हैं:
- समय सीमा समाप्ति समय
- उपयोगकर्ता नाम (वैकल्पिक)
- उपयोगकर्ता आईपी (वैकल्पिक)
- पासवर्ड का हैश (वैकल्पिक)
3.2। निजी कुंजी के साथ टोकन को एन्क्रिप्ट करें।

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

यह स्टेटलेस / रेस्टफुल ऑथेंटिकेशन है।

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

— jcoffland
स्रोत

5

क्या होगा अगर कोई व्यक्ति उस टोकन को पकड़ ले और उसके साथ एपीआई का आह्वान करे और ग्राहक बनने का नाटक करे?

— आबिदी

2

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

— 23

1

क्योंकि केवल प्रमाणीकरण सर्वर निजी कुंजी जानता है। अन्य सर्वर उपयोगकर्ता को केवल सार्वजनिक कुंजी और उपयोगकर्ता टोकन जानने के साथ प्रमाणित कर सकते हैं।

— jcoffland

1

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

— क्रेग

3

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

— क्रेग

37

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

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

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

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

— arg20
स्रोत

2

लोग आपको सत्र का उपयोग करने से मना नहीं कर रहे हैं। आप इसे करने के लिए स्वतंत्र हैं। लेकिन अगर आप ऐसा करते हैं, तो यह REST नहीं है।

— आंद्रे कालदास

6

@ AndréCaldas यह उसी तरह से REST नहीं है जैसे किसी भाषा में फ़ंक्शन या आदिम प्रकार होना ऊप नहीं है। मैं नहीं कह रहा हूँ कि सत्रों का होना उचित है। मैं बस एक हद तक प्रथाओं के एक सेट का पालन करने के बारे में अपनी राय दे रहा हूं, वे अब किसी को लाभ प्रदान नहीं करते हैं। (Btw, ध्यान दें, मैंने आपकी टिप्पणी का विरोध नहीं किया, हालाँकि, मैं यह नहीं कहूंगा कि यह REST नहीं है। मैं कहूंगा कि यह शुद्ध REST नहीं है )।

— arg20

तो अगर हम RESTful नहीं हैं तो हम इसे क्या कहते हैं? और निश्चित रूप से यदि एक अनुरोध में सत्र आईडी शामिल है, तो यह एक उपयोगकर्ता आईडी सहित एक अनुरोध के रूप में स्टेटलेस है? उपयोगकर्ता आईडी के स्टेटलेस और सत्र आईडी के स्टेटफुल क्यों हैं?

— mfhholmes 15

1

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

— डोबेस वांडरमेयर

1

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

— अरनौद बुचेज़

32

सबसे पहले और सबसे महत्वपूर्ण, एक पुरानी वेब सेवा स्थिति है (या दूसरे शब्दों में, बिना किसी कारण के))। इसलिए, एक RESTful सेवा में सत्र या कुकी शामिल होने की अवधारणा नहीं होनी चाहिए। Restful सेवा में प्रमाणीकरण या प्राधिकरण करने का तरीका HTTP प्राधिकरण शीर्ष लेख का उपयोग करके किया गया है जैसा कि RFC 2616 HTTP विशिष्टताओं में परिभाषित किया गया है। हर एक अनुरोध में HTTP प्राधिकरण शीर्षक होना चाहिए, और अनुरोध को HTTP (SSL) कनेक्शन पर भेजा जाना चाहिए। यह सही तरीका है प्रमाणीकरण करने और HTTP रेस्टफुल वेब सेवाओं में अनुरोधों के प्रमाणीकरण को सत्यापित करने के लिए। मैंने सिस्को सिस्टम पर सिस्को PRIME परफॉर्मेंस मैनेजर एप्लिकेशन के लिए एक RESTful वेब सेवा को लागू किया है। और उस वेब सेवा के हिस्से के रूप में, मैंने प्रमाणीकरण / प्राधिकरण को भी लागू किया है।

— रूबेंस
स्रोत

5

HTTP प्रमाणीकरण के लिए अभी भी उपयोगकर्ता आईडी और पासवर्ड का ट्रैक रखने के लिए सर्वर की आवश्यकता होती है। यह पूरी तरह से स्टेटलेस नहीं है।

— जकॉफलैंड

21

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

— एरिक मार्टिनो

3

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

— jcoffland 20

1

@jcoffland इसके अलावा, आपका समाधान साइन किए गए टोकन को डिक्रिप्ट करने के लिए एपीआई सर्वर की क्षमता पर बहुत निर्भर करता है। मुझे लगता है कि यह दृष्टिकोण न केवल बहुत विशिष्ट है, बल्कि यह भी बहुत थोड़ा सा परिष्कृत है कि लगभग आर। फिल्डिंग ने रेस्टफुल प्रमाणीकरण की समस्या से निपटने के लिए ध्यान में रखा था।

— माइकल एकोआ ऑग

2

@jcoffland क्या आप समझते हैं कि गहराई से अधिक गणना-गहन (और इसलिए संसाधन-गहन और गहन रूप से धीमा) असममित एन्क्रिप्शन है? आप एक ऐसी योजना के बारे में बात कर रहे हैं जो हर एक अनुरोध पर असममित एन्क्रिप्शन का उपयोग करेगी। HTTPS का सबसे धीमा पहलू, बार कुछ भी नहीं, प्रारंभिक हैंडशेक है जिसमें सार्वजनिक / निजी कुंजियों का निर्माण शामिल है जो एक साझा रहस्य को असममित रूप से एन्क्रिप्ट करने के लिए उपयोग किया जाता है जिसे बाद में सभी आगामी संचार को सममित रूप से एन्क्रिप्ट करने के लिए उपयोग किया जाता है।

— क्रेग

22

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

इसका सबसे आसान तरीका है RFC 2617 में HTTP के अंतर्निहित प्रमाणीकरण तंत्र के साथ शुरू करना ।

— जस्टिन शेही
स्रोत

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

— jcoffland 20

3

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

— बोरिस बी।

1

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

— jcoffland का

7

मुझे नहीं लगता कि सर्वर पर एक उपयोगकर्ता हैशेड पासवर्ड को संग्रहीत करना सर्वर-साइड राज्य माना जाना चाहिए। उपयोगकर्ता संसाधन हैं, जिसमें नाम, पता या हैशेड पासवर्ड जैसी जानकारी होती है।

— कोडपंकट

15

@Skrebel ( http://www.berenddeboer.net/rest/authentication.html ) द्वारा उल्लिखित The बहुत ही आनंददायक ’लेख प्रमाणीकरण के एक जटिल लेकिन वास्तव में टूटी हुई विधि पर चर्चा करता है।

आप पृष्ठ पर जाने का प्रयास कर सकते हैं (जो केवल प्रमाणित उपयोगकर्ता के लिए देखा जा सकता है) http://www.berenddeboer.net/rest/site/authenticated.html बिना किसी लॉगिन क्रेडेंशियल के।

(क्षमा करें, मैं उत्तर पर टिप्पणी नहीं कर सकता।)

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

— जी हान
स्रोत

स्ट्रिप डॉट कॉम अन्यथा आपकी टिप्पणी पर रेस्ट एंड ऑथेंटिकेशन पर मिक्सिंग न करने के लिए कहेगी ..

— एरिक

स्टेटलेस केवल सर्वर को संदर्भित करता है, क्लाइंट को नहीं। ग्राहक सत्र की सभी स्थिति को याद रख सकता है और प्रत्येक अनुरोध के साथ प्रासंगिक हो सकता है।

— डोबेस वांडरमेयर

अंत में कोई व्यक्ति कुछ समझदारी की बात कर रहा है, लेकिन सार्वजनिक-कुंजी क्रिप्टो का उपयोग करके स्टेटलेस प्रमाणीकरण संभव है। मेरा जवाब देखिए।

— जकॉफलैंड

1

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

— माइकल एकोआ ऑग

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

— क्रेग

12

मुझे लगता है कि बाकी के प्रमाणीकरण में अनुरोध में एक पैरामीटर के रूप में एक प्रमाणीकरण टोकन पारित करना शामिल है। उदाहरण api द्वारा apikeys का उपयोग कर रहे हैं। मेरा मानना है कि कुकीज़ का उपयोग या http योग्यता योग्य नहीं है।

— ब्योर्न
स्रोत

CSRF भेद्यता के कारण कुकीज़ और HTTP प्रामाणिक से बचा जाना चाहिए।

— डोबेस वैंडर्मर

@DobesVandermeer यदि आप मदद कर सकते हैं तो कृपया मेरे प्रश्न को देख सकते हैं? stackoverflow.com/questions/60111743/…

— हेमंत मेटलिया

12

16-फरवरी-2019 को अपडेट करें

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

मुझे लगता है कि निम्नलिखित दृष्टिकोण का उपयोग REST सेवा प्रमाणीकरण के लिए किया जा सकता है:

प्रमाणीकरण के लिए उपयोगकर्ता नाम और पासवर्ड स्वीकार करने के लिए एक लॉगिन RESTful API बनाएं। पारगमन के दौरान सुरक्षा के लिए कैशिंग और एसएसएल को रोकने के लिए HTTP POST विधि का उपयोग करें। सफल प्रमाणीकरण पर, एपीआई दो JWTs लौटाता है - एक एक्सेस टोकन (छोटी वैधता, 30 मिनट का कहना है) और एक ताज़ा टोकन (लंबी वैधता, 24 घंटे)
क्लाइंट (एक वेब आधारित यूआई) JWTs को स्थानीय भंडारण में संग्रहीत करता है और हर बाद की एपीआई कॉल में "ऑथोराइज़ेशन: बियरर #access टोकन" हेडर में एक्सेस टोकन पास करता है।
एपीआई हस्ताक्षर और समाप्ति तिथि की पुष्टि करके टोकन की वैधता की जांच करता है। यदि टोकन वैध है, तो जांचें कि क्या उपयोगकर्ता (यह उपयोगकर्ता नाम के रूप में JWT में "उप" दावे की व्याख्या करता है) के पास एपीआई के साथ कैश लुकअप की पहुंच है। यदि उपयोगकर्ता एपीआई का उपयोग करने के लिए अधिकृत है, तो व्यापार तर्क को निष्पादित करें
यदि टोकन समाप्त हो गया है, तो एपीआई HTTP प्रतिक्रिया कोड 400 लौटाता है
क्लाइंट, 400/401 प्राप्त करने पर, "ऑथराइजेशन: बियरर #refresh टोकन" हेडर में रिफ्रेश टोकन के साथ एक और REST API प्राप्त करता है, जिससे नया एक्सेस टोकन प्राप्त होता है।
ताज़ा टोकन के साथ कॉल प्राप्त करने पर, जांचें कि क्या ताज़ा टोकन हस्ताक्षर और समाप्ति तिथि की जाँच करके वैध है। यदि ताज़ा टोकन मान्य है, तो DB से उपयोगकर्ता के एक्सेस राइट कैश को ताज़ा करें और नए एक्सेस टोकन को लौटाएँ और टोकन ताज़ा करें। यदि ताज़ा टोकन अमान्य है, तो HTTP प्रतिक्रिया कोड 400 वापस करें
यदि कोई नया एक्सेस टोकन और रीफ़्रेश टोकन लौटाया गया है, तो चरण 2 पर जाएँ। यदि HTTP प्रतिक्रिया कोड 400 वापस आ जाता है, तो क्लाइंट मानता है कि ताज़ा टोकन समाप्त हो गया है और उपयोगकर्ता से उपयोगकर्ता नाम और पासवर्ड मांगता है।
लॉगआउट के लिए, स्थानीय भंडारण को शुद्ध करें

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

— सप्तर्षि बसु
स्रोत

उदाहरण के लिए कोणीय के साथ बनाई गई स्थैतिक वेबसाइट के साथ एक एपीआई के लिए आप इसका इस्तेमाल करेंगे? और मोबाइल एप्लिकेशन के बारे में क्या?

— यज़ान रावशदेह

8

ऐसा करने का तरीका है: लॉगिन के लिए OAuth 2.0 का उपयोग करना ।

आप अन्य प्रमाणीकरण विधियों का उपयोग तब कर सकते हैं जब तक Google OAuth का समर्थन करता है।

— मोशे बीरी
स्रोत

1

OAuth2 HTTPS के बिना सुरक्षित नहीं है, न ही स्टेटलेस।

— अरनौद बुचेज़

4

HTTPS के बिना कुछ भी सुरक्षित नहीं है।

— क्रेग

1

@ क्रेग और HTTPS या तो सुरक्षित नहीं हो सकते हैं, यदि प्रमाण पत्र श्रृंखला टूट गई है, जो अधिक अच्छे के लिए हो सकती है - en.wikipedia.org/wiki/Bullrun_(dec एन्क्रिप्शन_program ) ;)

— Arna Bouchez

1

@ArnaudBouchez कृपया स्पष्ट करें कि टूटी हुई प्रमाणपत्र श्रृंखला अधिक से अधिक अच्छे के लिए कैसे है? मुझे समझ नहीं आ रहा है कि आप कहां जा रहे हैं। ;)

— क्रेग

@ क्रेग कृपया लिंक का पालन करें, और आनंद लें! मेरी टिप्पणी में यह "अधिक अच्छा" दृष्टिकोण स्पष्ट रूप से निंदक था: बुलरुन जैसी प्रणालियां हमारी प्यारी और विश्वसनीय सरकारों द्वारा "हमारे अपने अच्छे" के लिए हैं।

— अरनौद बुचेज़

3

एक सार्वजनिक कुंजी घुसपैठ का उपयोग करना जिसमें एक कुंजी के पंजीकरण में उचित बंधन शामिल होता है, यह सुनिश्चित करता है कि सार्वजनिक कुंजी उस व्यक्ति के लिए बाध्य है जिसे इसे इस तरह से सौंपा गया है जो गैर-प्रतिपूर्ति सुनिश्चित करता है

Http://en.wikipedia.org/wiki/Public_key_infrastructure देखें । यदि आप उचित पीकेआई मानकों का पालन करते हैं, तो चोरी की हुई चाबी का अनुचित उपयोग करने वाले व्यक्ति या एजेंट को पहचाना और लॉक किया जा सकता है। यदि एजेंट को प्रमाण पत्र का उपयोग करना आवश्यक है, तो बंधन बहुत तंग हो जाता है। एक चतुर और तेज-तर्रार चोर बच सकता है, लेकिन वे अधिक टुकड़ों को छोड़ देते हैं।

— DonB।
स्रोत

2

मेरी समझ से इस सवाल का जवाब देने के लिए ...

एक प्रमाणीकरण प्रणाली जो REST का उपयोग करती है ताकि आपको अपने सिस्टम में उपयोगकर्ताओं को वास्तव में ट्रैक या प्रबंधित करने की आवश्यकता न हो। यह HTTP तरीकों POST, GET, PUT, DELETE का उपयोग करके किया जाता है। हम इन 4 तरीकों को लेते हैं और डेटाबेस इंटरैक्शन के संदर्भ में उनके बारे में सोचते हैं, जैसे कि, READ, UPDATE, DELETE (लेकिन वेब पर हम POST और GET का उपयोग करते हैं क्योंकि वर्तमान में जो एंकर टैग सपोर्ट करते हैं)। इसलिए POST और GET को हमारे CREATE / READ / UPDATE / DELETE (CRUD) के रूप में माना जाता है, तब हम अपने वेब एप्लिकेशन में मार्गों को डिज़ाइन कर सकते हैं जो सीआरयूडी की कार्रवाई को प्राप्त करने में सक्षम होंगे।

उदाहरण के लिए, रूबी ऑन रेल एप्लिकेशन में हम अपने वेब ऐप का निर्माण कर सकते हैं जैसे कि अगर कोई उपयोगकर्ता जो http://store.com/account/logout में लॉग इन है तो उस पेज का GET लॉगआउट करने का प्रयास करने वाले उपयोगकर्ता के रूप में देखा जा सकता है । हमारे रेल कंट्रोलर में हम उस एक्शन को बनाते हैं जो यूजर को लॉग आउट करता है और होम पेज पर वापस भेज देता है।

प्रवेश पृष्ठ पर एक GET एक फार्म प्राप्त होगा। लॉगिन पृष्ठ पर एक POST को एक लॉगिन प्रयास के रूप में देखा जाएगा और POST डेटा ले और इसे लॉगिन करने के लिए उपयोग करें।

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

मैं अभी भी सीख रहा हूं - अगर आपको कुछ भी मिला है तो मैंने कहा है कि कृपया मुझे सही करें, और यदि आप अधिक पोस्ट सीखते हैं तो इसे यहां वापस करें। धन्यवाद।

2

किसी भी वेब एप्लिकेशन को सुरक्षित करने के लिए मान्य टिप्स

यदि आप अपने एप्लिकेशन को सुरक्षित करना चाहते हैं, तो आपको निश्चित रूप से HTTP के बजाय HTTPS का उपयोग करके शुरू करना चाहिए , यह आपके और उपयोगकर्ताओं के बीच एक सुरक्षित चैनल बनाना सुनिश्चित करता है जो उपयोगकर्ताओं को भेजे गए डेटा को वापस सूँघने से रोकेगा और डेटा को बनाए रखने में मदद करेगा। विनिमय गोपनीय।

Restful API को सुरक्षित करने के लिए आप JWTs (JSON वेब कैम) का उपयोग कर सकते हैं , सर्वर-साइड सत्र की तुलना में इसके कई लाभ हैं, लाभ मुख्य रूप से हैं:

1- अधिक स्केलेबल, चूंकि आपके एपीआई सर्वर को प्रत्येक उपयोगकर्ता के लिए सत्र नहीं बनाए रखने होंगे (जो आपके कई सत्र होने पर बड़ा बोझ हो सकता है)

2- JWT स्वयं सम्‍मिलित हैं और उन दावों को कहते हैं जो उदाहरण के लिए उपयोगकर्ता की भूमिका को परिभाषित करते हैं और वह तिथि और समाप्ति की तारीख तक पहुंच और जारी कर सकते हैं (जिसके बाद JWT मान्य नहीं होगा)

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

4- आपके DB पर कम दबाव और साथ ही आपको प्रत्येक अनुरोध के लिए सत्र आईडी और डेटा को लगातार संग्रहीत और पुनर्प्राप्त नहीं करना होगा

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

कई पुस्तकालय अधिकांश प्रोग्रामिंग भाषाओं में JWTs बनाने और मान्य करने के लिए आसान तरीके प्रदान करते हैं, उदाहरण के लिए: नोड में। सबसे लोकप्रिय में से एक है jsonwebtoken

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

एक महत्वपूर्ण बात यह है कि आपको HTTPS का उपयोग करके क्लाइंट को JWT को सुरक्षित रूप से डिलीवर करना होगा और इसे सुरक्षित स्थान पर सहेजना होगा (उदाहरण के लिए स्थानीय भंडारण में)।

आप इस लिंक से JWTs के बारे में अधिक जान सकते हैं

— अहमद एल्कौसी
स्रोत