تدفق مستخدم المصادقة

نظرة عامة

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

المصادقة هي إدخال لطرق أخرى. ويخص associateAccount وcapture. وهذا يعني أنه يتم استخدام إثبات المصادقة كإدخال (مَعلمة) لهاتين الطريقتين.

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

ضع في اعتبارك أنه أثناء عملية الإعداد، ستتعاون Google معك لاختيار آلية المصادقة التي تناسب منتجك على أفضل وجه.

آلية عمل التدفق

هناك طريقتان لمصادقة المستخدم، لكل منهما مساره الخاص. عند إتمام عملية الدمج، يجب أن تحدّد الشركة التي سيتم دمجها.

  1. مصادقة إعادة التوجيه
  2. مصادقة الرسائل القصيرة SMS-MT OTP

مصادقة إعادة التوجيه

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

  1. تعيد Google توجيه المستخدم إلى الويب أو إلى تطبيق Android الخاص بالشركة لإجراء عملية المصادقة حيث يمكن المصادقة عليهما.
  2. للمصادقة، يتم استخدام requestId للمصادقة (من AuthenticationRequest) كإثبات للمصادقة.
  3. ينتج عن ذلك رد موقَّع، يُطلق عليه اسم AuthenticationResponse.
  4. وبعد ذلك، يُعيد التطبيق أو الموقع الإلكتروني توجيه المستخدم إلى Google مرة أخرى.

تستخدم مصادقة إعادة التوجيه طريقة HTTP GET، مع معلمات مشفرة في عنوان URL لتطبيق ويب. ويستخدم Android Intent لمصادقة تطبيق Android. لمزيد من التفاصيل حول الترميز، اطّلِع على مصادقة الويب. وبالنسبة إلى مَعلمات Android intent، يمكنك الاطّلاع على مصادقة Android.

النتيجة من كل من آليات المصادقة هذه هي استجابة موقَّعة تُسمى AuthenticationResponse. يجب أن يتضمّن هذا الغرض رسالة مصادقة Google العادية المشفرة والمشفّرة (gspAuthenticationResponse) للإبلاغ عن عملية مصادقة ناجحة. في حال استخدام الوضع المستقل، يتم استخدام gspResult والتوقيع لتحديد المصادقة الناجحة.

يوضِّح مخطّط التسلسل التالي التفاعل بين متصفّح المستخدم وGoogle وتطبيق الويب لخدمة عملية الدمج:

مسار مصادقة الويب لإعادة التوجيه

مسار مصادقة الويب

فيما يلي قائمة بالكائنات وما تمثله:

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

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

  1. تنشئ واجهة مستخدم Google عنوان URL للمصادقة يتم إرساله إلى خادم Google (الخلفية). وهذا ما يؤدي إلى تشغيل عملية المصادقة.
  2. ينشئ خادم Google طلب مصادقة (AuthenticationRequest).
  3. طلب المصادقة الذي تم إرساله إلى واجهة مستخدم Google.
  4. وسيتلقّى المستخدم رسالة تطلب منه مصادقة مستند تعريف الهوية لدى الشركة المتعهّدة.
  5. يرد المستخدم على أنه يريد المصادقة، ما يؤدي إلى إرسال الرسالة إلى الموقع الإلكتروني الخاص بالجهة.
  6. يطلب الموقع الإلكتروني للمسؤول عن دمج الدفعات إثبات هوية المستخدم.
  7. يقدّم المستخدم إثباتًا عن هويته يتم إرساله إلى الموقع الإلكتروني لشركة تكامل الدفع.
  8. يرسل مسؤول عملية الدمج ردًا (authenticationResponse) على الدليل الذي تم تقديمه (باستخدام authenticationResponse التي تم ترميزها في الرسالة).
  9. يتم إرسال عنوان URL للاستجابة هذا إلى المستخدم.
  10. يتم إرسال عنوان URL للردّ على الفور من المستخدم إلى واجهة مستخدم Google.
  11. ترسل واجهة مستخدم Google الاستجابة إلى خادم Google.
  12. يفسر خادم Google الاستجابة على أنها تم التحقق منها.

يوضِّح الرسم البياني التالي للتسلسل التفاعل بين هاتف المستخدم وGoogle وتطبيق Android الخاص بالجهة المسؤولة عن عملية الدمج:

