لماذا يستخدم OpenID Connect وOAuth 2.0 رموزًا منفصلة؟

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

ماذا يحدث إذا قبل التطبيق رمزًا مميزًا للهوية دون التحقق من توقيعه؟

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

الرمز المميز للهوية مقابل رمز الوصول: الفرق الجوهري في OpenID Connect

Q: هل يمكن استخدام الرمز المميز للهوية لاستدعاء واجهات برمجة التطبيقات أو الوصول إلى الموارد المحمية؟

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

Q: أين تقع قيمة "nonce" ضمن تبادل الرموز المميزة؟

الـ nonce هي سلسلة عشوائية تُنشأ في بداية تدفق تسجيل الدخول وتُضمَّن داخل الرمز المميز للهوية، ما يتيح للتطبيق منع هجمات إعادة التشغيل.

By Mirko Peters · 2026-10-28

اكتشف الفروق الجوهرية بين الرموز المميزة للهوية ورموز الوصول في OpenID Connect، وتعرّف على السبب الذي يجعل الخلط بينها يُنشئ ثغرات أمنية خطيرة.

Automatically translated with AI from the original post. Read the English original

Cover: OpenID Connect - Simply Explained

يُعد فهم الفرق بين الرمز المميز للهوية ورمز الوصول أمرًا بالغ الأهمية للمطورين ومسؤولي تكنولوجيا المعلومات الذين يعملون مع المصادقة الحديثة. فبينما يتولى OAuth 2.0 إدارة الأذونات، يقدّم OpenID Connect الرمز المميز للهوية لتأكيد هوية المستخدم. والخلط بين هذين الرمزين المتمايزين يؤدي إلى ثغرات أمنية حرجة في تطبيقات السحابة.

النقاط الرئيسية

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

المعضلة الأساسية: الهوية مقابل التفويض

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

لحل جزء من هذه المعضلة، ظهر OAuth 2.0. غير أن OAuth 2.0 لم يُصمَّم أصلًا للإجابة عن سؤال من هو الشخص. فغايته الأساسية توفير تصاريح تُعرف برموز الوصول، تسمح للتطبيق بالوصول إلى نقاط نهاية بيانات محددة نيابةً عن المستخدم. يحدد رمز الوصول ما يحق للتطبيق فعله، لكنه يبقى صامتًا تمامًا عن هوية الشخص الذي يحمله. وقد أدّت هذه الفجوة الجوهرية إلى أن الشركات التي سعت إلى بناء تجارب تسجيل دخول موحد اضطرت إلى إلحاق عمليات تحقق مخصصة للهوية بإطار OAuth، فنتج عن ذلك تطبيقات مجزأة نادرًا ما تتوافق مع بعضها.

سدّ OpenID Connect هذه الفجوة تحديدًا، من خلال تقديم طبقة موحدة مصممة خصيصًا للمصادقة. فباستخدام رمز ثانٍ إلى جانب رمز الوصول التقليدي، يفصل OpenID Connect بوضوح مسألة الهوية عن مسألة الأذونات. ويُعد الحفاظ على فصل هذين المفهومين أهم تحول في طريقة التفكير لأي شخص يبني تطبيقات سحابية أو يدقق فيها اليوم.

تشريح الرمز المميز للهوية: ما الذي يحتويه؟

عندما ينقر المستخدم على زر "تسجيل الدخول باستخدام Microsoft"، يعالج موفر الهوية بيانات الاعتماد، ويتعامل مع متطلبات المصادقة متعددة العوامل، وفي النهاية يعيد المستخدم إلى التطبيق مرفقًا برمز مميز للهوية. يُعبأ هذا الرمز بصيغة JSON Web Token، ويُختصر عادةً بـ JWT ويُنطق "جوت". للوهلة الأولى، يبدو JWT كسلسلة مربكة وغير مفهومة من الأحرف مفصولة بنقاط. ومع ذلك، فإن بنيته الداخلية بسيطة بشكل لافت بعد فك ترميزها.

داخل الرمز المميز للهوية، ستجد عددًا محدودًا من المطالبات القياسية، ولكل منها غرض محدد بدقة:

