Cyber Security Academy · درس

تدفقات OAuth 2.0

منح التفويض والرموز.

الدرس 1 من 413 خطوة

تدفقات OAuth 2.0 درس مجاني في Cyber Security Academy على CoddyKit. هذا هو الدرس 1 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في Cyber Security Academy، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة Cyber Security Academy 4 دروس في المجموع.

ما الذي يحله OAuth 2.0 فعليًا

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

يتعلق الأمر بـالتفويض (ما الذي يمكن للتطبيق فعله)، لا بالمصادقة (هوية المستخدم).
يتلقى التطبيق access_token محدد النطاق، وليس بيانات اعتماد المستخدم.

يجب على المدافعين تذكّر أن OAuth وحده لا يثبت الهوية. فاعتبار رمز الوصول دليلًا على تسجيل الدخول خطأ شائع يعالجه OIDC.

الأدوار الأربعة

يتضمن كل تدفق OAuth أربعة أدوار. ويُعد تحديدها بشكل صحيح أمرًا أساسيًا لنمذجة التهديدات.

مالك المورد، المستخدم الذي يملك البيانات.
العميل، التطبيق الذي يطلب الوصول.
خادم التفويض (AS)، يُصدر الرموز بعد الحصول على الموافقة.
خادم الموارد (RS)، واجهة API التي تحتفظ بالبيانات المحمية وتتحقق من الرموز.

تقع حدود الثقة بين هذه الأدوار. فالعميل المخترق أو خادم التفويض المتساهل يقوّض السلسلة بأكملها.

Roles:
  Resource Owner  -> grants consent
  Client          -> requests + uses tokens
  Authorization Server -> issues tokens
  Resource Server -> validates tokens

تدفق رمز التفويض

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

يُعاد توجيه المستخدم إلى AS لإجراء المصادقة ومنح الموافقة.
يعيد AS رمزًا قصير الأجل هو code إلى عنوان URI لإعادة التوجيه المسجّل.
يستبدل العميل الرمز (من جهة الخادم) بالرموز عبر قناة خلفية.

بما أن الرموز تُحصل عليها عبر القناة الخلفية، فإنها لا تظهر أبدًا في شريط عناوين المتصفح أو سجله.

GET /authorize?response_type=code
  &client_id=app123
  &redirect_uri=https://app.example/cb
  &scope=read:profile
  &state=xyz

// then back-channel:
POST /token  grant_type=authorization_code&code=...

PKCE: مفتاح الإثبات لتبادل الرمز

يعزز PKCE (RFC 7636) أمان تدفق رمز التفويض، ويوصى به الآن لجميع العملاء بما في ذلك العملاء السريين.

ينشئ العميل قيمة code_verifier عشوائية، ويرسل تجزئتها باعتبارها code_challenge.
عند مبادلة الرمز، يجب أن يقدّم قيمة التحقق الأصلية.

يربط ذلك الرمز بطالب التفويض الأصلي، ويمنع المهاجم الذي يعترض رمز التفويض من استبداله.

code_verifier  = random 43-128 chars
code_challenge = BASE64URL(SHA256(verifier))

/authorize ... &code_challenge=...&code_challenge_method=S256
/token     ... &code_verifier=<original>

تدفق بيانات اعتماد العميل

يُستخدم تدفق بيانات اعتماد العميل للوصول من خدمة إلى خدمة عندما لا يكون هناك مستخدم مشارك (مثل خدمة خلفية تستدعي واجهة API).

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

قيّد نطاق هذه الرموز بشدة وبدّل أسرار العميل دوريًا. لا تستخدم هذا التدفق أبدًا لانتحال شخصية المستخدمين النهائيين.

POST /token
  grant_type=client_credentials
  client_id=service-a
  client_secret=***
  scope=orders:read

رموز الوصول مقابل رموز التحديث

يُصدر OAuth نوعين رئيسيين من الرموز، يختلفان كثيرًا في مدة الصلاحية وقواعد التعامل.

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

رموز التحديث عالية القيمة. خزّنها بأمان، واربطها بالعميل، وادعم إبطالها.

POST /token
  grant_type=refresh_token
  refresh_token=<long-lived>
  client_id=app123

رموز Bearer ونقلها

معظم رموز الوصول في OAuth هي رموز Bearer؛ إذ يمكن لأي شخص يحمل الرمز استخدامه، تمامًا كالنقود.

