Feathers: ताज़ा टोकन के लिए समर्थन जोड़ें

:+1: @corymsmith और मैं इस बारे में बात कर रहे थे। "छुट्टियों" पर फिनिश लाइन पर इसमें से कुछ को किक करने में मदद करने की उम्मीद है।

इसके लिए हमारे पास मास्टर में समर्थन है लेकिन इसके लिए decoupling शाखा में भी समर्थन है। टोकन रीफ्रेश करने के लिए आपके पास 2 विकल्प हैं:

1. आप ईमेल/पासवर्ड, ट्विटर आदि का उपयोग करके या तो पुनः प्रमाणित कर सकते हैं।
2. आप GET /auth/token/refresh एक वैध टोकन पास कर सकते हैं

हमारे पास एक टोकन नवीनीकरण प्रक्रिया है, लेकिन पूरी तरह से ताज़ा टोकन समर्थन नहीं है जैसा कि मैंने ऊपर पोस्ट किए गए Auth0 लिंक में वर्णित किया है। एक वास्तविक रीफ्रेश टोकन गिटहब ऑथ कोड/पासवर्ड के समान काम करता है, लेकिन इसका उपयोग केवल एक नया जेडब्ल्यूटी टोकन प्राप्त करने के लिए किया जा सकता है। इसलिए भले ही आपका JWT टोकन समाप्त हो जाए, यदि आपके पास एक ताज़ा टोकन है तो आप उसका उपयोग फिर से लॉगिन करने के लिए कर सकते हैं। वे उपयोगकर्ता आईडी के साथ डेटाबेस में बने रहते हैं और किसी भी समय निरस्त किए जा सकते हैं। कम से कम, मैं Auth0 लेख से यही एकत्र कर रहा हूं।

आह आप सही कह रहे हैं @marshallswain। मान लीजिए मुझे लिंक पर क्लिक करना चाहिए था: पलक:

मुझे लगता है कि पहले कट के लिए हम इसे 1.0 मील का पत्थर छोड़ देंगे। लोगों के लिए बस फिर से प्रमाणित करना काफी आसान है।

मैं थोडा वोट देता हूं कि हम इसे feathers-authentication 2.0 चीज बनाते हैं।

महान दिमाग।

मैं अभी भी काफी उलझन में हूं क्योंकि यह स्पष्ट नहीं है कि प्रमाणीकरण वर्कफ़्लो वास्तव में कैसे काम करता है।

मैं अभी जो कर रहा हूं वह है।
1.) ग्राहक उपयोगकर्ता नाम और पासवर्ड भेजें

 curl -X POST https://xxx/auth/local   -H "Content-Type: application/json"   -d '{ "email":"xxx", "password":"yyy"}'

यह जेडब्ल्यूटी टोकन देता है।

{"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJfaWQiOiI1NzhhNjUyN2RkMTZiMjIwMDRhY2ZjNmEiLCJpYXQiOjE0NzAzMjYyODUsImV4cCI6MTQ3MDQxMjY4NSwiaXNzIjoiZmVhdGhlcnMifQ.OVvQbnxfoDGxPFm3Y6tBhRae2Qa6_mDq-PVIo8RcC8Y"}

2.) फिर, मैंने एपीआई तक पहुंचने के लिए इस टोकन को Authorizatin http शीर्षलेख में रखा है।

curl -X GET https://xxx/users  -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJfaWQiOiI1NzhhNjUyN2RkMTZiMjIwMDRhY2ZjNmEiLCJpYXQiOjE0NzAzMjU1NzYsImV4cCI6MTQ3MDQxMTk3NiwiaXNzIjoiZmVhdGhlcnMifQ._CHdx3RpEuI189t90mXq-IMPXRNuoVh7nBwY1ON7xCY'

जो चीज मुझे समझ में नहीं आ रही है वह यह है कि इस टोकन को वास्तव में कैसे रीफ्रेश किया जाए।
मैंने जो कोशिश की, वह यह है कि मैं इस टोकन को xxx/auth/टोकन/रीफ्रेश पर भेजता हूं
मुझे जो मिला वह सिर्फ एक और बहुत लंबा टोकन है। फिर मैंने एपीआई तक पहुँचने के लिए पुराने और इस नए टोकन दोनों का उपयोग करने की कोशिश की। दोनों काम करते हैं... (पुराने को अक्षम नहीं किया जाना चाहिए?)

