التحقق البيومتري متعدد المستويات لوصول واجهة برمجة تطبيقات الذكاء الاصطناعي: ربط الامتياز بالشخص (AR)

يُثبت التحقق عند الإعداد هوية من أنشأ الحساب. لكنه لا يُثبت شيئًا عن هوية من يستخدمه الآن.

هذه الفجوة أمر عادي في معظم المنتجات، وخطيرة في منصات الذكاء الاصطناعي، حيث تكون الأصول وراء الحساب هي الوصول إلى النماذج، والاعتمادات، والحصص. مفتاح واجهة برمجة التطبيقات (API key) هو رمز حامل — من يحمله هو صاحب الحساب. تُشارك المفاتيح داخل الفرق، وتُلصق في المستودعات، وتُباع، ويُستولى عليها. بعد ستة أشهر من عملية إعداد نظيفة، فإن عبارة "تم التحقق من هذا الحساب" هي بيان يتعلق بالماضي.

تُسد المصادقة البيومترية هذه الفجوة. إنها تُعيد التحقق من هوية الإنسان الفعلي في لحظة إجراء مميز — بدون مستندات، بدون كلمة مرور، في أقل من ثانيتين، 0.10 دولار لكل مصادقة.

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

• التحقق عند الإعداد هو لقطة. المصادقة البيومترية هي تحقق في اللحظة التي يهم فيها الأمر.
• التحقق من الحيوية بالإضافة إلى مطابقة الوجه مع الصورة المخزنة بالفعل من التحقق الأصلي للمستخدم. لا مستندات، لا كلمة مرور.
• خاصة بالجلسة فقط. لا يوجد نقطة نهاية /v3/biometric-auth/ — يتم تشغيلها عبر جلسة باستخدام workflow_type=BIOMETRIC_AUTHENTICATION.
• التفاصيل الهامة للتنفيذ: استخدم نفس vendor_data مثل التحقق الأصلي للمستخدم، أو لا يمكن استرداد الوجه المخزن.
• المحفزات الصحيحة: زيادات الحصص، ومنح الائتمان، وإصدار مفتاح واجهة برمجة تطبيقات جديد، وترقيات المستويات، وإضافة أعضاء فريق مميزين، وأي تنبيه سلوكي من طبقة حركة المرور الخاصة بك.
• 0.10 دولار لكل مصادقة، الدفع مقابل النجاح، في أقل من ثانيتين.

لماذا تنتمي إعادة المصادقة إلى منصة الذكاء الاصطناعي

ثلاثة أنماط فشل تجعل لقطة الإعداد غير كافية.

مشاركة المفاتيح وإعادة بيعها. يمكن أن ينتهي مفتاح صادر لمطور تم التحقق منه في أي مكان. يبقى الحساب موثوقًا؛ لكن الشخص الذي يستخدمه ليس هو الشخص الذي تم التحقق منه. هذه هي الآلية التي يصبح بها حساب تم التحقق منه بشكل مشروع نقطة دخول إلى شبكة مزورة — وهو أمر غير مرئي لأي تحكم ينظر فقط إلى عملية الإعداد.

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

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

في جميع الحالات الثلاث، يظل حالة التحقق من الحساب كما هي، والإنسان وراءه ليس كما تعتقد. كلمة المرور، الرمز لمرة واحدة، أو رمز الجلسة لا يمكنها التمييز بين هذه الحالات، لأن كل واحدة منها هي مهاجم يمتلك بيانات الاعتماد بشكل مشروع. فقط التحقق البيومتري يطرح السؤال المهم: هل الشخص الموجود هنا الآن هو الشخص الذي تم التحقق منه؟

كيف يعمل

تُعيد المصادقة البيومترية استخدام نفس مكونات LivenessV3 و FaceMatchV3 مثل تدفق الهوية العادي. الفرق الوحيد هو مصدر الصورة المرجعية — بدلاً من الصورة الشخصية على مستند تم تقديمه حديثًا، تستخدم الصورة الشخصية المخزنة بالفعل من التحقق السابق للمستخدم.

لهذا السبب لا تحتاج إلى مستندات، ولماذا هي سريعة ورخيصة بما يكفي لتوضع في تدفق منتج عادي.

خاصة بالجلسة فقط