يجب نقلها دائمًا عبر TLS، وليس مطلقًا ضمن عناوين URL، حيث قد تتسرب إلى السجلات وترويسات الإحالة.
أرسلها عبر ترويسة Authorization.
يُستحسن استخدام الرموز المقيّدة بالمرسل (DPoP، mTLS) مع واجهات API عالية الخطورة.

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

// AVOID:
GET /api/data?access_token=...   // leaks in logs

منحة Implicit متقادمة

كانت منحة Implicit القديمة تُعيد الرموز مباشرةً ضمن جزء التجزئة في عنوان إعادة التوجيه. وأصبحت الآن غير موصى بها وفقًا لـ OAuth 2.0 Security BCP، كما أُزيلت من OAuth 2.1.

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

استخدموا Authorization Code with PKCE بدلًا منها في تطبيقات SPA.

معلمة state وCSRF

تحمي معلمة state خطوة إعادة التوجيه من CSRF. ينشئ العميل قيمة عشوائية، ويخزنها في الجلسة، ويتحقق منها عند استلام الاستدعاء.

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

before:  session.state = randomNonce()
/authorize ... &state=<nonce>

on callback:
  if (req.state !== session.state) reject()

النطاقات وأقل قدر من الامتيازات

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

اطلبوا النطاقات التي تحتاجها الميزة فقط (read:profile وليس admin).
يجب على خوادم الموارد فرض النطاق في كل نقطة نهاية، لا الاكتفاء بالثقة في صلاحية الرمز.

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

أخطاء إعداد OAuth الشائعة

تنشأ معظم حوادث OAuth من الإعدادات، لا من البروتوكول نفسه.

تسمح مطابقة إعادة التوجيه المفتوحة أو redirect_uri المتساهلة للمهاجمين بسرقة الرموز.
يتيح غياب state أو PKCE هجمات CSRF وحقن الرموز.
رموز وصول طويلة العمر من دون إمكانية إبطالها.
التعامل مع رمز الوصول على أنه إثبات للمصادقة.

سجّلوا عناوين إعادة التوجيه الدقيقة وتحققوا منها بصرامة.

redirect_uri allowlist:
  EXACT: https://app.example/cb
  NOT:   https://app.example/*  (too broad)

تحقق سريع: تأمين مصادقة SPA

اختَروا التدفق الصحيح والحديث للسيناريو التالي.

أجب عليها في الدرس التفاعلي

مراجعة: تدفقات OAuth 2.0

أهم النقاط:

OAuth 2.0 هو تفويض مفوَّض وليس مصادقة.
الأدوار الأربعة هي: مالك المورد، والعميل، وخادم التفويض، وخادم المورد.
يُعد Authorization Code + PKCE الخيار الافتراضي للويب وتطبيقات الأجهزة المحمولة وتطبيقات SPA.
يغطي Client Credentials الوصول بين الآلات.
احموا النظام باستخدام state، والمطابقة الصارمة لعناوين إعادة التوجيه، ورموز الوصول قصيرة العمر، وTLS في كل مكان.
منحتا Implicit وPassword متقادمتان.

البدء مجانًا

تعلم Cyber Security Academy مع معلم ذكاء اصطناعي — مجانًا

اكتب وقم بتشغيل أكوادك الفعلية في المتصفح، واحصل على مساعدة فورية من معلم ذكاء اصطناعي متاح 24/7، واستمر من حيث توقفت على الويب أو في التطبيق.

الدورات: 76
الدروس: 303

ابدأ التعلم مجانًا عرض الدورة الكاملة

الأسئلة الشائعة

هل درس «تدفقات OAuth 2.0» مجاني؟

نعم — نص درس «تدفقات OAuth 2.0» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة Cyber Security Academy، انتقل إلى CoddyKit PRO. تتضمن دورة Cyber Security Academy 4 دروس في المجموع.

ماذا ستتعلم في «تدفقات OAuth 2.0»؟

منح التفويض والرموز. تتمرن على Cyber Security Academy مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ Cyber Security Academy؟

لا تُشترط خبرة سابقة. Cyber Security Academy على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 1 من أصل 4.

كم من الوقت يستغرق درس «تدفقات OAuth 2.0»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس Cyber Security Academy هذا؟

نعم. كل درس في Cyber Security Academy يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

← العودة إلى Cyber Security Academy