ما هي الاختلافات بين العملاء العامين والعملاء السريين؟

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

قبل أن نبدأ، نحتاج إلى تقديم مقدمة قصيرة لبعض المفاهيم.

ما هو OAuth؟#

OAuth هو معيار مفتوح لتفويض الوصول، والذي يُستخدم عادة كوسيلة للمستخدمين على الإنترنت لمنح المواقع الإلكترونية أو التطبيقات الوصول إلى معلوماتهم على مواقع أخرى دون تقديم كلمات المرور الخاصة بهم.

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

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

العملاء العامون والعملاء السريين#

يُعرِّف OAuth نوعين من العملاء، بناءً على قدرتهم على الحفاظ على سرية بيانات اعتماد العميل.

العميل السري#

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

العميل العام#

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

SPA، التطبيق الأصلي، وتطبيق الويب التقليدي#

مع المعرفة الأساسية المذكورة أعلاه، لنلقِ نظرة على ما تعنيه SPA، التطبيق الأصلي، وتطبيق الويب التقليدي في سياق Logto، وما إذا كانت تعتبر عملاء عامين أو عملاء سريين.

SPA#

يتم تنزيل كود الجانب العميل في SPA من خادم الويب ويتم تنفيذه في وكيل المستخدم (مثل متصفح الويب) التابع لمالك المورد على جهازه. بيانات البروتوكول وبيانات الاعتماد هي سهلة المنال (وغالبًا مرئية) لمالك المورد.

التطبيق الأصلي#

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

تطبيق الويب التقليدي#

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

لذلك، يمكننا أن نرى بوضوح أن SPA وتطبيقات الأصلية هي عملاء عامين، بينما تطبيق الويب التقليدي هو عميل سري.

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

كيف يعمل العميل في تدفق تفويض OAuth؟#

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

يعتبر معرف العميل معلومات عامة ومشتركة مع المستخدم أثناء عملية OAuth. يتم تضمينه عادةً في عنوان URL التفويض ويكون مرئيًا للمستخدمين النهائيين.

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

تقديم إثبات المفتاح لتبادل الرموز (PKCE)#

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

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

يعمل مساند الرمز في PKCE فعليًا كسر عميل ديناميكي. يتم ضمان أمانه بسبب عدم إمكانية عكس خوارزمية التجزئة.

ملخص#

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

كما ناقشنا عملية تسجيل العميل في OAuth وأدوار معرف العميل وسر العميل.

علاوة على ذلك، وجدنا أن العملاء العامين يواجهون محدوديات في تخزين أسرار العميل بأمان. للتغلب على هذا القيد، قدمنا PKCE (إثبات المفتاح لتبادل الرموز)، وهو امتداد لـ OAuth الذي يسمح للعملاء العامين بتبادل رموز التفويض بأمان دون الحاجة إلى سر العميل.

منتجنا، Logto، هو حل CIAM شامل يتبع أفضل ممارسات بروتوكولات OAuth وOIDC لضمان الأمان في كل مرحلة، بما في ذلك اعتماد استخدام PKCE لحماية أمان العملاء العامين.