Jwt-auth: تم تحديث Token Flow UX

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

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

أحصل على ما تحاول قوله هنا ولكن في نفس الوقت ما تقترحه هو أن مطالبة المستخدم بتسجيل الدخول إلى WordPress وإنشاء زوج مفاتيح أمر صعب إلى حد ما بالنسبة للمستخدمين غير التقنيين الذين يرغبون في إنشاء رمز مميز عبر REST API برمجيًا. أنا أزعم أن هؤلاء ليسوا مستخدمين غير تقنيين على الإطلاق.

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

إنه غير بديهي
سيحتاج أي نظام آخر يريد استخدام هذه الطريقة للتكامل مع WordPress إلى شرح / برنامج تعليمي حول كيفية إعداد زوج مفاتيح من أجل البدء.

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

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

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

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

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

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

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

بالإضافة إلى ذلك - أنا قلق بشأن إضافة طريقة إضافية لإلغاء الجلسات - يحتوي WordPress بالفعل على زر "تسجيل الخروج في كل مكان آخر" في صفحة الملف الشخصي - بصفتي مستخدمًا ، أتوقع أن يسجلني الخروج من أي تطبيقات أيضًا ( أو على الأقل سألني عما إذا كنت أرغب في القيام بذلك؟)

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

لا يوفر أي أمان إضافي
إذا كنت ، بصفتي مهاجمًا ، أمتلك بالفعل اسم المستخدم وكلمة المرور الخاصين بك ، فلا يوجد شيء لا يمكنني فعله مثلك (بافتراض عدم وجود 2FA في المكان).

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

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

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

أنا منفتح بنسبة 100٪ على إنشاء تدفق مصادقة للتطبيقات التي يُطلب منك عند الانتقال إليها تسجيل الدخول إلى WordPress ، مع إضافة أي إضافات مثل 2factor ، والتي من شأنها إنشاء زوج مفاتيح لك ثم استخدام نوع من إعادة الاتصال إعطاء التطبيق زوج المفاتيح. ثم لا يتعين على مطوري التطبيقات إنشاء الكثير من الحلول السيئة والتطبيق لا يخزن user:pass .

ما الذي يمكن فعله بدلاً من ذلك؟
يخدم المفتاح حاليًا غرضًا مهمًا - فهو يُستخدم للسماح بإلغاء الرمز المميز ، على الرغم من احتمال أن تكون الرموز المميزة طويلة الأمد. ومع ذلك ، لا نحتاج بالضرورة إلى زوج مفاتيح للقيام بذلك.

صحيح ، يمكنك استخدام العديد من الأساليب المختلفة.

أخذ الإلهام من إدخال session_tokens في WordPress في usermeta - ستسمح مجموعة مخزنة من مفاتيح الإبطال الخاصة بـ JWT بنفس الوظيفة ، وستجعل تنفيذ وظيفة "تسجيل الخروج في كل مكان آخر" أمرًا بسيطًا - فقط احذف هذا الإدخال من الجدول.

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

ماذا عن 2FA؟
أتساءل عما إذا كان من الممكن السماح بربط ربط يمكن أن تستخدمه مكونات 2FA لإخبار العميل "يرجى المحاولة مرة أخرى ، وتوفير رمز 2FA" إذا كان مطلوبًا ، ولكن لم يتم توفيره. بالإضافة إلى ذلك ، يمكن استخدام خطاف آخر (أو ربما نفس الشيء؟) للسماح للمكوِّن الإضافي 2FA بالتحقق من صحة الشفرة المقدمة؟ لن يقدم نظام JWT أي افتراضات حول كيفية تنفيذ المصادقة الثنائية (2FA) - والتي ستُترك لمكوِّن إضافي آخر - سنقوم فقط بتوفير الخطافات لجعل مثل هذا الشيء ممكنًا.

هذا من شأنه أن يضيف IMO طبقة غير ضرورية من التعقيد والتي لديها القدرة على إنشاء الكثير من طلبات الدعم.

شكرًا على قراءة هذا الآن - كل ما سبق هو IMHO ، لكنني آمل أن نتمكن من تبسيط هذه العملية قليلاً للمستخدمين لجعلها تعمل بشكل جيد حقًا للجميع.

أنا متأكد من أنني قد فاتني شيء على الأقل ، لذلك يسعدني سماع أي تعليقات قد تكون لدى الأشخاص حول هذا الأمر!

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

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

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

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

على الرغم من أنني أفهم الجانب الأمني ​​في القرار ، ونوع من الاتفاق معه. لكننا نحتاج إلى إيجاد طريقة يمكن أن تعمل لكليهما.

يبدو أن ما قلته هنا valendesigns يمكن أن يكون حلاً ممكنًا:

