Feathers: أضف دعمًا لرموز التحديث

: +1: corymsmith وأنا نتحدث عن هذا. على أمل المساعدة في دفع بعض هذا فوق خط النهاية خلال "الإجازات".

لدينا دعم لهذا بشكل رئيسي ولكن لدينا أيضًا دعمًا لهذا في الفرع decoupling . لتحديث رمز لديك خياران:

1. يمكنك إما إعادة المصادقة باستخدام البريد الإلكتروني / كلمة المرور ، تويتر ، إلخ.
2. يمكنك تمرير رمز مميز صالح إلى GET /auth/token/refresh

لدينا عملية تجديد الرمز المميز ، ولكن ليس دعمًا كاملاً لرمز التحديث كما هو موضح في رابط Auth0 الذي نشرته أعلاه. يعمل رمز التحديث الفعلي بشكل مشابه لرمز المصادقة / كلمة مرور GitHub ، ولكن لا يمكن استخدامه إلا للحصول على رمز JWT جديد. لذلك حتى إذا انتهت صلاحية رمز JWT الخاص بك ، إذا كان لديك رمز تحديث مميز ، فيمكنك استخدامه لتسجيل الدخول مرة أخرى. يتم الاحتفاظ بها في قاعدة البيانات مع userId سليمة ويمكن إبطالها في أي وقت. على الأقل ، هذا ما أجمعه من مقالة 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"}'

يؤدي هذا إلى إرجاع رمز JWT.

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

2.) بعد ذلك ، قمت بوضع هذا الرمز المميز في رأس Authorizatin http للوصول إلى واجهة برمجة التطبيقات.

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

الشيء الذي لا أفهمه هو بعد ذلك كيفية تحديث هذا الرمز المميز بالفعل.
ما حاولت هو إرسال هذا الرمز المميز إلى xxx / auth / token / Refresh
ما حصلت عليه هو مجرد رمز آخر طويل جدًا. ثم حاولت بعد ذلك استخدام كل من الرمز المميز القديم والجديد للوصول إلى واجهة برمجة التطبيقات. كلا العملين ... (ألا يجب تعطيل القديم؟)

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 ليس لدينا بالفعل دعم رمز التحديث حتى الآن. لهذا السبب هذه ميزة مقترحة.

الطريق للحصول على رمز جديد هي القيام POST إلى /auth/token مع صحيح JWT الموجودة لديك أو تسجيل الدخول باستخدام آلية المصادقة آخر. يبدو أنك تفعل كل شيء بشكل صحيح.

صحيح ، ولكن يرجى إلقاء نظرة فاحصة على كيف فعلت والنتيجة التي حصلت عليها.

دعنا نستخدم مثالا سهلا.
عندما أطلب رمزًا جديدًا باستخدام abcdefghijklmno (مجرد رمز هراء عشوائي).
الرد هو مجرد نسخة أطول من الرمز السابق -> abcdefghijklmnopqrstuvwxyz
إذا حاولت القيام بذلك مرة أخرى باستخدام abcdefghijklmnopqrstuvwxyz ، فسأحصل على نسخة أطول منه ->
abcdefghijklmnopqrstuvwxyz1234567890 وتستمر الحلقة (تطلب المزيد تحصل على نسخة أطول من النسخة السابقة).

أيضًا ، جميع الرموز الثلاثة المذكورة أعلاه قابلة للاستخدام في نفس الوقت.
ألا يجب أن تنتهي صلاحية الرمز السابق بعد أن نطلب رمزًا جديدًا؟

parnurzeal ما أقوله هو لا تفعل ما فعلته لأن هذه الميزة لم يتم تنفيذها بالفعل. استنادًا إلى التنفيذ (حتى الآن) ، فإن حقيقة أن الرمز المميز يستمر في النمو في كل مرة تضغط فيها على /auth/token/refresh لأننا نقوم فقط بدفع البيانات مرة أخرى إلى الرمز المميز. هذه ليست الطريقة التي يُقصد بها العمل ولم يكن لدينا الوقت لإنهائها ولماذا لم يتم توثيق ذلك. ليس من المفترض أن تستخدمها.

ألا يجب أن تنتهي صلاحية الرمز السابق بعد أن نطلب رمزًا جديدًا؟

هذه هي طبيعة نظرية الحرب العادلة. تنتهي صلاحيتها من تلقاء نفسها من TTL. إذا كنت ترغب في منع استخدام الرموز المميزة القديمة التي لم تنته صلاحيتها بعد ، فأنت بحاجة إلى الاحتفاظ بقائمة سوداء. حاليًا ، هذا متروك لك ولدينا مشكلة مفتوحة (رقم 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 الكثير من المشكلات الحالية المتعلقة بالمصادقة.

لقد فكرنا كثيرًا في تحديث الرموز ، لذا بمجرد إصدار 0.8 (هذا الأسبوع) ، أود أن أتطرق إلى هذه المشكلة لمناقشتها. من المحتمل أن أطرح أفكارنا الأولية في وقت لاحق من هذا الأسبوع.

عادل بما يكفي ekryski ، سأنتظر 0.8 :)

