سؤال

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

هل كانت مفيدة؟

المحلول

كيفية التعامل مع المصادقة في راحة العميل-الخادم هو موضوع نقاش.

عادة, فإنه لا يمكن أن يتحقق في SOA عبر HTTP العالم عن طريق:

  • HTTP الأساسية المصادقة على HTTPS;
  • الكوكيز الدورة الإدارية ؛
  • المميز في رؤوس HTTP (على سبيل المثال أوث 2.0 + JWT);
  • الاستعلام مصادقة إضافية توقيع المعلمات.

سوف تضطر إلى التكيف ، أو حتى أفضل مزيج من تلك التقنيات ، لمطابقة هندسة البرمجيات في أحسن الأحوال.

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

HTTP الأساسية المصادقة على HTTPS

هذا أول حل يستند إلى معيار بروتوكول HTTPS ، يستخدم من قبل معظم خدمات ويب.

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

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

قد نستخدم مصادقة تلخيصية, لكنه يتطلب أيضا HTTPS, لأنه هو عرضة MiM أو اعادتها الهجمات الخاصة HTTP.

الدورة عن طريق الكوكيز

أن نكون صادقين, جلسة تدار على الخادم ليس حقا عديمي الجنسية.

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

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

كوكي التقنية نفسها HTTP مرتبطة ، حتى انها ليست حقا مريحة ، الذي يجب أن يكون بروتوكول مستقل, IMHO.بل هو عرضة MiM أو اعادتها الهجمات.

منح عن طريق رمز (OAuth2)

البديل هو وضع مميز داخل رؤوس HTTP بحيث طلب مصادقة.هذا هو ما أوث 2.0 ، على سبيل المثال.انظر RFC 6749:

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

باختصار هذه هي مشابهة جدا كوكي و يعاني نفس القضايا:لا عديمي الجنسية ، والاعتماد على HTTP انتقال التفاصيل ، رهنا الكثير من نقاط الضعف الأمنية بما في ذلك الفلز واعادتها لذا يمكن استخدامها فقط عبر HTTPS.عادة ، JWT يستخدم كرمز.

الاستعلام المصادقة

الاستعلام التوثيق تتمثل في توقيع كل راحة طلب عبر بعض معلمات إضافية على URI.انظر هذا المرجع المادة.

كان المحددة في هذه المادة:

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

هذا الأسلوب هو ربما أكثر توافقا مع عديمي الجنسية العمارة و يمكن أيضا أن تنفذ مع ضوء إدارة الدورة (باستخدام الذاكرة دورات بدلا من DB استمرار).

على سبيل المثال, هنا هو عام URI عينة من الرابط أعلاه:

GET /object?apiKey=Qwerty2010

ينبغي أن تحال على هذا النحو:

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

سلسلة يجري التوقيع عليها ، /object?apikey=Qwerty2010&timestamp=1261496500 و التوقيع هو SHA256 تجزئة هذه السلسلة باستخدام خاص مكون من مفتاح API.

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

انظر هذه المادة بعض التفاصيل عن راحة المصادقة في ملقم-عميل ORM/الخدمية/إطار MVC, على أساس سلمان والراحة.منذ نسمح الاتصالات ليس فقط على HTTP/1.1 ، ولكن أيضا أنابيب الاتصال المسماة أو GDI الرسائل (محليا) ، حاولنا تنفيذ حقا مريحة المصادقة نمط ، و لا تعتمد على HTTP خصوصية (مثل الرأس أو ملفات تعريف الارتباط).

في وقت لاحق ملاحظة:إضافة توقيع في URI يمكن اعتبار ممارسة سيئة (منذ فعلى سبيل المثال سوف تظهر في http server logs) لذلك لابد من تخفيفها ، على سبيل المثالبواسطة سليم TTL لتجنب الاعادة.ولكن إذا كان لديك سجلات http للخطر ، وبالتأكيد سوف يكون أكبر المشاكل الأمنية.

في الممارسة العملية القادمة ماك الرموز مصادقة أوث 2.0 قد يكون تحسنا كبيرا فيما يتعلق "الممنوحة من قبل رمز" النظام الحالي.ولكن هذا لا يزال التقدم في العمل و هي مرتبطة HTTP انتقال.

الختام

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

نصائح أخرى

أشك في ما إذا كان الناس يهتفون بحماس "HTTP المصادقة" حاولت من أي وقت مضى جعل متصفح القائمة على تطبيق (بدلا من آلة-إلى-آلة خدمة ويب) مع الراحة (أي جريمة المقصود - أنا فقط لا أعتقد أنهم من أي وقت مضى واجهت مضاعفات).

