बाकी एपीआई लॉगिन पैटर्न

Question

मैं एक REST एपीआई बना रहा हूं, संज्ञाओं का उपयोग नहीं करते हुए बारीकी से अपीजी सुझावों का पालन कर रहा हूं, यूआरएल में बेक किए गए एपीआई संस्करण, संग्रह के लिए दो एपीआई पथ, जीईटी पोस्ट पोस्ट डिलीट उपयोग, आदि।

मैं लॉगिन सिस्टम पर काम कर रहा हूं, लेकिन उपयोगकर्ताओं को लॉगिन करने के लिए उचित रीस्ट तरीके से अनिश्चित। मैं इस बिंदु पर सुरक्षा पर काम नहीं कर रहा हूं, बस लॉगिन पैटर्न या प्रवाह। (बाद में हम एक HMAC, आदि के साथ 2 चरण oAuth जोड़ रहे हैं)

संभव विकल्प

• कुछ करने के लिए एक पोस्ट की तरह https://api...com/v1/login.json
• A PUT कुछ इस तरह https://api...com/v1/users.json
• हालांकि मैं कुछ भी नहीं है ...

उपयोगकर्ताओं में प्रवेश करने के लिए उचित REST शैली क्या है?

Comments

वह प्रतिक्रिया स्वरूप है। .json सर्वर को json के साथ प्रतिक्रिया करने के लिए कहता है, .xml सर्वर को xml प्रारूप के साथ प्रतिक्रिया करने के लिए कहता है। बल्कि यह कि इसके पीछे एक वैकल्पिक पैरामीटर बनाना? blog.apigee.com/detail/…

— Scott Roepnack

केवल हेडर में, URL पर की गई सामग्री की बातचीत कभी नहीं देखी गई। URL पर इसका मतलब है कि आप कैशिंग और अधिक का लाभ खो देते हैं।

— Oded

@ScottRoepnack तब आपको AcceptHTTP हेडर पर विचार करना चाहिए ।

— एलेसेंड्रो वेंडरसकोलो

@ यदि आपने Acceptहेडर का उपयोग किया है , तो आपके पास एक भी होगा Vary: Accept, इसलिए कैशिंग प्रभावित नहीं होगा। विस्तार में पहले से ही चर्चा की गई है ; मैं हालांकि शोन्ज़िला के जवाब से सहमत हूँ।

— cuckuckley

@Oded - मुझे समझ नहीं आता। यदि आप URL में सामग्री प्रकार निर्दिष्ट करते हैं (या तो .json प्रत्यय के रूप में क्वेरी पथ या टाइप = json क्वेरी परम के रूप में) तो आप कैशिंग का लाभ क्यों खो देंगे? और इस मामले में "आप" कौन है? वह व्यक्ति कौन है जो कैशिंग लाभ खोता है? यह मुझे लगता है कि किसी भी प्रश्न के परिणाम को उद्धृत किया जा सकता है, भले ही क्वेरी पथ या परम में क्या हो।

— चीजो

Answer 1

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

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

यह प्रतिबंध चार कार्यों को पूरा करता है, इस विशेष मामले में 1 और 3 महत्वपूर्ण हैं:

• पहला : यह कनेक्टर्स के लिए अनुरोधों के बीच आवेदन की स्थिति को बनाए रखने के लिए किसी भी आवश्यकता को हटाता है , इस प्रकार भौतिक संसाधनों की खपत को कम करता है और स्केलेबिलिटी में सुधार करता है;
• 3 : यह एक मध्यस्थ को अलगाव में एक अनुरोध को देखने और समझने की अनुमति देता है , जो आवश्यक हो सकता है जब सेवाओं को गतिशील रूप से पुनर्व्यवस्थित किया जाता है;

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

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

HMAC कार्यान्वयन के कई उदाहरण हैं , लेकिन मैं आपको निम्नलिखित तीन पर ध्यान देना चाहूंगा:

• Amazon Simple Storage Service (Amazon S3) के लिए प्रमाणित अनुरोध
• प्रश्न पर मॉरीशस द्वारा उत्तर: "एक विश्वसनीय WCF API में HMAC प्रमाणीकरण कैसे लागू करें"
• क्रिप्टो-जेएस: मानक और सुरक्षित क्रिप्टोग्राफिक एल्गोरिदम के जावास्क्रिप्ट कार्यान्वयन

यह व्यवहार में कैसे काम करता है

यदि क्लाइंट को गुप्त कुंजी पता है, तो यह संसाधनों के साथ काम करने के लिए तैयार है। अन्यथा वह अस्थायी रूप से पुनर्निर्देशित किया जाएगा (स्थिति कोड 307 अस्थायी पुनर्निर्देशित) को अधिकृत करने और गुप्त कुंजी प्राप्त करने के लिए, और फिर मूल संसाधन पर वापस भेज दिया जाएगा। इस मामले में पहले से जानने की आवश्यकता नहीं है (यानी कहीं हार्डकोड) जो क्लाइंट को अधिकृत करने के लिए URL है , और इस स्कीमा को समय के साथ समायोजित करना संभव है।