هذه الميزة ضرورية عندما يتعلق الأمر بتطبيقات React Native. يسجل المستخدم الدخول في البداية وعندما يفتح التطبيق بعد عدة أسابيع يتوقع أن يظل مسجلاً الدخول.

deiucanta ، الخبر السار هو أننا وضعنا هذه الميزة في الاعتبار أثناء قيامنا بتصميم [email protected]. لا أعتقد أنه سيمر وقت طويل قبل أن نضعها في مكانها ونوثقها.

إنه خبر سار! 👍 أتطلع لذلك

marshallswain نتطلع إلى تحديث هذه الميزة. واسمحوا لي أن أعرف متى نتوقع هذا. أم أنه صدر بالفعل؟ شكرا لك مقدما.

deiucanta في هذه الأثناء ، حتى يتم إطلاق هذه الميزة ، يمكنك استخدام الرموز المميزة ذات العمر الطويل. بمجرد إصداره ، يمكنك تدوير سر المصادقة الخاص بك إلى قيمة جديدة لمسح جميع الجلسات الحالية ، وإحضار جميع المستخدمين على الجلسات الأقصر والتجديد.

atulrpandey لم يتم إصداره رسميًا ولكن ليس من الصعب تنفيذه أيضًا. يمكنك ببساطة إضافة خطاف لإنشاء رمز تحديث جديد وتخزينه على كائن المستخدم في قاعدة البيانات وبمجرد استخدامه أو انتهاء صلاحيته ، يمكنك إزالته من المستخدم.

petermikitsh شيء آخر يمكنك القيام به (إذا كنت تستخدم الهاتف المحمول) هو تخزين clientId و clientSecret بشكل آمن على العميل وإذا انتهت صلاحية JWT accessToken ، فما عليك سوى إعادة المصادقة مع هؤلاء.

ekryski ، هل يمكنك إعطاء مثال على إحدى هذه الاستراتيجيات؟ سيكون ذلك مفيدًا حقًا.
أم أن الإفراج عن الدعم الرسمي سيستغرق وقتًا طويلاً؟ سيساعد هذا حقًا في المصادقة المتنقلة!

حول موضوع تحديث الرموز:

تحمل رموز التحديث المعلومات اللازمة للحصول على رمز وصول جديد. بمعنى آخر ، كلما كان رمز الوصول مطلوبًا للوصول إلى مورد معين ، يجوز للعميل استخدام رمز تحديث للحصول على رمز وصول جديد صادر عن خادم المصادقة. تتضمن حالات الاستخدام الشائعة الحصول على رموز وصول جديدة بعد انتهاء صلاحية الرموز القديمة ، أو الوصول إلى مورد جديد لأول مرة. يمكن أن تنتهي صلاحية رموز التحديث أيضًا ولكنها طويلة العمر إلى حد ما. تخضع رموز التحديث عادةً لمتطلبات تخزين صارمة لضمان عدم تسربها. يمكن أيضًا وضعها في القائمة السوداء بواسطة خادم التفويض. - https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/

لذلك دخلت إلى React Native بنفسي في وقت أقرب مما اعتقدت. أفكر في إمكانية المساهمة في هذا ، لكنني أريد أن أتأكد من أنني أفهم الآليات تمامًا للتأكد من أنها التطبيق الصحيح. نظرًا لأن رموز التحديث ليست عديمة الحالة ، فستكون هناك بعض القيود على الاستخدام (على سبيل المثال ، سيحتاج المطورون إلى توفير محول تخزين).

هل يمكنك استخدام JWT صالح للحصول على رمز التحديث؟ أم يتم إرجاع رموز التحديث تلقائيًا في استجابة المصادقة (على سبيل المثال ، بالإضافة إلى accessToken )؟ يبدو أن Auth0 يقوم بتضمينها في استجابات المصادقة (كل من accessToken و refreshToken ) في مثالهم على https://auth0.com/learn/refresh-tokens/.

petermikitsh لا أعتقد أنه يجب أن تكون قادرًا على استخدام JWT صالح للحصول على رمز التحديث. إذا قمت بذلك ، يمكن لأي شخص الحصول على JWT والاستمرار في الوصول إلى حساب.

عادةً ما يتم إرجاع رموز التحديث مع استجابات تسجيل الدخول / التسجيل ومن ثم لا يمكن للعميل حقًا الوصول إليها مرة أخرى للجلسة المحددة إلا إذا قاموا بتسجيل الدخول / الاشتراك مرة أخرى مما يمنحهم جلسة جديدة ورمزًا جديدًا للتحديث.

لا تحتاج رموز التحديث حقًا إلى انتهاء الصلاحية ولكن يمكن استحضارها إذا تم تخزينها في قاعدة البيانات ، وبهذه الطريقة ، يمكن للمستخدم أيضًا معرفة عدد الجلسات النشطة لديه. يمكنك تخزين المزيد من المعلومات عند إصدار رموز التحديث (مثل نظام التشغيل ، IP ، اسم الجهاز وما إلى ذلك لجعلها قابلة للتعريف - مثل طريقة عمل Facebook و GitHub).

على الأقل هذا كيف أفعل ذلك.