المشاكل وجدت مع استخدام HTTP المصادقة على راحة الخدمات التي تنتج صفحات HTML ليتم عرضه في المتصفح هي:

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

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

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

بجعل جلسات مريحة الموارد مع القواعد التالية:

  • A الدورة خرائط مفتاح معرف المستخدم (وربما الأخير-العمل زمني مهلة)
  • إذا الدورة موجود فهذا يعني أن المفتاح غير صالح.
  • تسجيل الدخول يعني نشر /دورات مفتاح جديد يتم تعيين ملف تعريف الارتباط
  • خروج يعني DELETEing /دورات/{مفتاح} (مع طاقتها بعد, تذكر, نحن المتصفح HTML 5 هو طريق طويل لنقطعه حتى الآن)
  • المصادقة يتم إرسال مفتاح ملف تعريف الارتباط في كل طلب التحقق من ما إذا كانت الدورة موجود صالحة

الفرق الوحيد أن مصادقة HTTP الآن هو أن مفتاح المصادقة يتم إنشاؤها بواسطة خادم إرسالها إلى العميل الذي يبقى إرساله مرة أخرى بدلا من الحوسبة العميل من إدخال بيانات الاعتماد.

converter42 ويضيف أنه عند استخدام https (ينبغي أن) ، من المهم أن الكعكة سوف يكون لها تأمين العلم أن المصادقة معلومات لم أرسل على غير اتصال آمن.نقطة كبيرة, لم أرى ذلك بنفسي.

أشعر أن هذا ليس حلا كافيا أن يعمل بشكل جيد, لكن يجب أن أعترف أنني لا يكفي خبير أمني لتحديد ثغرات محتملة في هذا النظام - كل ما أعرفه هو أن مئات من غير راحة تطبيقات الويب تستخدم أساسا نفس تسجيل الدخول البروتوكول ($_SESSION في PHP ، HttpSession في Java EE, الخ.).كوكي رأس المحتويات ببساطة تستخدم لمعالجة جانب الخادم الموارد ، مثل قبول اللغة قد تستخدم للوصول إلى موارد الترجمة, إلى آخره.أشعر أنه هو نفسه ، ولكن ربما البعض الآخر لا ؟ ما رأيك يا رفاق ؟

بما فيه الكفاية عن هذا الموضوع خير الناس هنا.ولكن هنا هو بلدي 2 سنت.

هناك 2 طرق التفاعل:

  1. الإنسان إلى آلة (HTM)
  2. آلة-إلى-آلة (MTM)

الجهاز هو القاسم المشترك ، كما أعرب عن بقية واجهات برمجة التطبيقات ، والجهات الفاعلة/العملاء سواء البشر أو الآلات.

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

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

النظر في هذا:لديك البيانات/المعلومات منصة يتعرض الأصول من بقية واجهات برمجة التطبيقات.ربما لديك الخدمة الذاتية بي المنبر الذي يعالج كافة البيانات مكعبات.ولكن كنت تريد الخاص بك (الإنسان) للعملاء الوصول إلى ذلك عن طريق (1) التطبيق على شبكة الإنترنت, (2) التطبيق المحمول, و (3) بعض 3rd الطرف التطبيق.في النهاية حتى سلسلة من MTMs يؤدي إلى HTM - صحيح.لذلك الإنسان للمستخدمين البقاء على قمة سلسلة من المعلومات.

في أول 2 الحالات لديك حالة الإنسان إلى آلة التفاعل المعلومات التي تستهلك في الواقع من قبل المستخدم.في الحالة الأخيرة, لديك آلة البرنامج تستهلك بقية واجهات برمجة التطبيقات.

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

الطريقة-1:

  1. لا يوجد تسجيل الدخول ، لتبدأ.كل طلب ينفذ تسجيل الدخول
  2. العميل يرسل تحديد معلمات + طلب محدد المعلمات مع كل طلب
  3. بقية API يأخذ منهم بالالتفاف الأصوات مخزن المستخدم (أيا كان هو) و يؤكد مصادقة
  4. إذا مصادقة هو إنشاء خدمات الطلب ؛ وإلا تنفي المناسبة رمز حالة HTTP
  5. كرر ما سبق على كل طلب جميع بقية واجهات برمجة التطبيقات في كتالوج

