في المشهد الحديث لأمن التطبيقات، يعد فهم كيفية مصادقة المستخدمين وتفويض الوصول إلى الموارد أمراً بالغ الأهمية. بالنسبة للمطورين، فإن التمييز بين OAuth 2.0 وOpenID Connect (OIDC) ليس مجرد مسألة أكاديمية؛ بل هو أمر حاسم لبناء تطبيقات آمنة وقابلة للتوسع. وعلى الرغم من استخدامها أحياناً بالتبادل، فإن هذه البروتوكولات تخدم أغراضاً متميزة ومتكاملة. يستكشف هذا المنشور الفروق الدقيقة التقنية لكلاهما، وكيفية تكاملهما، وأفضل الممارسات للتنفيذ.
الأساس: إطار عمل تفويض OAuth 2.0
من الضروري توضيح سوء فهم شائع: OAuth 2.0 هو إطار عمل للتفويض، وليس بروتوكول مصادقة. إنه يتعامل مع تفويض الوصول. عندما يرغب المستخدم في منح تطبيق تابع لجهة خارجية حق الوصول إلى موارده على خدمة أخرى (مثل السماح لتطبيق صور بالوصول إلى صورك على Instagram)، فإن OAuth 2.0 هو المعيار المستخدم لإصدار رموز الوصول.
الكيان الأساسي في OAuth 2.0 هو رمز الوصول (Access Token). يمثل هذا الرمز الأذونات الممنوحة لتطبيق العميل. والأهم من ذلك، لا ينبغي أبداً استخدام رموز الوصول لتحديد هوية المستخدم. إنها سلاسل غير مفهومة (opaque) مخصصة حصرياً لتفويض طلبات واجهة برمجة التطبيقات (API).
لنفترض سيناريو يطلب فيه تطبيق الهاتف المحمول الوصول إلى مكتبة Spotify الخاصة بمستخدم. تقوم خادم Spotify بإصدار رمز وصول. يرسل تطبيق الهاتف المحمول هذا الرمز في رأس Authorization عند إجراء مكالمات API:
GET /v1/me/tracks HTTP/1.1
Host: api.spotify.com
Authorization: Bearer 2YotnFZFEjr1zCsicMWpAAيضمن هذا أن التطبيق يمكنه قراءة المسارات، لكنه لا يثبت بشكل جوهري هوية المستخدم بما يتجاوز امتلاكه لرمز صالح.
توسيع OAuth 2.0: دخول OpenID Connect
إذا كان OAuth 2.0 يتعامل مع السؤال "هل يمكنني القيام بذلك؟"، فإن OpenID Connect يجيب على السؤال "من أنت؟". يعد OIDC طبقة هوية بسيطة مبنية فوق إطار عمل OAuth 2.0. فهو يسمح للعملاء بالتحقق من هوية المستخدم النهائي بناءً على المصادقة التي أجراها خادم التفويض، وكذلك للحصول على معلومات الملف الشخصي الأساسية للمستخدم النهائي بطريقة متوافقة وقريبة من REST.
الإضافة الرئيسية التي يجلبها OIDC إلى الطاولة هي رمز الهوية (ID Token). هذا هو رمز ويب JSON (JWT) الذي يحتوي على مطالبات حول حدث المصادقة. وعلى عكس رمز الوصول غير المفهوض، فإن رمز الهوية يكون منظماً وموقّعاً، مما يسمح للعميل بفك تشفير والتحقق من هوية المستخدم دون الحاجة إلى استعلام خادم الخلفية.
التنفيذ العملي: تدفق رمز التفويض
بالنسبة لتطبيقات الويب، يُعد تدفق رمز التفويض مع PKCE (مفتاح إثبات لتبادل الرموز) هو النهج الموصى به. يوازن هذا التدفق بين الأمان وسهولة الاستخدام مع التخفيف من هجمات الاعتراض.
خطوات التدفق
- البدء: ينشئ العميل رمز تحقق من الرمز (code verifier) وتحدي الرمز (code challenge)، ثم يعيد توجيه المستخدم إلى خادم التفويض.
- المصادقة: يسجل المستخدم الدخول.
- التفويض: يعيد الخادم التوجيه إلى العميل مع رمز تفويض.
- تبادل الرموز: يتبادل العميل الرمز للحصول على
access_token، وid_token، وrefresh_tokenمحتملاً.
عند معالجة الاستجابة من نقطة نهاية الرموز، يجب أن يعيد الخزان حمولة JSON مشابهة لما يلي:
{
"access_token": "SlAV32hkKG",
"token_type": "Bearer",
"id_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
"expires_in": 3600
}يجب التحقق من صحة id_token عن طريق التحقق من توقيعه مقابل المفتاح العام للمصدر والتحقق من مطالبات مثل iss (المصدر)، وaud (الجمهور المستهدف)، وexp (انتهاء الصلاحية).
أفضل الممارسات للتنفيذ الآمن
يتطلب تنفيذ هذه البروتوكولات الالتزام الصارم بمعايير الأمان. استخدم دائماً HTTPS لمنع اعتراض الرموز. لا تخزن الرموز أبداً في التخزين المحلي أو ملفات تعريف الارتباط (cookies) بدون علامات HttpOnly وSecure؛ استخدم تخزين الجلسة للرموز قصيرة الأجل حيث يكون ذلك مناسباً. علاوة على ذلك، قم دائماً بتنفيذ PKCE، حتى لتطبيقات الصفحة الواحدة (SPAs)، للدفاع ضد هجمات اعتراض رمز التفويض.
الخاتمة
إتقان OAuth 2.0 وOpenID Connect هو طقس عبور لمطوري الواجهات الخلفية والأمامية المتقدمين. من خلال فهم أن OAuth 2.0 يتعامل مع التفويض وOIDC يتعامل مع الهوية، يمكنك تصميم أنظمة تكون آمنة وسهلة الاستخدام في آن واحد. تذكر: استخدم OAuth للوصول، وOIDC للهوية، وقم دائماً بالتحقق من صحة الرموز بدقة. ومع تطور مشهد التهديدات، يضمن البقاء على اطلاع بهذه المعايير بقاء تطبيقاتك مرنة في وجه هجمات الهوية الحديثة.