curl -X GET https://xxx/auth/token/refresh  -H 'Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJfaWQiOiI1NzhhNjUyN2RkMTZiMjIwMDRhY2ZjNmEiLCJpYXQiOjE0NzAzMjU1NzYsImV4cCI6MTQ3MDQxMTk3NiwiaXNzIjoiZmVhdGhlcnMifQ._CHdx3RpEuI189t90mXq-IMPXRNuoVh7nBwY1ON7xCY'
{"query":{"token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJfaWQiOiI1NzhhNjUyN2RkMTZiMjIwMDRhY2ZjNmEiLCJpYXQiOjE0NzAzMjU1NzYsImV4cCI6MTQ3MDQxMTk3NiwiaXNzIjoiZmVhdGhlcnMifQ._CHdx3RpEuI189t90mXq-IMPXRNuoVh7nBwY1ON7xCY"},"provider":"rest","token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJxdWVyeSI6eyJ0b2tlbiI6ImV5SjBlWEFpT2lKS1YxUWlMQ0poYkdjaU9pSklVekkxTmlKOS5leUpmYVdRaU9pSTFOemhoTmpVeU4yUmtNVFppTWpJd01EUmhZMlpqTm1FaUxDSnBZWFFpT2pFME56QXpNalUxTnpZc0ltVjRjQ0k2TVRRM01EUXhNVGszTml3aWFYTnpJam9pWm1WaGRHaGxjbk1pZlEuX0NIZHgzUnBFdUkxODl0OTBtWHEtSU1QWFJOdW9WaDduQndZMU9ON3hDWSJ9LCJwcm92aWRlciI6InJlc3QiLCJ0b2tlbiI6ImV5SjBlWEFpT2lKS1YxUWlMQ0poYkdjaU9pSklVekkxTmlKOS5leUpmYVdRaU9pSTFOemhoTmpVeU4yUmtNVFppTWpJd01EUmhZMlpqTm1FaUxDSnBZWFFpT2pFME56QXpNalUxTnpZc0ltVjRjQ0k2TVRRM01EUXhNVGszTml3aWFYTnpJam9pWm1WaGRHaGxjbk1pZlEuX0NIZHgzUnBFdUkxODl0OTBtWHEtSU1QWFJOdW9WaDduQndZMU9ON3hDWSIsImRhdGEiOnsiX2lkIjoiNTc4YTY1MjdkZDE2YjIyMDA0YWNmYzZhIiwiaWF0IjoxNDcwMzI1NTc2LCJleHAiOjE0NzA0MTE5NzYsImlzcyI6ImZlYXRoZXJzIiwidG9rZW4iOiJleUowZVhBaU9pSktWMVFpTENKaGJHY2lPaUpJVXpJMU5pSjkuZXlKZmFXUWlPaUkxTnpoaE5qVXlOMlJrTVRaaU1qSXdNRFJoWTJaak5tRWlMQ0pwWVhRaU9qRTBOekF6TWpVMU56WXNJbVY0Y0NJNk1UUTNNRFF4TVRrM05pd2lhWE56SWpvaVptVmhkR2hsY25NaWZRLl9DSGR4M1JwRXVJMTg5dDkwbVhxLUlNUFhSTnVvVmg3bkJ3WTFPTjd4Q1kifSwiaWF0IjoxNDcwMzI2NDQyLCJleHAiOjE0NzA0MTI4NDIsImlzcyI6ImZlYXRoZXJzIn0.TqUv3051TTGbX4cPfkN-6pOOB5SN9nH-E7TU1HHSsb8","data":{"_id":"578a6527dd16b22004acfc6a","iat":1470325576,"exp":1470411976,"iss":"feathers","token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJfaWQiOiI1NzhhNjUyN2RkMTZiMjIwMDRhY2ZjNmEiLCJpYXQiOjE0NzAzMjU1NzYsImV4cCI6MTQ3MDQxMTk3NiwiaXNzIjoiZmVhdGhlcnMifQ._CHdx3RpEuI189t90mXq-IMPXRNuoVh7nBwY1ON7xCY"}}

यहां तक ​​​​कि अजीब चीजें भी मैंने इस नए टोकन का उपयोग करने की कोशिश की है और /auth/token/refresh को फिर से भेजने की कोशिश की है।
मुझे इससे भी लंबा टोकन मिला।

मुझे यकीन नहीं है कि मैंने यहां क्या गलत किया या गलत समझा। कृपया सुझाव दे।

@parnurzeal हमारे पास अभी तक ताज़ा टोकन समर्थन नहीं है। इसलिए यह एक प्रस्तावित विशेषता है।

एक नया टोकन प्राप्त करने का तरीका अपने मौजूदा वैध JWT के साथ /auth/token POST करना है या किसी अन्य ऑथ मैकेनिज्म का उपयोग करके लॉगिन करना है। ऐसा लगता है कि आप सब कुछ सही कर रहे हैं।

ठीक है, लेकिन कृपया ध्यान से देखें कि मैंने कैसे किया और मुझे क्या परिणाम मिला।

आइए एक आसान उदाहरण का उपयोग करें।
जब मैं abcdefghijklmno (केवल यादृच्छिक बकवास टोकन) का उपयोग करके एक नए टोकन का अनुरोध करता हूं।
प्रतिक्रिया वापस पिछले टोकन का एक लंबा संस्करण है -> abcdefghijklmnopqrstuvwxyz
अगर मैं abcdefghijklmnopqrstuvwxyz का उपयोग करके इसे फिर से करने का प्रयास करता हूं, तो मुझे इसका एक लंबा संस्करण मिलेगा ->
abcdefghijklmnopqrstuvwxyz1234567890 और लूप जारी रहता है (अधिक अनुरोध करने पर कि आप पिछले वाले का लंबा संस्करण प्राप्त करें)।

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

@parnurzeal जो मैं कह रहा हूं वह वह नहीं है जो आपने किया क्योंकि वह सुविधा वास्तव में लागू नहीं हुई है। कार्यान्वयन के आधार पर (अब तक) तथ्य यह है कि हर बार जब आप /auth/token/refresh हिट करते हैं तो टोकन बढ़ता रहता है क्योंकि हम डेटा को टोकन में वापस भेज रहे हैं। इस तरह से काम करने का इरादा नहीं है और हमारे पास इसे खत्म करने का समय नहीं है और यह दस्तावेज क्यों नहीं है। आपको इसका इस्तेमाल नहीं करना चाहिए।

क्या हमारे द्वारा नए टोकन के लिए अनुरोध करने के बाद पिछला टोकन समाप्त नहीं हो जाना चाहिए?