يجب أن يكون استخدام JWT صالحًا للحصول على رمز تحديث مميز طالما أنك تتحقق من التفويض عند إصدار رمز التحديث وعند محاولتك استخدام رمز التحديث المميز.

تضمين التغريدة

نسمح حاليًا بالحصول على رمز مميز جديد عن طريق نشر رمز مصادقة صالح إلى <loginEndpoint>/refresh . رموز التحديث لها سير عمل مختلف قليلاً ...

لذلك يجب أن يطلق عليه renew وليس refresh لتجنب الالتباس <loginEndpoint>/renew

كما قال abhishekbhardwaj

accessToken ، يجب ألا يكون قابل للتحديث عن طريق accessToken ، ولكن فقط عن طريق RefresehToken أو اسم مستخدم / كلمة مرور ، يجب إعادة تنشيط RefreshToken فقط من خلال مصادقة المستخدم / كلمة المرور ، أو بعض الأسرار الأخرى ، والتي لا يمكن الوصول إليها بواسطة المتصفح ، مثل عاملين المصادقة ...

حاليًا ، من الممكن تحديث accessToken الخاص بك باستخدام accessToken ، كما هو مذكور هنا:

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

هناك طريقة أخرى تتمثل في تخزين رمز التحديث داخل حمولة accessToken ، ثم يتحقق تحديث API الحالي إذا لم يتم إبطال رمز التحديث (من خلال قاعدة البيانات أو استدعاء redis). بهذه الطريقة يمكن أن يكون رمز التحديث عبارة عن معرّف زيادة تلقائي بسيط. كما يجب ألا يتحقق تحديث واجهة برمجة التطبيقات من انتهاء الصلاحية بعد الآن. نظرًا لأن رمز التحديث (عدد صحيح بسيط) موقّع برمز وصول ، فهو آمن.

بهذه الطريقة ، يجب أن تكون التغييرات في قاعدة الشفرة الحالية ضئيلة: بالنسبة لواجهة برمجة التطبيقات للتحديث ، توفر طريقة بحيث يمكن للمستخدم توفير خطاف للتحقق مما إذا لم يتم إبطال رمز الوصول (من خلال التحقق من رمز التحديث داخل الحمولة الخاصة به) ، إذا تم توفير هذا الخطاف ، ر التحقق من صحة وقت انتهاء الصلاحية بعد الآن.

هل يمكن أن تشرح هذا النهج أكثر من @ arash16 ؟

إذا قمت بتخزين رمز التحديث في حمولة accessTokens ، ولم تتحقق واجهة برمجة التطبيقات للتحديث من انتهاء الصلاحية ، فأنت لم تجعل كل عملية وصول "غير منتهية الصلاحية" بشكل فعال

لأنه يمكن استخدام أي AccessToken للحصول على رمز وصول جديد ، أليس كذلك؟

هل فاتني شيء؟

تضمين التغريدة
قصدت عدم التحقق من انتهاء الصلاحية فقط من أجل تحديث api ، يتم استخدام نفس accessToken كرمز تحديث ورمز وصول. هذا الرمز المميز غير منتهي الصلاحية فقط للتحديث والحصول على رمز وصول جديد ، يمكن للمستخدم إبطال معرف التحديث نفسه

يجب أن يمتلك المطور db-table / redis لتخزين جميع معرّفات التحديث. عندما يحتاج المستخدم إلى إبطال بعض (أو كل) الجلسات الأخرى أو تسجيل الخروج منها ، يمكننا تزويده بقائمة بجميع معرفات التحديث (بالإضافة إلى بعض المعلومات الإضافية الأخرى مثل المتصفح أو تاريخ الإنشاء وما إلى ذلك) ويختار إزالة (تسجيل الدخول) -منهم) بشكل انتقائي. بعد ذلك بمجرد انتهاء صلاحية الرمز المميز الذي يحتوي على معرّفات التحديث ، يرفض تحديث api إعطاء رمز جديد.

لا يتم استخدام رمز التحديث الداخلي في معظم الأوقات ويكون التفويض عديم الحالة حتى تنتهي صلاحية الرمز المميز ، وبعد ذلك قد يكون لدينا مكالمة واحدة إلى db للتحقق من صحة معرف التحديث وإرجاع رمز وصول جديد.

قد يكون وقت انتهاء صلاحية رمز الوصول قصيرًا (أقل من 10 دقائق) ، ويمكن للمستخدم إغلاق الصفحة والمشي بعيدًا ، في وقت لاحق عندما يفتح رمز الوصول إلى الصفحة منتهي الصلاحية بالفعل وتم تسجيل الخروج. لكن معرّف التحديث داخل الرمز المميز لديه وقت أطول للعيش تتم إدارته بواسطة قاعدة البيانات (على سبيل المثال 7 أو 30 يومًا) ، ويمكن أيضًا الإلغاء يدويًا.

من وجهة نظر الأمان ، يجب التعامل مع رمز الوصول المستخدم بهذه الطريقة كمفتاح جلسة قديم ، مع فائدة إضافية لن نضطر إلى استدعاء قاعدة البيانات للتحقق من صحتها في كل مرة (مرة واحدة فقط منتهية الصلاحية).