لا توجد نقطة نهاية مخصصة /v3/biometric-auth/. تُقدم المصادقة من خلال جلسة يتم تكوين سير عملها لها — workflow_type=BIOMETRIC_AUTHENTICATION. إذا كنت تبحث عن نقطة نهاية مستقلة في مرجع واجهة برمجة التطبيقات، فهذا هو السبب الذي يجعلك لا تجدها.

التدفق

1. قم بتكوين سير عمل من نوع BIOMETRIC_AUTHENTICATION في لوحة التحكم ودوّن workflow_id الخاص به.
2. أنشئ جلسة:

curl -X POST 'https://verification.didit.me/v3/session/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{
    "workflow_id": "YOUR_BIOMETRIC_AUTH_WORKFLOW_ID",
    "vendor_data": "acct_8842",
    "callback": "https://yourplatform.example/auth/complete"
  }'

1. أرسل المستخدم عبر الجلسة المُعادة — مستضافة، أو مدمجة مع أي من حزم SDK المجانية.
2. اجلب القرار:

curl -X GET 'https://verification.didit.me/v3/session/{sessionId}/decision/' \
  -H 'x-api-key: YOUR_API_KEY'

أو اشترك في session.status.updated واستقبل الـ webhook.

التفصيل الوحيد الذي يكسر عمليات التكامل

استخدم نفس vendor_data مثل التحقق الأصلي للمستخدم.

هذه القيمة هي كيفية استرداد Didit للصورة المخزنة لمطابقتها. تعني vendor_data جديدة أو مختلفة عدم وجود وجه مخزن للمقارنة، ولا يمكن للتدفق القيام بما طلبته. إذا كنت بحاجة إلى تجاوز المرجع المخزن عمدًا، فمرر portrait_image بشكل صريح — ولكن المسار العادي هو vendor_data ثابت لكل حساب، يتم تعيينه عند الإعداد وإعادة استخدامه إلى الأبد.

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

قراءة النتيجة

تصل النتائج في liveness_checks و face_matches. كلاهما دائمًا مصفوفات — ليست أبدًا كائنات مفردة — ويحمل كل عنصر node_id حتى تتمكن سير العمل متعددة المثيلات من تمييز الخطوات. كل منها null حتى تُنتج خطوته بيانات.

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

ما الذي يجب أن يطلق عملية التحقق متعدد المستويات

تعتمد قيمة هذا التحكم كليًا تقريبًا على تصميم المحفز. إذا كان هناك الكثير، فقد بنيت إزعاجًا؛ وإذا كان قليلًا جدًا، فإنه لا يُطلق أبدًا عندما يكون الأمر مهمًا.

تصعيد الوصول — زيادات الحصص، ومنح الائتمان، وإصدار مفتاح واجهة برمجة تطبيقات جديد، وترقيات المستويات، والانتقال إلى مستوى قدرة تعتبره حساسًا.

تغييرات الحساب — عضو فريق مميز جديد، تغيير مالك الفواتير، تغيير وجهة الدفع، إعادة تعيين كلمة المرور أو المصادقة متعددة العوامل.

التنبيهات السلوكية — المحفز ذو القيمة الأعلى. عندما تضع طبقة حركة المرور الخاصة بك علامة على حساب بسبب الاستعلامات المركزة أو نمط يشبه الاستخلاص، يسأل التحقق البيومتري متعدد المستويات السؤال الوحيد الذي لا يمكن لطبقة حركة المرور الإجابة عليه: هل الإنسان الذي تم التحقق منه لا يزال هو من يشغل هذا الحساب؟ النجاح يضيق التفسير. الفشل أو التخلي هو بحد ذاته إشارة قوية.

إشارات الربط — جلسة تحمل DEVICE_RECOVERED_HIGH_CONFIDENCE، أو وجه يطابق مستخدمًا تم التحقق منه بالفعل، قد اكتسبت تحققًا متعدد المستويات بغض النظر عما يطلبه الحساب.

الخمول بالإضافة إلى التصعيد — حساب هادئ لعدة أشهر يطلب فجأة زيادة كبيرة. ليس الخمول وحده؛ بل التركيبة.

لماذا لا نطلب كلمة مرور أو رمزًا فقط؟