यह जेडब्ल्यूटी की प्रकृति है। वे अपने टीटीएल से अपने आप समाप्त हो जाते हैं। यदि आप पुराने टोकन का उपयोग होने से रोकना चाहते हैं जो अभी तक समाप्त नहीं हुए हैं तो आपको एक ब्लैकलिस्ट बनाए रखने की आवश्यकता है। वर्तमान में, यह आप पर छोड़ दिया गया है और हमारे पास इसके आसपास एक खुला मुद्दा (#133) है, लेकिन संभवत: जल्द ही (यदि कभी) उस तक नहीं पहुंचेगा।

हाय वहाँ, मैंने /auth/refresh/token में देखा और मैं ऐसा कुछ लेकर आया:

...
function pick (o, ...props) {
  return Object.assign({}, ...props.map(prop => ({[prop]: o[prop]})));
}

// Provider specific config
const defaults = {
  payload: ['id', 'role'],
  passwordField: 'password',
  issuer: 'feathers',
  algorithm: 'HS256',
  expiresIn: '1d', // 1 day
};
...
// GET /auth/token/refresh
  get (id, params) {
    if (id !== 'refresh') {
      return Promise.reject(new errors.NotFound());
    }

    const options = this.options;

    // Add payload fields
    const data = pick(params.payload, options.payload);

    return new Promise(resolve => {
      jwt.sign(data, config.get('auth').token.secret, options, token => {
        return resolve({token: token});
      });
    });

  }

क्या यह कार्यान्वयन के रूप में बहुत भोला है? यदि नहीं, तो मैं पॉलिश करने की कोशिश कर सकता हूं, कुछ परीक्षण जोड़ सकता हूं और पीआर बना सकता हूं।

@aboutlo प्रयास के लिए धन्यवाद! v0.8 के बाहर होने तक प्रतीक्षा करना सबसे अच्छा है (यह अभी कुछ समय के लिए अल्फा में है) क्योंकि इसमें कई बदलाव हुए हैं और हो सकता है कि वह मार्ग इस सप्ताह दूर हो जाए।
मैं आज एक बीटा रिलीज़ काट रहा हूँ और वर्तमान में माइग्रेशन गाइड को समाप्त कर रहा हूँ। तो यह लंबा नहीं होगा और v0.8 auth के साथ कई मौजूदा मुद्दों को संबोधित करता है।

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

काफी उचित @ekryski , मैं 0.8 की प्रतीक्षा करूंगा :)

जब रिएक्ट नेटिव ऐप्स की बात आती है तो यह फीचर जरूरी है। उपयोगकर्ता शुरुआत में लॉग इन करता है और जब वह कई हफ्तों के बाद ऐप खोलता है तो वह अभी भी लॉग इन होने की अपेक्षा करता है।

@deiucanta अच्छी खबर यह है कि हमने [email protected] डिज़ाइन करते समय इस सुविधा को ध्यान में रखा है

ये अच्छी खबर है! उसके लिए तत्पर

@marshallswain इस सुविधा पर अपडेट की प्रतीक्षा कर रहा है। कृपया मुझे बताएं कि हम कब इसकी उम्मीद कर सकते हैं। या यह पहले से ही जारी है? अग्रिम में धन्यवाद।

@deiucanta इस बीच, जब तक यह सुविधा जारी नहीं हो जाती, आप लंबे समय तक

@atulrpandey इसे आधिकारिक तौर पर जारी नहीं किया गया है, लेकिन इसे लागू करना भी मुश्किल नहीं है। आप बस एक नया रीफ्रेश टोकन उत्पन्न करने के लिए एक हुक जोड़ते हैं और डीबी में उपयोगकर्ता ऑब्जेक्ट पर स्टोर करते हैं और एक बार इसका उपयोग या समाप्त होने के बाद आप इसे उपयोगकर्ता से हटा देते हैं।

@petermikitsh एक और चीज जो आप कर सकते हैं (यदि आप मोबाइल पर हैं) क्लाइंट पर सुरक्षित रूप से clientId और clientSecret स्टोर करें और यदि जेडब्ल्यूटी एक्सेस टोकन समाप्त हो जाता है तो आप उन लोगों के साथ फिर से प्रमाणीकरण कर सकते हैं।

@ekryski क्या आप कृपया इनमें से किसी एक रणनीति का उदाहरण प्रदान कर सकते हैं? जो वास्तव में मददगार होगा।
या, क्या आधिकारिक समर्थन जारी होने में लंबा समय लगेगा? यह वास्तव में मोबाइल प्रमाणीकरण में मदद करेगा!

ताज़ा टोकन के विषय पर:

रिफ्रेश टोकन में नई एक्सेस टोकन प्राप्त करने के लिए आवश्यक जानकारी होती है। दूसरे शब्दों में, जब भी किसी विशिष्ट संसाधन तक पहुंचने के लिए एक्सेस टोकन की आवश्यकता होती है, तो क्लाइंट प्रमाणीकरण सर्वर द्वारा जारी एक नया एक्सेस टोकन प्राप्त करने के लिए रीफ्रेश टोकन का उपयोग कर सकता है। सामान्य उपयोग के मामलों में पुराने के समाप्त होने के बाद नए एक्सेस टोकन प्राप्त करना, या पहली बार किसी नए संसाधन तक पहुंच प्राप्त करना शामिल है। रीफ्रेश टोकन भी समाप्त हो सकते हैं लेकिन लंबे समय तक रहते हैं। रीफ्रेश टोकन आमतौर पर सख्त भंडारण आवश्यकताओं के अधीन होते हैं ताकि यह सुनिश्चित हो सके कि वे लीक नहीं हुए हैं। उन्हें प्राधिकरण सर्वर द्वारा https://auth0.com/blog/refresh-tokens-what-are-the-and-when-to-use-them/

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

क्या आप रीफ्रेश टोकन प्राप्त करने के लिए वैध जेडब्ल्यूटी का उपयोग कर सकते हैं? या रीफ्रेश टोकन स्वचालित रूप से प्रमाणीकरण प्रतिक्रिया में लौटाए जाते हैं (उदाहरण के लिए, accessToken )? ऐसा लगता है कि Auth0 उन्हें https://auth0.com/learn/refresh-tokens/ पर उनके उदाहरण में प्रमाणीकरण प्रतिक्रियाओं ( accessToken और refreshToken ) में शामिल कर रहा है ।

