كيف يعمل التحقق من رقم الهاتف (خطوة بخطوة)

خلف كل رسالة "لقد أرسلنا رمزًا مكونًا من 6 أرقام إلى هاتفك" توجد سلسلة من العمليات التي يجب أن تعمل في أقل من ثلاث ثوانٍ، عبر أكثر من 200 دولة، على كل شبكة مشغل في العالم. عندما تنقطع هذه السلسلة، ينخفض معدل تحويل التسجيل بشكل ملحوظ. تُظهر أبحاث المصادقة من Auth0 باستمرار أن كل ثانية إضافية من تسليم كلمة المرور لمرة واحدة (OTP) زمن الاستجابة يؤدي إلى عمليات تسجيل مهجورة.

يستعرض هذا الدليل خطوة بخطوة بالضبط كيف يعمل التحقق من رقم الهاتف داخليًا — ما يحدث في كل مرحلة، ولماذا توجد كل خطوة، وأين تسوء الأمور عادةً، وما هي أفضل الممارسات التي يجب عليك تضمينها في تكاملك منذ اليوم الأول.

التحقق من رقم الهاتف: لمحة سريعة

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

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

عملية التحقق خطوة بخطوة

تتبع كل عملية تحقق حديثة نفس الخطوات الأربع بالتسلسل. تكمن الاختلافات بين المزودين في مدى جودة هندسة كل خطوة — خاصة فيما يتعلق بتوجيه التسليم والحماية من الاحتيال.

الخطوة 1: إدخال الرقم وتوحيد التنسيق

يدخل المستخدم رقم هاتفه في نموذج التسجيل أو تسجيل الدخول الخاص بك. قبل حدوث أي شيء آخر، يجب على تطبيقك — أو، في كثير من الأحيان، واجهة برمجة تطبيقات التحقق (API) نفسها — أن تقوم بـ توحيد الرقم إلى تنسيق E.164 الدولي. E.164 هو المعيار العالمي الذي تحتفظ به ITU-T: جهة رائدة +، ثم ما يصل إلى 15 رقمًا، بما في ذلك رمز الدولة ورمز المنطقة ورقم المشترك. لذلك يصبح "(415) 555-2671" +14155552671، و"98765 43210" مع سياق الدولة "IN" يصبح +919876543210.

التوحيد ليس مجرد أمر شكلي. إنه يحدد كيف تعرف واجهة برمجة التطبيقات (API) إلى أي بلد ينتمي الرقم، مما يحدد مسار المشغل الذي سيتم استخدامه، وتكلفة الرسالة، والقواعد التنظيمية التي يجب تطبيقها، وتنسيق معرف مرسل الرسائل القصيرة المسموح به. تقوم واجهة برمجة التطبيقات الجيدة أيضًا بإجراء التحقق من خطة أرقام الهواتف في هذه الخطوة، برفض الأرقام الصالحة نحويًا ولكنها لا تتوافق مع أي بادئة حقيقية في خطة أرقام الدولة الوجهة. هذا يقوم بتصفية الأخطاء المطبعية والبيانات غير المرغوب فيها الواضحة قبل أن تنفق المال على محاولة التسليم.

نصيحة احترافية: استخدم مكتبة جوجل مفتوحة المصدر libphonenumber على جانب العميل لتوحيد الأرقام والتحقق منها أثناء كتابة المستخدم. اكتشاف الأخطاء في مرحلة الإدخال يوفر استدعاءات واجهة برمجة التطبيقات ويحسن تجربة المستخدم.

الخطوة 2: توليد OTP

بمجرد أن يصبح الرقم صالحًا، تقوم واجهة برمجة التطبيقات بتوليد كلمة مرور لمرة واحدة — عادةً ما يكون رمزًا مكونًا من 4 أرقام أو 6 أرقام أو رمزًا أبجديًا رقميًا. اختيار الطول هو مفاضلة بين الأمان وتجربة المستخدم: الرموز المكونة من 4 أرقام تحتوي على 10,000 تركيبة فقط ويمكن تخمينها بالقوة الغاشمة دون تحديد معدل؛ الرموز المكونة من 6 أرقام تحتوي على مليون تركيبة وهي الافتراضي الحديث.