@ arash16 ، تعجبني فكرتك لتخزين رمز التحديث داخل JWT للوصول. هل هناك أي مثال على كيفية استرداد رمز التحديث هذا من جانب الخادم؟

مشكلتي الحالية: إذا انتهت صلاحية رمز الوصول ، فإن الحمولة غير متوفرة في سياق ربط الريش. أعتقد، أن طريقة هي استخدام verifyJWT() ظيفة فائدة @feathersjs/authentication حزمة، على سبيل المثال في البداية من app.service('authentication').hooks({ before: { create: ... } }) ؟

هل هناك أي طريقة واعية لاستخدام رموز التحديث في الريش الآن؟ أي خطط لإضافة الدعم لهم؟

اهلا جميعا ،

يبدو أنه لا يزال غير متوفر (أو هل فقدت شيئًا ما). هل يمكنك إخبارنا عندما يكون متاحًا؟ أرى أن هناك مستودعًا لرمز تحديث جواز السفر متاح. هل حاول أحد هذا؟
https://github.com/fiznool/passport-oauth2-refresh

مرحبا daffl ،
هل يمكن لأي شخص مساعدتي في فهم كيفية تحديث الرمز المميز لاستراتيجية Google؟ لأنني لن أمتلك كلمة مرور لسيناريو تسجيل الدخول إلى google؟

شكرا

هناك طريقة أخرى تتمثل في تخزين رمز التحديث داخل حمولة accessToken

لذلك أي شخص لديه حتى واحدة من رموز الوصول منتهية الصلاحية الخاصة بك سيتمكن بسهولة من إنشاء عدد لا نهائي من رموز الوصول الجديدة أو هل أفتقد شيئًا ما؟

يجب تخزين رموز التحديث بأمان على العميل ولا يجب أن يتمكن

deiucanta ، الخبر السار هو أننا وضعنا هذه الميزة في الاعتبار أثناء قيامنا بتصميم [email protected]. لا أعتقد أنه سيمر وقت طويل قبل أن نضعها في مكانها ونوثقها.

تم نشر هذا في عام 2016. أيها الرجال ، هل لا تزال لديك خطط لدعم هذه الميزة التي لا غنى عنها؟

لا ، لا يمكنك فعل أي شيء برمز منتهي الصلاحية. أيضًا ، يمكن الحصول على رموز التحديث بسهولة أكبر في الإصدار التجريبي من الإصدار 4 . سيكون إدخال كتاب الطبخ حول كيفية القيام بذلك جزءًا من الإصدار النهائي.

أيضًا ، يمكن الحصول على رموز التحديث بسهولة أكبر في الإصدار التجريبي من الإصدار 4 .

هل هناك تاريخ إصدار تقريبي؟

سيكون إدخال كتاب الطبخ حول كيفية القيام بذلك جزءًا من الإصدار النهائي.

حتى يتم إصدار هذا الدليل ، هل يمكن أن تشرح ببضع كلمات كيف يمكن القيام به في الإصدار 4 من الإصدار التجريبي؟

تضمين التغريدة

هل هناك طريقة رسمية للقيام بذلك حتى الآن؟ الإصدار 4 هنا ولا أرى أي شيء في المستندات

daffl هل يمكنك توضيح كيف يمكن تحقيق ذلك باستخدام 4.0 وبدون اختراق لخدمة المصادقة؟

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 في الإصدار 4 authentication لتحديث accessToken الخاص بي بعد 20 يومًا ...

جافا سكريبت
const {DateTime} = تتطلب ('luxon')
التجديد المستمر بعد = {الأيام: 20}

module.exports = () => {
إرجاع السياق غير المتزامن => {
لو (
Context.method === 'إنشاء' &&
Context.type === 'بعد' &&
Context.path === "المصادقة" &&
Context.data && context.data.strategy === 'jwt' &&
السياق.النتيجة &&
Context.result.accessToken) {
// تحقق مما إذا كان الرمز المميز بحاجة إلى التجديد
تحميل const = انتظار Context.app.service ("المصادقة"). checkAccessToken (Context.result.accessToken)
صدر constAt = DateTime.fromMillis (payload.iat * 1000)
تجديد const بعد = releaseAt.plus (تجديد بعد)
const الآن = DateTime.local ()
إذا (الآن> تجديد بعد) {
Context.result.accessToken = await context.app.service ('المصادقة'). createAccessToken ({sub: payload.sub})
}
}
سياق العودة
}
}
""

من المهم أن يكون لديك هذا الخطاف في after وكخطاف أخير ، بحيث تكون جميع عمليات التحقق وما إلى ذلك قد مرت

أي خطط لدمج رموز التحديث في الريش؟

أنا أؤيد هذا السؤال برسالة واحدة في وقت سابق.

أتساءل عن سير عمل رمز التحديث أيضًا. هل الحل الذي تمت صياغته بواسطة @ m0dch3n ممارسة جيدة؟ هل يجب أن نطبقها بطريقة أخرى؟