@petermikitsh मुझे नहीं लगता कि आपको रीफ्रेश टोकन प्राप्त करने के लिए वैध जेडब्ल्यूटी का उपयोग करने में सक्षम होना चाहिए। यदि आप ऐसा करते हैं, तो कोई भी व्यक्ति JWT प्राप्त कर सकता है और खाते तक पहुंच बना सकता है।

रीफ्रेश टोकन आम तौर पर लॉगिन/साइनअप प्रतिक्रियाओं के साथ लौटाए जाते हैं और फिर क्लाइंट वास्तव में विशिष्ट सत्र के लिए फिर से उन तक पहुंच प्राप्त नहीं कर सकता है जब तक कि वे फिर से लॉगिन/साइनअप न करें जो उन्हें एक नया सत्र और एक नया रीफ्रेश टोकन देता है।

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

कम से कम मैं ऐसा ही करता हूं।

जब तक आप रिफ्रेश टोकन जारी करते हैं और जब आप रीफ्रेश टोकन का उपयोग करने का प्रयास करते हैं, तब तक जब तक आप प्राधिकरण की जांच करते हैं, तब तक रीफ्रेश टोकन प्राप्त करने के लिए वैध जेडब्ल्यूटी का उपयोग करना ठीक होना चाहिए।

@marshallswain

हम वर्तमान में <loginEndpoint>/refresh एक वैध प्रमाणीकरण टोकन पोस्ट करके एक नया टोकन प्राप्त करने की अनुमति देते हैं। रीफ़्रेश टोकन का कार्यप्रवाह थोड़ा भिन्न होता है...

तो फिर इसे renew कहा जाना चाहिए न कि refresh भ्रम से बचने के लिए <loginEndpoint>/renew

जैसा कि @abhishekbhardwaj ने कहा

एक्सेस टोकन, एक्सेस टोकन द्वारा रीफ्रेश करने योग्य नहीं होना चाहिए, लेकिन केवल रीफ्रेश टोकन या उपयोगकर्ता नाम/पासवर्ड द्वारा, रीफ्रेश टोकन केवल उपयोगकर्ता/पासवर्ड प्रमाणीकरण, या किसी अन्य रहस्य द्वारा रीफ्रेश करने योग्य होना चाहिए, जो ब्राउज़र द्वारा पहुंच योग्य नहीं है, जैसे 2 कारक प्रमाणीकरण...

वर्तमान में, एक्सेस टोकन के साथ अपने एक्सेस टोकन को रीफ्रेश करना संभव है, जैसा कि यहां बताया गया है:

https://github.com/phersjs/authentication-jwt/issues/61

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

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

क्या आप इस दृष्टिकोण को कुछ और @ arash16 समझा सकते हैं?

यदि आप एक्सेस टोकन पेलोड में रीफ्रेश-टोकन स्टोर करते हैं, और रीफ्रेश एपीआई समाप्ति की जांच नहीं करता है, तो क्या आपने प्रभावी ढंग से प्रत्येक एक्सेस टोकन को "गैर-समाप्ति" नहीं बनाया है

क्योंकि किसी भी एक्सेस टोकन का उपयोग नया एक्सेस टोकन प्राप्त करने के लिए किया जा सकता है, है ना?

क्या मैं कुछ भूल रहा हूँ?

@बिगएबी
मेरा मतलब है कि केवल रीफ्रेश एपीआई के लिए समाप्ति की जांच न करें, वही एक्सेस टोकन रीफ्रेश-टोकन और एक्सेस-टोकन दोनों के रूप में उपयोग किया जाता है। यह टोकन केवल रीफ्रेश करने और एक नया एक्सेस-टोकन प्राप्त करने के लिए समाप्त नहीं हो रहा है, रीफ्रेश-आईडी स्वयं उपयोगकर्ता द्वारा मैन्युअल रूप से निरस्त किया जा सकता है।

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

टोकन के अंदर रीफ्रेश-आईडी का अधिकांश समय उपयोग नहीं किया जाता है और टोकन समाप्त होने तक प्राधिकरण स्टेटलेस होता है, उसके बाद हमारे पास रीफ्रेश आईडी को सत्यापित करने और एक नया एक्सेस-टोकन वापस करने के लिए डीबी को एक ही कॉल हो सकता है।

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

सुरक्षा के दृष्टिकोण से, इस तरह से उपयोग किए जाने वाले एक्सेस-टोकन को पुराने सत्र-कुंजी की तरह माना जाना चाहिए, अतिरिक्त लाभ के साथ कि हमें हर बार इसे सत्यापित करने के लिए डेटाबेस को कॉल नहीं करना पड़ेगा (केवल एक बार समाप्त हो गया)।

@ arash16 , मुझे जेडब्ल्यूटी एक्सेस के अंदर रीफ्रेश टोकन स्टोर करने का आपका विचार पसंद है। क्या कोई उदाहरण है, सर्वर साइड पर इस रीफ्रेश टोकन को कैसे पुनर्प्राप्त करें?

मेरी वर्तमान समस्या: यदि एक्सेस टोकन की समय सीमा समाप्त हो गई है, तो पेलोड पंखों के हुक संदर्भ में उपलब्ध नहीं है। मुझे लगता है, @feathersjs/authentication पैकेज के verifyJWT() उपयोगिता फ़ंक्शन का उपयोग करने का एक तरीका होगा, उदाहरण के लिए app.service('authentication').hooks({ before: { create: ... } }) शुरुआत में?

क्या अभी पंखों में ताज़ा टोकन का उपयोग करने का कोई ध्यान देने योग्य तरीका है? उनके लिए समर्थन जोड़ने की कोई योजना?

हैलो सभी को ,

ऐसा लगता है कि यह अभी भी उपलब्ध नहीं है (या क्या मुझे कुछ याद आ रहा है)। क्या आप कृपया हमें बता सकते हैं कि यह कब उपलब्ध होगा? मैं देख रहा हूं कि पासपोर्ट रिफ्रेश टोकन रिपोजिटरी उपलब्ध है। किसी ने यह कोशिश की?
https://github.com/fiznool/passport-oauth2-refresh

