في مشهد أمن التطبيقات الحديثة، نادراً ما تسبب مواضيع أخرى قدرًا كبيرًا من الارتباك أو تولد ثغرات أمنية حرجة مثل العلاقة بين OAuth 2.0 وOpenID Connect (OIDC). رغم ذكرهما غالبًا معًا، إلا أنهما يخدمان أغراضًا مختلفة جوهريًا. يُعد OAuth 2.0 إطار عمل للترخيص، بينما يُعد OpenID Connect طبقة مصادقة مبنية فوقه. فهم هذا التمييز ليس مجرد أمر أكاديمي؛ بل هو أمر ضروري لبناء تطبيقات آمنة وقابلة للتوسع وسهلة الاستخدام.
فيل الترخيص: OAuth 2.0
في جوهره، صُمم OAuth 2.0 لحل مشكلة محددة: كيف يمكن لتطبيق تابع لجهة خارجية الوصول إلى موارد المستخدم على خدمة أخرى دون التعامل مع بيانات اعتماد المستخدم؟ فكر في الأمر وكأنك تمنح مفتاحًا لخدمة السيارات (Valet Key). أنت لا تسلّم المفتاح الرئيسي الخاص بك (اسم المستخدم وكلمة المرور)؛ بل تسلّم مفتاحًا محدود الصلاحية يفتح الباب ويشغل المحرك فقط.
يحدد OAuth 2.0 أربعة أدوار رئيسية:
- مالك المورد: المستخدم الذي يمتلك البيانات.
- العميل: التطبيق الذي يطلب الوصول.
- خادم التفويض: الخدمة التي تقوم بمصادقة المستخدم وتصدر الرموز (مثل Google، GitHub).
- خادم المورد: الخدمة التي تستضيف البيانات المحمية.
عندما يمنح المستخدم الإذن، يصدر خادم التفويض رمز الوصول (Access Token). هذا الرمز هو سلسلة يقدمها العميل لخادم المورد للحصول على الوصول. والأهم من ذلك، أن رمز الوصول لا يحتوي على أي معلومات عن هوية المستخدم؛ إنه مجرد مفتاح لفتح الموارد.
طبقة الهوية: OpenID Connect
إذا كان OAuth 2.0 يتعامل مع "الوصول"، فإن OpenID Connect يتعامل مع "الهوية". يُعد OIDC طبقة هوية مبنية فوق بروتوكول OAuth 2.0. وهو يقدم نوعًا جديدًا من الرموز: رمز الهوية (ID Token).
رمز الهوية هو رمز ويب JSON (JWT) يحتوي على مطالبات حول حدث المصادقة - مثل من قام بتسجيل الدخول، ومتى، ومن أين. عندما ترى "تسجيل الدخول باستخدام Google" أو "تسجيل الدخول باستخدام GitHub"، فأنت تشهد OpenID Connect في العمل. تقوم مزود OIDC بمصادقة المستخدم ثم يعيد رمز الهوية إلى العميل، مما يؤكد هوية المستخدم.
الاختلافات الرئيسية في لمحة سريعة
| الميزة | OAuth 2.0 | OpenID Connect |
|---|---|---|
| الغرض | الترخيص (الوصول) | المصادقة (الهوية) |
| نوع الرمز | رمز الوصول | رمز الهوية (JWT) |
| حالة الاستخدام | قراءة تقويم المستخدم | التحقق من هوية المستخدم |
التنفيذ العملي: تدفق رمز التفويض
لتطبيقات الويب، يُعد التدفق الموصى به هو تدفق رمز التفويض مع PKCE (مفتاح إثبات لتبادل الرموز). يضمن هذا التدفق أنه حتى إذا تم اعتراض رمز التفويض، فلا يمكن لمهاجم استخدامه بدون سر العميل (أو متحقق PKCE).
إليك مثال مفاهيمي لهيكل الطلب:
GET /authorize?
response_type=code&
client_id=YOUR_CLIENT_ID&
redirect_uri=https://yourapp.com/callback&
scope=openid profile email&
code_challenge=YOUR_CODE_CHALLENGE&
code_challenge_method=S256
HTTP/1.1في هذا المثال، لاحظ معلمة scope=openid. هذه هي الإشارة لخادم التفويض بأنك تطلب المصادقة عبر OIDC، وليس مجرد ترخيص. بدون هذا النطاق، ستتلقى فقط رمز وصول للوصول إلى واجهة برمجة التطبيقات (API)، وليس رمز هوية للتحقق من الهوية.
أفضل الممارسات للأمان
يتم تنفيذ هذه البروتوكولات بشكل صحيح مليء بالفخاخ. قم دائمًا بتخزين الرموز في ملفات تعريف الارتباط httpOnly عندما يكون ذلك ممكنًا لمنع هجمات البرمجة عبر المواقع (XSS) من سرقتها. لا تقم بتخزين الرموز في التخزين المحلي (local storage) إلا إذا لزم الأمر بشدة، حيث يمكن لـ JavaScript قراءتها. علاوة على ذلك، تحقق دائمًا من توقيع رمز الهوية على الخادم الخلفي وتحقق من مطالبات iss (الصادر) و aud (الجمهور) للتأكد من أن الرمز قد تم إصداره بواسطة مزود موثوق لتطبيقك المحدد.
الخاتمة
يُعد OAuth 2.0 وOpenID Connect أدوات قوية، وعندما يتم فهمها وتنفيذها بشكل صحيح، يمكنها تعزيز وضع الأمان لتطبيقك بشكل كبير. من خلال فصل المسؤوليات - باستخدام OAuth للوصول وOIDC للهوية - فإنك تخلق أساسًا متينًا لتطبيقات الويب الحديثة. كمطورين، تقع على عاتقنا مسؤولية تجاوز نسخ ولصق الكود وفهم العواقب الأمنية لكل رمز نصدقه ونتحقق منه حقًا.