2015-11-11 10 views
5

मैं जेएसओएन वेब टोकन के साथ टोकन-आधारित प्रमाणीकरण के बारे में सीख रहा हूं और यहां मैं मोबाइल ऐप के लिए इसे कैसे देखता हूं, उदाहरण के साथ स्विफ्ट:मोबाइल ऐप से टोकन-आधारित प्रमाणीकरण

  1. मैं उपयोगकर्ता इनपुट का उपयोग करके ऐप के अंदर एक वस्तु बना सकते हैं,

    तरह

    { उपयोगकर्ता नाम: "patrickbateman", पासवर्ड: "ismyknifesharp", भूमिका: "नियमित", । .. }

  2. तब मैं library के साथ एक जेडब्ल्यूटी टोकन उत्पन्न कर सकता हूं।

  3. फिर मैं इसे एक समर्थित API एंडपॉइंट पर भेजता हूं, जैसे /api/contacts/list। या क्या मुझे लॉगिन/पासवर्ड भेजना है क्योंकि वे प्रमाणीकृत हैं?
  4. सर्वर किसी भी तरह टोकन शुद्धता की जांच करता है। पर कैसे? क्या यह सर्वर-जेनरेट किया गया टोकन डेटाबेस में सहेजा जाना चाहिए और कुंजी के रूप में उपयोग किया जाना चाहिए? या क्या मुझे क्लाइंट से अनुरोध प्राप्त होने पर क्लाइंट टोकन में तुलना करने पर सर्वर पर टोकन जेनरेट करना होगा?
  5. मुझे आवश्यक सभी डेटा प्राप्त करें और प्रबंधित करें।

    1. मैं उपयोगकर्ता को प्रमाणित करने सर्वर से प्रवेश/पासवर्ड युग्म भेजने की जरूरत नहीं है:

    यहाँ मेरी निष्कर्ष हैं।

  6. मुझे प्रत्येक बार टोकन भेजने की आवश्यकता होती है जब मुझे केवल-केवल डेटा प्राप्त करने की आवश्यकता होती है।
  7. मुझे कुछ एल्गोरिदम लागू करना चाहिए जो उत्पन्न होने वाले टोकन को कुछ कारकों के कारण बदलता है, जैसे कि समय बीतने, ताकि टोकन को टिकाऊ बनाया जा सके।
  8. मुझे हेडर के अंदर टोकन भेजना चाहिए, लेकिन जरूरी नहीं, क्योंकि यह JSON अनुरोधों के शरीर के अंदर किया जा सकता है।

क्या ये निष्कर्ष सही हैं? क्लाइंट भेजता है टोकन जांचने का तरीका क्या है?

उत्तर

1

मेरे राय:

  1. हम ग्राहक पर उपयोगकर्ता का पासवर्ड नहीं रखना चाहिए। साइन अप/साइन इन करते समय क्लाइंट को सर्वर पर पासवर्ड पोस्ट करना चाहिए, और इसे क्लाइंट में कहीं भी सेव न करें। अनुरोध https होना चाहिए, और पासवर्ड एन्क्रिप्ट नहीं किया जाना चाहिए। हम सर्वर के बाद पासवर्ड को एन्क्रिप्ट करेंगे।

  2. सर्वर उपयोगकर्ता लॉगिन सफलतापूर्वक बाद उपयोगकर्ता के लिए token उत्पन्न करेगा। token में आपकी समय सीमा समाप्त हो जाएगी। सर्वर के साथ अनुमति प्रमाणित करने के लिए हम टोकन का उपयोग करेंगे।

  3. मुझे लगता है कि साइन अप/साइन इन/भूल गए पासवर्ड अनुरोधों को छोड़कर, एपीआई के हर अनुरोध को टोकन प्रदान करना चाहिए।

  4. टोकन अनुरोध के शीर्षलेख के अंदर रखा जाना चाहिए।

  5. सर्वर ग्राहक के अनुरोध के बाद पुराने टोकन के साथ नया टोकन (शायद समाप्त हो गई हो)

और "कैसे सर्वर क्लाइंट से टोकन की जाँच करने के?" के लिए इस सवाल का जवाब अनुमति चाहिए। ऐसा करने के कई तरीके हैं। नीचे दिया गया तरीका मेरा वर्तमान दृष्टिकोण है:

सर्वर पक्ष एक टोकन उत्पन्न करता है, जो user info (जैसे कि टोकन की समय सीमा, उपयोगकर्ता आईडी, उपयोगकर्ता की भूमिका ...) और एक पासवर्ड की एन्क्रिप्टेड स्ट्रिंग है (केवल सर्वर पर रखें पक्ष) एचएमएसी या आरएसए एल्गोरिदम के साथ। जब उपयोगकर्ता token सबमिट करता है, तो सर्वर डिक्रिप्ट कर सकता है और डेटाबेस से पूछे बिना user info, समय समाप्त हो सकता है।

वैसे भी, यह प्रश्न Swift टैग से संबंधित नहीं है।

+0

ग्राहक पक्ष पर पासवर्ड और उपयोगकर्ता नाम रखने का अच्छा विचार क्यों नहीं है? आईओएस में हम उन्हें कीचेन में सुरक्षित रूप से सही स्टोर कर सकते हैं? – user805981

+0

यहां तक ​​कि जब हम उन्हें सुरक्षित तरीके से स्टोर कर सकते हैं, लेकिन इसके लिए कोई लाभ नहीं है। हमें पुनः लॉगिन करने के लिए संग्रहीत पासवर्ड का उपयोग नहीं करना चाहिए। अच्छा तरीका टोकन के साथ काम कर रहा है या उपयोगकर्ता को लॉग इन फॉर्म के माध्यम से फिर से पासवर्ड प्रदान करने की आवश्यकता है। – t4nhpt

+0

मैं देखता हूं। और अगर हम jwt का उपयोग करना चाहते थे और टोकन रीफ्रेश करना चाहते थे। क्या हमें यह निर्धारित करना चाहिए कि किसी भी http अनुरोध भेजने से पहले ग्राहक पक्ष में jwt की समयसीमा समाप्त हो गई है या नहीं? या क्या हमें ज्वेट की अवधि समाप्त होने से पहले jwt की अवधि समाप्त होनी चाहिए और क्लाइंट पक्ष में 400 वापस देना चाहिए? – user805981

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