हैलो @daffl ,
क्या कोई मुझे यह समझने में मदद कर सकता है कि Google रणनीति के लिए टोकन रीफ्रेश कैसे किया जा सकता है? क्योंकि मेरे पास Google लॉगिन परिदृश्य के लिए पासवर्ड नहीं होगा?

धन्यवाद

एक और तरीका है रीफ्रेश टोकन को एक्सेसटोकन के पेलोड के अंदर स्टोर करना

तो कोई भी जिसके पास आपकी एक भी एक्सपायर्ड एक्सेस टोकन है, वह आसानी से एक नए एक्सेस टोकन की अंतहीन गिनती उत्पन्न करने में सक्षम होगा या क्या मुझे कुछ याद आ रहा है?

रिफ्रेश टोकन को क्लाइंट पर सुरक्षित रूप से संग्रहीत किया जाना चाहिए और इस क्लाइंट को छोड़कर किसी के पास उन तक पहुंच नहीं होनी चाहिए!

@deiucanta अच्छी खबर यह है कि हमने [email protected] डिज़ाइन करते समय इस सुविधा को ध्यान में रखा है

यह 2016 में पोस्ट किया गया था। दोस्तों, क्या आपके पास अभी भी इस आवश्यक सुविधा का समर्थन करने की योजना है?

नहीं, आप समय सीमा समाप्त टोकन के साथ कुछ नहीं कर सकते। साथ ही, v4 प्रीरिलीज़ में रीफ़्रेश टोकन अधिक आसानी से संभव हैं। यह कैसे करना है इसके लिए एक कुकबुक प्रविष्टि अंतिम रिलीज का हिस्सा होगी।

साथ ही, v4 प्रीरिलीज़ में रीफ़्रेश टोकन अधिक आसानी से संभव हैं।

क्या कोई अनुमानित रिलीज की तारीख है?

यह कैसे करना है इसके लिए एक कुकबुक प्रविष्टि अंतिम रिलीज का हिस्सा होगी।

जब तक यह मार्गदर्शिका जारी नहीं हो जाती, क्या आप कुछ शब्दों में बता सकते हैं कि इसे v4 प्रीरिलीज़ में कैसे किया जा सकता है?

@daffl पिंग

क्या अभी तक ऐसा करने का कोई आधिकारिक तरीका है? v4 यहाँ है और मुझे दस्तावेज़ों में कुछ भी दिखाई नहीं दे रहा है

@daffl क्या आप विस्तार से

@MichaelErmer वर्कअराउंड के रूप में आप jwt को नवीनीकृत करने के लिए स्थानीय या किसी भी कस्टम रणनीति का उपयोग कर सकते हैं, आदर्श नहीं, लेकिन आंतरिक संचार के लिए ठीक काम करता है, आइए कार्यकर्ता और एपीआई के बीच कहें।

function initAuth() {
  return async (ctx) => {
    if (ctx.path !== 'authentication') {
      const [authenticated, accessToken] = await Promise.all([
        ctx.app.get('authentication'),
        ctx.app.authentication.getAccessToken(),
      ]);

      if (!accessToken || !authenticated) {
        const result = await ctx.app.authenticate(apiLocalCreds);
        ctx.params = {
          ...ctx.params,
          ...result,
          headers: { ...(ctx.params.headers || {}), Authorization: result.accessToken },
        };
      } else {
        const { exp } = decode(accessToken);
        const expired = Date.now() / 1000 > exp - 60 * 60;
        if (expired) {
          const result = await ctx.app.authenticate(apiLocalCreds);
          ctx.params = {
            ...ctx.params,
            ...result,
            headers: { ...(ctx.params.headers || {}), Authorization: result.accessToken },
          };
        }
      }
    }
    return ctx;
  };
}

client
  .configure(rest(apiHost).superagent(superagent))
  .configure(auth(authConfig))
  .hooks({ before: [initAuth()] });

वर्तमान में मैं इस after हुक का उपयोग v4 authentication में कर रहा हूं, 20 दिनों के बाद अपने एक्सेस टोकन को अपडेट करने के लिए ...

````जावास्क्रिप्ट
कॉन्स्ट {डेटटाइम} = आवश्यकता ('लक्सन')
कांस्ट नवीनीकरण के बाद = {दिन: 20}

मॉड्यूल.एक्सपोर्ट्स = () => {
वापसी async प्रसंग => {
अगर (
संदर्भ.विधि === 'बनाएं' &&
संदर्भ प्रकार === 'के बाद' &&
संदर्भ.पथ === 'प्रमाणीकरण' &&
संदर्भ.डेटा && संदर्भ.डेटा.रणनीति === 'jwt' &&
प्रसंग.परिणाम &&
संदर्भ.परिणाम.एक्सेसटोकन) {
// जांचें कि क्या टोकन को नवीनीकृत करने की आवश्यकता है
कॉन्स्ट पेलोड = प्रतीक्षा करें संदर्भ। ऐप। सेवा ('प्रमाणीकरण')। सत्यापित करें एक्सेसटोकन (संदर्भ। परिणाम। एक्सेस टोकन)
कास्ट जारी किया गया = डेटटाइम। मिलिस से (पेलोड.आईएटी * 1000)
const नवीनीकरण के बाद = जारी किया गया। प्लस (नवीनीकरण के बाद)
अब स्थिरांक = दिनांक समय। स्थानीय ()
अगर (अब> नवीनीकरण के बाद) {
संदर्भ.परिणाम.एक्सेसटोकन = प्रतीक्षित संदर्भ.एप.सेवा('प्रमाणीकरण')। createAccessToken({sub: payload.sub})
}
}
वापसी प्रसंग
}
}
````

