प्रतिष्ठित वेब सेवा - अन्य सेवाओं के अनुरोधों को कैसे प्रमाणित करें?

117

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

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

वे विकल्प जो मैं सोच सकता हूं (या मुझे सुझाव दिया गया है):

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

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

— तोम्मी
स्रोत

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

— यज़्मीर रामिरेज़

एक और सवाल मिला (लगभग दो साल पुराना) जो एक समान विषय को छूता है: stackoverflow.com/questions/1138831/…

— टॉमी

ओएस (वेब और अन्य दोनों) सेवाओं की मेजबानी किस पर की जाती है? क्या वे सर्वरों पर चल रहे हैं जो एक ही बुनियादी ढांचे का हिस्सा हैं?

— एंडर्स एबेल

ओएस अलग-अलग हो सकता है: विन, * निक्स आदि और क्लाइंट सेवाएं मेरी सेवा के समान बुनियादी ढांचे के भीतर हो सकती हैं या नहीं हो सकती हैं।

— टॉमी

34

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

मुझे नहीं लगता कि क्लाइंट सर्टिफिकेट समाधान के लिए आपकी बात ए को हल करना मुश्किल है। आप बस एक शाखा का उपयोग करें। if (client side certificat) { check it } else { http basic auth }मैं कोई जावा विशेषज्ञ नहीं हूँ और मैंने इसके साथ क्लाइंट साइड सर्टिफिकेट करने के लिए कभी काम नहीं किया है। हालाँकि एक त्वरित Google हमें इस ट्यूटोरियल की ओर ले जाता है जो आपकी गली के ठीक ऊपर दिखता है।

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

मुझे पता है कि आपने OAuth के बारे में प्रश्न व्यक्त किए हैं, लेकिन OAuth2 प्रस्ताव में " बेयर टोकन " नामक आपकी समस्या का समाधान शामिल है, जिसे एसएसएल के साथ संयोजन में उपयोग किया जाना चाहिए। मुझे लगता है, सादगी के लिए, मैं या तो हार्ड-कोडेड उपयोगकर्ता / पास (एक ऐप प्रति एक का चयन करता हूं ताकि उन्हें व्यक्तिगत रूप से रद्द किया जा सके) या बहुत समान वाहक टोकन।

— newz2000
स्रोत

27

ग्राहक प्रमाणपत्र एक साझा रहस्य नहीं है। इसलिए वे मौजूद हैं। क्लाइंट के पास एक निजी कुंजी है और सर्वर के पास एक सार्वजनिक कुंजी है। ग्राहक कभी भी इसका रहस्य साझा नहीं करता है, और सार्वजनिक कुंजी एक रहस्य नहीं है।

— टिम

5

ट्यूटोरियल लिंक एक ट्यूटोरियल लेख के लिए नहीं बल्कि Oracle साइट पर कुछ जावा इंडेक्स पेज पर ले जाता है ...

— मार्जन वेनमा

2

@MarjanVenema खैर, ऐसा इसलिए है क्योंकि आप newz2000 के उत्तर देने के बाद +2 साल से लिंक की कोशिश कर रहे हैं, लेकिन आप हमेशा WayBack मशीन आज़मा सकते हैं: web.archive.org/web/20110826004236/http://java.sun.com/…

— Fábio ड्यूक सिल्वा

1

@MarjanVenema: मुझे क्षमा करें, लेकिन आप उम्मीद कर रहे हैं कि यहाँ आने के बाद आपको newz2000 आने और लिंक को अपडेट करने की आवश्यकता होगी? जैसा आपने कहा, यह लिंक सड़ रहा है, इसलिए यह जल्दी या बाद में होता है। या तो आप संग्रह को देखने की कोशिश करते हैं कि लेखक उस समय क्या देख रहा था, या आप नई लिंक ढूंढते हैं और एक सकारात्मक योगदान देते हैं। मैं नहीं देखता कि आपकी टिप्पणी से किसी की मदद कैसे हुई। लेकिन यहाँ, इस लिंक का अनुसरण करें: oracle.com/technetwork/articles/javase/… (सावधान रहें कि यह अंततः सड़ जाएगा)

— Fábio Duque Silva

2