الأهم من ذلك، لا يتم تخزين كلمة المرور لمرة واحدة (OTP) نفسها كنص عادي. تقوم واجهة برمجة التطبيقات (API) بتشفير الرمز (عادةً باستخدام bcrypt أو scrypt أو Argon2) وتخزين التشفير (الهاش) جنبًا إلى جنب مع البيانات الوصفية: معرف التحقق، ورقم الهاتف المستهدف، والقناة المختارة، وطابع انتهاء الصلاحية (عادةً من 60 إلى 600 ثانية)، وعداد المحاولات. هذا يحمي من تسرب قواعد البيانات — حتى لو قام مهاجم بتفريغ مخزن كلمات المرور لمرة واحدة، فإن الرموز تكون عديمة الفائدة لأنها مشفرة ومحددة بوقت.

تُرجع واجهة برمجة التطبيقات (API) معرف تحقق (يُسمى أحيانًا معرف طلب أو معرف جلسة) إلى الواجهة الخلفية الخاصة بك. احفظه. ستحتاج إليه لاستدعاء نقطة نهاية التحقق عندما يُدخل المستخدم الرمز.

الخطوة 3: اختيار القناة والتسليم

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

بمجرد اختيار القناة، تختار واجهة برمجة التطبيقات مسار المشغل. داخل بلد واحد، يمكن أن يكون هناك عشرات المشغلين — مثل Airtel وJio وVi في الهند؛ وAT&T وVerizon وT-Mobile في الولايات المتحدة — ولكل منهم موثوقية وزمن استجابة وتكاليف مختلفة. تستخدم واجهات برمجة التطبيقات الحديثة للتحقق اتصالات مباشرة مع المشغلين، وتوجيهًا ذكيًا، وتحليلات تسليم في الوقت الفعلي لإرسال كل كلمة مرور لمرة واحدة (OTP) عبر المسار الأفضل أداءً في تلك اللحظة بالذات.

يتم تحديد هوية المرسل في هذه الخطوة أيضًا. تختلف معرفات مرسل الرسائل النصية القصيرة حسب البلد: تتطلب الهند رؤوسًا مسجلة في DLT، وتستخدم الولايات المتحدة رموزًا قصيرة أو طويلة 10DLC، وتتطلب الإمارات العربية المتحدة مرسلين أبجديين رقميين معتمدين من هيئة تنظيم الاتصالات (TRA)، ولدى الاتحاد الأوروبي قواعده الخاصة بكل بلد. تتعامل واجهات برمجة التطبيقات الموثوقة مع هذا التعقيد نيابة عنك (أو، حيثما أمكن، توجه عبر مسارات تسمح بالأحرف الأبجدية الرقمية لتجنب عناء التسجيل تمامًا).

أخيرًا، يتم إرسال الرسالة. يتم إطلاق رد اتصال التسليم (تقرير التسليم، أو "DLR") من المشغل في غضون ثوانٍ، مشيرًا إلى ما إذا كانت الرسالة قد تم قبولها أو تسليمها أو فشلت. تتعقب واجهات برمجة التطبيقات الجيدة تقارير DLR، وتعيد المحاولة بذكاء، وتعود إلى قنوات بديلة (الرسائل النصية القصيرة ← واتساب، أو العكس) إذا فشلت القناة الأساسية.

الخطوة 4: المستخدم يُدخل الرمز وواجهة برمجة التطبيقات تتحقق

يتلقى المستخدم الرسالة، ويُدخل كلمة المرور لمرة واحدة (OTP) في تطبيقك، ثم يرسلها. تستدعي الواجهة الخلفية الخاصة بك نقطة نهاية التحقق بمعاملين: معرف التحقق من الخطوة 2 والرمز الذي أدخله المستخدم.

تقوم واجهة برمجة التطبيقات بأربعة فحوصات: (أ) هل معرف التحقق موجود؟ (ب) هل لم تنتهِ صلاحيته؟ (ج) هل يتطابق تشفير الرمز المدخل مع التشفير المخزن؟ (د) هل لم يتجاوز عداد المحاولات الحد الأقصى (عادةً 3-5 محاولات)؟ إذا اجتازت جميع الفحوصات الأربعة، تُرجع واجهة برمجة التطبيقات استجابة "تم التحقق"، ويضع علامة على معرف التحقق بأنه مستخدم، ويمكن لنظام الواجهة الخلفية الخاص بك وضع علامة على رقم الهاتف هذا بأنه تم التحقق منه لهذا المستخدم.