إعادة التوجيه - مسار مصادقة تطبيقات Android

مسار مصادقة تطبيقات Android

إليك الكائنات وما تمثله:

  • المستخدم: هو الشخص الذي يريد إضافة طريقة دفع إلى حسابه على Google.
  • واجهة مستخدم Google: في هذه الحالة، واجهة التطبيق التي يبدأ فيها العميل بإعداد طريقة دفع.
  • خادم Google: خادم الخلفية في Google الذي يُجري فحص المصادقة، إلى جانب مهام المصادقة الأخرى
  • حزمة APK لخدمة تكامل الدفعات: تطبيق وحدة الدمج الذي يمكن للمستخدم من خلاله الوصول إلى حساب الشركة المتعهّدة.
  • خادم أداة دمج الدفعات: الخادم الخلفي لشركة الدمج حيث يتم تخزين معلومات المستخدم.

بما أنّ عملية المصادقة هذه تستند إلى عملية المصادقة، نفترض أنّ المستخدم يستخدم تطبيقًا (واجهة مستخدم Google) ويحاول إضافة طريقة دفع. هنا تبدأ عملية الإعداد.

  1. تنشئ واجهة مستخدم Google طلب مصادقة يتم إرساله إلى خادم Google (الخلفية).
  2. يُنشئ خادم Google طلب مصادقة (AuthenticationRequest).
  3. يرسل خادم Google ملف APK للمكالمات إلى واجهة مستخدم Google (التطبيق)، ويطلب المصادقة.
  4. ترسِل واجهة مستخدم Google معلومات المستخدم إلى حزمة APK لخدمة Payment Integrator (AUTHENTICATE_V1(authReq)).
  5. ترسِل حزمة APK التابعة لشركة تكامل الدفعات الطلب (authReq) إلى خادم هذه الشركة.
  6. يرسل خادم وحدة تكامل الدفعات تحديًا مرة أخرى إلى حزمة APK لشركة تكامل الدفعات.
  7. تعيد حزمة APK لأداة دمج الدفع إرسال التحدي إلى المستخدم.
  8. ويقدّم المستخدم إثباتًا لهويته والذي يتم إرساله إلى حزمة APK لخدمة دمج الدفعات.
  9. يتم بعد ذلك إرسال هذا الإثبات إلى خادم تكامل الدفعات.
  10. ينشئ الخادم authenticationResponse مُوقَّعة.
  11. اكتملت استجابة المصادقة بنجاح، ويتم إرسال رسالة authResp إلى حزمة APK لأداة دمج الدفعات.
  12. يتم إرسال رسالة النجاح (authResp) من حزمة APK لخدمة Payment Integrator إلى واجهة مستخدم Google.
  13. ترسل واجهة مستخدم Google الاستجابة إلى خادم Google.
  14. ويفسّر خادم Google الاستجابة الناجحة.

مصادقة SMS-MT OTP

هناك طريقة أخرى للمصادقة، وهي خدمة الرسائل القصيرة، التي يتم إنهاؤها من خلال الجوّال، وكلمة المرور التي تُستخدَم لمرة واحدة (SMS-MT OTP). وتستعين هذه الآلية برقم هاتف المستخدم لإرسال كلمة مرور لمرة واحدة إليه لإجراء المصادقة. تطلب Google من الشركة المتعهّدة إرسال كلمة مرور صالحة لمرة واحدة (OTP) إلى رقم هاتف المستخدم. وبعد تلقّيها وإدراجها في واجهة Google، سيتم التحقّق من المستخدم.

يتضمّن ذلك الخطوات التالية:

  1. تطلب واجهة المستخدم من Google من المستخدم إدخال رقم الهاتف الذي سبق أن تم تسجيله في عملية الدمج.
  2. يُدخِل المستخدم رقم هاتف في واجهة مستخدم Google.
  3. تشغِّل Google الشركة المتعهّدة (تسمى طريقة sendOtp) لإرسال كلمة المرور لمرة واحدة (OTP) إلى المستخدم.
  4. يتلقى المستخدم الرسالة القصيرة SMS التي تحتوي على كلمة المرور لمرة واحدة (OTP).
  5. بعد ذلك، يُدخِل المستخدم كلمة المرور لمرة واحدة (OTP) (التي يتم استخدامها كإدخال لعناصر capture وassociateAccount وverifyOtp) التي تلقّاها في واجهة Google، ما يؤدي إلى مصادقة المستخدم. هذا دليل على المصادقة.