إن سير عمل RefreshToken بأكمله في opion الخاص بي لا يحمي إلا قليلاً فقط من هجوم الرجل في الوسط ، بحيث إذا قام الرجل الأوسط بسرقة accessToken ، فيمكنه على الأقل عدم تحديثه والحصول على وصول غير محدود إلى المصادر.

إنه لا يحمي من XSS ، لأنه في هذه الحالة ، يكون المهاجم قادرًا على سرقة أي شيء مخزن من جانب العميل. وكذلك أيضًا RefreshToken ...

تكمن المشكلة الآن في أنك إذا جعلت وقت انتهاء صلاحية accessToken الخاص بك صغيرًا جدًا (أي 5 دقائق) ، فإنك تقوم أيضًا بتحديثه كثيرًا. الرجل في المنتصف يحتاج فقط للاستماع خلال 5 دقائق لطلبات العملاء من أجل اعتراض RefreshToken ثم ... إذا جعلت انتهاء الصلاحية أطول ، فسيكون لديه وصول أطول بمجرد accessToken ...

بصراحة لو يقول لي بعض العملاء، وحصلت على وصوله المسروقة، ولست بحاجة إلى القائمة السوداء accessToken وrefreshToken على أي حال للتأكد. لذلك أجد نفسي مضطرًا لتقديم طلب DB على كل طلب على أي حال.

في حالتي ، عندما أكون على دراية بمثل هذه الحالة ، أقوم بإدراج جميع رموز الوصول من آخر 40 يومًا في القائمة السوداء ، لأن صلاحية الوصول إلى الرموز الخاصة بي تبلغ 40 يومًا ...

استخدام طلب HTTPS يجعل هجمات الرجل في الوسط صعبة حقًا. ألا تستخدم طلبات HTTPS؟

بالطبع أنا أستخدم https ، لكن هناك 3 احتمالات لسرقة accessToken. الأول من جانب العميل (XSS ie) ، والثاني في النقل (الرجل في المنتصف) ، والثالث من جانب الخادم.

بالنسبة للعميل وأثناء النقل ، فأنا نصف مسؤول فقط عن الأمان ، والنصف الآخر هو العميل ، وهو ليس تحت سيطرتي تمامًا. لكن يمكنني مساعدة العميل ، لتجنب المخاطر الأمنية ، بجعل XSS مستحيلًا وعن طريق تأمين النقل باستخدام https ...

الهدف من RefreshToken هو جعل انتهاء صلاحية accessToken أقصر وعدم إرسال رمز مميز صالح أطول أو لانهائي في كل طلب

لذا فإن الأمن الوحيد الذي يوفره ، هو أنه من 100 طلب ، أي أنك لا تجعل كل الـ 100 عرضة للخطر أثناء النقل ، ولكنك فقط تطلب واحدًا

لذلك ، لا يمكن حماية أي رجل في منتصف الهجوم من خلال تحديث حديث وبالطبع ليس بواسطة XSS ... يمكن تقليله فقط من خلال عدد المرات التي ترسل فيها هذا التحديث ... تكلفة نقله أقل ومع ذلك ، يجب أن يكون accessToken صالحًا لفترة أطول ...

أنا فقط أنسخ / ألصق تعليقاتي من قناة Slack:

أعتقد أن رمز التحديث هو ميزة لا بد من دعمها ولا يتعلق الأمر بتجديد رمز الوصول الحالي تلقائيًا. رمز الوصول عديم الحالة ولن يتم تخزينه في جانب الخادم. الجانب السلبي هو أنه صالح إلى الأبد! كلما زاد طول رمز الوصول ، يتم فرض المزيد من المخاطر. ولكن إذا كان رمز الوصول قصيرًا جدًا ، فيجب على المستخدمين تسجيل الدخول في كثير من الأحيان ، مما سيؤثر بشكل كبير على سهولة الاستخدام.

هذا هو المكان الذي يأتي فيه رمز التحديث ، الرمز المميز المستخدم لتحديث رمز الوصول وهو رمز مميز طويل الأمد. عند انتهاء صلاحية رمز الوصول ، يمكن للعميل استخدام رمز التحديث للحصول على رمز وصول جديد ، وهذا هو الغرض الوحيد من رمز التحديث.

رمز التحديث قابل للإلغاء في حالة اختراق حساب المستخدم. وهذا هو الفرق الكبير بين رمز الوصول ورمز التحديث. لإلغاء رمز التحديث الذي تم إصداره ، يجب على الخادم تخزين جميع رموز التحديث التي تم إصدارها. بعبارة أخرى ، يكون رمز التحديث ذا الحالة. يحتاج الخادم إلى معرفة أيهما صالح وأيهما غير صالح.

لتنفيذ رمز التحديث بشكل صحيح ، نحتاج إلى نوع من مخزن الرموز للاستمرار في تحديث الرمز المميز. نحتاج أيضًا إلى تنفيذ ثلاثة تدفقات على الأقل:

تحديث التحقق من صحة الرمز المميز
تحديث رمز الوصول برمز تحديث صالح
إبطال رمز التحديث الخاص بالمستخدم المخترق

هناك وظائف إدارية أخرى من الجيد أيضًا امتلاكها مثل إحصائيات استخدام الرمز المميز.