@ FábioSilva: नहीं, मैं उनसे ऐसा करने की उम्मीद नहीं करता। मैंने संग्रह को पढ़ा, लेकिन मेरे पास एक नई कड़ी के लिए शिकार करने का समय नहीं था, इसलिए मैंने अगली सबसे अच्छी बात की: एक टिप्पणी में कहा कि यह मर चुका है इसलिए समुदाय का कोई दूसरा व्यक्ति नया स्थान ढूंढ सकता है और अपडेट कर सकता है पद। जैसा कि स्पष्ट रूप से आपके पास नई लिंक खोजने का समय था, तो आपने मुझे टिप्पणी में शामिल करने के बजाय पोस्ट में लिंक को अपडेट क्यों नहीं किया?

— मार्जन वेनेमा

36

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

प्रमाणीकरण टोकन उत्पन्न करने के लिए यहां एक उदाहरण दिया गया है:

(day * 10) + (month * 100) + (year (last 2 digits) * 1000)

उदाहरण के लिए: 3 जून 2011

(3 * 10) + (6 * 100) + (11 * 1000) = 
30 + 600 + 11000 = 11630

तब उपयोगकर्ता पासवर्ड के साथ संक्षिप्त करें, उदाहरण "my4wesomeP4ssword!"

11630my4wesomeP4ssword!

फिर उस स्ट्रिंग का MD5 करें:

05a9d022d621b64096160683f3afe804

जब आप एक अनुरोध कहते हैं, तो हमेशा इस टोकन का उपयोग करें,

https://mywebservice.com/?token=05a9d022d621b64096160683f3afe804&op=getdata

यह टोकन हमेशा हर दिन अद्वितीय होता है, इसलिए मुझे लगता है कि इस तरह की सुरक्षा हमेशा उर सेवा की रक्षा करने के लिए पर्याप्त से अधिक है।

आशा मदद करती है

:)

— kororo
स्रोत

1

मुझे वास्तव में यह पसंद है कि आपने प्रत्येक अनुरोध में सुरक्षा टोकन को जोड़ दिया, लेकिन क्या होता है जब प्रोग्रामर ने पहले से ही 100 के jsp पृष्ठ बनाए हैं और उसके बाद t0 को पहले बनाए गए 100pages के साथ-साथ बनाए जाने वाले पेजों में भी सुरक्षा को लागू किया है। उस मामले में एक सही विकल्प नहीं में प्रत्येक अनुरोध में टोकन जोड़ रहा है। अपनी तकनीक के लिए एक +1। :)

— अंकुर वर्मा

4

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

— निकग

@NickG, मुझे पहले यह समस्या थी, सर्वर समय का अनुरोध करके इसे सुरक्षित करने का एकमात्र तरीका। यह 99% यूटीसी की समस्या को मार देगा। बेशक नकारात्मक पक्ष सर्वर के लिए एक कॉल है।

— कोररो

लेकिन मैं अभी भी एक दिन के लिए इस टोकन का उपयोग करके आपकी वेब सेवा का उपभोग कर सकता हूं? मैं नहीं देखता कि यह कैसे मदद करेगा

— मीना गैब्रियल

@MinaGabriel आप टोकन पीढ़ी में अधिक समय सीमा जोड़ सकते हैं। (मिनट * 10) + (घंटा * 100) + (दिन * 1000) + (महीना * 10000) + (वर्ष (अंतिम 2 अंक) * 100000)

— कोरोरो

11

कई अलग-अलग दृष्टिकोण हैं जो आप ले सकते हैं।

Restful purists चाहते हैं कि आप BASIC प्रमाणीकरण का उपयोग करें, और हर अनुरोध पर क्रेडेंशियल भेजें। इनका औचित्य यह है कि कोई भी किसी राज्य का भंडारण नहीं कर रहा है।
ग्राहक सेवा एक कुकी संग्रहीत कर सकती है, जो एक सत्र आईडी बनाए रखती है। मैं व्यक्तिगत रूप से इसे आक्रामक नहीं मानता, जैसा कि कुछ शुद्धतावादियों ने मुझे सुना है - यह बार-बार प्रमाणित करना महंगा हो सकता है। ऐसा लगता है कि आप इस विचार के बहुत शौकीन नहीं हैं, हालाँकि।
आपके विवरण से, यह वास्तव में ऐसा लगता है कि आप OAuth2 में दिलचस्पी ले सकते हैं मेरा अनुभव अब तक, मैंने जो देखा है, वह यह है कि यह भ्रामक है, और रक्तस्राव की तरह है। वहाँ बाहर कार्यान्वयन कर रहे हैं, लेकिन वे कुछ और दूर के बीच कर रहे हैं। जावा में, मैं समझता हूं कि इसे स्प्रिंग 3 के सुरक्षा मॉड्यूल में एकीकृत किया गया है । (उनका ट्यूटोरियल अच्छी तरह से लिखा गया है।) मैं यह देखने के लिए इंतजार कर रहा हूं कि क्या रेस्टलेट में कोई एक्सटेंशन होगा , लेकिन अब तक, हालांकि यह प्रस्तावित है, और इनक्यूबेटर में हो सकता है, यह अभी भी पूरी तरह से शामिल नहीं है।

