यह आपके आवेदन पर निर्भर करता है (आपका खतरा परिदृश्य अधिक सटीक होना चाहिए)।
सबसे आम खतरों में से कुछ हैं - छिपकर बातें सुनने के (-> एन्क्रिप्ट चाहिए) - आदमी बीच में (-> अन्य पार्टी को प्रमाणित करना होगा) - ... तुम्हारा क्या हैं? (आपकी कुकी स्टोर कितनी सुरक्षित है ....)
पहली बार एक कुकी केवल एक टोकन रखती है कि कभी-कभी आपने सफलतापूर्वक प्रमाणीकरण किया है। यदि कुकी लंबे समय तक पर्याप्त है या एन्क्रिप्टेड परिवहन नहीं है, तो एक अच्छा मौका है कि किसी दिन किसी दिन पता चल जाएगा ...
इसके अलावा आपको यह ध्यान रखना होगा कि अतिरिक्त सुरक्षा उपाय पहले और सबसे महत्वपूर्ण हैं एसएसएल।
आपकी प्रमाणीकरण विधि क्या है (क्लाइंट को लॉगऑन करने की आवश्यकता क्या है)? क्या आपके पास पीपीके आधारभूत संरचना के आधार पर प्रमाणीकरण के साथ काम करने की संभावना है या संचार "विज्ञापन-प्रसार" है?
EDIT
Wrt। ओपनऑथ तक: जहां तक मैं प्रोटोकॉल को समझता हूं, इसकी मुख्य चिंता प्रमाणीकरण प्रतिनिधिमंडल है। एक परिदृश्य जहां आप किसी एजेंट को किसी अन्य पहचान की ओर से कुछ विशिष्ट कार्य करने के लिए प्राधिकृत करते हैं। इस तरह आप पूरे वेब पर अपने क्रेडेंशियल स्कैटर नहीं करते हैं। यदि आपके पास ओपनएथ जगह है, तो क्लाइंट सीधे प्रोटोकॉल का भी उपयोग कर सकता है। तो क्यों एक और जोड़ने परेशान है। लेकिन ओपनएथ स्पष्ट रूप से बताता है कि प्रत्यक्ष ग्राहक परिदृश्य के साथ आप फिर से सुरक्षा मुद्दों में भाग लेते हैं क्योंकि अब टोकन डिवाइस पर उपलब्ध है और तदनुसार संरक्षित होना चाहिए (जैसा कि आपको अपनी कुकी के साथ करना होगा)।
आपके उत्तर के लिए धन्यवाद। मान लीजिए कि हम सुरक्षित परिवहन (एसएसएल) और एक उचित समाप्ति नीति का उपयोग करते हैं, जैसे कि वेब ब्राउज़र के साथ, ऐसा लगता है कि आप कह रहे हैं कि यह ठीक होना चाहिए? हम केवल उपयोगकर्ता/पास भेज रहे हैं जैसा आमतौर पर पोस्ट अनुरोध के साथ किया जाता है। – Karan
यह भी सुनिश्चित नहीं है कि मैं समझता हूं कि "ad-hoc" से आपका क्या मतलब है। ऐसा लगता है कि ओएथ/एक्सएथ जैसे कुछ टोकन का उपयोग करने का स्वीकार्य तरीका है, लेकिन इस सवाल का उद्देश्य यह देखना है कि कुकीज़ पर्याप्त होगी या नहीं, क्यों नहीं? – Karan
यदि Sesion/कुकी चोरी आपके लिए कोई मुद्दा नहीं है, तो यह ठीक लगता है। – mtraut