الانتقال إلى المحتوى الرئيسي
ميزة المصادقة جديدة: didit_auth يعتمد على الإصدار. إحداثيات الحزمة والإصدارات وتواقيع الدوال غير مؤكدة هنا. لا تثبّت حزمة مُخمَّنة، ولا تستخدم حزمة SDK للتحقق من الهوية كأنها SDK للمصادقة.

​
تجهيز التطبيق

  1. تأكد من تفعيل Authentication لتطبيقك في Didit، وانسخ من الكونسول أصل تسجيل الدخول (https://<slug>.auth.didit.me، أو <slug>.sandbox.auth.didit.me للبيئة التجريبية).
  2. سجّل رابط استدعاء دقيقًا يدعمه تطبيقك وبيئة التشغيل. تحقّق من ملكية روابط التطبيق، ولا تفترض أن مخططات الروابط المخصصة العشوائية مقبولة.
  3. افصل إعدادات البيئة التجريبية عن إعدادات الإنتاج، بما في ذلك معالجة الاستدعاء وبيانات الاعتماد المخزنة.
  4. اختر آلية ثابتة لربط الشخص قبل ربط التحقق أو المراقبة.
اضبط روابط الاستدعاء واختبرها بشكل منفصل على iOS وAndroid. غلاف Authentication منفصل عن didit_sdk، الذي يتولى التحقق.

​
تنفيذ التدفق المستضاف

افتح متصفح المصادقة الخاص بالنظام على عنوان {origin}/sign-in. مرّر state عشوائيًا جديدًا، وتحدي PKCE بطريقة S256، وredirect_uri المسجَّل لديك. احتفظ بقيمة التحقق داخل تطبيقك لتلك المحاولة فقط. يعرض دليل البدء السريع لـ JavaScript البروتوكول الأساسي؛ استخدم في الكود الأصلي تشفير المنصة ومعالجة الروابط الخاصة بها، لا كائنات المتصفح العامة. عند الاستدعاء، تحقّق من state ومدة صلاحية المعاملة ووجهة الاستدعاء، ثم استبدل الكود المستخدم مرة واحدة عند token/. استخدم قيمة التحقق الأصلية وعنوان URI لإعادة التوجيه المطابق تمامًا. إلغاء المتصفح أو إغلاقه لا يُعد تسجيل دخول ناجحًا. خزّن رموز التحديث في التخزين المحمي للمنصة الأصلية، ولا تخزّنها أبدًا في ملف تفضيلات غير محمي أو في سجلات التحليلات أو سجلات الأعطال. تحقّق من الجلسة الحالية باستخدام GET session/ مع رمز Bearer الخاص بالمستخدم النهائي. نفّذ عمليات التحديث بالتسلسل، واستبدل الرمزين معًا، وامسح الحالة الخاصة بالمستخدم بعد تسجيل الخروج. للاطلاع على عقد الطلب وسلوك إعادة استخدام رموز التحديث، راجع الرموز المميزة وJWKS.

​
معاينة إصدار SDK الأصلي

من المخطط أن توفر وحدات Authentication الأصلية تسجيل الدخول والوصول إلى الجلسة الحالية واسترجاع الرموز وتسجيل الخروج والتحقق الإضافي (step-up)، مع إشارات الجهاز التلقائية. وستكون مفاتيح المرور الأصلية وتخزين الرموز المحمي جزءًا من ذلك الإصدار. ستتبع واجهات الغلاف عقود المنصات المنشورة لها، فلا تنسخ معاملات المُنشئات أو توقيعات الدوال مُخمَّنة من أي مثال تصميمي. إلى أن تُصدر الوحدة، أبقِ المحوّل الخاص بها معطّلًا، أو استخدم تنفيذًا مراجَعًا للبروتوكول المستضاف لتطبيقك المفعّل. لا تعلن أن دليل بدء Authentication الأصلي يعمل بمجرد تثبيت الحزمة.

​
ربط التحقق والمراقبة

يشتق الخادم الخلفي لديك vendor_data من الشخص الذي تمت مصادقته. ثم ينشئ جلسات التحقق أو يصدر رموز مراقبة محدودة النطاق لذلك الشخص. أعِد إلى تطبيقك بيانات اعتماد الجلسة أو الرمز المحدود فقط، ويبقى مفتاح API على الخادم. استخدم حزمة SDK للتحقق في Flutter عندما تحتاج إلى التحقق من الهوية. واتبع إرسال المعاملات عبر SDK لدعم المراقبة على منصتك. عامل قرارات تسجيل الدخول والتحقق والمعاملات كل منها على حدة.

​
التحقق من التكامل

اختبر العودة إلى تطبيق مغلق، والانتقال إلى الخلفية والعودة إلى المقدمة، وإلغاء المتصفح، واستدعاءً غير متطابق، وإعادة استخدام الكود، وانتهاء صلاحية الرموز، والتحديث المتزامن، والمصادقة متعددة العوامل (MFA)، وتسجيل الخروج، وتسجيل الدخول بحساب مستخدم آخر. اختبر تسجيل مفاتيح المرور وتسجيل الدخول بها على الأجهزة المدعومة بعد توفر ذلك الإصدار. يبقى أي فحص يقتصر على الجهاز غير موثَّق حتى يُجرى على المنصة المستهدفة.
آخر تعديل في ٧ نوفمبر ٢٠٢٦