إذا فشل أي تحقق، تُرجع واجهة برمجة التطبيقات رمز خطأ محددًا — code_mismatch، expired، max_attempts_exceeded — ويعرض تطبيقك رسالة مناسبة ودعوة لاتخاذ إجراء (إعادة الإرسال، تجربة رقم مختلف، إلخ).

رسائل SMS مقابل OTP عبر واتساب — مسارات مختلفة، نفس النتيجة

رسائل SMS و OTP عبر واتساب تحققان نفس الهدف ولكن من خلال مسارات مختلفة تمامًا.

مسار OTP عبر رسائل SMS

‍نظام الواجهة الخلفية الخاص بك ← واجهة برمجة تطبيقات التحقق ← مجمع رسائل SMS/CPaaS ← مشغل الهاتف المحمول ← هاتف المستخدم (عبر شبكة SS7 للاتصالات). رسائل SMS عالمية — يدعمها كل هاتف، ولا تتطلب تثبيت تطبيق. تتمثل المقايضات في ارتفاع التكلفة في بعض الأسواق، وبطء التسليم على مسارات المشغل المزدحمة، ووجود طرق هجوم موثقة جيدًا مثل تبديل بطاقة SIM واعتراض SS7.

مسار OTP عبر واتساب

‍نظام الواجهة الخلفية الخاص بك ← واجهة برمجة تطبيقات التحقق ← واجهة برمجة تطبيقات واتساب السحابية من Meta ← واتساب على هاتف المستخدم (عبر الإنترنت، مشفرة من طرف إلى طرف). OTP عبر واتساب أسرع (التسليم في أقل من ثانية أمر شائع)، وأقل تكلفة في الأسواق ذات الانتشار العالي لواتساب، ومحصنة ضد هجمات فئة SS7. المقايضات: تتطلب أن يكون لدى المستخدم واتساب مثبتًا (مرتفع في العديد من الأسواق، أقل في أسواق أخرى)، وتتطلب Meta قوالب رسائل معتمدة للمحتوى المتعلق بالمعاملات مثل OTP.

الإجابة الصحيحة في عام 2026 هي "كلاهما، مع آلية احتياطية ذكية". أرسل عبر واتساب أولاً حيث يكون الانتشار مرتفعاً؛ ثم ارجع تلقائياً إلى الرسائل النصية القصيرة (SMS) إذا فشل تسليم واتساب أو لم يقرأ المستخدم الرسالة خلال فترة قصيرة. VerifyNow تنفذ هذه الآلية الاحتياطية متعددة القنوات كمكالمة API واحدة.

التحديات الشائعة في التحقق عبر الهاتف

حتى عندما يعمل التدفق الأساسي، تواجه التطبيقات الواقعية مشاكل متكررة. أبرز خمسة:

1. فشل التسليم

‍تصفية المشغلين، ورفض معرف المرسل، وسجلات "عدم الإزعاج"، ومسارات التوجيه المزدحمة، كلها تتسبب في عدم وصول رموز OTP أبداً. بدون تحليلات التسليم، سترى انخفاضاً في التسجيل ولن تعرف السبب. الحل: اختر واجهة برمجة تطبيقات (API) تعرض معدلات نجاح التسليم لكل بلد ولكل مشغل، وتقوم بالرجوع التلقائي إلى قناة مختلفة عند الفشل.

2. احتيال ضخ الرسائل النصية القصيرة (IRSF)

‍يستخدم المهاجمون نصوصاً برمجية لتشغيل إرسال رموز OTP بشكل متكرر إلى أرقام ذات تعريفة مميزة في بلدان غير معروفة، مما يولد إيرادات للمهاجم من خلال اتفاقيات تقاسم الإيرادات مع مشغلين مشبوهين. وقد GSMA Fraud and Security Group تتبعت هذا كصناعة بمليارات الدولارات. الإجراءات الوقائية: تحديد معدل الاستخدام لكل عنوان IP، ولكل بصمة جهاز، ولكل بادئة رقم هاتف؛ استخدام كشف الشذوذ في أنماط حركة المرور؛ دع واجهة برمجة تطبيقات التحقق الخاصة بك تحظر البادئات عالية المخاطر افتراضياً.

3. تبديل شريحة SIM والاستيلاء على الحساب

