2017-02-08 12 views
5

मैं अपने वेब एपीआई में एक टोकन-आधारित प्रमाणीकरण बनाना चाहता हूं ताकि तृतीय पक्ष एप्लिकेशन उन एपीआई तक पहुंच सकें।एपीआई प्रमाणीकरण के लिए सबसे अच्छा अभ्यास क्या है?

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

उन आवश्यकताओं के साथ, jwt टोकन प्राप्त करने का सबसे अच्छा अभ्यास क्या है?

क्या मुझे ओपनआईडी या ओएथ 2 जैसे प्रोटोकॉल की आवश्यकता है, या बस, एक एंडपॉइंट का पर्दाफाश करें जो APIKey लेता है और यदि APIKey मान्य है तो यह सुरक्षा टोकन वापस कर देगा?

+0

सबसे अच्छा तरीका तृतीय पक्ष एप्लिकेशन और तृतीय पक्ष के साथ गुप्त कुंजी साझा करना है, गुप्त कुंजी के आधार पर जेडब्ल्यूटी को अपनी तरफ से बनाने के लिए, एपीआई सिर्फ टोकन को सत्यापित करें। –

+0

@ कूंगले क्या आप कृपया टिप्पणी करने के उत्तर के रूप में अपनी टिप्पणी जोड़ सकते हैं? – Homam

+0

क्या मेरी टिप्पणी वास्तव में आपकी समस्या का समाधान करती है? –

उत्तर

2

तो, मैं समझता हूं कि आपकी आवश्यकता मशीन संचार के लिए एक मशीन है। यदि हां, तो सबसे आसान तरीका है "क्लाइंट प्रमाण पत्र OAuth 2.0 का अनुदान प्रवाह" (देखें: documentation)।

उपरोक्त विधि केवल तभी उपयुक्त है यदि आपके डेटा में अत्यधिक संवेदनशील डेटा नहीं है।

दूसरे विकल्प के एक पूरे प्राधिकरण सर्वर को लागू या तो खुद का कोड का उपयोग कर या 3 पार्टी चौखटे का उपयोग कर और (: documentation देखें) "OAuth 2.0 की प्राधिकरण कोड अनुदान प्रवाह" का पालन करने के लिए होगा।

यह विकल्प महंगा होगा और मैं पहले की सिफारिश करता हूं।

+0

तक पहुंचने के लिए स्वीकृति देता है, क्या क्लाइंट_credentials उपयोगकर्ता नाम/पासवर्ड या क्लाइंट आईडी/क्लाइंट रहस्य, या apikey जैसी कुछ भी होनी चाहिए? – Homam

+0

प्राधिकरण कोड अनुदान के लिए उपयोगकर्ता नाम/पासवर्ड क्लाइंट प्रमाण-पत्र अनुदान प्रवाह के लिए क्लाइंट आईडी/क्लाइंट गुप्त। यह मेरे उत्तर में वर्णित आरएफसी दस्तावेज़ लिंक में अच्छी तरह से समझाया गया है। –

5

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

चाहे आपको ओएथ की आवश्यकता हो या नहीं, आपको OWIN (.NET के लिए ओपन वेब इंटरफेस) मिडलवेयर में देखना चाहिए। वर्तमान में हम अपने स्वयं के ओपन एपीआई को OAuth 2.0 Authorization Server कार्यक्षमता के साथ लागू करने के लिए ओविन का उपयोग कर रहे हैं। हालांकि, ओविन एक ओथ प्रमाणीकरण सर्वर को लागू करने तक सीमित नहीं है। निश्चित रूप से यह देखने के लिए एक नज़र डालें कि यह आपकी आवश्यकताओं के अनुरूप हो सकता है या नहीं।

आपके मामले के लिए, OAuth 2.0 को लागू करना आवश्यक नहीं हो सकता है; हालांकि, मैं यही सिफारिश कर रहा हूं। इस समस्या के लिए यह एक अच्छा, सुरक्षित समाधान है। न केवल यह समस्या हल करेगा, बल्कि भविष्य में, यदि आप उपयोगकर्ताओं को तृतीय-पक्ष एकाग्रता को अधिकृत करने की अनुमति देना चाहते हैं, तो OAuth - अधिक सुरक्षित विकल्प - पहले ही लागू किया जाएगा।

यदि आपके पास तीसरे पक्ष के एकीकरण का उपयोग करने वाले उपयोगकर्ता नहीं होंगे, तो आप API कुंजी का उपयोग कर सकते हैं। जब तक आप इसे सुरक्षित तरीके से कार्यान्वित करते हैं, तो यह एक अच्छा विकल्प है। यदि आप जो भी खोज रहे हैं, उससे अधिक है, तो post को एएसपी.NET वेब एपीआई प्रोजेक्ट के लिए तृतीय-पक्ष अनुप्रयोगों को सुरक्षित रूप से प्रमाणित (और अधिकृत) करने के लिए API कुंजी का उपयोग करने के बारे में पढ़ें।

1

मैं एक अलग प्रमाणीकरण सर्वर की तरह अनुशंसा करता हूं, जैसे कि आपका प्रशासन, प्रमाणीकरण और प्रमाणीकरण तर्क/यूआई से अलग रखा जाता है।

एक अच्छा अभ्यास https://github.com/IdentityServer/IdentityServer3 है।

संबंधित मुद्दे