العميل (Client)

ما هو العميل (Client)؟

العميل، في سياق OAuth 2.0 و OpenID Connect (OIDC) ، هو تطبيق يطلب المصادقة (authentication) أو التفويض (authorization). على سبيل المثال، عندما ينقر المستخدم على “تسجيل الدخول باستخدام Google” على تطبيق ما، يعمل التطبيق كـ العميل (Client) الذي يطلب التفويض من Google.

غالبًا ما يتم استخدام “العميل (Client)” و”التطبيق” بالتبادل في سياق إدارة الهوية والوصول (Identity and access management, IAM) .

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

العملاء العلنيون

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

• التطبيقات ذات الصفحة الواحدة (SPAs)
• تطبيقات الجوال
• تطبيقات سطح المكتب

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

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

العملاء السريون (الخاصة) هم تطبيقات يمكنها تخزين المعلومات الحساسة بشكل سري دون كشفها لأصحاب الموارد (المستخدمين النهائيين). أمثلة على العملاء السريين تشمل:

• خوادم الويب
• خدمات الخلفية

كيف يعمل العميل (Client)؟

مصادقة المستخدم والتفويض

عندما يريد العميل مصادقة المستخدم، يقوم العميل ببدء طلب الترخيص (Authorization request) إلى خادم التفويض (Authorization server) للحصول على رمز الوصول (Access token) . يجب أن يتضمن العميل المعلمات الضرورية في الطلب، مثل معرف العميل، و redirect URI، و scopes. إليك مخطط تسلسلي مبسط لتدفق رمز التفويض:

في هذا المثال، يعمل Google كـ خادم التفويض (authorization server) الذي يصدر رمز وصول إلى العميل (Client) (MyApp) بعد أن يقوم المستخدم بتسجيل الدخول بنجاح. يمكن للعميل بعد ذلك استخدام رمز الوصول (access token) لجلب ملف تعريف المستخدم (المورد المحمي) على Google.

بالنسبة إلى عملاء OpenID Connect (OIDC)، يحتاج العميل إلى بدء طلب مصادقة (Authentication request) لمصادقة المستخدم. يستخدم نفس نقطة النهاية مثل طلب التفويض، لكن المعلمات والاستجابة مختلفة.

الاتصال من جهاز إلى جهاز

بالنسبة إلى اتصال الآلة بالآلة (Machine-to-machine) الاتصال، يمكن للعميل استخدام تدفق بيانات الاعتماد للعميل (Client credentials flow) لإرسال طلب الرمز (Token request) مباشرة إلى خادم التفويض. يجب أن يتضمن العميل معرف العميل، والسر الأمان الخاص بالعميل، و scopes في الطلب. إليك مخطط تسلسلي مبسط لتدفق أوراق اعتماد العميل:

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

اعتبارات الأمان

أنواع العملاء

يؤثر نوع العميل (علني أو خاص) على اعتبارات الأمان للعميل.

• لا ينبغي للعملاء العلنيين استخدام تدفق أوراق اعتماد العميل لأنها لا تستطيع تخزين السر الأمان بشكل آمن. بدلاً من ذلك، يُوصى باستخدام تدفق رمز التفويض (Authorization code flow) مع مفتاح إثبات تبادل الكود (Proof Key for Code Exchange, PKCE) للعملاء العلنيين لمصادقة المستخدمين.
• يمكن للعملاء السريين استخدام تدفق أوراق اعتماد العميل للاتصال من جهاز إلى جهاز. ينبغي عليهم تخزين السر الأمان بشكل آمن واستخدامه فقط في البيئات الآمنة.

تخزين الرموز

يجب على العملاء استخدام أعلى مستوى ممكن من الأمان لتخزين الرموز. على سبيل المثال، في تطبيقات الويب، يُوصى باستخدام ملفات تعريف الارتباط HTTP-only لتخزين رموز الوصول لمنع هجمات XSS.

انتهاء صلاحية الرموز

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

إلغاء الرموز

يجب على العملاء أن يكونوا مستعدين للتعامل مع إلغاء الرموز. إذا قام المستخدم بتسجيل الخروج أو ألغى خادم التفويض الرمز، يجب على العميل مسح الرمز من تخزين الجانب العميل.

انظر أيضا

• OAuth 2.0
• منح OAuth 2.0 (Grant)
• OpenID Connect (OIDC)
• طلب الترخيص (Authorization request)
• طلب مصادقة (Authentication request)