ما هو OIDC: من الحاجة إليه إلى كيفية عمله

تعريف OpenID Connect (OIDC)#

OpenID Connect (OIDC) هو بروتوكول مصادقة الهوية مبني على قمة OAuth 2.0. بينما يوفر OAuth 2.0 التفويض فقط، يضيف OIDC إمكانيات المصادقة، مما يوفر حلاً أكثر توحيدًا لسيناريوهات تفويض ومصادقة المستخدمين.

ببساطة: OIDC = بروتوكول التفويض + مصادقة الهوية.

لماذا نحتاج إلى OIDC؟#

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

المفاهيم الرئيسية وتدفق التفويض لـ OAuth 2.0#

OAuth 2.0 (تفويض مفتوح) هو بروتوكول التفويض الذي يتيح للمستخدمين منح تطبيقات الطرف الثالث الوصول إلى مواردهم دون مشاركة بيانات اعتمادهم مثل أسماء المستخدمين وكلمات المرور. ويتضمن أربع أدوار رئيسية:

• مالك الموارد: المستخدم الذي يمتلك الموارد
• خادم الموارد: الخادم الذي يخزن موارد المستخدم
• العميل: تطبيق الطرف الثالث الذي يطلب الوصول إلى موارد المستخدم
• خادم التفويض: الخادم الذي يتحقق من هوية المستخدم ويصدر رموز الوصول

تعمل عملية تدفق التفويض في OAuth 2.0 بشكل عام كالتالي:

كما هو موضح، يركز OAuth 2.0 بشكل رئيسي على إصدار رموز الوصول لتمكين العملاء من الطرف الثالث للوصول إلى موارد المستخدم.

قيود OAuth 2.0#

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

لم تكن هذه مشكلة كبيرة في النظام البيئي للإنترنت في بدايته.

ومع ذلك، عندما تطورت منصات مثل Google وFacebook وTwitter وGithub، بدأت في تقديم موارد مستخدم غنية أصبحت ذات قيمة لتطبيقات الطرف الثالث.

بينما يتفوق OAuth 2.0 في تفويض الوصول إلى موارد المستخدم لتطبيقات الطرف الثالث، إلا أن له قيودًا. السيناريو النموذجي هو: حيث أن معلومات المستخدم تعتبر أيضًا مورداً، عندما تحتاج تطبيقات الطرف الثالث إلى الوصول إلى معلومات المستخدم الأساسية، تعيد منصات مختلفة (مثل Google وFacebook وTwitter) معلومات المستخدم بتنسيقات مختلفة، مما يخلق تحديات للمطورين.

تم إنشاء OIDC لمعالجة هذه التحديات.

الأدوار في OIDC#

لتمكين مصادقة المستخدم إلى أعلى OAuth 2.0 ومعالجة قيوده، أدخل OIDC ثلاثة أدوار:

• المستخدم النهائي (EU): المستخدم النهائي، ويمثل مالك الموارد في OAuth 2.0
• الطرف المعتمد (RP): الطرف المعتمد، ويمثل العميل في OAuth 2.0
• مزود OpenID (OP): مقدم خدمة المصادقة على الهوية، ويمثل خادم التفويض وخادم الموارد في OAuth 2.0

يعد OP الدور الأساسي، حيث يوفر كلا من وظائف التفويض للـ OAuth 2.0 ويعامل معلومات المستخدم كموارد منفصلة.

كيف يعمل OIDC؟#

إن عملية المصادقة في OIDC مشابهة لـ OAuth 2.0، ولكن بما أن OP يجمع بين أدوار خادم التفويض وخادم الموارد، فإنه يُرجع كلا من رمز الوصول ورمز الهوية. يحتوي رمز الهوية على معلومات هوية المستخدم، ويمكن للطرف المعتمد التحقق من هوية المستخدم عن طريق التحقق من رمز الهوية.

تبدو عملية عمل نموذجية هكذا:

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

رمز الهوية (Identity Token) في OIDC#

