OAuth مقابل JWT: فهم المصادقة الحديثة في عام 2026

الوصف التعريفي: تعرّف على الفرق بين OAuth وJWT في أنظمة المصادقة الحديثة، وكيف تعمل آليات التفويض، وكيف تُستخدم رموز JWT، وما أهم الاعتبارات الأمنية، ومتى يكون استخدام كل منهما مناسبًا.

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

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

فهم هذا الفرق يساعد المطورين على تصميم أنظمة مصادقة وتفويض أكثر أمانًا وقابلية للتوسع ومناسبة لبنية التطبيق.

ما هو OAuth؟

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

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

يعرّف OAuth عدة أدوار أساسية:

• مالك المورد: الشخص أو الجهة التي تمتلك الموارد المحمية.
• العميل: التطبيق الذي يطلب الوصول.
• خادم التفويض: النظام الذي يقوم بمصادقة المستخدم وإصدار بيانات التفويض.
• خادم الموارد: واجهة API أو الخدمة التي تستضيف الموارد المحمية.

يفصل OAuth عملية التفويض عن مشاركة بيانات اعتماد المستخدم مباشرة مع التطبيق. وبدلًا من إعطاء التطبيق كلمة مرور المستخدم، يحصل التطبيق على رمز وصول يحدد الصلاحيات ومدة الوصول.

ما هو JWT؟

JSON Web Token، أو JWT، هو تنسيق مدمج وآمن من ناحية النقل لتمثيل مجموعة من الادعاءات بين طرفين.

يتكون JWT عادةً من ثلاثة أجزاء:

• Header: يحتوي على معلومات مثل نوع الرمز والخوارزمية المستخدمة.
• Payload: يحتوي على Claims مثل هوية المستخدم والجهة المصدرة ووقت انتهاء الصلاحية ومعلومات أخرى.
• Signature: تُستخدم للتحقق من أن الرمز لم يتم تعديله وأنه صادر من جهة موثوقة وفقًا لخوارزمية وإدارة المفاتيح المستخدمة.

يمكن تبسيط بنية JWT بالشكل التالي:

header.payload.signature

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

OAuth مقابل JWT: ما الفرق الأساسي؟

العنصر	OAuth 2.0	JWT
النوع	إطار عمل للتفويض	تنسيق للرموز
الهدف الأساسي	التفويض ومنح الوصول	تمثيل الادعاءات الأمنية
يحدد تدفقات التفويض	نعم	لا
يحدد بنية الرمز	لا	نعم
يمكنه استخدام Access Tokens	نعم	يمكن أن يمثل Access Token
يمكن استخدامهما معًا	نعم	نعم

كيف يعمل OAuth؟

يمكن تبسيط تدفق التفويض باستخدام OAuth بالشكل التالي:

1. يبدأ المستخدم إجراءً يحتاج إلى الوصول إلى مورد محمي.
2. يتفاعل التطبيق مع خادم التفويض.
3. يقوم المستخدم بالمصادقة ويمنح الإذن.
4. يحصل التطبيق على نتيجة التفويض، مثل Authorization Code.
5. يقوم التطبيق بتبادل Authorization Code للحصول على Access Token.
6. يرسل التطبيق Access Token عند طلب الموارد المحمية.
7. يتحقق خادم الموارد من الرمز والصلاحيات ثم يسمح بالطلب أو يرفضه.

يجب أن تتبع تطبيقات OAuth الحديثة أفضل الممارسات الأمنية الحالية. بالنسبة إلى تطبيقات المتصفح والعملاء العامين، يعد PKCE من وسائل الحماية المهمة، كما تتطلب إرشادات OAuth الأمنية الحالية دعم PKCE من خوادم التفويض.

كيف تعمل مصادقة JWT؟

تعمل بنية المصادقة باستخدام JWT عادةً بطريقة مختلفة.

