JWT مقابل OAuth: الاختلافات الرئيسية، كيف يعملان معًا، وأفضل الممارسات

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

مع واجهات برمجة التطبيقات (APIs)، التكاملات مع أطراف ثالثة، والتقنيات الناشئة مثل الذكاء الاصطناعي (AI)، وبروتوكول MCP، والأنظمة القائمة على الوكلاء، يلعب هذان النظامان دورًا مباشرًا في سهولة استخدام منتجك، أمانه، ونموه. فهم الأساسيات يعني أنك تستطيع:

• تصميم ميزات آمنة منذ البداية
• التواصل بفعالية مع فريق التطوير
• اتخاذ قرارات أفضل حول المصادقة وتدفقات المستخدم
• تجنب أخطاء الأمان المكلفة التي تضر بثقة المستخدمين

على سبيل المثال، في مواصفة MCP الأحدث، يعتمد نظام التفويض على معايير مثبتة:

• مسودة OAuth 2.1 IETF (draft-ietf-oauth-v2-1-13)
• بيانات تعريف خادم تفويض OAuth 2.0 (RFC8414)
• بروتوكول تسجيل العميل الديناميكي OAuth 2.0 (RFC7591)
• بيانات تعريف المورد المحمي OAuth 2.0 (RFC9728)

لماذا هذا مهم#

حتى إذا لم تكتب كود خلفي مطلقًا:

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

JWT مقابل OAuth: المفهومان الرئيسيان#

عادةً ما يتم استخدام JWT (JSON Web Token) و OAuth (Open Authorization) معًا، لكن كلًا منهما له غرض مختلف.

فكر فيها بهذا الشكل:

• OAuth هو كيف تعطي المفاتيح لشخص ما، لكن فقط للأماكن المصرح له بدخولها.
• JWT هو بطاقة الهوية التي يحملها، لإثبات من هو وماذا يمكنه فعله.

في القسم التالي، سنوضحهما جنبًا إلى جنب حتى يمكنك رؤية الفروق وكيف يكمل كل منهما الآخر بوضوح.

ما هو OAuth 2.0؟#

OAuth 2.0 هو إطار تفويض واسع الانتشار يمكّن التطبيق (العميل) من الوصول إلى موارد المستخدم بصلاحيات محدودة، دون الحاجة لمشاركة بيانات اعتماد المستخدم (مثل كلمات المرور) .

الأدوار الأساسية في OAuth#

• العميل: التطبيق الذي يطلب الوصول.
• مالك المورد: عادة المستخدم، الذي يمنح الإذن.
• خادم التفويض: يصدر رموز الوصول بعد التفويض.
• خادم الموارد: يستضيف الموارد المحمية ويتحقق من صحة الرموز

أنواع منح OAuth الشائعة (التدفقات)#

• Authorization Code Grant: الأكثر أمانًا والمُوصى به، خاصة مع PKCE لتطبيقات المتصفح، SPA، والتطبيقات المحمولة.
• Implicit Grant: بات الآن غير مُوصى به في OAuth 2.1 لأسباب أمنية.
• Resource Owner Password Credentials (ROPC): يبادل اسم المستخدم وكلمة المرور مباشرة بالرموز؛ أقل أمانًا.
• Client Credentials Grant: لتواصل الخادم مع الخادم أو من جهاز لآخر.
• Device Flow: للأجهزة دون لوحات مفاتيح (مثلاً التلفزيونات الذكية)، حيث يصرح المستخدم من جهاز آخر.

ما هو JWT (JSON Web Token)؟#

JWT هو معيار مفتوح (RFC 7519) لنقل المعلومات (الادعاءات) بأمان بين طرفين بطريقة مضغوطة وآمنة لروابط URL.

بنية JWT#

يتكون JWT من ثلاثة أجزاء مشفرة بـ base64url، مفصولة بنقاط (.):

1. Header (الرأس): يحدد الخوارزمية (مثلاً، HS256، RS256) ونوع الرمز (JWT).
2. Payload (الحمولة): يحتوي على الادعاءات، مثل:
   • iss (المصدر)
   • sub (الموضوع، مثل معرف المستخدم)
   • aud (الجمهور)
   • exp (وقت الانتهاء)
   • ادعاءات مخصصة حسب الحاجة