أعلاه هو فهمي الحالي فيما يتعلق بكيفية تنفيذ رمز التحديث. ليس الأمر سهلاً ولكن من الضروري بالتأكيد بناء نظام أكثر أمانًا.

اتضح أن Feathers مدمج بالفعل في جميع الوظائف / الوحدات المطلوبة لتنفيذ رموز التحديث بشكل صحيح:

1. متجر رمز التحديث: يمكن دعمه بسهولة بواسطة Feathers Service.
2. إصدار والتحقق من رمز التحديث المميز: يمكن فقط إعادة استخدام دعم JWT الحالي والذي يتضمن خدمة AuthenticationService.

استنادًا إلى العمل الذي أنجزته TheSinding (https://github.com/TheSinding/authentication-refresh-token) ، قمت بتطبيق إصداري الخاص من رموز التحديث المميزة بخدمة مخصصة واحدة وثلاثة خطافات (https://github.com/ jackywxd / feathers-Refresh-token) التي تتيح وظائف التحديث الأساسية:

1. إصدار رمز التحديث بعد مصادقة المستخدم بنجاح ؛
2. تحديث رمز الوصول برمز تحديث JWT صالح ؛
3. مستخدم تسجيل الخروج عن طريق حذف رمز التحديث

بينما تستفيد بشكل كامل من قاعدة الكود الموجودة في Feathres ، فإن جهد الترميز الفعلي هو الحد الأدنى ، وهو يتكامل مع بنية Feathers الحالية بشكل جيد. إنه يثبت أن هندسة الريش الحالية قابلة للتمديد للغاية.

لكن الميزة الكاملة لـ Refresh-token تتطلب أيضًا دعمًا من جانب العميل ، مثل رمز تحديث المتجر في جانب العميل ، وإعادة مصادقة المستخدم بعد انتهاء صلاحية رمز الوصول ، وتسجيل خروج المستخدم باستخدام رمز التحديث.

بعد مراجعة الكود المصدري لعميل مصادقة الريش والمصادقة ، أعتقد أنه يمكن الاستفادة من رمز التحديث في رمز الميزات الحالي على أساس السماح بتشغيل دعم رمز التحديث بنفس سهولة تشغيل المصادقة.

لقد قمت بالفعل بنقل قاعدة رمز التحديث المميز لإصدار الخطافات إلى @ feathersjs / المصادقة. بعد ذلك ، سأحاول إجراء تغيير على عميل المصادقة لتمكين ميزات جانب العميل. هدفي النهائي هو تمكين دعم رمز التحديث في كل من الخادم والعميل.

سؤالي / قلقي هو كيف سيتم تخزين رمز التحديث في العميل؟

راجع https://auth0.com/blog/securing-single-page-applications-with-refresh-token-rotation/

لسوء الحظ ، لا تعد RTs طويلة العمر مناسبة لـ SPA لأنه لا توجد آلية تخزين ثابتة في المتصفح يمكنها ضمان الوصول عن طريق التطبيق المقصود فقط. نظرًا لوجود نقاط ضعف يمكن استغلالها للحصول على هذه القطع الأثرية عالية القيمة ومنح الجهات الفاعلة الخبيثة الوصول إلى الموارد المحمية ، فقد تم تثبيط استخدام رموز التحديث في SPAs بشدة.

راجع https://afteracademy.com/blog/implement-json-web-token-jwt-authentication-using-access-token-and-refresh-token

إذن ، ما هو أفضل مكان ممكن لتخزين الرموز المميزة بشكل آمن؟ يمكنك قراءة المزيد عنها على الإنترنت إذا كنت متحمسًا لتحقيق تخزين آمن تمامًا. بعض الحلول مثالية ولكنها ليست عملية للغاية. عمليًا ، أود تخزينه في ملفات تعريف الارتباط مع httpOnly وعلامة Secure. إنه ليس آمنًا بنسبة 100 في المائة ولكنه ينجز المهمة.

شاهد هذه المناقشة الطويلة حول ملف تعريف الارتباط - https://github.com/feathersjs-ecosystem/authentication/issues/132 أيضًا

bwgjoseph أود أن أقترح استخدام جلسة صريحة عادية ، وتخزين جميع الرموز هناك ، بدلاً من جانب العميل. هذا ما أفعله ويعمل بشكل جيد مع جميع أنواع التطبيقات بما في ذلك SPA

sarkistlt تقصد أن تقول لتخزين جميع رموز JWT للعميل على جانب الخادم؟ أي مرجع / مادة مادة لذلك؟ لست متأكدًا تمامًا من الشكل الذي ستكون عليه العملية. إذن ما الذي يرسله العميل ، عندما يطلب البيانات (CRUD)؟

bwgjoseph كما هو الحال دائمًا ، ملف تعريف الارتباط ، فقط أضف الوسيط قبل تسجيل خدماتك:

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

ثم في الخادم الخاص بك ، على سبيل المثال ، خدمة تسجيل دخول العميل ، عندما تتم مصادقة العميل ، تقوم فقط بتخزين الرمز المميز في الجلسة مثل ctx.params.session.token = token ، حيث يكون الرمز المميز هو وصول JWT أو رمز التحديث الخاص بك ، ويعتمد على منطق التطبيق الخاص بك.
ومع أي طلب جديد من العميل ، سوف تتحقق مما إذا كان الرمز المميز موجودًا في الجلسة وسوف تستخدمه للمصادقة. يعد هذا نهجًا أكثر أمانًا وأمانًا ، حيث لا يتم الكشف عن أي من الرموز المميزة من جانب العميل على الإطلاق.

سأضيف فقط أن هذا يعمل بشكل أفضل مع العميل (المتصفح) - تطبيقات الخادم. عند الاتصال داخليًا بين الخوادم أو العامل / الخادم ، لا تحتاج إلى جلسة.

لقد تمت مناقشة هذا الأمر _ الكثير _ من قبل (لقد أضفت أيضًا إدخالًا إلى الأسئلة الشائعة ) وليس بالضرورة أكثر أمانًا لتخزين رمز مميز في الجلسة. إذا تمكن شخص ما من الوصول إلى صفحتك ليتمكن من تنفيذ البرامج النصية ، فقد قام أيضًا باختراق الجلسة ويمكنه تقديم طلبات مصادقة على أي حال.

ومن ثم ، فمن المقبول عادةً تخزين رمز مميز في التخزين المحلي على سبيل المثال (الذي يمكن للصفحة الحالية فقط الوصول إليه أيضًا) ويعمل أيضًا بسلاسة مع الأنظمة الأساسية الأخرى التي لا تعمل بالمتصفح (مثل تطبيقات الأجهزة المحمولة الأصلية ومن خادم إلى خادم وما إلى ذلك) __و websockets__ (لا يمكنني التأكيد بما فيه الكفاية على مدى صعوبة جعل Websockets تعمل بسلاسة وأمان مع ملفات تعريف ارتباط HTTP - أصبحت حياتي أسهل كثيرًا منذ توقفنا عن محاولة القيام بذلك). بشكل عام ، يجب أن يكون رمز التحديث قابلاً للإلغاء لأنه عادةً ما يكون طويلاً.

في كلتا الحالتين ، سيكون طلب السحب لهذا موضع ترحيب كبير ، وأجد أنه يجعل تسوية التفاصيل أسهل كثيرًا.

jackywxd - عمل رائع ، لقد ألقينا نظرة
هل هناك أي طريقة لتسهيل الأمر على المطور الذي يقوم بتنفيذ ذلك؟
مثل دمج الخطافات التي قمت بإنشائها في المكتبة ، لذلك لن نحتاج إلى إضافة الخطافات لاحقًا؟

أعتقد أنه يجب عليك إنشاء طلب سحب ويمكننا إجراء المناقشة هناك.

daffl نعم أتفق ، خاصة مع WS. وإذا قام كل من العميل والخلفية بالبناء بواسطتك أنت أو فريقك ، فمن الأفضل استخدام JWT فقط وتجنب التبعيات الإضافية والتعقيد في تطبيقك.
ولكن في بعض الحالات ، على سبيل المثال ، عند إنشاء واجهة REST-API لواجهة المتجر والتي سيتم استخدامها من قبل شركات / مطورين تابعين لجهات خارجية ، يكون من الأسهل استخدام الجلسة العادية ، واطلب من المطورين تضمين بيانات الاعتماد مع طلباتهم ثم وصف كيفية استرداد الوصول (والتحديث ) الرموز وتخزينها وتمريرها مع كل طلب. والتي تم التعامل معها بشكل مثالي من قبل عميل الريش ، ولكن في معظم الحالات عندما لا يكون المطور على دراية بكيفية إنشاء الواجهة الخلفية ، سيستخدمون request, superagent, fetch or axios لتوصيل تطبيقهم بالواجهة الخلفية. في حالتي على الأقل ، كان هذا هو السبب الرئيسي لنقل الجزء الأمامي من واجهة برمجة التطبيقات للعمل مع الجلسات العادية بدلاً من JWT مباشرةً.

ولكن ألن يكون هذا هو قرار التصميم والمسؤولية ، لصانع واجهة المتجر المذكورة ، للتنفيذ في واجهة برمجة التطبيقات الخاصة بهم ثم توثيق هذه الميزة بشكل صحيح ، بدلاً من "فرض" هذا القرار على المجتمع؟

TheSinding أعتقد أنه يمكننا أن نقول "فرض" حول النهج الأقل شيوعًا ، وليس حول ملف تعريف الارتباط الذي كان (ولا يزال) النهج الأكثر شيوعًا لإدارة جلسات المستخدم.

ونعم ، إنه قرار تصميم تم اتخاذه بعد ملاحظات المطورين الذين يستخدمون واجهة برمجة التطبيقات. عندما تقوم بتشغيل نظام متعدد المستأجرين أو واجهة برمجة تطبيقات تستخدمها فرق متعددة ، فمن الأفضل أحيانًا اتباع الممارسات الصناعية العامة لتجنب الارتباك الإضافي والوقت الإضافي الذي يقضيه المطورون ، خاصة إذا كان الحل البديل لا يوفر أي ميزة للمستخدم النهائي.

مرة أخرى للتوضيح ، يعد استخدام JWT أمرًا رائعًا ، ويسهل استخدامه بشكل خاص لواجهة برمجة التطبيقات في الوقت الفعلي وهذا ما نستخدمه في 90٪ من الحالات + لا تحتاج إلى تشغيل redis أو أي شيء آخر لإدارة جلسات ملفات تعريف الارتباط.
ولكن هناك بعض الحالات الاستثنائية التي قد لا يكون فيها الخيار الأفضل ، فقد قدمت مثالاً على هذا الموقف في تعليقي السابق.

لم أكن أقول إنك كنت مخطئًا ، كنت أفكر فقط "بصوت عالٍ" :)

