OAuth وJWT والبوابات: فصل ضوابط الأمان

الخلاصة

ينظم OAuth 2.0 التفويض المفوض، ويضيف OpenID Connect طبقة مصادقة. JWT صيغة رمز والبوابة نقطة تحكم؛ هذه أدوار مختلفة.

غرفة خيالية خالية للتحقق من الهوية فيها مفتاحا أمان وبطاقة فارغة وملف خمري
في هذا المقال

اختر الدور قبل الأداة

قد يكون رمز وصول OAuth معتماً أو بصيغة JWT. فك JWT لا يتحقق من أصالته؛ والتوقيع لا يشفر محتواه تلقائياً. وجود بوابة لا يحل محل تفويض الأعمال داخل الخدمات.

العنصرالدورالحد الظاهر
OAuth 2.0تفويض الصلاحيات.ليس وحده بروتوكول تسجيل دخول للمستخدم.
OpenID Connectمصادقة فوق OAuth 2.0.يتطلب فحص الملف والرموز.
JWTصيغة للادعاءات.الفك والتوقيع والتشفير عمليات مختلفة.
بوابة APIضوابط مشتركة عند المدخل.لا تستبدل صلاحيات كل كائن.

تحقق من البروتوكول وكل وصول

  • اختر تدفقاً مناسباً للعميل. لمسارات المستخدم اتبع التوصيات الحالية لرمز التفويض وPKCE، مع مكتبة مصانة وإعادة توجيه مضبوطة بدقة.
  • افحص توقيع JWT المقبول والخوارزميات المسموحة والجهة المصدرة والجمهور والقيود الزمنية للملف. ارفض الرمز المخصص لاستخدام آخر.
  • افحص كل كائن وإجراء ومؤسسة. اختبر الوصول المتبادل بين الحسابات ببيانات افتراضية؛ فالدور أو النطاق العام لا يكفي دائماً.

خطط للانتهاء والإلغاء والحوادث

وثق التجديد وتدوير المفاتيح وفقد الأسرار واستراتيجية الإلغاء. التحقق المحلي لا يعلم تلقائياً بإلغاء بعيد. قلل بيانات الرموز والسجلات؛ فلا JWT ولا الحصص تضمن وحدها الأمان أو الامتثال.

المراجع الأساسية

لا تُغني البوابة عن تفويض الكائن.

يجب على واجهة برمجة التطبيقات (API) التحقق من أن الرمز المميز مُخصص لها، وأن المُستدعي مُخوّلٌ لتنفيذ العملية على الكائن. لا يُثبت توقيع JWT صالح أو تسجيل دخول OAuth ناجح هذه الصلاحيات. اختبر الهويات المجاورة والوظائف ذات الامتيازات.

  • ارفض رمزًا مميزًا صالحًا مُخصصًا لجمهور آخر.
  • اختبر الوصول عبر الحسابات، والحقول الخاصة، والعمليات الإدارية.
  • فعّل خاصية انتهاء الصلاحية وتغيير الأدوار دون تسجيل الرموز المميزة في السجلات.

المصدر الأساسي: IETF — RFC 9700, OAuth 2.0 Security Best Current Practice. المنهج المرتبط: اقرأ الدليل العملي.

مفاتيح المرور: الاستعداد لتغيير النطاق وRP ID

فصل الحساب وأصل الويب وRP ID لتجنب إعادة ربط بيانات الاعتماد بصمت.

  • سجّل الأصول القديمة والجديدة وRP ID والحسابات المرتبطة. تطابق اسم الحساب لا يجعل مفتاح المرور صالحاً لـRP ID آخر. افحص التركيبات المسموحة في WebAuthn ومسارات الوصول المتاحة أثناء الانتقال.
  • في بيئة اختبار مصرح بها افحص التحدي والأصل وRP ID وربط الحساب بمكتبة مناسبة. جرّب أصلاً غير متوقع وتحدياً معاداً. تغيير RP ID يتطلب تسجيلاً جديداً موثّقاً؛ نسخ صف لا ينقل المفتاح.
  • اختبر مستخدماً يملك الاعتماد القديم فقط والاسترداد والجلسات المفتوحة. حدّد فتح المسارات وإيقافها مع رجوع مختبر. التسجيل في النطاق الجديد لا يثبت إلغاء كل الجلسات القديمة.

حالة قبول قابلة للتكرار

مثال افتراضي: البيانات لا تصف عميلاً أو نتيجة مرصودة.

عرض بيانات الحالة
{
    "old_origin": "https://login.old.example",
    "old_rp_id": "old.example",
    "new_origin": "https://login.new.example",
    "new_rp_id": "new.example",
    "same_service_account": true,
    "expected": "authenticated_new_registration"
}

القرار المتوقع

مثال افتراضي: الحساب نفسه، لكن old.example يصبح new.example مع RP ID مختلف. لا يعاد ربط الاعتماد القديم بصمت؛ يتبع التسجيل الجديد المسار الموثّق المخطط.

W3C — Web Authentication Level 2

هل يمكن تغيير RP ID لمفتاح المرور بتعديل قاعدة البيانات؟

لا. RP ID جزء من النطاق المتحقق منه للاعتماد. أعد تسجيلاً صالحاً للنطاق الجديد وربط حساب موثّقاً.

المصدر الأساسي: W3C — Web Authentication Level 2. المنهج المرتبط: اقرأ الدليل العملي.

تجديد TLS: التحقق من الشهادة المقدمة فعلياً

متابعة التجديد إلى نقاط إنهاء TLS والعملاء قبل إعلان اكتمال التغيير.

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

حالة قبول قابلة للتكرار

مثال افتراضي: البيانات لا تصف عميلاً أو نتيجة مرصودة.

عرض بيانات الحالة
{
    "issuance_succeeded": true,
    "proxy_count": 2,
    "proxies_serving_expected_certificate": 1,
    "other_proxy_certificate_expired": true,
    "tls_verification_enabled": true,
    "expected": "change_incomplete_fix_and_verify_client_paths"
}

القرار المتوقع

مثال افتراضي: التجديد ناجح لكن أحد وكيلين يقدم شهادة منتهية. التغيير غير مكتمل؛ أصلح الوكيل وافحص مسارات العملاء دون تعطيل تحقق TLS.

Let’s Encrypt — Integration Guide

المصدر الأساسي: Let’s Encrypt — Integration Guide. المنهج المرتبط: اقرأ الدليل العملي.

استكشاف كتالوج CISA KEV

الملاحظات المرجعية المفصّلة متاحة باللغة الإنجليزية في هذه النسخة.

One identifier can span several technical layers

An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.

  • Connect the CVE, component supplier and final-product supplier.
  • Check version, configuration and execution path in the authorised environment.
  • Do not infer remediation from an empty search result.

استكشاف الكتالوج والمنهج →

CISA KEV · 2026.11.06 · Documentary review : 2026-11-07

الإضافات: الأذونات والوصول

الملاحظات المرجعية المفصّلة متاحة باللغة الإنجليزية في هذه النسخة.

Robust authentication does not describe extension access

Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.

  • Test approved extensions in a profile dedicated to sensitive operations.
  • For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
  • Distinguish session revocation, token revocation, extension disablement and native-component removal.

Read the permission directory and manifest examples →

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent