OpenID Connect: دليل المطور للبيانات التعريفية

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

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

OIDC مبني على OAuth 2.0: يستفيد OIDC من إطار عمل OAuth 2.0 للمصادقة والتفويض، مع إضافة طبقة هوية.

رموز الهوية (ID Tokens): تنقل رموز الهوية المستندة إلى JWT بيانات هوية المستخدم التي تم التحقق منها بشكل آمن.

المطالبات: يستخدم OIDC 'المطالبات' لتمثيل أجزاء من معلومات المستخدم، وهي موحدة من أجل التشغيل البيني.

سير عمل موحد: يحدد OIDC العديد من سير العمل لأنواع التطبيقات المختلفة (الويب والجوال والتطبيقات الأصلية) لتبسيط التكامل.

ما هو OpenID Connect؟

OpenID Connect (OIDC) هو طبقة مصادقة فوق إطار عمل التفويض OAuth 2.0. إنه يوفر طريقة موحدة للتطبيقات للتحقق من هوية المستخدم النهائي بناءً على المصادقة التي يتم إجراؤها بواسطة خادم التفويض. والأهم من ذلك، أن OIDC يقدم مفهوم رمز الهوية، وهو رمز JSON Web Token (JWT) يحتوي على مطالبات حول المستخدم المصادق عليه. توفر هذه المطالبات بيانات هوية أساسية، مثل اسم المستخدم وعنوان البريد الإلكتروني وصورة الملف الشخصي. على عكس رموز الوصول OAuth 2.0 التي تمنح حق الوصول إلى الموارد، تم تصميم رموز الهوية خصيصًا لتأكيد هوية المستخدم.

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

فهم مطالبات OIDC

المطالبات هي اللبنات الأساسية لبيانات الهوية في OIDC. إنها عبارة عن بيانات حول المستخدم، مثل اسمه أو بريده الإلكتروني أو عنوانه. يحدد OIDC مجموعة من المطالبات القياسية، مما يضمن قابلية التشغيل البيني بين موفري الهوية المختلفين (IdPs) والتطبيقات. تتضمن المطالبات المستخدمة بشكل شائع:

• sub: معرف الموضوع - معرف فريد للمستخدم.
• name: الاسم الكامل للمستخدم.
• given_name: الاسم الأول للمستخدم.
• family_name: اسم عائلة المستخدم.
• email: عنوان البريد الإلكتروني للمستخدم.
• picture: عنوان URL لصورة ملف تعريف المستخدم.
• aud: الجمهور - معرف العميل للتطبيق الذي يتلقى رمز الهوية.
• iss: المُصدر - عنوان URL لخادم التفويض الذي أصدر رمز الهوية.
• exp: وقت الانتهاء - الطابع الزمني الذي يصبح رمز الهوية غير صالح بعده.

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

سير عمل OIDC: سير عمل رمز التفويض مع PKCE

يدعم OIDC العديد من سير العمل، ولكل منها تصميم لنوع معين من التطبيقات. سير العمل الأكثر شيوعًا والموصى به لتطبيقات الويب الحديثة هو سير عمل رمز التفويض مع Proof Key for Code Exchange (PKCE). يوفر هذا السير عمل أمانًا معززًا ضد هجمات اعتراض الرمز.

نظرة عامة مبسطة:

1. يقوم التطبيق بإنشاء مُتحقق للرمز وتحدي للرمز.
2. يقوم التطبيق بإعادة توجيه المستخدم إلى خادم التفويض مع تحدي الرمز.
3. يصادق المستخدم مع خادم التفويض.
4. يقوم خادم التفويض بإعادة توجيه المستخدم مرة أخرى إلى التطبيق مع رمز تفويض.
5. يبادل التطبيق رمز التفويض و مُتحقق الرمز مقابل رمز هوية ورمز وصول.
6. يقوم التطبيق بالتحقق من صحة رمز الهوية ويستخدم المطالبات لتحديد هوية المستخدم.

دمج OIDC مع Didit

تبسّط Didit تكامل OIDC من خلال منصة شاملة وواجهات برمجة تطبيقات سهلة الاستخدام للمطورين. تتعامل منصتنا مع تعقيدات OIDC، مما يتيح لك التركيز على بناء تطبيقك. تشمل الميزات الرئيسية:

• موصلات OIDC مدمجة مسبقًا: تكامل سلس مع موفري الهوية المشهورين مثل Google و Facebook و Microsoft.
• مطالبات قابلة للتخصيص: اطلب مطالبات محددة مصممة خصيصًا لاحتياجات تطبيقك.
• التحقق الآمن من الرمز: التحقق التلقائي من رموز الهوية لضمان الأصالة.
• أوركسترة سير العمل: بناء تدفقات هوية مخصصة تتضمن مصادقة OIDC.

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

كيف يساعدك Didit

يوفر Didit منصة هوية شاملة تبسّط تعقيدات OpenID Connect. نتعامل مع الجهد الأكبر لتنفيذ OIDC، مما يسمح للمطورين بـ:

• تقليل وقت التطوير: موصلات مدمجة مسبقًا وواجهات برمجة تطبيقات بديهية تسرع التكامل.
• تعزيز الأمان: التحقق الآمن من الرمز ودعم PKCE يحمي من الهجمات الشائعة.
• تحسين تجربة المستخدم: تدفقات المصادقة السلسة تقلل الاحتكاك للمستخدمين.
• التوسع بثقة: تم تصميم منصة Didit للتعامل مع أحجام كبيرة من طلبات المصادقة.

هل أنت مستعد للبدء؟

هل أنت مستعد للاستفادة من قوة OpenID Connect وتبسيط عملية مصادقة تطبيقك؟

سجّل للحصول على حساب Didit مجاني واستكشف وثائقنا الشاملة على Didit Docs. ابدأ في بناء تطبيقات آمنة وقابلة للتطوير اليوم!

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

ما الفرق بين OAuth 2.0 و OpenID Connect؟

OAuth 2.0 هو إطار عمل تفويض يسمح للتطبيقات بالوصول إلى الموارد نيابة عن المستخدم. OpenID Connect هو طبقة هوية مبنية على OAuth 2.0 توفر طريقة موحدة للتحقق من هوية المستخدم والحصول على بيانات الهوية.

ما هو رمز الهوية؟

رمز الهوية هو رمز JSON Web Token (JWT) يحتوي على مطالبات حول المستخدم المصادق عليه. يتم إصداره بواسطة خادم التفويض بعد المصادقة الناجحة ويستخدمه التطبيق لتحديد هوية المستخدم.

ما هي المطالبات في OIDC؟

المطالبات هي بيانات حول المستخدم، مثل اسمه وعنوان بريده الإلكتروني وصورة ملفه الشخصي. يحدد OIDC مجموعة من المطالبات القياسية لضمان قابلية التشغيل البيني بين موفري الهوية والتطبيقات المختلفة.

هل OIDC آمن؟

نعم، OIDC هو بروتوكول آمن عند تنفيذه بشكل صحيح. سير عمل رمز التفويض مع PKCE هو سير العمل الموصى به لتطبيقات الويب الحديثة، لأنه يوفر أمانًا معززًا ضد هجمات اعتراض الرمز. يعد استخدام موفر هوية موثوق به والتحقق من رمز الهوية أمرًا بالغ الأهمية للأمان.