अन्य एपीआई प्रमाणीकरण

181

मैं एक एप्लिकेशन बना रहा हूं जिसे एक सर्वर पर होस्ट किया जाएगा। मैं किसी भी प्लेटफ़ॉर्म (वेब ऐप, मोबाइल ऐप) से बातचीत की सुविधा के लिए एप्लिकेशन के लिए एपीआई बनाना चाहता हूं। मुझे समझ में नहीं आ रहा है कि REST API का उपयोग करते समय, हम उपयोगकर्ता को कैसे प्रमाणित करते हैं।

उदाहरण के लिए, जब कोई उपयोगकर्ता लॉग इन किया है और फिर एक फोरम विषय बनाना चाहता है। मुझे कैसे पता चलेगा कि उपयोगकर्ता पहले से लॉग इन है?

api rest

— नूर
स्रोत

4

आपको शायद यहाँ "REST प्रमाणीकरण" खोजना चाहिए। इसे कई अन्य सवालों में कवर किया गया है।

— ब्रायन केली

10

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

— opyate

यह भी देखें कि मेरे वेब विजेट का उपयोग करने वाले को कैसे नियंत्रित किया जाए ।

— अर्जन

@ सुरक्षा की दृष्टि से देखें, तो यह वास्तव में एक अच्छा विचार नहीं है कि सत्र को REST API मामले में कुकीज़ का उपयोग किया जाए, क्योंकि हमलावर उपयोगकर्ता की सहमति के बिना अनुरोध भेज सकते हैं। HTTP हेडर (जैसे प्राधिकरण) में सत्र हैश या टोकन शामिल करना बेहतर है।

— s3v3n

1

@ s3v3n मुझे सही करें अगर मैं गलत हूं, लेकिन आपके और मेरे सुझाव दोनों एक ही चीज़ को प्रभावित करने के लिए हेडर + लोकल स्टोरेज कॉम्बो का उपयोग करने के अलग-अलग तरीके हैं। यह Authorizationहैडर + जैसे ब्राउज़र लोकलस्टोरेज वीएस Cookieहेडर + स्टैंडर्ड ब्राउज़र कुकी स्टोरेज है।

— 10

72

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

मूल प्रमाणीकरण - उपयोगकर्ता और पासवर्ड पर Base64 एन्कोडिंग का उपयोग करता है
डाइजेस्ट ऑथेंटिकेशन - नेटवर्क पर भेजने से पहले यूजरनेम और पासवर्ड को हैश कर दें।

OAuth सबसे अच्छा है जो इसे प्राप्त कर सकता है। ओउथ जो लाभ देता है वह एक प्रतिशोधी या अपेक्षित टोकन है। लागू करने के तरीके का पालन करें: टिप्पणियों से कार्य लिंक: https://www.ida.liu.se/~TDP024/labs/hmacarticle.pdf

— ankitjaininfo
स्रोत

4

कृपया इस सवाल और लेस हेज़लवुड (अपाचे शेरो के लेखक) द्वारा प्रदान किया गया उत्तर पढ़ें ।

— justin.hughey

1

उपयोगी लिंक ट्विटर कैसे सुरक्षित करता है यह अन्य एपीआई है: ट्विटर

— रीस्ट

जैसा कि यह स्वीकृत उत्तर है मुझे लगता है कि यह उल्लेख करना महत्वपूर्ण है कि आप डाइजेस्ट प्रमाणीकरण का भी उपयोग कर सकते हैं। बेसिक और डाइजेस्ट प्रमाणीकरण के बीच अंतर के बारे में यहाँ पढ़ें: stackoverflow.com/questions/9534602/…

— Rayee Roded

116

उदाहरण के लिए, जब उपयोगकर्ता के पास लॉगिन होता है। अब यह कहने दें कि उपयोगकर्ता एक मंच विषय बनाना चाहता है, मुझे कैसे पता चलेगा कि उपयोगकर्ता पहले से लॉग इन है?

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

जांचें कि अमेज़ॅन एडब्ल्यूएस प्रमाणीकरण कैसे करता है। यह एक एपीआई से दूसरे एपीआई के आसपास "हिरन गुजरने" का एक आदर्श उदाहरण है।

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

