الانتقال إلى المحتوى الرئيسي
يوفّر Didit خادم تفويض OpenID Connect مصمّماً خصيصاً للتحقق المفوّض من الهوية. يطبّق العقد الذي يتوقعه إطار عمل Okta المسمّى “bring your own identity verification vendor” (BYO IDV): طلبات التفويض المرسلة مسبقاً (PAR، RFC 9126)، وتدفق رمز التفويض مع PKCE، ورمز ID يحمل كائن OpenID Connect باسم verified_claims. تعمل نقاط النهاية نفسها مع أي طرف معتمِد يلتزم بهذا الملف، بما في ذلك إجراءات Auth0 بعد تسجيل الدخول.

نقاط النهاية

تقع جميع نقاط النهاية ضمن عنوان URL الأساسي لجسر التحقق من الهوية. تستخدم بيئة الإنتاج والبيئة التجريبية نقاط النهاية نفسها. يحدد التطبيق المرتبط ببيانات اعتماد العميل الخاصة بك البيئة التي تعمل فيها. استخدم بيانات اعتماد عميل منفصلة وسير عمل يتبع التطبيق المقابل لكل بيئة. راجع Sandbox & Test Data للاطلاع على نتائج التحقق المحاكاة. يعلن مستند الاكتشاف في {base}/.well-known/openid-configuration عن جميع نقاط النهاية: تستخدم مصادقة العميل client_secret_basic أو client_secret_post. يتطلب تدفق رمز التفويض استخدام PKCE مع code_challenge_method=S256. تُوقَّع رموز ID باستخدام RS256، وتحقق منها عبر نقطة نهاية JWKS.

التدفق

  1. يرسل الطرف المعتمِد طلب التفويض إلى POST /par، ويتضمن تحدي PKCE، وstate، وnonce، وredirect_uri المسجّل لديه، والنطاقات openid profile identity_assurance، والمطالبات التي يريد التحقق منها. يعيد Didit request_uri صالحاً للاستخدام مرة واحدة ولمدة 60 ثانية.
  2. يوجّه الطرف المعتمِد متصفح المستخدم إلى GET /authorize?request_uri=.... ينشئ Didit جلسة تحقق، ويوجّه المستخدم إلى تدفق التحقق المستضاف.
  3. عندما ينهي المستخدم العملية، يقيّم Didit قرار التحقق، ويقارن الهوية المستخرجة بالمطالبات التي أُرسلت، ثم يعيد المستخدم إلى redirect_uri الخاص بالطرف المعتمِد مع code لمرة واحدة وstate الأصلي.
  4. يستبدل الطرف المعتمِد الـ code عبر POST /token مع code_verifier الخاص به، فيستلم رمز ID موقّعاً.

طلب المطالبات

أرسل المطالبات المراد مقارنتها ضمن معامل claims القياسي في OpenID Connect داخل طلب PAR. يُدعم كل من given_name وfamily_name، وتُقارن الاثنتان دائماً بشكل تقريبي. تأتي verified_claims في صورة مصفوفة، وهذا يتوافق مع ملف BYO IDV لدى Okta ومع استجابة رمز ID أدناه.

رمز ID

يحمل رمز ID مصفوفة verified_claims. تكون قيمة assurance_level هي VERIFIED فقط إذا كانت جلسة التحقق مقبولة و تطابق كل مطالبة مطلوبة مع المستند المتحقق منه. وفي غير ذلك تكون القيمة FAILED.
تمثل verification_process معرّف جلسة Didit، لذلك يمكنك البحث عن عملية التحقق في وحدة التحكم أو عبر واجهة برمجة الجلسات.
لا تعامل المستخدم على أنه موثّق إلا عندما تكون trust_framework مساوية لـ IDV-DELEGATED و assurance_level مساوية لـ VERIFIED. أي تركيبة أخرى تعني أن التحقق لم ينجح.

إعداد Okta

اطلب من Didit تفعيل التحقق من الهوية لتطبيقي الإنتاج والبيئة التجريبية، وربط كل تطبيق بسير عمل التحقق الخاص به، وتسجيل رابط الاستدعاء الدقيق لكل مستأجر Okta. لا يكفي وجود تطبيق أو مفتاح API حالي لتفعيل هذا التكامل. في Okta Admin Console، أضف مزوّد تحقق من الهوية مخصصاً، وأدخل القيم الواردة أدناه. ينشئ Okta التكامل بوصفه مزوّد هوية من النوع IDV_STANDARD مع البروتوكول ID_PROOFING، ثم تشير إليه من قاعدة في Account Management Policy. اضبط بيئة الإنتاج والبيئة التجريبية بوصفهما تكاملين منفصلين للتحقق من الهوية، كل منهما ببياناته الخاصة. استخدم نقاط النهاية أعلاه في الحالتين. إن سر العميل مطلوب حتى مع استخدام PKCE في التدفق. لا يمكن لمفتاح API مسمّى أُنشئ بشكل منفصل أن يحل محل مفتاح API الأساسي للتطبيق في هذا التكامل. أرسل إلى Didit رابط الاستدعاء الخاص بك ليتم تسجيله على العميل لديك. يبنيه Okta بالصيغة {yourOktaOrgUrl}/idp/identity-verification/callback.

إعداد Auth0

لا يوفّر Auth0 خانة أصلية لمزوّد التحقق من الهوية، لذلك يعمل التحقق من خلال إجراء بعد تسجيل الدخول يوجّه المستخدم إلى التدفق نفسه. خزّن DIDIT_IDV_BASE وDIDIT_CLIENT_ID وDIDIT_CLIENT_SECRET بوصفها أسراراً للإجراء، وسجّل https://{yourAuth0Domain}/continue بوصفه رابط إعادة التوجيه لدى Didit.
يلحق Auth0 قيمة state الخاصة به بإعادة التوجيه إلى /authorize ليتمكن من استئناف تسجيل الدخول. يعتمد Didit على هذه القيمة state ويعيدها إلى /continue، وهذا ما يسمح لـ Auth0 بإكمال المعاملة. لا تمرر state الخاص بـ Auth0 ضمن جسم PAR، لأنه لا يُنشأ إلا عند إعادة التوجيه.
خزّن code_verifier الخاص بـ PKCE لكل معاملة تسجيل دخول، مع استخدام event.transaction.id مفتاحاً لها، ولا تخزنه في حقل واحد ضمن app_metadata. إذا أعاد المستخدم المحاولة أو بدأ تسجيل دخول متداخلاً، فسيُستبدل الحقل المشترك ويفشل تبادل الرمز ويظهر الخطأ invalid_grant.

الأخطاء

تتوافق الأخطاء مع المعيارين RFC 6749 وRFC 9126. تؤدي مصادقة العميل الفاشلة إلى الاستجابة 401 مع {"error": "invalid_client"}، وتؤدي request_uri أو رمز التفويض المنتهيان أو المُعاد استخدامهما إلى الاستجابة 400 مع invalid_request أو invalid_grant. رموز التفويض وقيم request_uri وجلسات التحقق تُستخدم مرة واحدة فقط.
آخر تعديل في ٧ نوفمبر ٢٠٢٦