IMO ، أعتقد أن النهج مع JWT سيكون نهجًا أفضل ، نظرًا لأن هذا هو ما يتم دعمه بالفعل وباعتبار daffl فإنه من الأسهل أيضًا العمل معه

شكرا لجميع ملاحظاتك! JWT مقابل الجلسة هو موضوع مختلف يمكننا مناقشته بشكل منفصل.

أعتقد أن شيئًا واحدًا نتفق عليه جميعًا هو أن رمز الوصول + رمز التحديث هو حل أكثر أمانًا من مجرد رمز وصول. لقد تم تبنيه على نطاق واسع من قبل عمالقة الإنترنت الكبار. من الإنصاف القول إن مجتمع Feathers يود أن يرى قاعدة الشفرة الرئيسية Feathers لتوفير دعم مدمج لرمز التحديث. في الواقع لقد فاجأني عندما أدركت لأول مرة أن Feathers لا يدعم رمز التحديث.

لقد كنت أستخدم AWS cognito في اثنين من مشاريعي ، وستحفظ AWS Amplify ثلاثة رموز مميزة في التخزين المحلي: الرمز المميز للمعرف ، ورمز الوصول ، والرمز المميز للتحديث ، وتعالج Amplify جميع الأعمال القذرة المتعلقة بإدارة الرمز المميز ، وتوفر زوجين من واجهات برمجة التطبيقات التي تتيح سهولة و واجهة مباشرة للأمام تعمل مع الواجهة الخلفية لـ Cognito. أود أن أرى تجربة تطوير مماثلة مع Feathers.