एक लॉगिन / लॉगआउट एपीआई बनाएं जैसे: /api/v1/loginऔरapi/v1/logout
इन लॉगिन और लॉगआउट एपीआई में, अपने उपयोगकर्ता स्टोर के साथ प्रमाणीकरण करें
परिणाम एक टोकन है (आमतौर पर, JSESSIONID) जो क्लाइंट को भेजा जाता है (वेब, मोबाइल, जो भी हो)
इस बिंदु से, आपके क्लाइंट द्वारा की गई सभी बाद की कॉल में यह टोकन शामिल होगा
मान लीजिए कि आपका अगला कॉल API नाम से बना है /api/v1/findUser
यह एपीआई कोड पहली बार टोकन के लिए जांच करेगा ("क्या यह उपयोगकर्ता प्रमाणित है?"
यदि उत्तर NO के रूप में वापस आता है, तो आप क्लाइंट पर HTTP 401 स्थिति वापस लाते हैं। उन्हें इसे संभालने दो।
यदि उत्तर हां है, तो अनुरोधित उपयोगकर्ता को वापस करने के लिए आगे बढ़ें

बस इतना ही। उम्मीद है की यह मदद करेगा।

— Kingz
स्रोत

तो आप जो वर्णन कर रहे हैं वह अनिवार्य रूप से एक सत्र कुकी है, है ना?

— लॉर्डऑफइग्स पिग्स

हां, लेकिन सत्र 2 अलग-अलग स्थानों पर "बनाए रखा गया" है। एक एपीआई सर्वर में, दूसरा ब्राउज़र में। JSON (या जो भी) वापस ब्राउज़र पोस्ट सफल लॉगिन के लिए प्रतिक्रिया आईडी सर्वर पर सत्र आईडी संचार करना चाहिए। ये सत्र स्वतंत्र रूप से उनके संबंधित एजेंटों द्वारा प्रबंधित किए जाते हैं।

— किंग्ज

11

मेरा मानना है कि किंग्ज इस विचार को लागू करने की कोशिश कर रहा था कि सत्र को बनाए रखने का तंत्र जानबूझकर अस्पष्ट है। एक सत्र कुकी उस तंत्र का सिर्फ एक कार्यान्वयन है।

— justin.hughey

2

@Kingz, इस समाधान में सुरक्षा के बारे में क्या है, उदाहरण के लिए अगर कोई हैकर सेशन_आईडी के साथ लिंक को सूँघता है और अनुरोधों को भेजना शुरू कर देता है जो सत्र का सही है? हम सर्वर कनेक्शन से ssl जोड़कर इसे हल कर सकते हैं, लेकिन ग्राहकों के बारे में क्या?

— अहमद समिलो

1

कैसे बीच-बीच में अटैक मामले में अपहरण को रोकने के लिए?

— m0z4rt 10

38

क्लाइंट को प्रमाणित करने के लिए HTTP बेसिक ऑथेंट का उपयोग करें , लेकिन केवल अस्थायी सत्र टोकन के रूप में उपयोगकर्ता नाम / पासवर्ड का इलाज करें ।

सेशन टोकन हर HTTP रिक्वेस्ट से जुड़ा एक हेडर है , जैसे: Authorization: Basic Ym9ic2Vzc2lvbjE6czNjcmV0

स्ट्रिंग Ym9ic2Vzc2lvbjE6czNjcmV0 ऊपर स्ट्रिंग "bobsession1: s3cret" (जो एक यूजरनेम / पासवर्ड है) Base64 में इनकोडेड है।
ऊपर अस्थायी सत्र टोकन प्राप्त करने के लिए, एक एपीआई फ़ंक्शन (जैसे:) प्रदान करें http://mycompany.com/apiv1/loginजो इनपुट के रूप में मास्टर-उपयोगकर्ता नाम और मास्टर-पासवर्ड लेता है, सर्वर पर एक अस्थायी HTTP बेसिक प्रामाणिक उपयोगकर्ता नाम / पासवर्ड बनाता है, और टोकन लौटाता है (जैसे: Ym9ic2Vzc2lvbjE6czNjcmV0)। यह उपयोगकर्ता नाम / पासवर्ड अस्थायी होना चाहिए, यह 20min या उसके बाद समाप्त हो जाना चाहिए।
अतिरिक्त सुरक्षा के लिए यह सुनिश्चित करें कि आपकी REST सेवा HTTPS पर दी गई है ताकि जानकारी सादा स्थानांतरित न हो

यदि आप जावा पर हैं, तो स्प्रिंग सिक्योरिटी लाइब्रेरी उपरोक्त विधि को लागू करने के लिए अच्छा समर्थन प्रदान करती है

— gerrytan
स्रोत

1

20 मिनट के बाद इसकी अवधि क्यों समाप्त होनी चाहिए? क्या होगा यदि यह फेसबुक जैसी वेबसाइट है जो उपयोगकर्ता के लॉग आउट होने तक लॉगिन है?

— देजेल

1

@ देजेल I इस धारणा के तहत था कि "सत्र" प्रकृति में अस्थायी है। यदि उपयोगकर्ता निष्क्रिय है तो यह समाप्त हो जाना आम बात है

— जेरेतन

Base64 किसके लिए है? आप बस अस्थायी पासवर्ड वापस कर सकते हैं। दोनों मामलों में, वास्तव में क्या मायने रखता है कि यह अस्थायी पासवर्ड मजबूत है। सुरक्षा की

— ।stackexchange.com

7

मुझे लगता है कि OAuth2 का उपयोग करना सबसे अच्छा तरीका है। इसे Google और आपको इसे सेट करने में मदद करने के लिए बहुत सारे उपयोगी पोस्ट मिलेंगे।

वेब ऐप या मोबाइल से अपने एपीआई के लिए क्लाइंट एप्लिकेशन विकसित करना आसान हो जाएगा।

आशा है कि यह आपकी मदद करता है।

— पाउलो हेनरिक
स्रोत

2

कृपया इस सवाल और लेस हेज़लवुड (अपाचे शेरो के लेखक) द्वारा जवाब पढ़ें ।

— justin.hughey

0

मैं JWT प्रमाणीकरण का उपयोग कर रहा हूं। मेरे आवेदन में ठीक काम करता है।

एक प्रमाणीकरण विधि है जिसके लिए उपयोगकर्ता क्रेडेंशियल्स की आवश्यकता होगी। यह विधि क्रेडेंशियल्स को मान्य करती है और सफलता के मामले में एक पहुंच टोकन लौटाती है।

यह टोकन अनुरोध के हेडर में मेरे वेब एपीआई में हर दूसरी विधि को भेजा जाना चाहिए।

इसे लागू करना बहुत आसान है, और परीक्षण करना बहुत आसान है।

— आर्थर मेडिएरोस
स्रोत