الهوية الأساسية مقابل أذونات البورِّر أي طريقة تحقق من الهوية للواجهة البرمجية يجب استخدامها

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

الهوية الأساسية عبر HTTP

تُرسل الهوية الأساسية بيانات المصادقة مع كل طلب. يُجمع العميل بين الاسم المستخدم وكلمة المرور كـ username:password، ثم يُحولها إلى نص مُكود بـ Base64، ويُوضع في Authorization الرأس:

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

هذا النص المُكود بـ Base64 هو لا يُشفَّر. أي شخص يُعوّل على الطلب يمكنه تشفيره في ثوانٍ. الهوية الأساسية آمنة فقط عبر HTTPS، ورغم ذلك، تنتقل بيانات المصادقة مع كل طلب، وتُسجل في سجلات الخادم ما لم تُمسح بشكل فعّال.

لإنشاء القيمة الصحيحة للرأس بدون تشفير يدوي للبيانات، استخدم مولد الهوية الأساسية IO Tools.

# curl with Basic Auth
curl -u username:password https://api.example.com/data

# Or with the explicit header
curl -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=" https://api.example.com/data

// fetch with Basic Auth
const credentials = btoa('username:password');
fetch('https://api.example.com/data', {
  headers: { Authorization: `Basic ${credentials}` }
});

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

مفاتيح الواجهة (API Keys)

مفتاح الواجهة هو مفتاح ثابت — سلسلة عشوائية طويلة مُجمعة مع تطبيق أو مُرسل معين. يُرسل العميل هذا المفتاح في رأس، عادةً في X-API-Key أو عبر رأس Authorization مع نمط مخصص:

# curl with API key
curl -H "X-API-Key: sk_live_abc123xyz" https://api.example.com/data

# Or with Authorization header
curl -H "Authorization: ApiKey sk_live_abc123xyz" https://api.example.com/data

// fetch with API key
fetch('https://api.example.com/data', {
  headers: { 'X-API-Key': 'sk_live_abc123xyz' }
});

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

عندما تُستخدم: تكاملات مع مطورين، منتجات واجهات برمجة تطبيقات، ووصول واجهات برمجة تطبيقات عامة حيث ترغب في تقييد معدل الطلب لكل عميل دون الحاجة إلى تكاليف OAuth.

أذونات البورِّر (JWT)

أذونات البورِّر — الأكثر شيوعًا هي JWT (أذونات ويب من JSON) — تُصدرها خادم المصادقة ويُرسل في Authorization الرأس مع نمط Bearer :

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

تُحمل أذونات JWT محتوى مُوقّع يحتوي على بيانات: من هو المستخدم، ما هي صلاحياته، وما هو تاريخ انتهاء الصلاحية. يتحقق الخادم من صحة الأذونات من خلال التحقق من التوقيع باستخدام سرّ مشترك أو مفتاح علني — لا حاجة لبحث في قاعدة البيانات. هذا التحقق بدون حالة هو الميزة الرئيسية في أنظمة الموزعات والأنظمة المُوزعة.

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

# curl with Bearer token
curl -H "Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." \
  https://api.example.com/data

// fetch with Bearer token
fetch('https://api.example.com/data', {
  headers: { Authorization: `Bearer ${token}` }
});

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

OAuth 2.0: أذونات الوصول وأذونات التحديث

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

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

# Step 1: Exchange credentials for a token (client credentials flow)
curl -X POST https://auth.example.com/token \
  -d "grant_type=client_credentials" \
  -d "client_id=myapp" \
  -d "client_secret=mysecret"

# Step 2: Use the access token
curl -H "Authorization: Bearer ACCESS_TOKEN" https://api.example.com/data

# Step 3: Refresh when expired
curl -X POST https://auth.example.com/token \
  -d "grant_type=refresh_token" \
  -d "refresh_token=REFRESH_TOKEN" \
  -d "client_id=myapp"

أذونات الوصول تكون عادةً JWT. أذونات التحديث هي سلاسل غير مُفهومة تُخزن على الخادم — لا تُعرض أبدًا في كود المتصفح.

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

قواعد الأمان التي تنطبق على جميع الطرق

بغض النظر عن الطريقة التي تختارها، تُطبّق هذه القواعد دون استثناء.

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

موجه القرار: أي طريقة تناسب حالة الاستخدام المحددة

طريقة	غير مُحَدَّد	قابل للإلغاء	تعقيد	الواجهات، الخدمات الصغيرة، التحقق عبر الحدود
المصادقة الأساسية	نعم	بإعادة تعيين البيانات	منخفضة جدًا	أدوات داخلية، بيئة التطوير
مفتاح الواجهة	نعم	نعم، فورًا	قليل	تكاملات مع مطورين، منتجات واجهات برمجة تطبيقات
أذونات البورِّر (JWT)	نعم	باستخدام قائمة أذونات مُحذوفة فقط	واسطة	واجهات برمجة تطبيقات تُستخدم من قبل المستخدمين، أنظمة ميكروسيفرات
OAuth 2.0	تختلف	نعم	عالي	إذن من المستخدم، تكاملات مع مزود خارجي

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

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

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

الوصول إلى خدمة خارجية نيابة عن أحد مستخدميك: مُسار التصاريح OAuth 2.0. لا تُسرع من هذا. نموذج التمثيل من المستخدم موجود لأنه هو الطريقة الأكثر أمانًا لمعالجة موافقة المزود في المدى الواسع.

الاختيار الصحيح غالبًا ما يعتمد على سؤالين: من هو المُرسل، وما إذا كان هناك حاجة لموافقة من مستخدم بشري على ما يفعله المُرسل؟ إذا كان المُرسل هو جهاز وليست هناك مصادقة من المستخدم، فإن مفاتيح الواجهة تُعالج معظم الحالات بشكل ناجح. أضف JWT عندما تحتاج إلى بيانات مدمجة أو هوية غير مُحَدَّدة بين الخدمات. ابحث عن OAuth فقط عندما تكون الموافقة من المستخدم جزءًا من التدفق.

قد يعجبك أيضاً