كيف يعمل
لكل تطبيق أصل تسجيل دخول خاص به ومُصدِر token خاص به. تطبيقات الإنتاج وتطبيقات البيئة التجريبية منفصلة: لكل منها أصول وإعدادات وهويات مستقلة.
التدفق هو تدفق رمز التفويض في OAuth 2.0 مع PKCE (
S256 فقط):
- يفتح تطبيقك
{origin}/sign-inمعredirect_uriوstateوcode_challengeوcode_challenge_method=S256. - تُسجّل الصفحة المستضافة دخول الشخص أو تُنشئ حسابه باستخدام الطرق التي فعّلتها، بما فيها أي عامل ثانٍ مطلوب.
- يعود المتصفح إلى
redirect_uriلديك معcodeوstate. - يستبدل تطبيقك الرمز عند
POST {origin}/token/بـtoken وصول وtoken للهوية وtoken لتحديث الجلسة.
اختر منصتك
JavaScript
تسجيل الدخول المستضاف والاستدعاء والجلسة وتسجيل الخروج.
React
حالة العميل وواجهات التطبيق المحمية.
Next.js
جلسات الخادم ومسارات الاستدعاء وملفات تعريف الارتباط.
iOS
متصفح النظام وتخزين الرموز الآمن.
Android
تفويض المتصفح واستدعاءات التطبيق.
React Native
تحضير غلاف المصادقة الأصلي.
Flutter
تحضير غلاف المصادقة الأصلي.
جهّز تطبيقك
- اطلب من Didit تفعيل المصادقة لتطبيقك. اختبر أولًا في تطبيق البيئة التجريبية.
- سجّل عناوين إعادة التوجيه الدقيقة (حتى 50) و
allowed_originsالخاصة بالمتصفح (حتى 50) التي تستدعي واجهة برمجة التشغيل. - فعّل طرق تسجيل الدخول التي تريد عرضها. Didit ID Wallet مفعّلة دائمًا.
- اختر إعدادات الجلسة وكلمة المرور (انظر أدناه).
- اختبر التسجيل وتسجيل الدخول واستعادة كلمة المرور والمصادقة متعددة العوامل وانتهاء الجلسة وتسجيل الخروج قبل الإطلاق.
عناوين إعادة التوجيه
لا تُعيد Didit الشخص إلا إلى عنوان سجّلته. سجّل عنوانك في وحدة التحكم، ضمن Authentication > Security and sessions > Redirect URLs and allowed origins. يجب أن يطابقredirect_uri في طلب تسجيل الدخول عنوانًا مسجلاً حرفًا بحرف: المخطط والمضيف والمنفذ والمسار والاستعلام.
منفذ مختلف، أو شرطة مائلة في النهاية، أو اختلاف في حالة الأحرف، كلها عناوين مختلفة.
تُرفض علامات البدل والأجزاء وبيانات الاعتماد داخل العنوان والمخططات المخصصة.
عندما لا يكون العنوان مسجلاً، لا يُعيد Didit التوجيه إليه أبدًا.
{origin}/sign-in يُرجع 400 مع صفحة توضح ما يجب تسجيله وأين، وPOST {origin}/authorize/ يُرجع 400 {"error": "invalid_redirect_uri"}.
التطوير المحلي
اختبر على جهازك باستخدام تطبيق البيئة التجريبية:- سجّل رابط الاستدعاء مع منفذه، مثل
http://localhost:3000/auth/callback. - إذا كان كود المتصفح يستدعي واجهة برمجة التشغيل، مثلًا لاستبدال الرمز عند
POST {origin}/token/، فأضف الأصل إلى الأصول المسموح بها أيضًا:http://localhost:3000، دون مسار وبلا شرطة مائلة في النهاية. - ابدأ تسجيل الدخول على أصل البيئة التجريبية،
https://<slug>.sandbox.auth.didit.me، باستخدام مفتاحpk_test_...الخاص بك.
localhost و127.0.0.1 و[::1] عناوين منفصلة، وكذلك كل منفذ. سجّل كل عنوان تستخدمه.
لا تقبل تطبيقات الإنتاج عنوان http:// أبدًا.
قبل الإطلاق، سجّل رابط الاستدعاء https:// الخاص بالإنتاج في تطبيق الإنتاج.
إعدادات التطبيق
تدير هذه الإعدادات من وحدة التحكم، أو من خلال جلسة وحدة تحكم مصرّح بها تملك الصلاحيةwrite:authentication.
الحفاظ على هوية المستخدم نفسه عبر المنتجات
تحمل كل هوية قيمةvendor_data. وهي external_id الذي زوّدت به النظام عند استيراد الشخص، وإلا فهو معرّف هوية Didit. تظهر هذه القيمة في رمز الوصول، وفي رمز الهوية، وفي GET session/.
استخدم القيمة نفسها بوصفها vendor_data عند إنشاء جلسات التحقق وإرسال المعاملات. عندها تظهر أحداث المصادقة للشخص نفسه في وحدة التحكم، مع عمليات التحقق والمعاملات الخاصة به. راجع الأحداث وwebhook.
استخرج vendor_data على الخادم من رمز مُتحقَّق منه، ولا تستخرجه أبدًا من حقل في المتصفح لم يُتحقَّق منه.
استخدم تعليمات التكامل المشتركة لأي مجموعة. واطّلع على الحماية من الروبوتات للسياسات التي تعمل عند تسجيل الدخول.