आशा है कि यह आपको उचित समाधान खोजने में मदद करेगा!

Comments

मैक का मतलब संदेश की शुद्धता साबित करना और छेड़छाड़ से बचाना है - इसका उपयोगकर्ता प्रमाणीकरण से कोई लेना-देना नहीं है

— yrk

उदाहरणों में से एक को जोड़ा, कैसे " लॉगिन URL " के बारे में पहले से पता किए बिना उपयोगकर्ता / ग्राहक प्रमाणीकरण को संभालना है

— Akim

REST सेवाओं के लिए स्टेटलेस उदाहरणों के साथ एक और दो अच्छे लेख यहां दिए गए हैं: blog.jdriven.com/2014/10/… technicalrex.com/2015/02/20/…

— व्लादिमीर

Answer 2

TL, DR अनुरोध प्रत्येक लॉग के लिए एपीआई सुरक्षा को लागू करने के लिए एक आवश्यक घटक नहीं है, प्रमाणीकरण है।

सामान्य रूप से सुरक्षा के बारे में बात किए बिना लॉगिन के बारे में आपके प्रश्न का उत्तर देना कठिन है। कुछ प्रमाणीकरण योजनाओं के साथ, कोई पारंपरिक लॉगिन नहीं है।

REST किसी भी सुरक्षा नियमों को निर्धारित नहीं करता है, लेकिन व्यवहार में सबसे आम कार्यान्वयन 3-तरीका प्रमाणीकरण के साथ OAuth है (जैसा कि आपने अपने प्रश्न में उल्लेख किया है)। प्रत्येक लॉग में कोई लॉग-इन नहीं है, कम से कम प्रत्येक एपीआई अनुरोध के साथ नहीं है। 3-तरफ़ के साथ, आप केवल टोकन का उपयोग करते हैं।

1. उपयोगकर्ता एपीआई क्लाइंट को मंजूरी देता है और लंबे समय तक टोकन के रूप में अनुरोध करने की अनुमति देता है
2. Api क्लाइंट लंबे समय तक रहने वाले का उपयोग करके एक अल्पकालिक टोकन प्राप्त करता है।
3. Api क्लाइंट प्रत्येक अनुरोध के साथ अल्पकालिक टोकन भेजता है।

यह योजना उपयोगकर्ता को किसी भी समय पहुंच को रद्द करने का विकल्प देती है। व्यावहारिक रूप से सभी सार्वजनिक रूप से उपलब्ध RESTful API को मैंने इसे लागू करने के लिए OAuth का उपयोग करते देखा है।

मुझे नहीं लगता कि आपको लॉगिन के संदर्भ में अपनी समस्या (और प्रश्न) को फ्रेम करना चाहिए, बल्कि सामान्य रूप से एपीआई को सुरक्षित करने के बारे में सोचना चाहिए।

सामान्य रूप से REST API के प्रमाणीकरण के बारे में अधिक जानकारी के लिए, आप निम्नलिखित संसाधनों को देख सकते हैं:

• http://www.infoq.com/news/2010/01/rest-api-authentication-schemes
• अन्य एपीआई प्रमाणीकरण
• प्रतिष्ठित एपीआई प्रमाणीकरण

Comments

हाँ, OAuth! बहुत सीधा सा जवाब, स्वीकृत उत्तर होना चाहिए, इहो।

— लेविट

Answer 3

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

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

लेकिन REST API के लिए, एक लॉगिन स्क्रीन और सत्र कुकीज़ कड़ाई से आवश्यक नहीं हैं, क्योंकि प्रत्येक अनुरोध में एक मानव उपयोगकर्ता को प्रभावित किए बिना क्रेडेंशियल्स शामिल हो सकते हैं; और यदि ग्राहक किसी भी समय सहयोग नहीं करता है, तो 401"अनधिकृत" प्रतिक्रिया दी जा सकती है। RFC 2617 HTTP में प्रमाणीकरण समर्थन का वर्णन करता है।

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

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

Comments

"चूंकि प्रत्येक अनुरोध में एक मानव उपयोगकर्ता को प्रभावित किए बिना क्रेडेंशियल्स शामिल हो सकते हैं" 3-रास्ता प्रमाणीकरण और ओउथ का आविष्कार किया गया था क्योंकि उद्धरण में बात खराब है। यदि आप सर्वर पर एक तंत्र के बिना प्रत्येक अनुरोध के साथ क्रेडेंशियल की आपूर्ति करते हैं तो उन्हें रद्द करने के लिए, यह असुरक्षित होगा यदि w / o SSL का उपयोग किया जाता है।

— स्लाव

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

— १

और अगर आप किसी भी कारण से TLS या OAuth का उपयोग नहीं कर रहे हैं, तो क्या हर बार केवल एक बार भेजने की तुलना में वास्तव में एक उपयोगकर्ता / पासवर्ड भेज रहा है? यदि हमलावर उपयोगकर्ता / पासवर्ड प्राप्त कर सकता है, तो हमलावर संभवतः सत्र कुकी भी प्राप्त कर सकता है।

— wberry

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

— स्लाव