— jwismar
स्रोत

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

— टॉमी

यदि अंतिम-उपयोगकर्ता आपका उपयोगकर्ता है, तो मध्यस्थ सेवा आपके अनुरोधों को पहले अनुरोध पर आपके पास भेज सकती है, और आप एक कुकी या अन्य टोकन वापस कर सकते हैं।

— jwismar

इसी तरह, OAuth परिदृश्य में, अंत-उपयोगकर्ता मध्यस्थ सेवा को आपकी वेब सेवा तक उनकी पहुंच का प्रतिनिधित्व कर रहा है।

— jwismar

एक गलतफहमी होने लगती है - ग्राहक सेवा के पीछे कोई अंतिम उपयोगकर्ता नहीं है । मैंने स्थिति को बेहतर तरीके से समझाने के लिए अपने सवाल को अपडेट किया है।

— टॉमी

1

मैं सिर्फ इतना जोड़ूंगा कि ऊपर सूचीबद्ध # 1 विकल्प केवल HTTPS पर होना चाहिए।

— mr-sk

3

मेरा मानना है कि दृष्टिकोण:

पहला अनुरोध, क्लाइंट आईडी / पासकोड भेजता है
अनन्य टोकन के लिए एक्सचेंज आईडी / पास
प्रत्येक बाद के अनुरोध पर टोकन को समाप्त करें जब तक कि यह समाप्त न हो जाए

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

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

उम्मीद है की यह मदद करेगा

— Dynrepsys
स्रोत

3

जहां तक क्लाइंट सर्टिफिकेट अप्रोच जाता है, तब भी इसे लागू करना बहुत मुश्किल नहीं होगा जबकि अभी भी क्लाइंट सर्टिफिकेट के बिना यूजर्स को अनुमति दी जा सकती है।

यदि आपने वास्तव में अपना स्वयं का हस्ताक्षरित प्रमाणन प्राधिकरण बनाया है, और प्रत्येक ग्राहक सेवा को क्लाइंट सेर जारी किया है, तो आपके पास उन सेवाओं को प्रमाणित करने का एक आसान तरीका होगा।

आपके द्वारा उपयोग किए जा रहे वेब सर्वर के आधार पर, क्लाइंट प्रमाणीकरण को निर्दिष्ट करने के लिए एक विधि होनी चाहिए जो क्लाइंट प्रमाणन को स्वीकार करेगी, लेकिन इसके लिए किसी की आवश्यकता नहीं है। उदाहरण के लिए, टॉमकैट में अपने https कनेक्टर को निर्दिष्ट करते समय, आप 'true' या 'false' के बजाय 'clientAuth = want' सेट कर सकते हैं। फिर आप अपने स्वयं के हस्ताक्षरित CA प्रमाण पत्र को अपने ट्रस्टस्टोर में जोड़ना सुनिश्चित करेंगे (डिफ़ॉल्ट रूप से आपके द्वारा उपयोग किए जा रहे JRE में कैसर्ट फ़ाइल को, जब तक कि आप अपने वेबसर्वर कॉन्फ़िगरेशन में किसी अन्य फ़ाइल को निर्दिष्ट नहीं करते), इसलिए केवल विश्वसनीय प्रमाणपत्र ही जारी किए जाएंगे। अपने हस्ताक्षर किए हुए सीए।

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

मेरी राय में, यह सबसे 'सुरक्षित' तरीका है, लेकिन इसमें निश्चित रूप से इसके सीखने की अवस्था और उपरि है, इसलिए यह आपकी आवश्यकताओं के लिए सबसे अच्छा समाधान नहीं हो सकता है।

— bobz32
स्रोत

3

5. कुछ और - वहाँ अन्य समाधान होना चाहिए?

तुम सही हो, वहाँ है! और इसे JWT (JSON वेब टोकन) कहा जाता है।