3. Signature (التوقيع) – يتحقق من أن الرمز لم يتم التلاعب به.

مثال:

مثال على JWT#

فيما يلي مثال لـ JWT نموذجي في صورته المشفرة، مع هيكله المفكك لتوضيح ما يمثله كل جزء.

JWT مشفر (Base64URL)

هذا مكون من ثلاثة أجزاء مفصولة بنقاط: header.payload.signature

الهيكل بعد فك التشفير

• Header (الرأس)

• Payload (الحمولة)

تحتوي الحمولة على الادعاءات

• Signature (التوقيع)

يضمن التوقيع أن الرمز لم يتم التلاعب به.

السمات الأساسية#

• مكتفٍ ذاتيًا: كل المعلومات اللازمة داخل الرمز.
• بدون حالة: لا حاجة لتخزين جلسات على الخادم.
• موقع: (ويمكن تشفيره اختياريًا) لضمان الأصالة.

JWT مقابل OAuth: الاختلافات الجوهرية#

باختصار:

• JWT هو الحاوية: مثل جواز السفر مع تفاصيل الهوية.
• OAuth هو النظام: مثل مراقبة الحدود التي تحدد من يحصل على جواز السفر وما يمكنه الوصول إليه.

متى تستخدم JWT فقط#

استخدم JWT بمفرده عندما:

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

مثال:

تطبيق صفحة واحدة وواجهة برمجة خلفية تملكها. تصدر API رمز JWT يحتوي على sub (معرف المستخدم)، role (الدور) وexp (الانتهاء).

متى تستخدم OAuth فقط#

استخدم OAuth بدون JWT عندما:

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

مثال:

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

متى تستخدم JWT و OAuth معًا#

استخدمهما معًا عندما:

• لديك خدمات أو واجهات API متعددة وتريد OAuth لتدفق آمن و JWT لرموز يمكن التحقق منها عبر الخدمات.
• تقدم تسجيل دخول لطرف ثالث مثل "تسجيل الدخول مع Google" حيث يدير OAuth الموافقة ويحمل JWT رمز الوصول أو الهوية.
• تعمل في بنية الخدمات المصغرة (microservices) بحيث يمكن لكل خدمة التحقق من رموز JWT محليًا.
• تحتاج إلى قابلية التوسع من خلال نموذج التفويض في OAuth والتحقق عديم الحالة لـ JWT.

مثال:

يسمح تطبيقك للمستخدمين بتسجيل الدخول باستخدام Google. يدير OAuth عملية التفويض، تصدر Google رمز JWT وصول، والتحقق يتم محليًا عبر واجهات API.

كيف يعمل JWT و OAuth معًا#

في إعدادات المصادقة/التفويض الحديثة:

1. OAuth يدير تدفق منح الوصول.
2. خادم التفويض يصدر رمز الوصول: غالبًا ما يكون JWT.
3. JWT يُرسل مع طلبات واجهات API لإثبات الهوية والصلاحيات.

رموز خاصة في OAuth#

• رمز الهوية (ID token): يُستخدم في OpenID Connect لإثبات هوية المستخدم؛ دائمًا يكون JWT.
• رمز الوصول (Access token): يمكن أن يكون JWT أو رمز معتم (opaque token).

أفضل الممارسات لاستخدام JWT و OAuth#

• استخدم HTTPS لحماية الرموز أثناء النقل.
• حدد أوقات انتهاء قصيرة لرموز JWT؛ استخدم رموز التحديث لجلسات أطول.
  • https://auth.wiki/offline-access.
• تحقق من التوقيع قبل الوثوق بأي ادعاءات.
• تحقق من المطالبة aud لتتأكد أن الرمز مخصص لتطبيقك.
• تجنب تخزين الرموز في localStorage إذا كان خطر XSS قائمًا؛ فضل الكوكيز الآمنة.

أفكار أخيرة#

• OAuth 2.0 يحدد كيفية طلب واستخدام الرموز.
• JWT يحدد ما هي هيئة الرمز وكيف يحمل المعلومات.
• هما مكملان لبعضهما، وليس بدائل متبادلة.

تستخدم معظم واجهات API الحديثة OAuth لتدفقات التفويض وJWT لتمثيل الرموز. فهم كلاهما سيساعدك في تصميم أنظمة مصادقة متينة وقابلة للتوسع.