في الوضع المستقل، سيتم طلب الإجراء verifyOtp فقط للتحقّق من قيمة كلمة المرور لمرة واحدة (OTP).

يوضّح مخطّط التسلسل التالي التفاعل بين هاتف المستخدم وGoogle والجهة المتعهّدة عند إرسال كلمة مرور لمرة واحدة (OTP):

مسار مصادقة الهاتف (إرسال كلمة المرور لمرة واحدة)

مسار مصادقة الهاتف (OTP)

فيما يلي قائمة بالكائنات في الرسم التخطيطي وما تمثله:

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

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

  1. تطلب واجهة مستخدم Google (الهاتف أو الموقع الإلكتروني) من المستخدم تقديم رقم هاتفه.
  2. يُدخِل المستخدم رقم هاتفه في واجهة مستخدم Google.
  3. ترسل واجهة مستخدم Google الرقم (sendChallenge(phoneNum)) إلى خادم Google.
  4. يرسل خادم Google طلبًا إلى خادم دمج الدفعات (SendOtp(phoneNum)) لإرسال كلمة مرور لمرة واحدة.
  5. يرسل خادم تكامل الدفع كلمة مرور لمرة واحدة (OTP) إلى المستخدم.
  6. يستجيب خادم تكامل الدفعات لطلب Google رقم 5، للإشارة إلى أنه تم إرسال كلمة المرور لمرة واحدة (OTP) بنجاح.
  7. يُدخِل المستخدم كلمة المرور هذه لمرة واحدة (OTP) هذه في واجهة مستخدم Google (الهاتف أو الموقع الإلكتروني).
  8. وترسل واجهة مستخدم Google كلمة المرور لمرة واحدة (OTP) إلى خادم Google حيث يتم إرسالها في النهاية إلى وحدة تكامل الدفع لإثبات صحتها. يؤدي ذلك إلى التحقق من هوية المستخدم والمصادقة على المستخدم.

المصادقة وإعادة المصادقة

هناك نقطتان يمكن أن تحدث فيهما المصادقة:

  1. المصادقة الأولية: تُستخدَم لتحديد مستخدم ومصادقته. يتم استخدام المصادقة الأولية كإدخال في طريقة associateAccount.
  2. إعادة المصادقة: مستخدَمة في جميع السياقات الأخرى، مثلاً بشكل مستقل أو كإدخال في capture.

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

خلال هذه العملية، يتم تقديم مرجع، يُسمى associationId، إلى عملية الربط الأصلية (من عملية الربط). ويتم توفير ذلك من خلال طلب إجراء associateAccount أثناء عملية الربط. وتحدّد السمة associationId الحساب الذي يجب تقديم طلب إعادة نظر بشأنه. لدواعي الأمان، يجب ألا يتمكن المستخدم من تغيير الحساب الذي يتم اختباره.

لإعادة مصادقة الرسائل القصيرة SMS-MT OTP، تحتفظ Google برقم الهاتف الذي تم تقديمه أثناء المكالمة الأصلية إلى sendOtp كرقم ثابت. لا يمكن تغيير هذا الإعداد مرة أخرى لأسباب تتعلق بالأمان.

في ما يلي مثال على الخطوات التي تقرّر فيها Google الاعتراض (إعادة المصادقة) قبل إجراء عملية الشراء:

مسار إعادة المصادقة

مسار إعادة المصادقة

فيما يلي قائمة الكائنات وما تمثله:

  • المستخدِم: وهو الشخص الذي يريد إجراء عملية شراء.
  • واجهة مستخدم Google: في هذه الحالة، موقع إلكتروني من Google أو تطبيق هاتف يبدأ من خلاله العميل بإجراء عملية الشراء.
  • واجهة مستخدم وحدة تكامل الدفعات: الموقع الإلكتروني أو التطبيق الموجّه للعميل والذي يمكن للمستخدم من خلاله الوصول إلى معلومات حسابه مع الشركة المتعهّدة.
  • خادم Google: خادم الخلفية في Google الذي يُجري فحص إعادة المصادقة، إلى جانب المهام الأخرى
  • خادم أداة دمج الدفعات: الخادم الخلفي لشركة الدمج حيث يتم تخزين معلومات المستخدم.

