2014-12-31 17 views
31

मैं एक मोबाइल ऐप बना रहा हूं और प्रमाणीकरण के लिए जेडब्ल्यूटी का उपयोग कर रहा हूं।जेडब्ल्यूटी रीफ्रेश टोकन प्रवाह

ऐसा लगता है कि ऐसा करने का सबसे अच्छा तरीका है जेडब्ल्यूटी एक्सेस टोकन को रीफ्रेश टोकन के साथ जोड़ना ताकि मैं जितनी बार चाहूं एक्सेस टोकन को समाप्त कर सकूं।

  1. रीफ्रेश टोकन कैसा दिखता है? क्या यह एक यादृच्छिक स्ट्रिंग है? क्या वह स्ट्रिंग एन्क्रिप्टेड है? क्या यह एक और जेडब्ल्यूटी है?
  2. रीफ्रेश टोकन उपयोगकर्ता मॉडल पर डेटाबेस में संग्रहीत किया जाएगा, सही? ऐसा लगता है कि इसे इस मामले में एन्क्रिप्टेड किया जाना चाहिए
  3. क्या मैं उपयोगकर्ता लॉगिन के बाद रीफ्रेश टोकन वापस भेजूंगा, और उसके बाद क्लाइंट एक्सेस-टोकन पुनर्प्राप्त करने के लिए एक अलग मार्ग तक पहुंच जाएगा?
+1

नोट, यदि आप ताज़ा टोकन का उपयोग कर रहे हैं तो आपको उपयोगकर्ताओं को यूआई पर उन्हें अमान्य करने की क्षमता प्रदान करनी चाहिए। यदि उन्हें एक महीने के लिए उदाहरण के लिए उपयोग नहीं किया जाता है तो स्वचालित रूप से उन्हें समाप्त करने की भी अनुशंसा की जाती है। –

+0

@jtmarmon: आप क्लाइंट साइड पर ताज़ा टोकन कैसे स्टोर करते हैं? मेरा मतलब एंड्रॉइड डिवाइस सुरक्षा के साथ है? – j10

उत्तर

11

यह मानते हुए कि इस OAuth 2.0 के बारे में है, क्योंकि यह JWTs के बारे में है और टोकन ताज़ा ...:

  1. सिर्फ एक पहुँच टोकन की तरह, सिद्धांत रूप में एक ताज़ा टोकन के सभी सहित कुछ भी हो सकता आपके द्वारा वर्णित विकल्प; एक जेडब्ल्यूटी का उपयोग तब किया जा सकता है जब प्राधिकरण सर्वर स्टेटलेस बनना चाहता है या इसे पेश करने वाले क्लाइंट को किसी प्रकार के "प्रमाण-के-कब्जे" अर्थशास्त्र को लागू करना चाहता है; ध्यान दें कि रीफ्रेश टोकन एक एक्सेस टोकन से अलग होता है जिसमें यह किसी संसाधन सर्वर को प्रस्तुत नहीं किया जाता है, बल्कि केवल प्राधिकरण सर्वर पर जो इसे पहले स्थान पर जारी करता है, इसलिए जेडब्ल्यूटी-ए-एक्सेस-टोकन के लिए स्वयं निहित सत्यापन अनुकूलन करता है ताज़ा टोकन

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

  3. एक प्राधिकरण सर्वर दोनों टोकन एक्सेस जारी कर सकता है और एक ही समय में टोकन रीफ्रेश करें, अनुदान के आधार पर क्लाइंट द्वारा उन्हें प्राप्त करने के लिए उपयोग किया जाता है; कल्पना मानकीकृत अनुदान

+1

2. आपको अपने डेटाबेस में रीफ्रेश टोकन का हैश स्टोर करना चाहिए और फिर अपने संग्रहीत हैश के साथ उपयोगकर्ता के रीफ्रेश टोकन के हैश की तुलना करना चाहिए। "अपने डेटाबेस में सादा पाठ पासवर्ड स्टोर न करें" का नियम यहां चलता है। उपयोगकर्ता के लिए बनाए गए यादृच्छिक पासवर्ड की तरह टोकन पर विचार करें। – Rohmer

10

इस implementation with Node.js of JWT with refresh token में आधारित में से प्रत्येक पर विवरण और विकल्पों में शामिल हैं:)

1 इस मामले में वे एक uid का उपयोग में है और यह एक जेडब्ल्यूटी नहीं है। जब वे टोकन रीफ्रेश करते हैं तो वे रीफ्रेश टोकन और उपयोगकर्ता भेजते हैं। यदि आप इसे जेडब्ल्यूटी के रूप में कार्यान्वित करते हैं, तो आपको उपयोगकर्ता को भेजने की आवश्यकता नहीं है, क्योंकि यह जेडब्ल्यूटी के अंदर होगा।

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

3) इस कार्यान्वयन में यह दोनों के साथ लॉग इन विधि, टोकन तक पहुंचने और टोकन रीफ्रेश करने के लिए प्रतिक्रिया देता है। यह मेरे लिए सही है।

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