طرق تفويض API
في هذه المقالة، سنستكشف ثلاث آليات تفويض شائعة لـ API وهي مفاتيح API، المصادقة الأساسية، و OAuth JWT tokens. وفي النهاية، سنتحدث أيضًا عن كيفية مساعدة Logto في حماية واجهات برمجة التطبيقات الخاصة بك باستخدام OAuth JWT tokens.
مقدمة
في عالم اليوم، تعتبر واجهات برمجة التطبيقات (APIs) العمود الفقري للتطبيقات الحديثة. إنها الطريقة الرئيسية للوصول إلى البيانات والوظائف من خدمات الخلفية. تتيح APIs لنظم البرمجيات المختلفة من الأطراف المختلفة التواصل ومشاركة البيانات مع بعضها البعض، مما يجعلها لا غنى عنها بالنسبة للشركات. ومع ذلك، تعتبر APIs أيضًا هدفًا شائعًا للهجمات. الحاجة إلى حماية APIs أصبحت أقوى من ذي قبل.
حماية APIs هي عملية تأمينها من الوصول غير المصرح به، وسوء الاستخدام، والهجمات. إنها مكون بالغ الأهمية لأي استراتيجية API. في هذه المقالة، سنستعرض ثلاث آليات حماية شائعة لـ API وهي: مفاتيح API، المصادقة الأساسية، و OAuth JWT tokens. وفي النهاية، سنبين كيف تتمكن Logto من حماية APIs الخاصة بك باستخدام OAuth JWT tokens.
مفاتيح API
مفتاح API هو الطريقة الأكثر مباشرة وانتشاراً لتأمين APIs. مفتاح API هو سلسلة طويلة من الأحرف التي تُولد بواسطة مزود API وتُشارك مع المستخدمين المصرح لهم. يجب تضمين هذا المفتاح في ترويسة الطلب عند الوصول إلى API. تعد مفاتيح API بسيطة وفعالة لاحتياجات الأمان ا لأساسية. على سبيل المثال، تقدم الخدمات الشهيرة مثل Google Maps API وAWS مفاتيح API للتحكم في الوصول ومراقبة الاستخدام. ومع ذلك، لديها قيود من حيث الأمان. غالبًا ما تستخدم في التواصل بين النظم.
e.g.
الإيجابيات:
- سهلة التنفيذ: مفاتيح API سهلة التنفيذ والاستخدام. تتطلب إرفاق مفتاح بترويسة الطلب، مما يجعلها طريقة بسيطة للمطورين والعملاء لفهمها واستخدامها.
- سهلة المراقبة: مفاتيح API سهلة المراقبة. يمكنك تتبع استخدام كل مفتاح وإلغائه إذا لزم الأمر.
- فعالة في تحديد معدل الاستخدام: مفاتيح API فعالة في تحديد معدل الاستخدام. يمكنك وضع حد لعدد الطلبات لكل مفتاح لمنع الإساءة.
- مناسبة للبيانات غير الحساسة: مفاتيح API مناسبة للبيانات غير الحساسة أو واجهات برمجة التطبيقات المتاحة علنيًا، حيث تكون متطلبات الأمان أقل.
السلبيات:
- أمان محدود: مفاتيح API ليست آمنة بما يكفي للبيانات الحساسة، خاصة لتطبيقات جانبية العميل. غالبًا ما تُستخدم في الاتصالات بين الآلات.
- غير مناسبة لمصادقة المستخدم: ترتبط مفاتيح API بالتطبيقات أو الأنظمة، وليس المستخدمين الفرديين، مما يجعل من الصعب تحديد المستخدمين المحددين أو تتبع أفعالهم.
- لا يوجد انتهاء صلاحية للرمز: عادةً ما تكون مفاتيح API ثابتة ولا تنتهي صلاحيتها. إذا تم اختراق مفتاح، يمكن إساءة استخدامه إلى أجل غير مسمى ما لم يُعاد إنشاؤه يدوياً.
المصادقة الأساسية
المصادقة الأساسية هي طريقة شائعة أخرى لتأمين APIs. إنها خطة مصادقة بسيطة مدمجة في بروتوكول HTTPs. تتضمن إرسال اسم مستخدم وكلمة مرور في ترويسة الطلب. يقوم الخادم بعد ذلك بالتحقق من صحة الاعتمادات ويعيد المورد المطلوب إذا كانت صالحة. على سبيل المثال، تستخدم العديد من تطبيقات الويب وواجهات RESTful APIs المصادقة الأساسية كطريقة سريعة وسهلة للتحقق من هوية المستخدمين. المصادقة الأساسية أكثر أمانًا من مفاتيح API لأنها تستخدم اسم مستخدم وكلمة مرور بدلاً من مفتاح ثابت. ومع ذلك، لا تزال ليست آمنة بما يكفي للبيانات الحساسة. حيث تُنقل اعتمادات العميل بنص عادي، فهي عرضة للاعتراض. المصادقة الأساسية مناسبة للأنظمة الداخلية حيث يكون الاتصال الشبكي آمنًا، مثلاً، اتصالات بين الآلات.
e.g.
or
الإيجابيات:
- أمان أقوى: المصادقة الأساسية أكثر أمانًا من مفاتيح API لأنها تستخدم اسم مستخدم وكلمة مرور بدلاً من مفتاح ثابت.
- دعم واسع النطاق: المصادقة الأساسية معتمدة بشكل واسع ومدعومة من معظم خوادم الويب والمتصفحات.
- بساطة: مثل مفاتيح API، فإن المصادقة الأساسية بسيطة نسبيًا للإعداد والاستخدام.
السلبيات:
- تعرض الاعتمادات: المصادقة الأساسية ترسل الاعتمادات بنص عادي، مما يجعلها عرضة للاعتراض إذا لم تُستخدم عبر اتصال آمن (HTTPS).
- لا يوجد انتهاء صلاحية للرمز: المصادقة الأساسية لا تدعم انتهاء صلاحية الرمز. إذا تم اختراق الرمز، يمكن إساءة استخدامه إلى أجل غير مسمى ما لم يُعاد إنشاؤه يدوياً.
OAuth JWT tokens
رمز JSON Web (JWT)، المحدد بواسطة RFC 7519، هو معيار مفتوح لنقل المعلومات بشكل آمن بين الأطراف ككائن JSON. يُستخدم بشكل شائع للتحقق من الهوية والتفويض في تطبيقات الويب وواجهات برمجة التطبيقات.
يحتوي JWT الموقع على التنسيق التالي:
يتكون من ثلاثة أجزاء مفصولة بـ.
: الرأس، الحمولة، والتوقيع.
هنا مثال على JWT:
- الرأس: يحتوي على معلومات عن نوع الرمز وخوارزم التوقيع المستخدم لتوقيعه.
- الحمولة: تحتوي على الادعاءات (البيانات) حول المستخدم وبيانات أخرى.
- التوقيع: هو تجزئة للرأس والحمولة، يتم توقيعه بمفتاح سري.
OAuth هو معيار مفتوح شامل لتأمين واجهات برمجة التطبيقات وللتفويض الوصول، يُستخدم بشكل شائع كوسيلة لمستخدمي العملاء لمنح المواقع أو التطبيقات الوصول إلى معلوماتهم على مواقع أخرى دون إعطائهم كلمات المرور.
عند استخدامه مع JWT، توفر OAuth JWT tokens حلاً أمنيًا قويًا. بدلاً من نقل معلومات حساسة مثل أسماء المستخدمين وكلمات المرور مع كل طلب، يتم إصدار OAuth JWT tokens للعملاء المصرح لهم بعد التحقق الناجح. تحتوي هذه الرموز على معلومات عن المستخدم وصلاحياته. بالإضافة إلى ذلك، يتم توقيع JWT tokens رقميًا لمنع التلاعب ويمكن أن تنتهي صلاحيتها، مما يوفر طبقة إضافية من الأمان.
أحد الفوائد الرئيسية لـ OAuth JWT tokens هو مرونتها. يمكن استخدامها لأنواع مختلفة من التطبيقات، بما في ذلك تطبيقات الويب وتطبيقات الجوال، وحلول تسجيل الدخول الموحد، وأكثر من ذلك. على سبيل المثال، تستخدم منصات الوسائط الاجتماعية الكبرى مثل Facebook وTwitter وLinkedIn OAuth JWT tokens للتحق ق من هوية المستخدمين والسماح لتطبيقات الطرف الثالث بالوصول إلى بيانات المستخدم بأمان.
الإيجابيات:
- تعزيز الأمان: توفر OAuth JWT tokens مستوى أعلى من الأمان. يتم توقيعها رقميًا ويمكن تشفيرها، مما يقلل من خطر الوصول غير المصرح به وتلاعب البيانات.
- هوية المستخدم والتحكم في الوصول: يمكن لـ JWT tokens حمل معلومات هوية المستخدم وتتضمن ادعاءات تحدد الإجراءات أو الموارد التي يُسمح للمستخدم بالوصول إليها.
- التحكم الدقيق في الوصول: يمكن استخدام JWT tokens لتنفيذ السيطرة الدقيقة على الوصول. على سبيل المثال، يمكنك تحديد الموارد التي يمكن للمستخدم الوصول إليها وما الإجراءات التي يمكنه تنفيذها على تلك الموارد.
- انتهاء صلاحية الرمز: يمكن ضبط انتهاء صلاحية OAuth JWT tokens بعد فترة زمنية معينة، مما يقلل من خطر الإساءة.
السلبيات:
- التعقيد: تعتبر OAuth JWT tokens أكثر تعقيدًا من مفاتيح API والمصادقة الأساسية. تتطلب خطوات إضافية للإعداد والاستخدام.
- إدارة الرمز: يحتاج OAuth JWT tokens إلى إدارة وإلغاء إذا لزم الأمر. يمكن أن يكون ذلك تحديًا للتطبيقات الكبيرة مع العديد من المستخدمين والعملاء.
- استهلاك المو ارد: قد يكون توليد والتحقق من الرموز عبئًا على الأداء، مما قد يثير القلق في سيناريوهات عالية الحركة.
حماية API بواسطة Logto
تعتمد اختيار طريقة المصادقة على المتطلبات المحددة والاعتبارات الأمنية لتطبيقك. تعتبر مفاتيح API بسيطة ولكنها أقل أمانًا، وتوفر المصادقة الأساسية أمانًا أكبر ولكنها تفتقر إلى ميزات هوية المستخدم، بينما توفر OAuth JWT tokens أماناً قويًا وقدرات هوية المستخدم ولكن تزيد من التعقيد في التنفيذ والإدارة.
توفر Logto طريقة بسيطة وآمنة لحماية API الخاصة بك باستخدام OAuth JWT tokens. تدعم كلاً من معايير OAuth 2.0 وOpenID Connect (OIDC)، مما يتيح لك اختيار طريقة المصادقة التي تناسب احتياجاتك بشكل أفضل. يمكنك استخدام مسار client_credentials
للتواصل بين الآلات ومسار authorization_code
لتطبيقات الويب.
الاتصالات بين الآلات
تستخدم Logto مسار client_credentials
لتطبيقات من نوع الاتصالات بين الآلات. هذا المسار مناسب لتواصل خادم الخلفية، حيث يكون العميل عميلًا سريًا يمكنه تخزين بيانات الاعتماد بأمان. يُعرف أيضًا باسم "OAuth ذي الساقين" لأنه لا يتضمن مستخدمًا. تُستخدم بيانات اعتماد العميل مباشرة كمنحة تفويض للحصول على رمز وصول.
عملية التكامل بسيطة ومباشرة:
- قم بإنشاء مصدر API في Logto Console.
- قم بإنشاء عميل للاتصال بين الآلات في Logto Console.
- ارسل طلبًا إلى نقطة نهاية رمز Logto للحصول على رمز وصول.
- الوصول إلى المورد المحمي باستخدام رمز الوصول.
يرجى الاطلاع على وثائق دمج الاتصالات بين الآلات للحصول على المزيد من التفاصيل.
تطبيقات الويب
بالنسبة للعملاء العامين مثل تطبيقات الويب، تستخدم Logto مسار authorization_code
للتحقق من هوية المستخدمين. هذا المسار مناسب لتطبيقات الويب حيث يكون العميل عميلًا عامًا لا يمكنه تخزين بيانات الاعتماد بأمان. يُعرف أيضًا باسم "OAuth ذي الثلاثة أرجل" لأنه يتضمن مستخدمًا. يتم إعادة توجيه المستخدم إلى خادم التفويض للتحقق من هويته وتفويض العميل. يستخدم العميل بعد ذلك رمز التفويض للحصول على رمز الوصول.
عملية التكامل أكثر تعقيدًا قليلاً من مسار الاتصال بين الآلات:
يرجى الاطلاع على مقالتنا حول حماية API Express.js باستخدام JWT وLogto كمثال شامل حول كيفية دمج Logto مع React والوصول إلى واجهات خادم Express الخاصة بك باستخدام JWT tokens.