‍يقوم المهاجم بإقناع مشغل الهاتف المحمول بنقل رقم الضحية إلى شريحة SIM جديدة؛ فجأة، تصل جميع رموز OTP إلى المهاجم. وقد FCC's wireless protection guidance صنفت هذا كتهديد متزايد للمستهلكين. الإجراءات الوقائية: الجمع بين رموز OTP عبر الرسائل النصية القصيرة وإشارات ربط الجهاز أو الارتقاء إلى عامل أقوى (مفتاح مرور، رمز أمان مادي) للإجراءات عالية القيمة.

4. الامتثال عبر الحدود

‍DLT الهندية، و10DLC الأمريكية، وTRA الإماراتية، وقواعد موافقة GDPR للاتحاد الأوروبي — لكل سوق رئيسي إطاره الخاص الذي يحدد من يمكنه إرسال أي نوع من الرسائل وكيف يجب وضع علامة عليها. الحل: استخدام واجهة برمجة تطبيقات للتحقق (API) تتولى التسجيل ووضع العلامات نيابة عنك، أو تقوم بالتوجيه عبر مرسلين متوافقين ومعتمدين مسبقًا.

5. خطأ المستخدم وإعادة استخدام الرمز

‍يخطئ المستخدمون في الكتابة، أو يلصقون رمزًا خاطئًا، أو يطلبون عدة رموز OTP ويستخدمون رمزًا قديمًا، أو يضغطون على زر الرجوع. الحل: تصميم تجربة مستخدم واضحة (UX) (التعبئة التلقائية من الرسائل النصية حيثما كان ذلك مدعومًا، وحقول إدخال سهلة اللصق، ومؤقت "إعادة الإرسال خلال 30 ثانية") والتأكد من أن واجهة برمجة التطبيقات (API) الخاصة بك تتعامل مع "رمز OTP منتهي الصلاحية" بسلاسة دون ظهور خطأ مربك.

أفضل الممارسات لتطبيق تحقق موثوق

تلخيص ما سبق في قائمة مرجعية يمكن لفريق الهندسة الخاص بك العمل بها:

استخدم رموزًا مكونة من 6 أرقام افتراضيًا

‍الرموز المكونة من 4 أرقام سهلة الاختراق بالقوة الغاشمة دون تحديد صارم لمعدل المحاولات. الرموز المكونة من 8 أرقام أو أكثر تزعج المستخدمين دون تحقيق مكاسب أمنية إضافية كبيرة.

عيّن صلاحية رمز OTP بين 3 و 10 دقائق

‍إذا كانت قصيرة جدًا (أقل من 60 ثانية) فإن الشبكات البطيئة تحبط المستخدمين. إذا كانت طويلة جدًا (أكثر من 30 دقيقة) فإن الرموز المسروقة من تسريبات لقطات الشاشة تصبح خطرًا حقيقيًا.

حدد عدد المحاولات بـ 3–5

‍قفل الحساب بعد عدد قليل جدًا من المحاولات يضر بتجربة المستخدم (UX)؛ بينما السماح بعدد كبير جدًا يدعو إلى هجمات القوة الغاشمة.

حدد معدل المحاولات لكل رقم، ولكل عنوان IP، ولكل جهاز

‍ثلاثة حدود مستقلة لمعدل المحاولات توقف معظم عمليات الاحتيال واسعة النطاق في مهدها.

أرسل دائمًا عبر القناة الأنسب للمستخدم أولاً

‍بالنسبة للأسواق الناضجة، هذا يعني استخدام واتساب قبل الرسائل النصية القصيرة (SMS) في أسواق مثل الهند والبرازيل. يجب أن يكون الحل البديل تلقائيًا وغير مرئي للمستخدم.

طبّق استرجاع الرسائل النصية القصيرة (SMS) التلقائي حيثما أمكن

‍نظام أندرويد SMS Retriever API وميزة التعبئة التلقائية من الرسائل في نظام iOS تتيح للمستخدمين تخطي كتابة الرمز بالكامل — مما يحسن معدل التحويل بشكل ملموس.

سجّل كل محاولة تسليم مع القناة والمسار وزمن الاستجابة والنتيجة

‍بدون بيانات القياس عن بعد هذه، لا يمكنك معرفة ما إذا كانت مشكلة التسليم عبارة عن خطأ برمجي، أو حدث احتيال، أو انقطاع خدمة من قبل المشغل.

