يستكشف المجالات الرئيسية والتطبيقات العملية لتكوين OpenID Connect.
في عالم اليوم الرقمي، أصبح التحقق من الهوية مكونًا أساسيًا في تأمين المواقع والتطبيقات. يوفر OpenID Connect (OIDC)، وهو طبقة تحقق مبنية على بروتوكول OAuth 2.0، طريقة موحدة وبسيطة للتحقق من الهويات.
ومع ذلك، يمكن أن يكون دمج OIDC بشكل صحيح تحديًا، خاصة للمبتدئين. نقطة البداية الجيدة غالبًا ما تكون في ملف تكوين OIDC، الذي يوجد عادةً في عنوان URL {authServerUrl}/.well-known/openid-configuration، والذي يحتوي على جميع التفاصيل اللازمة لتنفيذ خدمات OIDC.
يهدف هذا الدليل إلى توضيح المجالات الرئيسية ضمن هذا التكوين، مما يساعد المطورين على فهم أهميتها والتطبيقات العملية لدمج OIDC بشكل أفضل في مشاريعهم.
التكوين الخاص بـ OIDC هو ملف JSON مشابه لما يلي:
بعد ذلك، سوف نتعمق أكثر في بعض المجالات الرئيسية.
عند دمج خدمات OIDC، عادة ما تبدأ الخطوة الأولى في معالجة طلبات تسجيل الدخول للمستخدم داخل التطبيق. يتضمن هذا العملية إعادة توجيه المستخدمين إلى نقطة النهاية authorization_endpoint لخادم التفويض. هذه النقطة النهائية هي عنوان الخادم حيث يتم إرسال طلبات التفويض، وتوجيه المستخدمين إلى صفحة تسجيل الدخول للتحقق من الهوية.
عند تقديم طلب إلى authorization_endpoint، يجب تكوينه مع معلمات استعلام إضافية لكل تفويض:
response_type: يحدد نوع التفويض الذي يتم إرجاعه. يشمل ذلك عادة "code" (لتدفق رمز التفويض)، "token" (لتدفق ضمني)، و"id_token token" أو "code id_token" (لتدفق هجين)، الذي يمكن العثور عليه في حقل response_types_supported الخاص بتكوين OIDC.client_id: معرف فريد يتم تخصيصه للتطبيق بواسطة خادم التفويض عند تسجيل التطبيق. يستخدم هذا المعرف من قبل خادم التفويض للتعرف على التطبيق العميل الذي يبدأ الطلب.scope: يحدد نطاق الوصول المطلوب، ويحدد الموارد أو معلومات المستخدم المتاحة. تشمل النطاقات الشائعة "openid" (إجباري)، "profile"، و"email"، من بين أمور أخرى. يمكنك العثور على النطاقات المدعومة في حقل scopes_supported في تكوين OIDC؛ يجب أن تكون النطاقات المختلفة مفصولة بمسافات.redirect_uri: بعد تسجيل الدخول أو التفويض، يعيد خادم التفويض توجيه المستخدم إلى عنوان URI الذي يوفره التطبيق. يجب أن يتطابق هذا ال URI بشكل صارم مع ال URI الذي تم توفيره أثناء تسجيل التطبيق.state: سلسلة يتم توليدها عشوائيًا تُستخدم لحماية العميل من هجمات تزوير الطلبات عبر المواقع. يجب الحفاظ على تناسق حالة الطلب بين طلب التفويض واسترجاع النداء لضمان الأمن.تتيح هذه المعلمات للمطورين التحكم بدقة في سلوك طلبات التفويض OIDC، مما يضمن أنها آمنة وتلبي احتياجات التطبيق.
بعد إكمال الطلب إلى authorization_endpoint ومرور عبر التحقق من الهوية، يتم إعادة توجيه المستخدمين إلى redirect_uri المحدد، والذي يتضمن معلمة استعلام مهمة جدًا—code. يتم توفير رمز التفويض هذا من قبل خادم التفويض وهو نتيجة لتحقق المستخدم وتفويض التطبيق للوصول إلى معلوماتهم في خادم التفويض.
token_endpoint هو النقطة النهائية للخادم المستخدمة من قبل خادم التفويض لتبادل رمز التفويض المذكور للحصول على رموز وصول وتحديث. في تدفق رمز تفويض OAuth 2.0، تعتبر هذه الخطوة حاسمة لأنها تتضمن تحويل رمز التفويض المأخوذ إلى رموز وصول فعلية، والتي يمكن للتطبيق استخدامها للوصول إلى الموارد المحمية للمستخدم.
إليك كيفية تنفيذ تبادل رمز التفويض للحصول على رموز الوصول (مع الانتباه إلى أن هذا المثال يستخدم طريقة التحقق client_secret_post. بالنسبة لطرق التحقق الأخرى المدعومة، يرجى الرجوع إلى التحليل لاحقًا في حقل
token_endpoint_auth_methods_supportedفي هذا الكود، نرسل أولاً طلبًا إلى token_endpoint باستخدام الطريقة POST. يتم تعيين نوع المحتوى إلى application/x-www-form-urlencoded، وهو مطلوب من قبل معظم خوادم التفويض. يتضمن محتوى الطلب المعلمات التالية:
redirectUri بعد أن يكمل المستخدم التفويض."authorization_code" هنا، مما يشير إلى أن رمز الوصول يتم الحصول عليه من خلال رمز التفويض.يتم تنفيذ هذه الوظيفة بشكل غير متزامن وتعيد كائن JSON يحتوي على رمز الوصول، الذي يمكن للتطبيق استخدامه لطلب بيانات المستخدم أو تنفيذ عمليات أخرى.
userinfo_endpoint هو النقطة النهائية للخادم المستخدمة من قبل خادم التفويض للحصول على المعلومات التفصيلية حول المستخدمين الذين تم التحقق منهم. بعد أن ينجح المستخدمون في التفويض ويحصلون على رموز الوصول عبر token_endpoint، يمكن للتطبيق طلب هذه النقطة النهائية للوصول إلى معلومات الملف الشخصي للمستخدم، مثل اسم المستخدم وعنوان البريد الإلكتروني. تعتمد المعلومات المحددة المحصلة على "النطاق" المحدد من قبل المستخدم في طلب التحقق من الهوية.
في هذه الوظيفة، نستخدم أولاً الطريقة GET لطلب userinfo_endpoint، بما في ذلك الحقل Authorization في عنوان الطلب الذي يتكون من token_type و accessToken. هذه عملية معيارية وفقًا لمواصفات OAuth 2.0، مما يضمن الاسترجاع الآمن لمعلومات المستخدم. بالإضافة إلى ذلك، يعتمد نطاق معلومات المستخدم التي تم الوصول إليها عبر رمز الدخول بشكل كامل على القيم الخاصة بمعامل scope المعتمد من قبل المستخدم خلال بدء التفويض. على سبيل المثال، إذا تم استخدام نطاق email، فيجب أن يتضمن الرد عنوان البريد الإلكتروني للمستخدم.
المورد يحدد عنوان URL لخادم التفويض، بينما يوفر jwks_uri عنوان URI لمجموعة مفاتيح الويب (JWKS) التي هي مجموعة من المفاتيح العامة المستخدمة للتحقق من توقيعات JWT. يُعد التحقق من issuer لـ JWT وتوقيعه من الخطوات الأساسية لضمان أمان الرمز، ولكن في السيناريوهات الواقعية، يشمل عملية التحقق عادةً التحقق من فترة صلاحية الرمز والجمهور ونطاق التفويض والحقول المهمة الأخرى.
يُظهر الكود التالي بشكل أساسي كيفية استخدام issuer و jwks_uri معًا للتحقق من JWT:
تعلن حقول claims_supported و scopes_supported عن سمات المستخدم (الأحقية) والنطاقات المدعومة (النطاقات) من قبل خادم التفويض. تساعد هذه الحقول العملاء على فهم السمات والنطاقات المدعومة من قبل خادم التفويض، مما يمكنهم من بناء طلبات التفويض وتحليل الردود بشكل فعال.
عند بناء طلب تفويض، يمكن للعملاء تحديد النطاق المطلوب بناءً على احتياجات التطبيق. يحدد scope الموارد والعمليات التي يطلب العميل الوصول إليها، مثل "openid"، "email"، "profile" وغيرها.
من المهم ملاحظة أن الأحقية المحددة والمتاحة في كل طلب تفويض يعتمد على قيم النطاق المحددة في بداية طلب التحقق من الهوية. على سبيل المثال، يمنح نطاق البريد الإلكتروني الوصول إلى عنوان البريد الإلكتروني للمستخدم، بينما يوفر نطاق الهاتف الوصول إلى رقم هاتفه. لذلك، يجب على العملاء اختيار النطاق المناسب بعناية ليتناسب مع احتياجات التطبيق عند إنشاء طلب التفويض، لضمان قدرتهم على استرداد السمات المطلوبة:
يحدد حقل
token_endpoint_auth_methods_supportedعند التحقق باستخدام نقطة النهاية الخاصة بالرمز، تشمل طرق التحقق الشائعة client_secret_post، client_secret_basic و client_secret_jwt.
client_secret_post: يستخدم العميل معرف العميل والسر العميل لإنشاء جسم مرمز بالصيغ الترميزية، وهو يتم إرساله كجزء من جسم الطلب. لقد رأينا بالفعل مثالاً على هذه الطريقة في قسم token_endpoint أعلاه.
client_secret_basic: يستخدم العميل معرف العميل والسر العميل لإنشاء عنوان مصادقة أساسية، يضاف إلى عنوان الطلب.
client_secret_jwt: يستخدم العميل JWT (رمز الويب المصدق) كتأكيد العميل للتحقق. يحتوي هذا ال JWT على معرف العميل وبعض البيانات التعريفية الإضافية ويتم توقيعه باستخدام السر العميل. بعد تلقي الخادم الطلب، يتحقق من هوية العميل عن طريق التحقق من توقيع JWT.في التطبيقات العملية، يجب على العملاء اختيار طريقة التحقق المناسبة بناءً على الطرق المدعومة من قبل خادم التفويض، والتأكد من إضافة معلومات التحقق بشكل صحيح إلى الطلب لتبادل رمز التفويض بأمان للحصول على رموز الوصول.
لقد استكشفنا الآن المجالات الرئيسية في تكوين OIDC، مع التركيز على أغراضها وتطبيقاتها. فهم هذه التفاصيل سيعزز من فهمك لـ OpenID Connect، مما يمنحك القدرة على دمجه واستخدامه بشكل أكثر فاعلية في مشاريعك. مسلحًا بهذا المعرفة، أنت مجهز بشكل أفضل للاستفادة من كامل إمكانات OIDC للحصول على حلول تحقيق هوية مستخدم أكثر أمانًا وكفاءة.
كخدمة تحقق من الهوية مبنية على OIDC، تقدم Logto مجموعة شاملة من SDKs بعدة لغات مع العديد من دروس التكامل، مما يتيح لك دمج تسجيلات الدخول OAuth / OIDC بسلاسة في تطبيقاتك في دقائق معدودة. إذا كنت تبحث عن خدمة OIDC موثوقة وسهلة الاستخدام، جرب Logto اليوم!