أنا منفتح بنسبة 100٪ على إنشاء تدفق مصادقة للتطبيقات التي يُطلب منك عند الانتقال إليها تسجيل الدخول إلى WordPress ، مع إضافة أي إضافات مثل 2factor ، والتي من شأنها إنشاء زوج مفاتيح لك ثم استخدام نوع من إعادة الاتصال إعطاء التطبيق زوج المفاتيح. ثم لا يتعين على مطوري التطبيقات إنشاء الكثير من الحلول السيئة والتطبيق لا يخزن مستخدمهم: تمرير.

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

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

أود الحصول على مزيد من المعلومات حول هذا الجزء:

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

يبدو أنه إذا قمت بتسجيل الدخول إلى site.com عبر المتصفح والتطبيق ، إذا قمت بالنقر فوق "تسجيل الخروج في كل مكان آخر" في المتصفح ، فسأقوم أيضًا بتسجيل الخروج من التطبيق ، أليس كذلك؟! أستطيع أن أرى التطبيقات حيث سيكون هذا هو الافتراض. توقع أن يتم تسجيل خروجك في كل مكان.

يجب أن يحدث نفس الشيء عند حذف الحساب.

يجب أن أتفق مع ما قيل حول كون زوج المفاتيح UX غير سهل الاستخدام للغاية.

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

• لقد أنشأت مكونًا إضافيًا مخصصًا منذ فترة لمكوِّن OAuth1a الإضافي (القديم) الذي عرض رمز QR مشفرًا (بكلمة مرور قصيرة وقابلة للتعيين) في صفحة مسؤول التطبيقات (عندما يتطابق اسم التطبيق وعنوان URL لمعاودة الاتصال مع تطبيقي) ، والذي بعد ذلك تمرير معلومات تطبيق العميل إلى تطبيق الهاتف المحمول ، للسماح للمستخدم بعد ذلك بالمصادقة.

منحت (التورية المقصودة) ، JWT أسهل كثيرًا من OAuth1a ؛)

نظرًا لأنه يتعين على المستخدم تسجيل الدخول إلى Wordpress (نأمل عبر https) في المقام الأول ، باستخدام اسم مستخدم وكلمة مرور ، فأنا لا أرى حقًا مشكلة الأمان المتمثلة في أن يكون زوج اسم المستخدم / كلمة المرور قادرًا على الحصول على رمز وصول ؟ يتم إرسالها جميعًا عبر نفس "السلك" في نهاية اليوم؟ بالتاكيد؟

إن فرض زوج مفاتيح التطبيق المطبق حاليًا يجعل طريقة المصادقة هذه مستحيلة تمامًا (في العالم الحقيقي) لاستخدامها في تطبيقات الهاتف المحمول.

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

لقد جربت OAuth1a و OAuth2 والآن اثنين من مكونات JWT الإضافية لتنفيذ تطبيقاتي الأصلية مع إمكانية الوصول وكلها تفشل في "الخروج من الصندوق" ، دون بعض الاختراق لمحاولة جعل الأشياء تعمل للمستخدم. من المفترض أن تصبح هذه الأشياء أسهل ، بالتأكيد؟

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

فشل هذا المكون الإضافي `` قريبًا أن يصبح رسميًا '' (آمل!) بسبب الافتقار إلى سهولة استخدام الهاتف المحمول ويبدو أنه يتجاهل نوع التطبيقات التي يمكن تطويرها بشكل واقعي لها. وهذا يبدو قصير النظر للغاية.

هناك سبب لعدم وجود تطبيقات الجوال الأصلية للنشر على مواقع wp.org. وهذا هو.

من فضلك ، من فضلك من فضلك هل يمكننا الحصول على بعض الحركة في هذا الشأن؟ (لقد كنت أعمل على تطبيق محلي منذ سنوات ، في انتظار طريقة "مناسبة" لمصادقة المستخدمين ، منذ تقديم REST API)

:)

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

هذه المشكلة مع تسجيل دخول المستخدم> تدفق الرمز المميز تعيق بشكل خطير تطوير العديد من التطبيقات التي يمكن أن تستخدم JWT.

تستمر الأشهر والأشهر وهي ببساطة لا تتم معالجتها.

كما قلت أعلاه ، حقيقة أن المستخدمين يستخدمون زوجًا من اسم المستخدم / كلمة المرور لتسجيل الدخول فعليًا إلى المسؤول يجعل أي حجة لاستخدام عدم استخدام أزواج اسم المستخدم / كلمة المرور للحصول على رمز مميز تبدو غير صالحة إلى حد ما؟ بالتاكيد؟

فقط لتحديث هذا الموضوع - يبدو أن هذا المشروع قد تم استبداله بواحد لتنفيذ تدفق OAuth الكامل في WP core. يجب أن يعالج الجوانب السلبية للنهج التي تمت مناقشتها هنا مع الاحتفاظ بكل نقاط القوة.

إذا كنت ترغب في المشاركة في ذلك ، فلا تتردد في القفز إلى