1. يرسل المستخدم بيانات تسجيل الدخول إلى خدمة المصادقة.
2. يتحقق الخادم من صحة بيانات المستخدم.
3. ينشئ الخادم JWT موقّعًا يحتوي على Claims مناسبة.
4. يحصل التطبيق على الرمز.
5. يرسل التطبيق الرمز عند إجراء طلبات API محمية.
6. يتحقق الخادم من الرمز ومن Claims مثل تاريخ الانتهاء والجهة المصدرة والجمهور والصلاحيات.

على سبيل المثال، يمكن إرسال رمز Bearer داخل ترويسة Authorization:

Authorization: Bearer <access-token>

تُعد طريقة إصدار الرموز وتخزينها والتحقق منها وتجديدها وإلغائها من القرارات المهمة في تصميم النظام ويجب التعامل معها بعناية.

هل OAuth أفضل من JWT؟

ليس بالضرورة. فالمقارنة بينهما تشبه مقارنة إطار عمل أمني بتنسيق بيانات.

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

لذلك يمكن للتطبيق استخدام OAuth مع JWT Access Tokens.

على سبيل المثال، يمكن لخادم OAuth إصدار Access Token بتنسيق JWT، ثم يقوم خادم API بالتحقق من هذا الرمز. في هذه الحالة، OAuth يدير عملية التفويض، بينما JWT يحدد شكل الرمز.

استخدام OAuth مع JWT

يمكن أن يكون الجمع بين OAuth وJWT مفيدًا في الأنظمة الموزعة وبنى التطبيقات التي تعتمد على API.

يمكن أن تتكون البنية من:

• تطبيق Frontend
• خادم تفويض
• واحد أو أكثر من APIs
• خادم موارد
• Access Tokens قصيرة المدة
• آلية Refresh Tokens عند الحاجة

في هذه البنية، يدير OAuth عملية التفويض، بينما يمكن استخدام JWT لتمثيل Access Token.

مزايا OAuth

الوصول المفوض

يسمح OAuth للتطبيقات بالحصول على وصول محدد إلى الموارد دون الحاجة إلى مشاركة كلمة مرور المستخدم مباشرة مع التطبيق العميل.

الصلاحيات والنطاقات

يمكن تقييد Access Tokens باستخدام Scopes وصلاحيات أخرى، مما يساعد التطبيقات على طلب الحد الأدنى من الصلاحيات المطلوبة.

التكامل مع خدمات الطرف الثالث

يُعد OAuth مناسبًا بشكل خاص عندما تحتاج التطبيقات إلى التفاعل مع APIs أو خدمات خارجية نيابةً عن المستخدمين.

مرونة البنية

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

مزايا JWT

تنسيق مدمج

تتميز JWTs بحجمها المدمج، مما يجعلها مناسبة لنقل Claims عبر الأنظمة التي تعتمد على HTTP.

Claims داخل الرمز

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

مناسب لواجهات API

تُستخدم JWTs بشكل شائع في بنى API التي تحتاج فيها الخدمات إلى طريقة موحدة لاستقبال Claims والتحقق منها.

الاتصال بين الخدمات

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

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

استخدام OAuth أو JWT لا يعني تلقائيًا أن التطبيق أصبح آمنًا. تعتمد الحماية بشكل كبير على طريقة التنفيذ وإدارة دورة حياة الرموز.

استخدم HTTPS

يجب حماية حركة بيانات المصادقة والتفويض باستخدام اتصال آمن، وعدم إرسال الرموز عبر اتصالات غير مشفرة.

استخدم Access Tokens قصيرة المدة

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

قلل نطاق الصلاحيات

ينبغي عدم منح Access Token صلاحيات أكثر من المطلوب. وتوصي إرشادات OAuth الأمنية الحالية بتقليل مدة صلاحية الرموز وتقليل Scopes قدر الإمكان.

احمِ Refresh Tokens

يمكن أن تمنح Refresh Tokens وصولًا طويل المدى، ولذلك يجب حمايتها بعناية واستخدام آليات مناسبة للتدوير والإلغاء عند الحاجة.

تحقق من JWT Claims