@ TheSinding شكرًا على عملك الرائع السابق!

نظرًا لأنه يتم تنفيذ المصادقة الحالية كخدمة عادية ، يمكننا بسهولة تمكين دعم رمز التحديث من خلال توسيع الفئة وإضافة خطافات ثنائية:

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

تمامًا مثلما نشغل المصادقة باستخدام CLI ، يمكننا تقديم الخيار المماثل في CLI لدعم رمز التحديث. يمكن للمطور الإجابة بنعم ، ثم يقوم CLI تلقائيًا بإنشاء خدمة "تحديث الرموز" للعميل وتحديث التكوينات ذات الصلة برمز التحديث في ملف التكوين الافتراضي. لذلك فهو بمثابة حل جاهز للمطورين.

daffl David ، شكرًا على إنشاء Feathers! فقط أتساءل هل هناك أي "دليل مساهم" ، "توجيه ترميز" ، "دليل أسلوب" للريش؟

كما ذكرت من قبل ، فإن العلاقات العامة مع تنفيذ رموز التحديث (أو حتى بعض الأفكار فقط) ستكون موضع ترحيب كبير. لم تتح لي الفرصة بعد للتحقق من المستودعات المرتبطة وهذه المناقشة تستغرق وقتًا طويلاً. إن تحديثها بالكامل وفي مكان واحد سيجعل الأمور أسهل كثيرًا. بعض النقاط المهمة:

• يمكن إصدار رموز التحديث من خلال توسيع خدمة المصادقة
• يجب تخزين رموز التحديث في localStorage
• يجب أن تكون رموز التحديث قابلة للإلغاء (لذلك يجب أن يكون هناك تنفيذ أكثر عمومية لآلية الإلغاء الموضحة في https://docs.feathersjs.com/cookbook/authentication/revoke-jwt.html)
• نظرًا للتعقيد الإضافي والإعداد (مثل Redis لتخزين الرموز المميزة التي تم إلغاؤها) ، يمكن أن يكون متاحًا كميزة ولكن لا ينبغي تمكينه افتراضيًا (على سبيل المثال ، تطبيق تم إنشاؤه بشكل قياسي - يمكن أن يكون جزءًا من CLI ولكن قبل القيام بأي شيء على ذلك ، ما زلت أبحث حقًا عن مساعدة في بدء تشغيل مولد يعتمد على
• يمكن العثور على معلومات المساهمة في دليل المساهمين

إذا كان شخص ما يستخدم RefreshToken ، فإننا ننشئ مكتبة تتعامل مع الواجهة الأمامية ، والوصول إلى الكلام و RefreshToken مثل "الجلسات" ، وهو سهل الاستخدام للغاية.

تحتاج فقط إلى تمرير الرموز المميزة وتحاول المكتبة الحصول على وصول جديد باستخدام RefreshToken عندما تنتهي صلاحيته. يستخدم حاليا في فيدسك .

المستودع: معالج المصادقة الأمامي