Jwt-auth: [السؤال] حالة استخدام API مقطوعة الرأس
بنية تدفق المصادقة في هذا البرنامج المساعد رائعة ؛ أنا أفهم المخاوف الأمنية. على الرغم من أنه ربما يعطل حالة الاستخدام الأساسية لمثل هذه الميزة: Wordpress باعتباره CMS مقطوعة الرأس.
لإيقاف مصادقة CMS مقطوعة الرأس
يتطلب نظام إدارة المحتوى بدون رأس أن يقوم المستخدمون بتسجيل الدخول عبر username و password . بمجرد أن يكون لدى المستخدم JWT ، يمكنه إرسال طلبات مصادقة إلى الموارد المحمية ، في بيئة CMS بدون رأس ، سيكون من المحظور وغير المنطقي مطالبة المستخدمين بإنشاء رموز API المميزة.
يجب تنفيذ الأمن من خلال امتيازات RBAC وأدوار المستخدم ومسؤولياته التي تملي ما هو محمي في API. يمكن التخفيف من حدة المخاوف الأمنية من خلال الإعدادات الافتراضية الصارمة للغاية لـ RBAC. بالفعل Wordpress لديه إطار أدوار ومسؤوليات كبيرة.
لمعالجة المخاوف الأمنية الفعلية:
- عمرا طويلا الرموز؟ اجعلهم رموزًا قصيرة العمر.
- مخاوف من إمكانية سرقة الرموز المميزة التي تدوم طويلاً؟ لذلك يمكن أن الرموز المميزة API ، وسيطة فارغة.
- تملي أفضل ممارسات JWT
tokensrefresh_tokensالأمد (رموز التحديث قابلة للإلغاء) وبالتالي فإن هذا أكثر أمانًا من توزيع الرموز المميزة لواجهة برمجة التطبيقات (API) اللانهائية التي يمكن فقدها.
أليس هذا مجرد OAuth2؟
هذا النهج هو في الأساس سيناريو منح رمز oAuth2 "personal access" . وبالتالي أود أن أتساءل عن مزايا نهج خادم مصادقة الرمز المميز المخصص مثل هذا عبر تنفيذ معيار oAuth2 مناسب؟ إذا كان الأمن هو الشغل الشاغل هنا ، فحينئذٍ يمثل هذا الأسلوب مخاطر أمنية؟ على سبيل المثال ، تنفيذ اختبار المعركة لـ oAuth2 مثل php-league-oatuh-2
أرى حالة الاستخدام الوحيدة القابلة للتطبيق لتدفق المصادقة الحالي application-to-application المصادقة؟ يحدد oAuth2 طرق تدفق مصادقة متعددة لمنح الرموز المميزة. أحدهما هو ما يستخدمه هذا الأسلوب "personal access" والآخر هو ما أصفه "password access" Tokens. سيسمح تنفيذ oAuth2 الكامل لكل من هذه السيناريوهين والمزيد ...
بالإضافة إلى ذلك
نعتقد أن استيعاب WP-API وبالتالي تحديث نظام Wordpress البيئي بشكل عام سيتم تعزيزه بشكل كبير إذا كان من السهل على المطورين الوصول إلى أشياء مثل مصادقة API عديمة الحالة.
هذه مجرد تأملات وأحب المناقشة والمساهمة!
عمل عظيم!
andrewmclagan
ال 3 كومينتر
لقد كنت أقوم بإنشاء تطبيقات أصلية (أو أحاول) منذ ذلك الحين قبل أن تصل واجهة برمجة تطبيقات REST إلى النواة. (على سبيل المثال: سنوات)
في البداية ، كانت الطريقة الوحيدة لتطبيقي للمصادقة وتحميل / إنشاء المحتوى هي استخدام المكون الإضافي "OAuth1.0a" الذي بدأه فريق واجهة برمجة التطبيقات.
لدي الآن أشياء تعمل مع OAuth2.0 (مرة أخرى ، هناك ميزة أخرى تحتاج إلى مكون إضافي مثبت. ليست لدي فكرة عما إذا كان هذا سيصل إلى النواة)
والآن لدينا JWT الذي يعرض مشاكل جديدة في كيفية توصيل تطبيقي. من الطبيعي أن يعمل اسم المستخدم / كلمة المرور بشكل أفضل ، مع توفير رمز مميز. (لحسن الحظ ، يدعم إصدار 'WP-API' هذا من JWT تحديث الرمز المميز. وهناك مكون إضافي آخر لـ JWT يستخدم على نطاق واسع لا يفعل ذلك)
لا أستطيع أن أصدق الكم الهائل من الفرص الضائعة (والوقت) الذي يمر ، مع عدم وجود تنفيذ قوي "مقطوع الرأس" / متنقل للمصادقة "خارج الصندوق" (في الأساس).
يتطلب تطبيق الهاتف المحمول الخاص بي البرنامج الإضافي الخاص به للقيام بعمله ودعم الكثير من الأشياء المتعلقة بالمسؤول وتحسينات المسار. الكتل المخصصة وما إلى ذلك. أفضل ألا أضطر إلى حمل مستخدمي التطبيق / العملاء على تنزيل وتثبيت مكون إضافي آخر "غير مكتمل تمامًا".
أتمنى فقط وجود حل قوي (و "رسمي").
kosso
في ١٧ ديسمبر ٢٠١٩
أوافق بشدة. تم وضع Wordpress ليصبح رائدًا في مجال CMS مقطوعة الرأس. يبدو أن الفريق الأساسي يشق طريقه إلى ذلك ، ولكن ربما فقط لخدمة حالة استخدام محددة لموقع Wordpress.com؟ غير متأكد.
نقوم حاليًا بتطوير عميل متماثل الشكل لهذا الغرض. جنبا إلى جنب مع خطاطيف رد الفعل والمقدمين. https://github.com/wp-headless/fetch. ربما يتعين علينا كتابة المكون الإضافي JWT auth الخاص بنا. أفكاري حول الشكل الذي يجب أن يبدو عليه:
- اتبع مواصفات oAuth2 (لماذا تنشئ تدفق مصادقة مخصص؟)
- لديك عدة طرق لمنح الرمز المميز:
password،machine-to-machine،api-keyإلخ .. - تعتمد على الحزم الرائدة التي تم اختبارها جيدًا.
andrewmclagan
في ١٨ ديسمبر ٢٠١٩
أنا هنا عالق في محاولة تنفيذ نظام تسجيل / مصادقة مستخدم عبر WP REST API ، فقط لمعرفة أن فريق WP يعيد اختراع العجلة ويبتكر عجلة جديدة.
w33zy
في ٢١ ديسمبر ٢٠١٩
القضايا ذات الصلة
jkmassel
·
7تعليقات
beberlei
·
3تعليقات
iamkoby
·
3تعليقات
maxrice
·
3تعليقات
PhenX
·
3تعليقات
التعليق الأكثر فائدة
لقد كنت أقوم بإنشاء تطبيقات أصلية (أو أحاول) منذ ذلك الحين قبل أن تصل واجهة برمجة تطبيقات REST إلى النواة. (على سبيل المثال: سنوات)
في البداية ، كانت الطريقة الوحيدة لتطبيقي للمصادقة وتحميل / إنشاء المحتوى هي استخدام المكون الإضافي "OAuth1.0a" الذي بدأه فريق واجهة برمجة التطبيقات.
لدي الآن أشياء تعمل مع OAuth2.0 (مرة أخرى ، هناك ميزة أخرى تحتاج إلى مكون إضافي مثبت. ليست لدي فكرة عما إذا كان هذا سيصل إلى النواة)
والآن لدينا JWT الذي يعرض مشاكل جديدة في كيفية توصيل تطبيقي. من الطبيعي أن يعمل اسم المستخدم / كلمة المرور بشكل أفضل ، مع توفير رمز مميز. (لحسن الحظ ، يدعم إصدار 'WP-API' هذا من JWT تحديث الرمز المميز. وهناك مكون إضافي آخر لـ JWT يستخدم على نطاق واسع لا يفعل ذلك)
لا أستطيع أن أصدق الكم الهائل من الفرص الضائعة (والوقت) الذي يمر ، مع عدم وجود تنفيذ قوي "مقطوع الرأس" / متنقل للمصادقة "خارج الصندوق" (في الأساس).
يتطلب تطبيق الهاتف المحمول الخاص بي البرنامج الإضافي الخاص به للقيام بعمله ودعم الكثير من الأشياء المتعلقة بالمسؤول وتحسينات المسار. الكتل المخصصة وما إلى ذلك. أفضل ألا أضطر إلى حمل مستخدمي التطبيق / العملاء على تنزيل وتثبيت مكون إضافي آخر "غير مكتمل تمامًا".
أتمنى فقط وجود حل قوي (و "رسمي").