اختبر على مستخدمين حقيقيين في أسواقك الثلاثة الرئيسية قبل الإطلاق عالميًا

‍تختلف قواعد معرف المرسل وخصوصيات المشغلين وانتشار واتساب كثيرًا من بلد لآخر، لدرجة أن عبارة "إنه يعمل في الولايات المتحدة" لا تخبرك شيئًا تقريبًا عما إذا كان سيعمل في إندونيسيا.

أسئلة شائعة

ما هي مدة صلاحية الرمز لمرة واحدة (OTP)؟‍

النطاق المقبول يتراوح بين 3 و10 دقائق، مع اعتبار 5 دقائق كإعداد افتراضي معقول. فترات الصلاحية الأقصر تقلل من نافذة الهجمات التي تستهدف سرقة الرموز لمرة واحدة، لكنها تزيد من إحباط المستخدمين عند بطء تسليم الرسائل النصية القصيرة؛ أما فترات الصلاحية الأطول فتفعل العكس. NIST SP 800-63B يوصي بأدوات مصادقة قصيرة الأجل لسياقات الضمان الأعلى.

ماذا يحدث إذا لم يستلم المستخدم كلمة المرور لمرة واحدة (OTP)؟‍

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

لماذا يتم تسليم بعض كلمات المرور لمرة واحدة (OTPs) في ثوانٍ بينما تستغرق أخرى دقيقة؟‍

يعتمد زمن استجابة التسليم على مسار المشغل، وازدحام شبكة الرسائل القصيرة في بلد الوجهة، وسمعة معرف المرسل، وما إذا كان المسار مباشرًا (مملوكًا للمشغل) أو مجمعًا (العديد من مجمعي الرسائل القصيرة بينك وبين شركة الاتصالات). عادةً ما يتم التسليم عبر المسارات المباشرة والمميزة في غضون 1-3 ثوانٍ؛ بينما قد تستغرق سلاسل المجمعين الطويلة أكثر من 30 ثانية في أسوأ الحالات.

هل يمكن تجاوز التحقق عبر الهاتف؟‍

نعم، من قبل المهاجمين الذين يتحكمون في الرقم المستهدف — غالبًا عن طريق احتيال تبديل بطاقة SIM أو عن طريق اعتراض إشارات SS7. كلمة المرور لمرة واحدة عبر الرسائل القصيرة (SMS OTP) لم تعد تُعتبر مصادقة قوية بمفردها. بالنسبة للإجراءات عالية القيمة، ادمج كلمة المرور لمرة واحدة (OTP) مع المصادقة القائمة على المخاطر (بصمة الجهاز، تحديد الموقع الجغرافي لعنوان IP، الإشارات السلوكية) أو انتقل إلى عامل أقوى مثل مفتاح المرور أو رمز الأجهزة.

كيف تمنع واجهات برمجة التطبيقات (APIs) للتحقق احتيال ضخ الرسائل القصيرة (SMS pumping fraud)؟‍

تجمع واجهات برمجة التطبيقات الموثوقة بين دفاعات متعددة: تحديد معدل الطلبات لكل عنوان IP ولكل رقم، واكتشاف الشذوذ في أنماط حركة المرور (الارتفاعات المفاجئة إلى بادئات دول معينة هي علامة حمراء)، والحظر التلقائي للبادئات المعروفة ذات الأسعار المميزة، وتحديات CAPTCHA أو ما شابهها قبل إرسال كلمة المرور لمرة واحدة (OTP). VerifyNow توفر هذه الحمايات بشكل افتراضي.

هل أنت مستعد لبناء تدفق التحقق الخاص بك؟

إذا كنت تقوم بدمج التحقق من رقم الهاتف لأول مرة — أو تستبدل تطبيقًا داخليًا غير مستقر — فإن أسرع طريقة للتحقق من الأداء الشامل هي الاختبار على قاعدة المستخدمين الخاصة بك. اشترك في VerifyNow للحصول على رصيد تجريبي مجاني بدون الحاجة لبطاقة ائتمان، مع دعم الرسائل النصية (SMS) والواتساب والمكالمات الصوتية كخيار احتياطي ضمن واجهة برمجة تطبيقات (API) واحدة، بالإضافة إلى مسارات مشغل مباشرة في أكثر من 200 دولة.

‍