وتبدأ عملية إعادة المصادقة عندما يبدأ العميل في إجراء عملية شراء. يؤدي ذلك إلى إعداد تدفق لإعادة مصادقة المستخدم.

  1. يقرر المستخدم شراء عنصر أو خدمة.
  2. ويتم إرسال الطلب من واجهة مستخدم Google إلى خادم Google.
  3. يرسل خادم Google طلب مصادقة (authenticationRequest) مرة أخرى إلى واجهة مستخدم Google.
  4. ترسل واجهة مستخدم Google طلبًا إلى واجهة المستخدم في "جهة تكامل الدفعات" لمصادقة (associationId، authenticationRequest) المستخدم.
  5. تبحث واجهة المستخدم في Payment Integrator عن المستخدم لإثبات هويته (LookupIdentity(associationId)).
  6. تطلب واجهة المستخدم الخاصة بالوحدة من المستخدم تقديم بيانات الاعتماد في واجهة المستخدم (الموقع الإلكتروني أو التطبيق الخاص بالشركة).
  7. يتم إرسال ردّ المصادقة إلى خادم "أداة دمج الدفعات".
  8. يتم إرسال ردّ المصادقة الموقَّع (authenticationResponse) مرة أخرى إلى واجهة مستخدم خدمة تكامل الدفعات.
  9. يتم إرسال ردّ المصادقة (authenticationResponse) من واجهة مستخدم خدمة تكامل الدفعات إلى واجهة مستخدم Google.
  10. ترسِل واجهة مستخدم Google الرد الذي يتضمّن معلومات الشراء إلى خادم Google.
  11. يرسل خادم Google رسالة capture (للعثور على الأموال المتاحة) إلى خادم دمج الدفعات (authenticationRequestId، GPT، المبلغ).
  12. يرسل خادم مسؤول عن دمج الدفعات رسالة نجاح إلى خادم Google.
  13. يرسل خادم Google رسالة نجاح إلى واجهة مستخدم Google.
  14. وتسلِّم واجهة مستخدم Google السلع إلى العميل (أو تُعلِمه بأنّه سيتم تسليمها قريبًا).

مصادقة SMS-MO

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

مسار مصادقة الرسائل القصيرة SMS-MO

فيما يلي قائمة بالكائنات في الرسم التخطيطي وما تمثله:

  • المستخدم: هو الشخص الذي يريد إضافة طريقة دفع إلى حسابه على Google.
  • جهاز/واجهة مستخدم Google: في هذه الحالة، تطبيق هاتف من Google حيث يبدأ العميل بإعداد طريقة دفع.
  • Google Server: خادم الخلفية في Google الذي ينشئ تعليمات الرسائل القصيرة (SMS) باستخدام مُعرِّف طلب المصادقة (ARID) ويتلقى نتيجة المصادقة من مسؤول عملية الدمج.
  • خادم أداة تكامل الدفعات: الخادم الخلفي لشركة الدمج الذي يتلقى رسائل SMS للمصادقة ويعيد رقم تعريف طلب المصادقة إلى Google.

بما أنّ عملية المصادقة هذه تستند إلى عملية المصادقة، نفترض أنّ المستخدم يستخدم تطبيقًا (واجهة مستخدم Google) ويحاول إضافة طريقة دفع. هنا تبدأ عملية الإعداد.

  1. يختار المستخدم أداة محوَّلة إلى رمز مميّز لإضافتها.
  2. تستدعي واجهة مستخدم Google خادم Google لبدء تحدي SMS-MO.
  3. يعرض خادم Google تعليمات الرسائل القصيرة SMS التي تتكون من وجهة ونص يحتوي على رقم تعريف طلب المصادقة.
  4. وترسل واجهة مستخدم Google الرسائل القصيرة إلى شركة تكامل الدفعات.
  5. يستدعي خادم خدمة تكامل عمليات الدفع نقطة النهاية abuseResultNotification على خادم Google باستخدام رقم تعريف طلب المصادقة.
  6. يتم التحقق من صحة رقم تعريف طلب المصادقة عن طريق خادم Google، الذي يستجيب بنجاح.
  7. تستدعي واجهة مستخدم Google خادم Google للحصول على نتيجة محاولة المصادقة.
  8. استجابة خادم Google SUCCESS.

