يمكن الآن لواجهة برمجة التطبيقات WebOTP API تلقّي كلمات المرور التي تُستخدَم لمرة واحدة من داخل إطارات iframe.
تُستخدَم عادةً كلمات المرور لمرة واحدة (OTP) المرسَلة عبر الرسائل القصيرة SMS لإثبات ملكية أرقام الهواتف، مثلاً كخطوة ثانية في المصادقة أو لإثبات ملكية الدفعات على الويب. مع ذلك، فإنّ التبديل بين المتصفّح وتطبيق الرسائل القصيرة SMS أو النسخ واللصق أو إدخال كلمة المرور لمرة واحدة (OTP) يدويًا يُسهّل ارتكاب الأخطاء ويؤثر سلبًا في تجربة المستخدم.
إنّ WebOTP API تتيح للمواقع الإلكترونية إمكانية الحصول آليًا على كلمة المرور التي تُستخدَم لمرة واحدة من رسالة SMS وإدخالها تلقائيًا في شكلها للمستخدمين بنقرة واحدة فقط بدون تبديل التطبيق. ويتم تنسيق رسالة SMS بشكل خاص وربطها بمصدر البيانات، ما يحدّ من احتمالات سرقة كلمة المرور لمرة واحدة من قِبل المواقع الإلكترونية أيضًا.
إحدى حالات الاستخدام التي لم يتم دعمها بعد في WebOTP هي استهداف مصدر داخل إطار iframe. ويُستخدَم هذا الإجراء عادةً لتأكيد الدفع، خاصةً باستخدام 3D Secure. تتميّز واجهة WebOTP API الآن بالتنسيق الشائع لإتاحة إطارات iframe من مصادر متعددة، وأصبحت الآن ترسل كلمات المرور لمرة واحدة (OTP) المرتبطة بمصادر مدمجة، بدءًا من Chrome 91.
آلية عمل واجهة برمجة التطبيقات WebOTP
إنّ WebOTP API نفسها بسيطة بما يكفي:
…
const otp = await navigator.credentials.get({
otp: { transport:['sms'] }
});
…
يجب تنسيق رسالة SMS باستخدام الرموز لمرة واحدة والمرتبطة بالمصدر.
Your OTP is: 123456.
@web-otp.glitch.me #12345
يُرجى ملاحظة أنّ السطر الأخير يحتوي على المصدر الذي سيتم ربطه به مسبوقًا برمز @
يليه رمز OTP مسبوقًا برمز #
.
عند وصول الرسالة النصية، ينبثق شريط معلومات يطلب من المستخدم
إثبات ملكية رقم هاتفه. بعد أن ينقر المستخدم على الزر Verify
، يعيد المتصفّح توجيه كلمة المرور لمرة واحدة تلقائيًا إلى الموقع الإلكتروني ويحلّ navigator.credentials.get()
. يمكن للموقع الإلكتروني بعد ذلك استخراج رمز OTP وإكمال
عملية إثبات الملكية.
تعرَّف على أساسيات استخدام WebOTP في مقالة إثبات ملكية أرقام الهواتف على الويب باستخدام واجهة برمجة التطبيقات WebOTP API.
حالات استخدام إطارات iframe مشتركة المصدر
إنّ إدخال كلمة مرور صالحة لمرة واحدة في نموذج داخل إطار iframe من مصدر مختلف هو أمر شائع في سيناريوهات الدفع. تتطلّب بعض جهات إصدار بطاقات الائتمان خطوة تحقّق إضافية لتحقق من هوية المدفوع له. وهذا ما يسمى بالتصميم الثلاثي الأبعاد ويتم عرض النموذج عادةً داخل إطار iframe على الصفحة نفسها كما لو كان جزءًا من تدفق الدفع.
على سبيل المثال:
- يزور مستخدم الموقع الإلكتروني
shop.example
لشراء حذاء باستخدام بطاقة ائتمان. - بعد إدخال رقم بطاقة الائتمان، يعرض مقدّم خدمة الدفع المدمج
bank.example
نموذجًا في إطار iframe يطلب من المستخدم إثبات ملكية رقم هاتفه من أجل إتمام الدفع بسرعة. - يرسل تطبيق "
bank.example
" رسالة قصيرة SMS تحتوي على كلمة المرور لمرة واحدة إلى المستخدم حتى يتمكّن من إدخاله لإثبات هويته.
كيفية استخدام واجهة برمجة التطبيقات WebOTP API من إطار iframe متعدد المصادر
لاستخدام WebOTP API من داخل إطار iframe من مصدر مختلف، عليك تنفيذ أمرين:
- أضِف تعليقات توضيحية على كلّ من مصدر الإطار العلوي ومصدر iframe في محتوى الرسالة القصيرة.
- يمكنك إعداد سياسة الأذونات للسماح لإطار iframe متعدد المصادر بتلقّي كلمة المرور لمرة واحدة من المستخدم مباشرةً.
يمكنك تجربة الإصدار التجريبي بنفسك على الرابط https://web-otp-iframe-demo.stackblitz.io.
إضافة تعليقات توضيحية إلى المصادر المرتبطة بالرسالة النصية القصيرة SMS
عند استدعاء WebOTP API من داخل إطار iframe، يجب أن تشمل الرسالة النصية عبر الرسائل القصيرة
مصدر الإطار العلوي مسبوقًا برمز @
متبوعًا برمز OTP مسبوقًا برمز #
متبوعًا بمصدر إطار iframe مسبوقًا برمز @
.
@shop.example #123456 @bank.exmple
إعداد سياسة الأذونات
لاستخدام WebOTP في إطار iframe من مصدر مختلف، على مُدرِج المحتوى منح إذن الوصول إلى واجهة برمجة التطبيقات هذه من خلال سياسة أذونات بيانات اعتماد otp لتجنُّب أي سلوك غير مقصود. بشكل عام، هناك طريقتان لتحقيق هذا الهدف:
- من خلال عنوان HTTP:
Permissions-Policy: otp-credentials=(self "https://bank.example")
- من خلال سمة iframe
allow
:
<iframe src="https://bank.example/…" allow="otp-credentials"></iframe>
اطّلِع على مزيد من الأمثلة عن كيفية تحديد سياسة أذونات .
المحاذير
مستويات التداخل
في الوقت الحالي، لا يدعم Chrome سوى طلبات البيانات من واجهة برمجة التطبيقات WebOTP API من إطارات iframe متعددة المصادر والتي ليس لها أكثر من مصدر فريد في سلسلة الكيانات الأصلية. في السيناريوهات التالية:
- a.com -> b.com
- a.com -> b.com -> b.com
- a.com -> a.com -> b.com
- a.com -> b.com -> c.com
إنّ استخدام WebOTP في b.com متاح، ولكنّ استخدامه في c.com غير متاح.
يُرجى العلم أنّ السيناريو التالي غير متاح أيضًا بسبب نقص الطلب وتعقيدات تجربة المستخدم.
- a.com -> b.com -> a.com (يُجري طلبات بيانات من واجهة برمجة التطبيقات WebOTP API)
إمكانية التشغيل التفاعلي
على الرغم من أنّ محرّكات المتصفّحات غير Chromium لا تُنفِّذ WebOTP API،
يستخدم Safari تنسيق الرسائل القصيرة
نفسه مع ميزة input[autocomplete="one-time-code"]
. في Safari، بعد وصول رسالة
قصيرة تتضمّن تنسيق رمز مُحدَّد المصدر لمرة واحدة مع مصدر
مطابق، تقترح لوحة المفاتيح إدخال الرمز المُحدَّد لمرّة واحدة في حقل الإدخال.
اعتبارًا من نيسان (أبريل) 2021، يتيح Safari استخدام iframe مع تنسيق SMS فريد باستخدام
%
.
ومع ذلك، وبعد انتهاء مناقشة المواصفات مع @
بدلاً من ذلك، نأمل أن يتقارب استخدام تنسيق الرسائل القصيرة SMS المتوافق.
ملاحظات
إنّ ملاحظاتك قيّمة جدًا في تحسين WebOTP API، لذا ننصحك بتجربة هذه الواجهة وإعلامنا برأيك.
الموارد
- إثبات ملكية أرقام الهواتف على الويب باستخدام واجهة برمجة التطبيقات Web OTP
- أفضل الممارسات المتعلّقة بنموذج كلمة المرور لمرة واحدة (OTP) عبر الرسائل القصيرة
- WebOTP API
- يتم إرسال الرموز لمرة واحدة والمرتبطة بنقطة الشحن عبر رسالة SMS
الصورة مقدمة من rupixen.com على Unsplash