JSON वेब टोकन (JWT) एक खुला मानक (RFC 7519) है जो JSON ऑब्जेक्ट के रूप में पार्टियों के बीच सूचना को सुरक्षित रूप से प्रसारित करने के लिए एक कॉम्पैक्ट और स्व-निहित तरीका निर्धारित करता है। यह जानकारी सत्यापित और विश्वसनीय हो सकती है क्योंकि यह डिजिटल रूप से हस्ताक्षरित है। JWTs एक रहस्य (HMAC एल्गोरिथ्म के साथ) या RSA का उपयोग कर एक सार्वजनिक / निजी कुंजी जोड़ी का उपयोग करके हस्ताक्षर किए जा सकते हैं।

मैं अत्यधिक JWTs में देखने की सलाह देता हूं। जब वे वैकल्पिक समाधानों की तुलना में समस्या का अधिक सरल समाधान करते हैं।

https://jwt.io/introduction/

— justin.hughey
स्रोत

1

आप सर्वर पर सत्र बना सकते हैं और sessionIdप्रत्येक REST कॉल के साथ क्लाइंट और सर्वर के बीच साझा कर सकते हैं ।

पहले REST अनुरोध प्रमाणित करें /authenticate:। प्रतिसाद देता है (अपने ग्राहक प्रारूप के अनुसार) sessionId: ABCDXXXXXXXXXXXXXX;
इस स्टोर sessionIdमें Mapवास्तविक सत्र के साथ। Map.put(sessionid, session)या SessionListenerआपके लिए कुंजी बनाने और नष्ट करने के लिए उपयोग ;
```
public void sessionCreated(HttpSessionEvent arg0) {
  // add session to a static Map 
}

public void sessionDestroyed(HttpSessionEvent arg0) {
  // Remove session from static map
}
```
हर REST कॉल के साथ सेशनिड प्राप्त करें, जैसे URL?jsessionid=ABCDXXXXXXXXXXXXXX(या अन्य तरीके से);
HttpSessionमानचित्र का उपयोग करके पुनर्प्राप्त करें sessionId;
यदि सत्र सक्रिय है तो उस सत्र के लिए अनुरोध करें;
प्रतिक्रिया या त्रुटि संदेश भेजें।

— arviarya
स्रोत

0

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

— डेविन एम
स्रोत

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

— टॉमी

अच्छी तरह से टोकन जो आप उत्पन्न करते हैं और दूसरे एप्लिकेशन पर वापस भेजते हैं वह एक लगातार टोकन है, यह उपयोगकर्ता और एप्लिकेशन से जुड़ा हुआ है। यहां फोरस्क्वेयर डॉक्स डेवलपर .foursquare.com/docs/oauth.html का लिंक दिया गया है और यह मूल रूप से oauth2 है इसलिए एक अच्छे प्रमाणीकरण समाधान के लिए इसे देखें।

— डेविन एम

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

— टॉमी

बस अनुप्रयोगों के लिए कुंजी उत्पन्न करें, यदि आप सब कर रहे हैं तो अनुप्रयोगों के लिए उपयोग की अनुमति है तो एक साधारण application_id और application_key प्रमाणीकरण के लिए काम करना चाहिए। यदि आप चाहते हैं कि वे एक टोकन प्रमाणीकरण विकल्प का उपयोग करके एक टोकन लुक के साथ प्रमाणित करें, क्योंकि यह आपके आवेदन के लिए url अनुरोध के साथ एक पैरामीटर होगा।

— डेविन एम

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

— टॉमी

-3

प्रमाणीकरण के अलावा, मेरा सुझाव है कि आप बड़ी तस्वीर के बारे में सोचें। बिना किसी प्रमाणीकरण के अपने बैकएंड Restful सेवा पर विचार करें; फिर अंतिम उपयोगकर्ता और बैकएंड सेवा के बीच कुछ बहुत ही सरल प्रमाणीकरण आवश्यक मध्य परत सेवा को रखें।

— Dagang
स्रोत

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

— टॉमी

बीच की परत वेब सर्वर हो सकती है जैसे कि नग्नेक्स, आप वहां प्रमाणीकरण कर सकते हैं। प्रमाणीकरण मॉडल सत्र आधारित हो सकता है।

— दगांग

जैसा कि मैंने अपने प्रश्न में समझाने की कोशिश की है, मुझे इन क्लाइंट सेवाओं के लिए सत्र-आधारित प्रमाणीकरण योजना नहीं चाहिए। (कृपया मेरे सवालों के अपडेट देखें।)

— टॉमी

मेरा सुझाव है कि आप नाम और पासवर्ड के बजाय सफेद आईपी सूची या आईपी रेंज का उपयोग करें। आमतौर पर, ग्राहक सेवा आईपी स्थिर है।

— Dagang