यह हुक after और अंतिम हुक के रूप में होना महत्वपूर्ण है, ताकि सभी सत्यापन आदि पास हो जाएं

पंखों में ताज़ा टोकन को एकीकृत करने की कोई योजना है?

मैं उस प्रश्न को एक संदेश पहले दूसरा करता हूं।

ताज़ा टोकन वर्कफ़्लो के बारे में भी सोच रहा हूँ। क्या @m0dch3n द्वारा तैयार किया गया समाधान एक अच्छा अभ्यास है? क्या हमें इसे दूसरे तरीके से लागू करना चाहिए?

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

यह XSS से सुरक्षा नहीं करता है, क्योंकि उस स्थिति में, हमलावर क्लाइंट साइड पर संग्रहीत कुछ भी चोरी करने में सक्षम होता है। तो रीफ्रेश टोकन भी ...

अब समस्या यह है कि यदि आप अपने एक्सेस टोकन समाप्ति समय को बहुत छोटा कर देते हैं (अर्थात 5 मिनट), तो आप इसे अधिक बार रीफ्रेश भी करते हैं। बीच में आदमी को केवल 5 मिनट के दौरान ग्राहकों के अनुरोधों को रिफ्रेश टोकन को इंटरसेप्ट करने के लिए सुनने की जरूरत है ...

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

मेरे मामले में, जब मुझे इस तरह के मामले की जानकारी होती है, तो मैं पिछले 40 दिनों के सभी एक्सेस टोकन को ब्लैकलिस्ट कर देता हूं, क्योंकि मेरे एक्सेस टोकन की वैधता 40 दिनों की होती है ...

HTTPS अनुरोध का उपयोग करने से व्यक्ति को बीच के हमलों में वास्तव में मुश्किल होती है। क्या आप HTTPS अनुरोधों का उपयोग नहीं कर रहे हैं?

बेशक मैं https का उपयोग कर रहा हूं, लेकिन एक्सेस टोकन चोरी करने की 3 संभावनाएं हैं। पहला क्लाइंट साइड (XSS यानी) पर है, दूसरा ट्रांसपोर्ट पर (बीच में आदमी), और तीसरा सर्वर साइड पर है।

क्लाइंट और ट्रांसपोर्ट पर, मैं सुरक्षा के लिए केवल आधा जिम्मेदार हूं, और दूसरा आधा क्लाइंट है, जो पूरी तरह से मेरे नियंत्रण में नहीं है। लेकिन मैं XSS को असंभव बनाकर और https...

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

तो यह एकमात्र सुरक्षा लाता है, वह यह है कि 100 अनुरोधों से, यानी, आप परिवहन पर सभी 100 को कमजोर नहीं बनाते हैं, लेकिन केवल 1 अनुरोध करते हैं

तो मूल रूप से मध्य हमले में एक आदमी, एक रीफ्रेश टोकन द्वारा संरक्षित नहीं किया जा सकता है और निश्चित रूप से एक एक्सएसएस द्वारा नहीं ... इसे केवल कम किया जा सकता है, आप कितनी बार इस रीफ्रेश टोकन को प्रेषित करते हैं ... इसे कम संचारित करने की लागत हालांकि, यह है कि एक्सेसटोकन को लंबे समय तक वैध होने की जरूरत है ...

मैं सिर्फ स्लैक चैनल से अपनी टिप्पणियों को कॉपी/पेस्ट करता हूं:

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

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

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

रीफ्रेश टोकन को ठीक से कार्यान्वित करने के लिए, हमें रीफ्रेश टोकन जारी रखने के लिए किसी प्रकार के टोकन स्टोर की आवश्यकता होती है। हमें कम से कम तीन प्रवाहों को लागू करने की भी आवश्यकता है:

टोकन सत्यापन ताज़ा करें
मान्य रीफ़्रेश टोकन के साथ रीफ़्रेश एक्सेस टोकन
छेड़छाड़ किए गए उपयोगकर्ता के रीफ़्रेश टोकन को निरस्त करें

टोकन उपयोग के आँकड़े जैसे अन्य प्रबंधन कार्य भी अच्छे हैं।

रीफ्रेश टोकन को कार्यान्वित करने के तरीके के बारे में मेरी वर्तमान समझ ऊपर है। यह आसान नहीं है लेकिन एक अधिक सुरक्षित प्रणाली का निर्माण करना निश्चित रूप से आवश्यक है।

यह पता चला है कि पंख पहले से ही अंतर्निहित सभी कार्यात्मकताओं/मॉड्यूल में रीफ्रेश-टोकन को ठीक से कार्यान्वित करने के लिए आवश्यक हैं:

1. रीफ्रेश-टोकन स्टोर: पंख सेवा द्वारा आसानी से समर्थित किया जा सकता है।
2. रीफ्रेश टोकन जारी करना और मान्य करना: मौजूदा जेडब्ल्यूटी समर्थन का फिर से उपयोग किया जा सकता है जो अंतर्निहित प्रमाणीकरण सेवा है।