لأن كل عامل تقليدي هو بيانات اعتماد حامل، ونموذج التهديد هنا هو مهاجم يحمل بيانات الاعتماد.

يذهب الرمز لمرة واحدة إلى رقم الهاتف أو العنوان المسجل — الذي يتحكم فيه المهاجم بعد الاستيلاء، والذي يقوم الشريك الشرعي ببساطة بإعادة توجيهه. تُثبت كلمة المرور معرفة سلسلة. يُثبت مفتاح الجهاز امتلاك كائن، والذي يمكن تسليمه مع المفتاح.

تُثبت مطابقة الوجه التي تم التحقق من حيويتها أن إنسانًا معينًا موجود في هذه اللحظة. لربط الامتياز بشخص، هذا هو العامل الوحيد الذي يجيب على السؤال الفعلي. بتكلفة 0.10 دولار وفي أقل من ثانيتين، هو أيضًا رخيص بما يكفي لاستخدامه في المحفزات الحقيقية بدلاً من حفظه لحالات الطوارئ.

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

حالات الاستخدام

منصات واجهة برمجة تطبيقات الذكاء الاصطناعي التي تحد من تصعيد الحصص، ومنح الائتمان، وإصدار المفاتيح وراء التحقق من هوية الإنسان.

منتجات الوكيل والأتمتة التي تتطلب تحققًا متعدد المستويات قبل منح الوكيل قدرة جديدة أو رفع حد الإنفاق.

الخدمات المالية التي تُعيد المصادقة قبل تحويل ذي قيمة عالية أو تغيير وجهة الدفع.

الأسواق التي تُعيد التحقق من البائع قبل تغيير طريقة الدفع — وهو المكافأة الأكثر شيوعًا للاستيلاء على الحساب.

أي منصة بها تدفق استرداد تستخدم المصادقة البيومترية لإعادة التحقق بدلاً من الأسئلة المستندة إلى المعرفة، والتي تعد أضعف حلقة في معظم تصاميم أمان الحسابات.

أسئلة مكررة

هل يحتاج المستخدم إلى تقديم مستند مرة أخرى؟

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

ماذا لو لم يتم التحقق من المستخدم مطلقًا باستخدام Didit؟

إذًا لا توجد صورة شخصية مخزنة ولا يوجد شيء للمصادقة عليه. المصادقة البيومترية هي بدائية لإعادة التحقق؛ فهي تفترض تحققًا سابقًا تحت نفس vendor_data.

كم يستغرق من الوقت؟

استدلال في أقل من ثانيتين. من وجهة نظر المستخدم، هو صورة شخصية ولحظة.

هل يمكن تشغيله داخل واجهتنا الخاصة؟

نعم. حزم SDK للويب، iOS، Android، React Native و Flutter جميعها مجانية، و White Label (0.20 دولار) تزيل علامة Didit التجارية.

ماذا لو قام شخص ما برفع صورة أو فيديو لمالك الحساب؟

هذا ما يهدف إليه الكشف عن الحيوية. يتمتع الكشف عن الحيوية السلبي في Didit بتقييم iBeta المستوى 1 لاكتشاف هجوم العرض، وتظهر تنبيهات هجوم الوجه في التحذيرات. يمكن تهيئة العتبات.

كم تكلفتها؟

0.10 دولار لكل مصادقة، الدفع مقابل النجاح، لا يوجد حد أدنى.

هل يجب أن تتطلب كل عملية تسجيل دخول هذا؟

لا. تسجيل الدخول هو المحفز الخاطئ — يتم تشغيله باستمرار ومعظم الوقت بلا داعي. اربطه بتصعيد الامتياز وبالتنبيهات، حيث تكون تكلفة الخطأ عالية والتكرار منخفضًا.

جاهز للبدء؟

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

• اقرأ الوثائق — نظرة عامة على المصادقة البيومترية و واجهة برمجة تطبيقات الجلسات.
• شاهد المنتج — التحقق من المستخدم.
• تحقق من الأسعار — 0.10 دولار لكل مصادقة، الدفع مقابل النجاح، لا يوجد حد أدنى.
• ابدأ مجانًا — business.didit.me، 500 عملية تحقق من KYC شهريًا بدون تكلفة.