إذا كنت جديدًا في مجال المصادقة وتبني تطبيقًا يتعامل مع تسجيلات الدخول أو المدفوعات أو بيانات المستخدم، فمن المحتمل أنك صادفت مصطلحي JWT و OAuth. قد تبدو هذه المواضيع معقدة ومقتصرة على "المطورين الخلفيين"، لكنها ليست موجهة فقط لمهندسي الأمان.
مع واجهات برمجة التطبيقات (APIs)، التكاملات مع أطراف ثالثة، والتقنيات الناشئة مثل الذكاء الاصطناعي (AI)، وبروتوكول MCP، والأنظمة القائمة على الوكلاء، يلعب هذان النظامان دورًا مباشرًا في سهولة استخدام منتجك، أمانه، ونموه. فهم الأساسيات يعني أنك تستطيع:
تصميم ميزات آمنة منذ البداية
التواصل بفعالية مع فريق التطوير
اتخاذ قرارات أفضل حول المصادقة وتدفقات المستخدم
تجنب أخطاء الأمان المكلفة التي تضر بثقة المستخدمين
على سبيل المثال، في مواصفة MCP الأحدث
لماذا هذا مهم#
حتى إذا لم تكتب كود خلفي مطلقًا:
يتعلم المطورون كيفية تأمين واجهات البرمجة وإدارة الجلسات والتكامل مع خدمات الأطراف الثالثة.
يحصل مدراء المنتجات على المفردات اللازمة لمناقشة تدفقات تسجيل الدخول والتكاملات والالتزام مع الفرق والشركاء.
يتجنب المؤسسون والفرق الناشئة بناء أنظمة تسجيل دخول هشة يمكن أن تتعطل مع التكاملات أو تترك ثغرات أمان.
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
بنية JWT#
يتكون JWT من ثلاثة أجزاء مشفرة بـ base64url، مفصولة بنقاط (.):
Header (الرأس): يحدد الخوارزمية (مثلاً، HS256، RS256) ونوع الرمز (JWT).Payload (الحمولة): يحتوي على الادعاءات، مثل:
iss (المصدر)
sub (الموضوع، مثل معرف المستخدم)
aud (الجمهور)
exp (وقت الانتهاء)
ادعاءات مخصصة حسب الحاجة
Signature (التوقيع) – يتحقق من أن الرمز لم يتم التلاعب به.
مثال:
مثال على JWT#
فيما يلي مثال لـ JWT نموذجي في صورته المشفرة، مع هيكله المفكك لتوضيح ما يمثله كل جزء.
JWT مشفر (Base64URL)
هذا مكون من ثلاثة أجزاء مفصولة بنقاط: header.payload.signature
الهيكل بعد فك التشفير
تحتوي الحمولة على الادعاءات
يضمن التوقيع أن الرمز لم يتم التلاعب به.
السمات الأساسية#
مكتفٍ ذاتيًا: كل المعلومات اللازمة داخل الرمز.بدون حالة: لا حاجة لتخزين جلسات على الخادم.موقع: (ويمكن تشفيره اختياريًا) لضمان الأصالة.
JWT مقابل OAuth: الاختلافات الجوهرية#
الجانب JWT OAuth 2.0 التعريف تنسيق رمز إطار عمل تفويض الغرض نقل الهوية/المطالبات بأمان تحديد كيفية منح وإدارة الوصول النطاق تمثيل البيانات العمليات والتدفقات يعمل بمفرده؟ نعم، لمعالجة الرموز داخليًا لا، يحتاج لتنسيق رمز (مثل JWT) مثال للاستخدام تصدر API رموز 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 معًا#
في إعدادات المصادقة/التفويض الحديثة:
OAuth يدير تدفق منح الوصول.خادم التفويض يصدر رمز الوصول: غالبًا ما يكون JWT.JWT يُرسل مع طلبات واجهات API لإثبات الهوية والصلاحيات.
رموز خاصة في OAuth#
أفضل الممارسات لاستخدام JWT و OAuth#
استخدم HTTPS لحماية الرموز أثناء النقل.حدد أوقات انتهاء قصيرة لرموز JWT؛ استخدم رموز التحديث لجلسات أطول.
تحقق من التوقيع قبل الوثوق بأي ادعاءات.تحقق من المطالبة aud لتتأكد أن الرمز مخصص لتطبيقك.تجنب تخزين الرموز في localStorage إذا كان خطر XSS قائمًا؛ فضل الكوكيز الآمنة.
أفكار أخيرة#
OAuth 2.0 يحدد كيفية طلب واستخدام الرموز.JWT يحدد ما هي هيئة الرمز وكيف يحمل المعلومات.هما مكملان لبعضهما ، وليس بدائل متبادلة.
تستخدم معظم واجهات API الحديثة OAuth لتدفقات التفويض وJWT لتمثيل الرموز. فهم كلاهما سيساعدك في تصميم أنظمة مصادقة متينة وقابلة للتوسع.