مصادقة الرسائل القصيرة SMS-MO التي تمت محاكاتها

لأغراض إجراء اختبارات تشخيصية لتدفق مصادقة SMS-MO، تُحدِّد Google نقطة نهاية محاكاة الرسائل القصيرة SMS. يغنيك ذلك عن الحاجة إلى إرسال رسالة قصيرة SMS حقيقية والتحقق من صحتها عند إجراء عمليات ربط تجريبية في بيئة وضع الحماية.

مسار مصادقة الرسائل القصيرة SMS-MO التي تمت محاكاتها

فيما يلي قائمة بالكائنات في الرسم التخطيطي وما تمثله:

  • المختبِر: وهو الشخص الذي يبدأ اختبار تشخيص الربط بإرسال الرسائل القصيرة SMS-MO.
  • واجهة مستخدم Google: واجهة مستخدم Google حيث يبدأ المختبِر ويراقب حالة اختبار تشخيص SMS-MO.
  • خادم Google: خادم الخلفية في Google الذي ينشئ تعليمات الرسائل القصيرة باستخدام رقم تعريف طلب المصادقة (ARID)، ويرسل رسالة SMS التي تمت محاكاتها ويتلقى نتيجة المصادقة من مسؤول عملية الدمج.
  • خادم وحدة تكامل الدفعات: الخادم الخلفي لشركة الدمج الذي يتلقى الرسائل القصيرة SMS للمصادقة التي تمت محاكاتها ويعرض رقم تعريف طلب المصادقة إلى Google.

الخطوات في هذا المسار هي:

  1. يبدأ المختبِر اختبار التشخيص للرسائل القصيرة SMS-MO من خلال تقديم رقم تعريف مشترك الاختبار (SID) لاستخدامه في الاختبار. وسيتم تضمين معرّف SID هذا في المكالمة simulateSms المُرسلة إلى جهة تكامل الدفع.
  2. تستدعي واجهة مستخدم Google خادم Google لبدء تحدي SMS-MO.
  3. يعرض خادم Google تعليمات الرسائل القصيرة SMS التي تتكون من وجهة ونص يحتوي على رقم تعريف طلب المصادقة. لأغراض هذا الاختبار، سيتم إلغاء الوجهة من خلال اتصال HTTPS في وضع الحماية لدى "جهة تكامل الدفع".
  4. تستدعي واجهة مستخدم Google خادم Google لإرسال رسالة SMS التي تمت محاكاتها.
  5. يتم إجراء طلب simulateSms من خادم Google إلى خادم Payment Integrator Server. ويتم تضمين كلّ من "معرّف طلب المصادقة" و"معرّف المشترِك" (كما هو موضَّح في الخطوة 1) في طلب البيانات من واجهة برمجة التطبيقات.
  6. يردّ خادم تكامل الدفعات على ACKNOWLEDGED.
  7. يستجيب خادم Google بنجاح إلى واجهة مستخدم Google.
  8. يستدعي خادم خدمة تكامل عمليات الدفع نقطة النهاية abuseResultNotification على خادم Google باستخدام رقم تعريف طلب المصادقة.
  9. يستجيب خادم Google بنجاح.
  10. تستدعي واجهة مستخدم Google خادم Google للحصول على نتيجة محاولة المصادقة.
  11. يستجيب خادم Google بـ "مكتمل".
  12. تستدعي واجهة مستخدم Google خادم Google لتنفيذ محاولة ربط.
  13. يتم إجراء طلب associateAccount من خادم Google إلى خادم Payment Integrator Server.
  14. يردّ خادم تكامل عمليات الدفع بنجاح على المشكلة.
  15. يستجيب خادم Google بنجاح.
  16. يتم تعديل واجهة المستخدم من Google لتوضح للمختبِر أنّ اختبار التشخيص عن طريق SMS-MO قد أكمل بنجاح.

أفضل الممارسات والاعتبارات الأخرى

اختيار المنصات

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