الطريقة 2:

  1. يبدأ العميل مع مصادقة الطلب
  2. تسجيل الدخول REST API سيتم التعامل مع كل هذه الطلبات
  3. فإنه يأخذ في المصادقة المعلمات (API الرئيسية ، uid/pwd أو ما كنت اختيار) والتحقق من مصادقة المستخدم على متجر (LDAP, الإعلان, أو MySQL DB.... الخ)
  4. إذا كان التحقق يخلق رمز المصادقة واليدين مرة أخرى إلى العميل/المتصل
  5. المتصل ثم يرسل هذا رمز المصادقة + طلب محدد params مع كل طلب لاحق إلى الأعمال الأخرى بقية واجهات برمجة التطبيقات, حتى تسجيل الخروج أو حتى انتهاء عقد الإيجار

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

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

ولكن هذا ليس موضوعنا.

النقطة هي "الدولة" (عن العميل مصادقة الوضع) تحتاج إلى صيانة و مشترك بحيث كل بقية واجهات برمجة التطبيقات يمكن إنشاء دائرة الثقة.إذا لم نفعل هذا ، وهي طريقة-1, يجب علينا أن نقبل أن قانون التوثيق يجب أن يتم تنفيذ أي/جميع الطلبات القادمة.

أداء التوثيق هو مورد عملية مكثفة.تخيل تنفيذ استعلامات SQL, كل واردة الطلب ضد المستخدم الخاص بك متجر للتحقق من uid/pwd المباراة.أو لتشفير وأداء تجزئة مباريات (AWS نمط).و معماريا كل REST API سوف تحتاج إلى تنفيذ هذا أشك باستخدام مشترك في نهاية العام خدمة تسجيل الدخول.لأنه إذا كنت لا ، فأنت القمامة الرمز في كل مكان.فوضى كبيرة.

حتى أكثر طبقات أكثر الكمون.

الآن خذ الطريق-1 و تنطبق HTM.لا (الإنسان) المستخدم تهتم حقا إذا كان لديك لإرسال uid/pwd/تجزئة أو أيا كان مع كل طلب ؟ لا طالما كنت لا تهتم لها عن طريق رمي auth/صفحة تسجيل الدخول في كل ثانية.بالتوفيق وجود العملاء إذا كنت تفعل.لذا ما سوف تفعله هو أن تخزين معلومات تسجيل الدخول في مكان ما على جانب العميل في المتصفح في بداية وإرسالها مع كل طلب.عن (الإنسان) المستخدم لديها بالفعل بتسجيل الدخول ، و "الدورة" هو متاح.ولكن في الواقع أنها مصادقة على كل طلب.

نفسه مع الطريقة-2.الخاص بك (الإنسان) لا إشعار.لذلك لا تم القيام به الضرر.

ماذا لو طبقنا الطريقة-1 إلى MTM?في هذه الحالة منذ آلة, نحن يستطيع تحمل الجحيم من هذا الرجل بسؤال تقديم معلومات المصادقة مع كل طلب.لا أحد يهتم!أداء الطريقة-2 على MTM لا تثير أي رد فعل.في الآلة اللعينة.يمكن أن الرعاية أقل!

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

في النهاية الفلسفات لا يهم.ما يهم حقا هو اكتشاف المعلومات, عرض, واستهلاك الخبرة.إذا كان الناس يحبون واجهات برمجة التطبيقات الخاصة بك, قمت بعملك.

هنا هو حقا تماما راحة المصادقة الحل:

  1. إنشاء المفتاح العام/الخاص زوج على خادم المصادقة.
  2. توزيع المفتاح العمومي إلى كافة الملقمات.

  3. عند عميل يصادق:

    3.1.إصدار المميز الذي يحتوي على ما يلي:

    • وقت انتهاء الصلاحية
    • المستخدمين الاسم (اختياري)
    • المستخدمين IP (اختياري)
    • تجزئة كلمة المرور (اختياري)

    3.2.تشفير المميز مع المفتاح الخاص.

    3.3.إرسال المشفرة رمزية إلى المستخدم.

  4. عندما يصل المستخدم إلى أي API يجب أن تمر أيضا في رمز المصادقة.

  5. ملقمات يمكن التحقق من أن رمزي صالح قبل فك الشفرة باستخدام مصادقة خادم المفتاح العام.

هذا هو عديمي الجنسية/راحة المصادقة.

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

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

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

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

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