TheSinding (https://github.com/TheSinding/authentication-refresh-token) द्वारा किए गए कार्य के आधार पर, मैंने एक कस्टम सेवा और तीन हुक (https://github.com/) के साथ रिफ्रेश-टोकन का अपना संस्करण लागू किया। jackywxd / पंख-रीफ्रेश-टोकन) जो बुनियादी ताज़ा-टोकन कार्यात्मकताओं को सक्षम करता है:

1. उपयोगकर्ता प्रमाणीकरण सफलतापूर्वक होने के बाद रीफ्रेश-टोकन जारी करें;
2. वैध जेडब्ल्यूटी रीफ्रेश-टोकन के साथ एक्सेस टोकन रीफ्रेश करें;
3. रीफ्रेश-टोकन हटाकर उपयोगकर्ता लॉगआउट करें

फेदर्स में मौजूदा कोड बेस का पूरी तरह से लाभ उठाते हुए, वास्तव में कोडिंग प्रयास न्यूनतम है, और यह वर्तमान फेदर आर्किटेक्चर के साथ अच्छी तरह से एकीकृत होता है। यह साबित करता है कि वर्तमान पंख वास्तुकला बहुत विस्तार योग्य है।

लेकिन रीफ्रेश-टोकन की एक पूर्ण सुविधा के लिए क्लाइंट साइड पर भी समर्थन की आवश्यकता होती है, जैसे क्लाइंट साइड में स्टोर रीफ्रेश-टोकन, एक्सेस-टोकन समाप्ति के बाद उपयोगकर्ता को पुन: प्रमाणित करना, रीफ्रेश-टोकन के साथ लॉगआउट उपयोगकर्ता।

फेदर-ऑथेंटिकेशन और ऑथेंटिकेशन-क्लाइंट के सोर्स कोड की समीक्षा करने के बाद, मेरा मानना ​​​​है कि रिफ्रेश-टोकन को मौजूदा फीचर्स कोड में टैप किया जा सकता है, जो रिफ्रेश-टोकन सपोर्ट को ऑथेंटिकेशन ऑन करने जितना आसान है।

मैंने पहले से ही अपने हुक संस्करण रीफ्रेश-टोकन कोड बेस को @ पंखज/प्रमाणीकरण में पोर्ट कर दिया है। आगे मैं क्लाइंट साइड फीचर्स को सक्षम करने के लिए ऑथेंटिकेशन-क्लाइंट पर बदलाव करने की कोशिश करूंगा। मेरा अंतिम लक्ष्य सर्वर और क्लाइंट दोनों पक्षों में रीफ्रेश-टोकन समर्थन सक्षम करना है।

मेरा प्रश्न/चिंता यह है कि क्लाइंट में रीफ्रेश टोकन कैसे संग्रहीत किया जाएगा?

देखें https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/

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

देखें https://afteracademy.com/blog/implement-json-web-token-jwt-authentication-using-access-token-and-refresh-token

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

कुकी पर यह लंबी चर्चा देखें - https://github.com/phersjs-ecosystem/authentication/issues/132 भी

@bwgjoseph मैं नियमित एक्सप्रेस सत्र का उपयोग करने का सुझाव

@sarkistlt आप सर्वर-साइड पर सभी क्लाइंट जेडब्ल्यूटी टोकन स्टोर करना चाहते हैं? उसके लिए कोई संदर्भ/लेख सामग्री? मुझे बिल्कुल यकीन नहीं है कि प्रक्रिया कैसी होगी। तो क्लाइंट क्या भेजता है, जब वे डेटा (सीआरयूडी) के लिए अनुरोध करते हैं?

@bwgjoseph हमेशा की तरह, कुकी, अपनी सेवाओं को पंजीकृत करने से पहले बस बीच में जोड़ें:

app.use('* | [or specific rout]', session(sess), (req, res, next) => {
      req.feathers.session = req.session || {};
      next();
    });

फिर अपने सर्वर में, मान लें कि ग्राहक लॉगिन सेवा, जब ग्राहक प्रमाणित होता है, तो आप सत्र में टोकन स्टोर करते हैं जैसे ctx.params.session.token = token , जहां टोकन आपकी जेडब्ल्यूटी एक्सेस या रीफ्रेश टोकन है, आपके एप्लिकेशन तर्क पर निर्भर करता है।
और क्लाइंट से किसी भी नए अनुरोध के साथ आप जांच करेंगे कि सत्र में टोकन मौजूद है या नहीं और प्रमाणीकरण के लिए इसका इस्तेमाल करेंगे। यह अधिक सुरक्षित और सुरक्षित दृष्टिकोण है, क्योंकि क्लाइंट की ओर से कोई भी टोकन बिल्कुल भी उजागर नहीं होता है।

मैं सिर्फ यह जोड़ूंगा कि यह क्लाइंट (ब्राउज़र) - सर्वर अनुप्रयोगों के लिए सबसे अच्छा काम करता है। सर्वर, या कार्यकर्ता/सर्वर के बीच आंतरिक रूप से संचार करते समय, आपको सत्र की आवश्यकता नहीं होती है।

इस पर पहले _a बहुत_ चर्चा की गई है (मैंने अक्सर पूछे जाने वाले प्रश्न में एक

इसलिए आमतौर पर टोकन को स्टोर करना ठीक होता है जैसे लोकलस्टोरेज (जिसमें केवल वर्तमान पेज तक ही पहुंच है) और यह अन्य गैर-ब्राउज़र प्लेटफॉर्म (जैसे देशी मोबाइल ऐप, सर्वर-टू-सर्वर आदि) के साथ भी काम करता है। __और websockets__ (मैं इस बात पर जोर नहीं दे सकता कि HTTP कुकीज़ के साथ websockets को निर्बाध और सुरक्षित रूप से काम करना कितना दर्दनाक है - मेरा जीवन बहुत आसान हो गया है क्योंकि हमने ऐसा करने का प्रयास करना बंद कर दिया है)। सामान्य तौर पर, एक ताज़ा टोकन रद्द करने योग्य होना चाहिए, हालांकि यह आमतौर पर बहुत अधिक लंबे समय तक रहता है।

किसी भी तरह, इसके लिए एक पुल अनुरोध का बहुत स्वागत होगा, मुझे लगता है कि यह विवरण को इस्त्री करना बहुत आसान बनाता है।

@jackywxd - बढ़िया काम, इस पर एक संक्षिप्त नज़र
क्या इसे लागू करने वाले डेवलपर के लिए इसे आसान बनाने का कोई तरीका है?
जैसे आपके द्वारा बनाए गए हुक को लाइब्रेरी में एकीकृत करना, इसलिए हमें बाद में हुक जोड़ने की आवश्यकता नहीं होगी?

मुझे लगता है कि आपको एक पुल अनुरोध बनाना चाहिए और हम वहां चर्चा कर सकते हैं।

@daffl हाँ सहमत हैं, खासकर WS के साथ। और यदि क्लाइंट और बैकएंड दोनों आपके या आपकी टीम द्वारा निर्मित होते हैं, तो हाँ, केवल JWT का उपयोग करना और अपने आवेदन में अतिरिक्त निर्भरता और जटिलता से बचना सबसे अच्छा है।
लेकिन कुछ मामलों में, उदाहरण के लिए, स्टोरफ्रंट आरईएसटी-एपीआई का निर्माण करते समय जिसका उपयोग तीसरे पक्ष की कंपनियों/डेवलपर्स द्वारा किया जाएगा, नियमित सत्र का उपयोग करना आसान होता है, और डेवलपर्स से अपने अनुरोधों के साथ क्रेडेंशियल्स शामिल करने के लिए कहें ताकि यह वर्णन किया जा सके कि एक्सेस कैसे प्राप्त करें (और रीफ्रेश करें) ) टोकन, इसे स्टोर करें, और इसे प्रत्येक अनुरोध के साथ पास करें। जिसे पंख क्लाइंट द्वारा पूरी तरह से संभाला जाता है, लेकिन ज्यादातर मामलों में जब डेवलपर बैकएंड के निर्माण से परिचित नहीं होता है, तो वे अपने एप्लिकेशन को बैकएंड से जोड़ने के लिए request, superagent, fetch or axios का उपयोग करेंगे। कम से कम मेरे मामले में एपीआई के स्टोरफ्रंट हिस्से को सीधे जेडब्ल्यूटी के बजाय नियमित सत्रों के साथ काम करने का मुख्य कारण था।

लेकिन क्या यह डिजाइन निर्णय और जिम्मेदारी नहीं होगी, उक्त स्टोरफ्रंट के निर्माता को, अपने स्वयं के एपीआई में लागू करने के लिए और फिर इस निर्णय को समुदाय पर "मजबूर" करने के बजाय इस सुविधा को ठीक से दस्तावेज करना होगा?

@TheSinding मुझे लगता है कि हम कम आम तौर पर इस्तेमाल किए जाने वाले दृष्टिकोण के बारे में 'मजबूर' कह सकते हैं, कुकी के बारे में नहीं जो उपयोगकर्ता सत्रों को प्रबंधित करने के लिए सबसे अधिक इस्तेमाल किया जाने वाला दृष्टिकोण है (और अभी भी है)।

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

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

मैं यह नहीं कह रहा था कि आप गलत थे, मैं बस "ज़ोर से" सोच रहा था :)