المُصدِر (Issuer): يحدد موفر الهوية المحدد (مثل Microsoft Entra ID) الذي أنشأ الرمز ووقّعه.
المعرّف الفريد (sub): يعمل كمعرّف فريد وثابت للمستخدم. والأهم من ذلك أنه مصمَّم ليبقى دون تغيير حتى لو قام المستخدم بتحديث اسم العرض أو عنوان البريد الإلكتروني.
الجمهور المستهدف (aud): يحدد التطبيق المحدد الذي أُنشئ الرمز المميز من أجله، مما يضمن ألا يتمكن تطبيق آخر من اعتراض رمز مُعدّ لتطبيق واحد وإعادة استخدامه بشكل ضار.
الطوابع الزمنية: تحدد وقت إصدار الرمز المميز، وموعد انتهاء صلاحيته، واللحظة الدقيقة التي صادق فيها المستخدم على هويته.
القيمة العشوائية (nonce): تعمل كرقم إيصال آمن يربط الرمز المميز الناتج بجلسة تسجيل الدخول المحددة التي بدأت الطلب، مما يمنع فعليًا هجمات إعادة التشغيل.

والأهم أن الحزمة بأكملها موقّعة باستخدام المفتاح الخاص لمزود الهوية. ويتحقق التطبيق المستقبِل من هذا التوقيع باستخدام المفتاح العام المطابق الذي ينشره المزود. ومن دون هذا التحقق التشفيري، لا يعدو رمز الهوية (ID token) كونه ملاحظة غير موثّقة تنتقل بين الأطراف.

خطورة التعامل مع الهوية على أنها وصول

من أخطر الأنماط الخاطئة في تطوير التطبيقات التعامل مع رمز الهوية (ID token) على أنه مفتاح للأذونات. فلأن رمز الهوية يؤكد أن المستخدم هو John Doe من مؤسسة محددة، يقع بعض المطوّرين المبتدئين في الخطأ باستخدام هذا التأكيد لمنح صلاحيات إدارية أو وصول غير مقيّد إلى قاعدة البيانات. وهذا يُسيء فهم البنية من أساسها.

رمز الهوية يخبرنا فقط بمن يقف عند الباب الأمامي، ولا يملك أي رأي فيما إذا كان مسموحًا لهذا الشخص بفتح كل غرفة داخلية أو الضغط على زر إداري محدد. ويجب أن يتولى التطبيق منطق التفويض بشكل منفصل باستخدام التحكم في الوصول القائم على الأدوار (RBAC) أو آليات مشابهة، مع اعتبار الهوية المُتحقَّق منها نقطة انطلاق لا قرارًا نهائيًا بالتفويض.

كذلك، كثيرًا ما تقع التطبيقات في خطأ قبول رموز الهوية الواردة دون إجراء فحوصات التحقق المناسبة. فالثقة بالرمز المميز بشكل أعمى لمجرد أن مكتبة برمجية عالجته في الخلفية تترك الأنظمة معرّضة للبيانات المزوّرة. ويُعدّ التحقق من التوقيع، وفحص الطوابع الزمنية لانتهاء الصلاحية، والتحقق من مطالبة الجمهور المستهدف (audience claim) خطوات لا غنى عنها للحفاظ على وضع أمني سليم.

الخاتمة

إن إتقان الحد الفاصل بين الهوية والتفويض يساعد على تبسيط بنية السحابة الحديثة. فعندما تبقى رموز الهوية مركزة بصرامة على إثبات من يجلس أمام لوحة المفاتيح، وتترك رموز الوصول لتحدد الإجراءات المسموح بها، يستطيع المطورون بناء تكاملات قوية وآمنة مع منصات مثل Microsoft Entra ID. ولسماع شرح شامل لهذه المفاهيم واستكشاف كيفية عمل تدفقات تسجيل الدخول الحديثة في منظومة Microsoft، تابع النقاش الكامل. استمع إلى الحلقة كاملة وتعمّق في آليات الهوية السحابية اليوم!

الأسئلة المتداولة

هل يمكن استخدام رمز الهوية (ID token) لاستدعاء واجهات برمجة التطبيقات (APIs) أو الوصول إلى الموارد المحمية؟

لا. يحتوي رمز الهوية فقط على مطالبات هوية تتعلق بمن هو المستخدم. ولاستدعاء واجهات برمجة التطبيقات أو الوصول إلى الموارد المحمية، يجب على التطبيق استخدام رمز وصول (access token) يُصدر عبر OAuth 2.0.

لماذا يستخدم OpenID Connect وOAuth 2.0 رمزين مميزين منفصلين؟

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

ماذا يحدث إذا قبل التطبيق رمز هوية دون التحقق من توقيعه؟

يؤدي تخطي التحقق من التوقيع إلى تعريض التطبيق للرموز المزوّرة، إذ يمكن لأي شخص إنشاء سلسلة مخصصة تدّعي أنها لمستخدم صالح.

أين تقع قيمة "nonce" ضمن تبادل الرموز المميزة؟

الـ nonce سلسلة عشوائية تُنشأ في بداية تدفق تسجيل الدخول وتُدرج داخل رمز الهوية، مما يتيح للتطبيق منع هجمات إعادة التشغيل.