وأولا وقبل كل شيء، وهي خدمة على شبكة الإنترنت مريحة هو <م> STATELESS (أو بعبارة أخرى، <م> SESSIONLESS ). لذلك، ليس لديها خدمة مريحة ويجب أن لا يكون لها مفهوم الجلسة أو ملفات تعريف الارتباط المعنية. طريقة للقيام المصادقة أو ترخيص في خدمة مريحة عن طريق استخدام رأس تفويض HTTP كما هو محدد في المواصفات HTTP RFC 2616. وينبغي أن يتضمن كل طلب واحد رأس HTTP التخويل، ويجب إرسال هذا الطلب خلال اتصال HTTPS (SSL). هذه هي الطريقة الصحيحة للقيام المصادقة والتحقق إذن من الطلبات في HTTP خدمات مريحة على شبكة الإنترنت. لقد نفذت خدمة الإنترنت مريحة لتطبيق إدارة الأداء سيسكو PRIME في شركة سيسكو سيستمز. وكجزء من هذه الخدمة على شبكة الإنترنت، لقد نفذت التوثيق / ترخيص أيضا.

وروبنز غوميز.

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

أسهل طريقة لمعالجة هذه هي البداية مع HTTP المدمج في آليات التوثيق في RFC 2617.

وو"الثاقبة جدا" المادة التيskrebel المذكورة ( http://www.berenddeboer.net /rest/authentication.html ) يناقش أسلوب معقد ولكن كسر حقا المصادقة.

يمكنك محاولة زيارة الصفحة (التي من المفترض أن تكون للعرض فقط لمصادقة المستخدم) <وأ href = "http://www.berenddeboer.net/rest/site/authenticated.html" يختلط = "noreferrer" > http://www.berenddeboer.net/rest/site/authenticated.html دون أية بيانات اعتماد تسجيل الدخول.

و(عذرا لا أستطيع التعليق على الاجابة.)

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

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

تحديث على 16-Feb-2019

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

أعتقد النهج التالي يمكن استخدامها للراحة خدمة المصادقة:

  1. إنشاء تسجيل الدخول RESTful API قبول اسم المستخدم وكلمة المرور للمصادقة.استخدام HTTP POST طريقة لمنع التخزين المؤقت SSL الأمن أثناء النقل على المصادقة الناجحة ، API اثنين JWTs واحد رمز وصول (أقصر صلاحية يقول 30 دقيقة) واحدة تحديث رمز (أطول صحة القول 24 ساعة)
  2. العميل (على شبكة الإنترنت واجهة المستخدم) يخزن JWTs في التخزين المحلي و في كل لاحقا استدعاء API يمر رمز الوصول في "إذن:حامل #رمز وصول" رأس
  3. API التحقق من صحة رمز خلال التحقق من التوقيع وتاريخ انتهاء الصلاحية.إذا كان رمزي صالح ، تحقق مما إذا كان المستخدم (هذا يفسر "الفرعية" المطالبة في JWT مثل اسم المستخدم) لديه حق الوصول إلى API مع البحث في ذاكرة التخزين المؤقت.إذا كان المستخدم مخولا الوصول إلى API ، تنفيذ الأعمال المنطق
  4. إذا كان الرمز المميز منتهية الصلاحية ، API HTTP رمز الاستجابة 400
  5. العميل في تلقي 400/401 تحتج آخر REST API مع تحديث رمز في "إذن:حامل #تحديث رمز" رأس الحصول على الرمز المميز للوصول.
  6. على تلقي المكالمة مع تحديث رمز التحقق إذا تحديث رمزي صالح طريق التحقق من التوقيع وتاريخ انتهاء الصلاحية.إذا كان تحديث رمزي صالح تحديث الوصول إلى الحق ذاكرة التخزين المؤقت المستخدم من DB و عودة جديدة رمز وصول وتحديث رمزية.إذا كان تحديث مميز غير صالح عودة رمز استجابة HTTP 400
  7. أنا رمز وصول وتحديث رمزية يتم إرجاعها ، انتقل إلى الخطوة 2.إذا كان رمز استجابة HTTP 400 عاد العميل يفترض أن التحديث المميز قد انتهت و يطلب اسم المستخدم و كلمة المرور من المستخدم
  8. من أجل الخروج, تطهير التخزين المحلي

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

وهذه هي الطريقة للقيام بذلك: استخدام OAuth 2.0 للدخول .

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

للرد على هذا السؤال من وجهة نظري فهم ...

ونظام التوثيق الذي يستخدم REST بحيث لا تحتاج إلى تتبع فعلا أو إدارة المستخدمين في النظام الخاص بك. ويتم ذلك باستخدام أساليب HTTP POST، GET، PUT، DELETE. ونغتنم هذه الأساليب 4 ويفكر فيها من حيث التفاعل قاعدة البيانات كما خلق، اقرأ، UPDATE، DELETE (ولكن على شبكة الإنترنت التي نستخدمها وظيفة وGET لأن هذا هو ما تدعم تثبيت العلامات حاليا). حتى علاج ما بعد والحصول على لدينا CREATE / القراءة / UPDATE / DELETE (CRUD) ثم يمكننا تصميم الطرق في تطبيق ويب لدينا من شأنها أن تكون قادرة على استنتاج ما عمل CRUD نحن في صدد تحقيق.

وعلى سبيل المثال، في روبي على القضبان تطبيق نتمكن من بناء التطبيق على شبكة الانترنت بحيث إذا كان المستخدم الذي قام بتسجيل في مرة <لأ href = "http://store.com/account/logout" يختلط = "نوفولو noreferrer "> http://store.com/account/logout ثم GET تلك الصفحة يمكن أن ينظر إليها على أنها المستخدم محاولة خروج. في وحدة التحكم القضبان لدينا ستبني العمل في خروج المستخدم من وتعيدهم إلى الصفحة الرئيسية.

وA GET في صفحة تسجيل الدخول شأنه أن يسفر عن نموذج. فإن وظيفة في صفحة تسجيل الدخول اعتبار محاولة الدخول واتخاذ بعد البيانات واستخدامها للدخول.

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

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

وباستخدام المفتاح العمومي infrastruction فيها تسجيل مفتاح ينطوي يضمن المناسبة ملزمة بأن المفتاح العمومي لا بد أن الفرد الذي يتم تعيينه بطريقة تضمن عدم التنصل

http://en.wikipedia.org/wiki/Public_key_infrastructure . إذا كنت تتبع المعايير PKI المناسبة، والشخص أو الوكيل الذي يستخدم بشكل غير صحيح يمكن تحديد وتأمين مفتاح المسروقة. إذا كنت بحاجة إلى وكيل لاستخدام شهادة، الربط يحصل ضيق جدا. لص ذكي وسريع الحركة يمكن الهروب، لكنها تترك المزيد من الفتات.

نصائح صالحة لتأمين أي تطبيق ويب

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

يمكنك استخدام JWTs (JSON ويب الرموز) لتأمين راحة واجهات برمجة التطبيقات, هذا له العديد من المزايا بالمقارنة مع جانب الخادم جلسات الفوائد أهمها:

1 - أكثر قابلة للتطوير ، كما API خوادم سوف لا يكون لديك للحفاظ على دورات لكل مستخدم (التي يمكن أن تكون عبئا كبيرا عندما يكون لديك العديد من الدورات)

2 - JWTs هي بذاتها ولها المطالبات التي تحدد دور المستخدم على سبيل المثال & ما يمكنه الوصول إلى صدر في تاريخ & تاريخ انتهاء الصلاحية (بعد JWT لن تكون سارية المفعول)

3 - أسهل في التعامل معها عبر تحميل-موازنات & إذا كان لديك عدة API الخوادم كما أنك لن تضطر إلى مشاركة بيانات الدورة ولا تكوين ملقم توجيه الدورة على نفس الخادم ، كلما طلب JWT ضرب أي ملقم يمكن مصادقة & أذن

4 - أقل من الضغط على DB وكذلك لن باستمرار تخزين و استرجاع الدورة id & البيانات لكل طلب

5 - JWTs لا يمكن العبث بها إذا كنت تستخدم مفتاح قوي توقيع JWT ، لذلك يمكن أن تثق المطالبات في JWT التي يتم إرسالها مع طلب دون الحاجة إلى التحقق من المستخدم الدورة & إذا أذن له أو لا ، يمكنك التحقق من JWT & ثم أنت كل مجموعة أن أعرف من & ما يمكن للمستخدم القيام به.

العديد من المكتبات توفر طرق سهلة لإنشاء و التحقق من صحة JWTs في معظم لغات البرمجة ، على سبيل المثال:في node.js واحدة من أكثر شعبية هو jsonwebtoken

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

شيء واحد مهم هو أن نلاحظ أن عليك أن آمن تسليم JWT إلى العميل باستخدام HTTPS & حفظه في مكان آمن (على سبيل المثال في التخزين المحلي).

يمكنك معرفة المزيد عن JWTs من هذا الرابط

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top