आईएमओ, मुझे लगता है कि जेडब्ल्यूटी के साथ दृष्टिकोण एक बेहतर दृष्टिकोण होगा, क्योंकि यह वही है जो पहले से ही समर्थित है और @daffl के साथ काम करना भी आसान है

अपने सभी फ़ीडबैक के लिए शुक्रिया! JWT बनाम सत्र एक अलग विषय है जिस पर हम अलग से चर्चा कर सकते हैं।

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

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

@TheSinding आपके पिछले महान कार्य के लिए धन्यवाद!

क्योंकि मौजूदा प्रमाणीकरण को सामान्य सेवा के रूप में लागू किया गया है, हम आसानी से रीफ्रेश-टोकन समर्थन को कक्षा का विस्तार करके और युगल हुक जोड़कर सक्षम कर सकते हैं:

this.hooks({ after: { create: [issueRefreshToken(), connection('login'), event('login')], remove: [logoutUser(), connection('logout'), event('logout')], patch: [refreshAccessToken()], },

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

@daffl डेविड, पंख बनाने के लिए धन्यवाद! बस सोच रहा है कि पंखों के लिए कोई "योगदान करने वाली मार्गदर्शिका", "कोडिंग दिशानिर्देश", "शैली मार्गदर्शिका" है?

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

• प्रमाणीकरण सेवा का विस्तार करके ताज़ा टोकन जारी किए जा सकते हैं
• रिफ्रेश टोकन को लोकलस्टोरेज में स्टोर किया जाना चाहिए
• रीफ्रेश टोकन को निरस्त करने योग्य होने की आवश्यकता है (इसलिए https://docs.phersjs.com/cookbook/authentication/revoke-jwt.html में वर्णित निरसन तंत्र के अधिक सामान्य उद्देश्य कार्यान्वयन की आवश्यकता है)
• अतिरिक्त जटिलता और सेटअप के कारण (जैसे निरस्त टोकन संग्रहीत करने के लिए रेडिस) यह एक सुविधा के रूप में उपलब्ध हो सकता है लेकिन डिफ़ॉल्ट रूप से सक्षम नहीं होना चाहिए (यानी एक मानक जेनरेट ऐप - सीएलआई का हिस्सा हो सकता है लेकिन उस पर कुछ भी करने से पहले, मैं अभी भी वास्तव में एक हाइजन आधारित जनरेटर शुरू करने में मदद की तलाश में
• योगदानकर्ता मार्गदर्शिका में योगदान की जानकारी मिल सकती है

यदि कोई रिफ्रेशटोकन का उपयोग कर रहा है, तो हम एक पुस्तकालय बनाते हैं जो फ्रंटएंड में हैंडल करता है, एक्सेस टोकन और रीफ्रेशटोकन जैसे "सत्र", उपयोग करने में बहुत आसान है।

केवल टोकन पास करने की आवश्यकता होती है और लाइब्रेरी रीफ्रेश टोकन के साथ एक नया एक्सेस टोकन प्राप्त करने का प्रयास करती है जब समाप्त हो जाएगी। वर्तमान में Videsk में उपयोग किया जाता है।

रिपोजिटरी: फ्रंट ऑथ हैंडलर