يجب على APIs التحقق من خصائص JWT المهمة بدلًا من مجرد فك Payload والثقة بالمعلومات الموجودة داخله. ويمكن أن يشمل ذلك Signature وIssuer وAudience وExpiration والصلاحيات المطلوبة، حسب بنية النظام.

استخدم PKCE مع تدفقات OAuth المناسبة

يساعد PKCE على حماية تدفق Authorization Code من بعض هجمات اعتراض Authorization Code والمخاطر المرتبطة بها. وتوصي إرشادات OAuth الحالية بدعم PKCE من خوادم التفويض.

OAuth مقابل JWT: متى تستخدم كل منهما؟

استخدم OAuth عندما:

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

استخدم JWT عندما:

• تحتاج إلى تنسيق مدمج لتمثيل Claims.
• تحتاج بنية API إلى رموز موقعة.
• تحتاج عدة خدمات إلى التحقق من Claims.
• تحتاج إلى تنسيق موحد للرموز.

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

• تحتاج إلى التفويض بالإضافة إلى Access Tokens بتنسيق JWT.
• يحتوي التطبيق على عدة APIs أو خدمات.
• تبني بنية حديثة للهوية والتفويض.
• تحتاج إلى التحكم في الوصول بين العملاء وخوادم الموارد.

OAuth مقابل JWT لتطبيقات الويب والهواتف

بالنسبة إلى تطبيقات الويب الحديثة، يمكن استخدام OAuth عندما تتم إدارة المصادقة والتفويض من خلال منصة هوية مخصصة. ويجب على تطبيقات المتصفح اتباع إرشادات OAuth الأمنية الحالية، مع الاهتمام بشكل خاص بالتعامل مع الرموز واستخدام Authorization Code Flow مع PKCE عند الحاجة.

أما تطبيقات الهواتف، فيمكنها استخدام OAuth لتوفير تدفقات تفويض قياسية، بينما يمكن استخدام JWT كتنسيق لـ Access Token. ويجب على تطبيقات الهواتف استخدام آليات الحماية المناسبة للمنصة وعدم تخزين بيانات الاعتماد السرية داخل كود التطبيق العميل.

أخطاء شائعة يجب على المطورين تجنبها

• اعتقاد أن OAuth وJWT هما التقنية نفسها.
• استخدام JWT لمجرد أنه شائع دون دراسة متطلبات التطبيق.
• وضع معلومات حساسة داخل JWT دون إدراك أن Payload في JWT الموقّع يمكن قراءته عادةً من قبل حامل الرمز.
• استخدام Access Tokens طويلة المدة دون حاجة.
• عدم التحقق من Expiration وClaims المهمة.
• منح Scopes أو صلاحيات واسعة جدًا.
• تنفيذ OAuth دون وسائل حماية مناسبة مثل PKCE.
• تخزين الرموز بطريقة غير آمنة على أجهزة المستخدم.
• الاعتقاد بأن صحة Signature وحدها تعني أن الطلب يجب السماح به تلقائيًا.

طريقة بسيطة لتذكر الفرق بين OAuth وJWT

يمكن تذكر الفرق بهذه الطريقة:

OAuth يجيب عن السؤال: "كيف يمكن للتطبيق الحصول على وصول مصرح به؟"

JWT يجيب عن السؤال: "كيف يمكن تمثيل Claims داخل رمز مدمج؟"

يمكن استخدام كل منهما بشكل مستقل في بعض البنى، لكنهما غالبًا يعملان معًا في الأنظمة الحديثة.

الخلاصة

يلعب OAuth وJWT دورين مختلفين في أمن التطبيقات الحديثة. يوفر OAuth 2.0 إطارًا للتفويض والتحكم في الوصول المفوض، بينما يوفر JWT تنسيقًا موحدًا لتمثيل Claims.

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

وفي كثير من البنى الحديثة، لا يكون القرار الحقيقي هو الاختيار بين OAuth وJWT، بل فهم كيفية عملهما معًا. يمكن لـ OAuth إدارة عملية التفويض، بينما يمكن استخدام JWT كأحد التنسيقات الممكنة لـ Access Token.

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