authentication - مصادقة RESTful




restful-authentication rest-security (12)

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


Answers

That's the way to do that: Using OAuth 2.0 for Login .

You may use other authentication methods other then Google's as long as it supports OAuth.


أولاً وقبل كل شيء ، فإن خدمة RESTful على شبكة الإنترنت هي STATELESS (أو بعبارة أخرى ، SESSIONLESS ). لذلك ، ليس لدى خدمة RESTful ويجب أن يكون لديك مفهوم جلسة العمل أو ملفات تعريف الارتباط المعنية. طريقة إجراء المصادقة أو التخويل في خدمة RESTful هي باستخدام رأس تخويل HTTP كما هو محدد في مواصفات HTTP RFC 2616. يجب أن يحتوي كل طلب على رأس تخويل HTTP ، ويجب إرسال الطلب عبر اتصال HTTPs (SSL). هذه هي الطريقة الصحيحة لإجراء المصادقة والتحقق من مصادقة الطلبات في خدمات HTTP RESTful على الويب. لقد قمت بتطبيق خدمة RESTful على الويب لتطبيق Cisco PRIME Performance Manager في Cisco Systems. وكجزء من خدمة الويب هذه ، قمت بتطبيق المصادقة / التخويل أيضًا.

روبنز جوميز.


To answer this question from my understanding...

An authentication system that uses REST so that you do not need to actually track or manage the users in your system. This is done by using the HTTP methods POST, GET, PUT, DELETE. We take these 4 methods and think of them in terms of database interaction as CREATE, READ, UPDATE, DELETE (but on the web we use POST and GET because that is what anchor tags support currently). So treating POST and GET as our CREATE/READ/UPDATE/DELETE (CRUD) then we can design routes in our web application that will be able to deduce what action of CRUD we are achieving.

For example, in a Ruby on Rails application we can build our web app such that if a user who is logged in visits http://store.com/account/logout then the GET of that page can viewed as the user attempting to logout. In our rails controller we would build an action in that logs the user out and sends them back to the home page.

A GET on the login page would yield a form. a POST on the login page would be viewed as a login attempt and take the POST data and use it to login.

To me, it is a practice of using HTTP methods mapped to their database meaning and then building an authentication system with that in mind you do not need to pass around any session id's or track sessions.

I'm still learning -- if you find anything I have said to be wrong please correct me, and if you learn more post it back here. شكر.


Using a Public key infrastruction in which the registration of a key involves proper binding ensures that the public key is bound to the individual to which it is assigned in a way that ensures non-repudiation

See http://en.wikipedia.org/wiki/Public_key_infrastructure . If you follow the proper PKI standards, the person or agent who improperly uses the stolen key can be identified and locked out. If the agent is required to use a certificate, the binding gets pretty tight. A clever and quick-moving thief can escape, but they leave more crumbs.


إليك حل مصادقة RESTful حقيقي تمامًا:

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

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

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

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

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

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

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

هذا هو مصادقة عديمة الحالة / RESTful.

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


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

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

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

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


تعتبر كيفية معالجة المصادقة في بنية RESTful Client-Server مسألة مناقشة.

عادة ، يمكن تحقيق ذلك ، في SOA عبر HTTP عبر العالم:

  • المصادقة الأساسية لـ HTTP عبر HTTPS ؛
  • ملفات تعريف الارتباط وإدارة الجلسة
  • الرمز المميز في رؤوس HTTP (على سبيل المثال OAuth 2.0) ؛
  • مصادقة الاستعلام مع معلمات توقيع إضافية.

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

يحتوي كل نظام مصادقة على PROs و CONS الخاصة به ، اعتمادًا على الغرض من سياسة الأمان الخاصة بك وبنية البرامج.

المصادقة الأساسية لـ HTTP عبر HTTPS

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

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

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

قد نستخدم مصادقة ديجست ، ولكن يتطلب ذلك أيضًا HTTPS ، نظرًا لأنها عرضة لهجمات MiM أو Replay ، وهي خاصة بـ HTTP.

الجلسة عبر ملفات تعريف الارتباط

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

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

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

تقنية ملفات تعريف الارتباط نفسها مرتبطة بـ HTTP ، لذا فهي ليست RESTful حقًا ، والتي يجب أن تكون مستقلة عن البروتوكول ، IMHO. وهي عرضة لهجمات MiM أو Replay .

منح عبر الرمز المميز (OAuth2)

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

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

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

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

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

تم تعريفه على هذا النحو في هذه المقالة:

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

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

على سبيل المثال ، إليك عينة عامة من URI من الرابط أعلاه:

GET /object?apiKey=Qwerty2010

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

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

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

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

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

من الناحية العملية ، قد يكون المصادقة المقبلة على MAC Tokens for OAuth 2.0 تحسينًا كبيرًا فيما يتعلق بالنظام الحالي "Granted by Token". ولكن لا يزال هذا العمل قيد التقدم ، وهو مرتبط بنقل HTTP.

استنتاج

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


ما يقال بالفعل على هذا الموضوع من قبل الناس جيدة هنا. ولكن هنا سنتي 2.

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

  1. من إنسان لآخر (HTM)
  2. من آلة إلى آلة (MTM)

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

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

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

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

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

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

طريقة 1:

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

طريقة 2:

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

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

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

لكنني استطرادا.

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

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

المزيد من الطبقات ، والمزيد من الكمون.

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

نفس مع Way-2. لن يلاحظ المستخدم (البشري) أبدًا. لذلك لا ضرر القيام به.

ماذا لو طبقنا Way-1 على MTM؟ في هذه الحالة ، منذ جهازها ، يمكننا أن نخرج الجحيم من هذا الرجل عن طريق طلب تقديم معلومات التوثيق مع كل طلب. لا أحد يهتم! أداء الطريق 2 على MTM لن يثير أي رد فعل خاص. لها آلة لعنة. يمكن أن تهتم أقل!

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

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


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

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

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

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

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

من خلال جعل جلسات مورد RESTful مع القواعد التالية فقط:

  • تعيّن الجلسة مفتاحًا لمعرف المستخدم (وربما آخر طابع زمني للوقت)
  • إذا وجدت جلسة ، فهذا يعني أن المفتاح صالح.
  • تسجيل الدخول يعني POSTING إلى / جلسات ، يتم تعيين مفتاح جديد كملف تعريف ارتباط
  • يعني "تسجيل الخروج" حذف / جلسات / {key} (مع POST زائد التحميل ، تذكر ، نحن متصفح ، و HTML 5 هو طريق طويل لنقطعه حتى الآن)
  • تتم المصادقة عن طريق إرسال المفتاح كملف تعريف ارتباط في كل طلب والتحقق مما إذا كانت الجلسة موجودة وصالحة

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

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

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


I think restful authentication involves the passing of an authentication token as a parameter in the request. Examples are the use of apikeys by api's. I don't believe the use of cookies or http auth qualifies.


تناقش مقالة "ثاقبة جدًا" التي ذكرهاskrebel ( here ) طريقة مصادقة معقدة ولكن تم كسرها حقًا.

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

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

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


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

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





rest authentication restful-authentication rest-security