عندما يقوم المستخدمون بتفويض تطبيقات الطرف الثالث، يُرجع OP كلا من رمز الوصول لـ OAuth 2.0 ورمز الهوية بصيغة JWT. يحتوي رمز الهوية على معلومات هوية المستخدم مثل معرّف المستخدم، اسم المستخدم، البريد الإلكتروني، والصورة الرمزية. يمكن للطرف المعتمد تأكيد هوية المستخدم عن طريق التحقق من رمز الهوية.

كـ JWT، يحتوي رمز الهوية على مطالبات موحدة، بما في ذلك هذه المطالبات الأساسية المطلوبة:

• iss (الجهة المصدرة): معرف فريد لمزود OpenID الذي يصدر رمز الهوية
• sub (الموضوع): معرف فريد للمستخدم
• aud (الجمهور): معرف لتطبيق العميل الذي يستقبل رمز الهوية
• exp (وقت الانتهاء): وقت انتهاء صلاحية رمز الهوية
• iat (وقت الإصدار): وقت إصدار رمز الهوية

للحصول على معلومات تفصيلية حول رموز الهوية، يرجى الرجوع إلى: رمز الهوية.

نقطة نهاية معلومات المستخدم#

نقطة نهاية معلومات المستخدم هي واجهة برمجة تطبيقات HTTP موحدة تقدمها OP للحصول على تفاصيل المستخدم الذي تمت مصادقته. من خلال إرسال طلبات GET أو POST مع رمز الوصول إلى هذه النقطة النهائية، يمكنك تلقي معلومات المستخدم بصيغة JSON. تتضمن البيانات المعادة حقولًا موحدة مثل معرف المستخدم الفريد (sub)، اسم المستخدم (name)، البريد الإلكتروني، والصورة.

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

للحصول على معلومات تفصيلية حول نقطة نهاية معلومات المستخدم، يرجى الرجوع إلى: نقطة نهاية معلومات المستخدم.

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

النطاقات في OIDC#

تعرف النطاقات في OIDC المعلومات التي يمكن للطرف المعتمد الوصول إليها. يحدد OIDC نطاقات قياسية، مع النطاق openid المطلوب في سير تدفقات مصادقة OIDC.

تشمل النطاقات القياسية الشائعة:

• openid: تشير إلى طلب مصادقة OIDC
• profile: معلومات المستخدم الأساسية مثل الاسم والصورة الرمزية
• email: معلومات البريد الإلكتروني للمستخدم
• phone: رقم هاتف المستخدم
• address: معلومات عنوان المستخدم

تعيد النطاقات المختلفة معلومات مختلفة عن المستخدم. على سبيل المثال، طلب openid profile email يعيد معلومات المستخدم الأساسية والبريد الإلكتروني في رمز الهوية ومعلومات المستخدم، بينما openid profile email phone address يتضمن رقم الهاتف ومعلومات العنوان كذلك.

إدارة الهوية بناءً على OIDC#

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

• تسجيل دخول واحد (SSO): يدعم OIDC بطبيعة الحال SSO من خلال معلومات الجلسة الموسعة للمستخدم، مما يتيح إدارة حالة تسجيل الدخول الموحدة ومشاركة الهوية عبر التطبيقات
• إدارة الهيكل التنظيمي: يمكن أن تدير معلومات المنظمة الموسعة للمستخدم هياكل تنظيمية معقدة، بما في ذلك التسلسلات الهرمية للإدارات والعلاقات بين مجموعات المستخدمين
• إدارة الأذونات: تتيح سمات الأذونات الموسعة للمستخدم التحكم في الوصول إلى الموارد بدقة، بما في ذلك معلومات الدور وتكوين سياسة الأذونات

يتكيف مرونة OIDC مع احتياجات إدارة الهوية المتطورة. تم بناء العديد من أنظمة إدارة الهوية على OIDC، مثل Logto، التي توفر ميزات SSO وإدارة المنظمة وإدارة الأذونات.