معنى - مصادقة RESTful




restful api شرح (9)

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


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

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

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

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

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

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

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

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

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

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


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

روبنز جوميز.


تعتبر كيفية معالجة المصادقة في بنية 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 على الإطلاق ، ولكن يجب أن يتم استخلاصها من طبقة الاتصال.


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

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

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

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


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

أسهل طريقة للتعامل مع هذا هي البدء بآليات مصادقة HTTP المضمنة في RFC 2617 .


ما يقال بالفعل على هذا الموضوع من قبل الناس جيدة هنا. ولكن هنا سنتي 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 لن يثير أي رد فعل خاص. لها آلة لعنة. يمكن أن تهتم أقل!

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

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


I think the following approach can be used for REST service authentication:

  1. Create a login RESTful API to accept username and password for authentication. Use HTTP POST method to prevent caching and SSL for security during transit On successful authentication, the API returns two JWTs - one access token (shorter validity, say 30 minutes) and one refresh token (longer validity, say 24 hours)
  2. The client (a web based UI) stores the JWTs in local storage and in every subsequent API call passes the access token in "Authorization: Bearer #access token" header
  3. The API checks the validity of the token by verifying the signature and expiry date. If the token is valid, check if the user (It interprets the "sub" claim in JWT as username) has access to the API with a cache lookup. If the user is authorized to access the API, execute the business logic
  4. If the token is expired, the API returns HTTP response code 400
  5. The client, on receiving 400/401, invokes another REST API with the refresh token in "Authorization: Bearer #refresh token" header to get a new access token.
  6. On receiving the call with refresh token, check if the refresh token is valid by checking the signature and the expiry date. If the refresh token is valid, refresh the access right cache of the user from DB and return new access token and refresh token. If the refresh token is invalid, return HTTP response code 400
  7. If a new access token and refresh token are returned, go to step 2. If HTTP response code 400 is returned, the client assumes that the refresh token has expired and asks for username and password from the user
  8. For logout, purge the local storage

With this approach we are doing the expensive operation of loading the cache with user specific access right details every 30 minutes. So if an access is revoked or new access is granted, it takes 30 minutes to reflect or a logout followed by a login.


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.


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.







rest-security