توفير تجربة تسجيل دخول سلسة وبيانات اعتماد رقمية على Android

مرحبًا،

وشكرًا على انضمامكم إلينا اليوم.

يسرّنا اليوم التحدّث عن مستقبل المصادقة والهوية الرقمية.

اسمي "توم كولفين".

أنا رئيس قسم التكنولوجيا في Apptaura، وخبير Google معتمَد في Android، وينضم إليّ "تشيبينغ ييه"، وهو كبير مهندسي علاقات مطوّري برامج Android في Google.

انتهى عصر كلمات المرور التقليدية.

أو على الأقل، يجب أن يكون كذلك.

سأتحدث إليكم اليوم عن عالم بلا كلمات مرور.

تُعد كلمات المرور ثغرة أمنية معروفة في البنية الأساسية للأمان.

وحتى عند تخزينها بشكل آمن، تكون عرضة للتصيّد الاحتيالي واختراقات الخوادم والهجمات الآلية، مثل حشو بيانات الاعتماد.

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

وتشير الأدلة إلى أنّ هذه الطريقة قد فشلت، ويرجع ذلك جزئيًا إلى أنّه كلما زادت صعوبة كلمة المرور، زاد تشجيعك على السلوك غير الآمن، وهذا أمر متناقض.

لأنّ كلمة المرور المعقّدة التي يتم تغييرها بانتظام من المرجّح أن يتم تدوينها على ورقة ملاحظات لاصقة.

وحتى المصادقة الثنائية المستندة إلى الرسائل القصيرة أثبتت أنّها عرضة للاعتراض، مثل تبديل شريحة SIM.

ومع ذلك، تم حل هذه المشكلة إلى حد كبير اليوم.

تستند مفاتيح المرور إلى معايير FIDO وتستخدم تشفير المفتاح العام والخاص.

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

بياننا اليوم بسيط.

حان الوقت للانتقال إلى عالم بلا كلمات مرور.

والأدوات اللازمة لذلك متوفّرة لدينا حاليًا.

ولتحقيق هذه القفزة على Android، نقدّم لك Jetpack Credential Manager.

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

يمكنك استدعاء واجهة برمجة التطبيقات Credential Manager API، وستتولى الواجهة إدارة واجهة المستخدم لاختيار طريقة المصادقة التي يريد المستخدم رؤيتها.

بعد ذلك، تنفّذ هذه الواجهة المهام الصعبة لإرجاع بيانات الاعتماد الصحيحة التي تم الحصول عليها بشكل آمن.

وتتيح تسجيل الدخول والاشتراك والاحتفاظ بنسخة احتياطية من بيانات الاعتماد.

ويمكنك استخدامها لتعديل بيانات الاعتماد وحذفها.

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

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

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

والأهم من ذلك بالنسبة إلينا هو أنّها تتضمّن مسارًا مخصّصًا لمفاتيح المرور.

إليك ما يظهر للمستخدم أثناء الاشتراك.

يُعلم تطبيقي Credential Manager بأنّ المصادقة باستخدام مفتاح المرور متاحة، ويقدّم له التفاصيل التي تم جمعها من الخلفية.

عند النقر على "تسجيل"، يعرض لك Credential Manager بطاقة سفلية تتضمّن طلب قفل الشاشة.

ويتم فتح قفلها في أغلب الأحيان باستخدام المقاييس الحيوية، مثل بصمة الإصبع أو الوجه.

بعد ذلك، يتولّى Credential Manager تنفيذ مهام التشفير المعقّدة، مثل إنشاء مفتاح المرور.

ويحفظ مفتاح المرور في Credential Manager، وهو في هذه الحالة "مدير كلمات المرور في Google"، ولكن يمكن أن يكون شيئًا آخر.

إليك شكل الرمز.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

val createCredentialResponse =  credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

أولاً، ننشئ كائن createPublicKeyCredentialRequest هذا باستخدام تفاصيل الخلفية التي توفّرها، أي registerRequestJson.

بعد ذلك، نستدعي الطريقة السحرية credentialManager.createCredential.

نرسل هذا الطلب والسياق المحلي، ما يسمح بعرض واجهة المستخدم.

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

يتولى Credential Manager ذلك بالكامل نيابةً عنا.

هذه هي عملية تسجيل الدخول.

بالنسبة للمستخدم، يبدو الأمر مشابهًا إلى حد كبير لعملية الاشتراك.

سيظهر لك طلب واحد لفتح القفل، وبذلك تكون قد انتهيت.

بالنسبة إلى المطوّرين، يختلف الأمر قليلاً.

val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
   requestJson = authenticationRequestJson
)
val signInRequest =
   GetCredentialRequest(listOf(getPublicKeyCredentialOption))

val result =  credentialManager.getCredential  (
   context = localActivity,
   request = signInRequest
)

أولاً، نحصل على تفاصيل تسجيل الدخول من الخلفية لإنشاء مثيل GetPublicKeyCredential.

نُعلم Credential Manager بأنواع بيانات الاعتماد التي نتيحها.

في هذه الحالة، لا يتم استخدام سوى مفاتيح المرور.

ويمكننا أيضًا إضافة أنواع أخرى من بيانات الاعتماد إذا أردنا ذلك.

بعد ذلك، نطلب credentialManager.getCredential لتمرير قائمة بيانات الاعتماد التي طلبناها للتو.

مرة أخرى، لا يوجد رمز واجهة مستخدم.

لا حاجة إلى كتابة أي رمز لواجهة المستخدم.

يتولّى Credential Manager هذه المهمة بالكامل نيابةً عنا.

فهو يدفع المستخدم نحو الخيار الأكثر استخدامًا مع ترك الخيارات الأخرى متاحة كنسخة احتياطية.

يحلّ ذلك تلقائيًا إحدى أكثر مشاكل المصادقة المزعجة في الوقت الحالي.

هل لاحظت ذلك؟

وهذا يعني تذكُّر الطريقة الأخيرة التي استخدمتها لتسجيل الدخول.

انظر، هناك الإجابة معروضة بدقة في بطاقة سفلية.

بالمناسبة، لا يقتصر الأمر على إزعاج المستخدم.

إنّها نقطة احتكاك حقيقية.

ويؤدي ذلك إلى عمليات استرداد غير ضرورية للحسابات، وله تأثير تجاري مثل سلال التسوّق المتروكة.

إليك الرمز البرمجي للتطبيق التجريبي الذي يمكنك استخدامه لتجربة Credential Manager بنفسك.

ويمكنك الاطّلاع على هذه التدفقات على جهازك.

وهناك عينات التعليمات البرمجية الرسمية من Google على اليمين.

وهذا يعالج إنشاء مفاتيح المرور.

ماذا عن ترقية المستخدمين الحاليين الذين يستخدمون كلمات المرور إلى مفاتيح المرور؟

"الإنشاء الشرطي" (Conditional Create) هو أداة فعّالة لذلك.

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

في هذه الحالة، تتيح لنا ميزة "الإنشاء المشروط" طلب إنشاء مفتاح مرور تلقائيًا في الخلفية.

ولا يقاطع سير عمل المستخدم.

يتم إنشاء مفتاح المرور وتخزينه بدون إرسال أي إشعارات.

ويعرض "مدير كلمات المرور في Google" إشعارًا لتأكيد ذلك.

وقد تختلف طريقة عمل مدراء كلمات المرور الآخرين.

يشبه رمز الإنشاء الشرطي إلى حد كبير رمز الاشتراك.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson,
   preferImmediatelyAvailableCredentials = false,
   isConditional = true
)

val createCredentialResponse = credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

قيمة العلامة السحرية هي isConditional، ما يضمن عدم ظهور واجهة المستخدم هذه للمستخدم.

وبما أنّها تعمل بشكل انتهازي، سنضعها في كتلة try-catch.

سنعالج أي أخطاء بدون إرسال إشعارات، لكي لا نُزعج المستخدم في حال تعذّر إكمال العملية.

بعد ذلك، يتم حفظ مفتاح المرور في Credential Manager الخاص بالمستخدم، وسيكون متاحًا له في المرة القادمة.

تتيح واجهة برمجة التطبيقات Credential Manager أيضًا لموفّري بيانات الاعتماد استيراد بيانات الاعتماد وتصديرها بأمان.

ببضع نقرات فقط

ما مِن حاجة إلى تنزيل أي ملفات.

يمنح هذا مرونة أكبر، مع الحفاظ على أمان المعلومات.

يبدو المسار على النحو التالي:

في موفّر بيانات الاعتماد الجديد، يطلب المستخدم استيراد بيانات الاعتماد.

بعد ذلك، تعالج واجهة برمجة التطبيقات Credential Manager واجهة مستخدم الاستيراد، ما يتيح للمستخدم اختيار مصدر بيانات الاعتماد.

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

وأخيرًا، يتم تزويد مزوّد بيانات الاعتماد الجديد للمستخدم بالبيانات عبر قناة آمنة.

وبالتالي، يمكن استيرادها بدون أي تفاعل من المستخدم.

ولكن ماذا يحدث إذا ألغى المستخدم مفتاح مرور من تطبيقه أو موقعه الإلكتروني؟

وبالتالي، لا يعرف مزوّد بيانات الاعتماد بالضرورة أنّ ذلك قد حدث.

في المرة التالية التي يحاول فيها المستخدم تسجيل الدخول، سيقدّم له Credential Manager مفتاح المرور غير الصالح، وستكون محاولته مرفوضة.

وبالمثل، عندما يعدّل مستخدم اسم المستخدم أو الاسم المعروض، يجب إجراء مزامنة.

الآن، باستخدام Signal API، يمكن لتطبيقك الإبلاغ عن هذه الحالات المحدّدة لموفّر بيانات الاعتماد.

على سبيل المثال، لنفترض أنّك حاولت تسجيل الدخول باستخدام كلمة مرور تم إبطالها.

ويمكن لتطبيقك رصد حالة الخطأ المحدّدة هذه واستخدامها لإبلاغ مزوّد بيانات الاعتماد الخاص بالمستخدم.

يمكن لمزوّد بيانات الاعتماد بعد ذلك تعديل نفسه بحيث لا يتم عرض مفتاح المرور هذا.

هذه بعض ميزات Credential Manager، وهي مفيدة للغاية في حثّ المستخدمين على الاشتراك باستخدام مفاتيح المرور ومنح الأولوية لمفاتيح المرور على الطرق الأخرى عند تسجيل الدخول.

لكن تذكَّر أنّ هدفنا النهائي هنا هو الاستغناء عن كلمات المرور تمامًا.

كيف يساعد Credential Manager في تحقيق هذا الهدف؟

إليك العملية المقترَحة المكوّنة من خمس خطوات.

في الخطوتَين الأوليَين، يمكنك ترقية المستخدمين الذين يعتمدون على كلمات المرور إلى مفاتيح المرور.

أولاً، نحاول بشكل استباقي استخدام ميزة "الإنشاء الشرطي".

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

ويمكننا البدء تدريجيًا في عرضها بشكل أكثر بروزًا.

فمن وجهة نظر المستخدم، لا يحتاج عادةً إلا إلى تقديم قفل الشاشة، مثل المقاييس الحيوية.

عندما تُظهر الإحصاءات أنّ الغالبية العظمى من المستخدمين لديهم حسابات تستخدم مفاتيح المرور، يمكن فرض استخدام مفاتيح المرور على جميع المستخدمين الجدد.

ولكن هؤلاء المستخدمين القدامى، هم من نتعامل معهم في هذه الخطوات الثلاث الأخيرة.

نشجّع مستخدمي مفاتيح المرور على إزالة كلمات المرور.

لذلك، في الخطوة 3، نسمح لهم بإجراء ذلك يدويًا، من خلال خيار "حذف كلمة المرور" الواضح جدًا في إعدادات حساباتهم.

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

وأخيرًا، يمكنك التبديل من حذف كلمة المرور من الموافقة إلى الإيقاف.

في النهاية، قد يختفي حتى خيار الإيقاف الأخير.

ستمنحنا الإحصاءات الثقة لإزالة مسارات كلمات المرور من التطبيق تمامًا.

لذلك، لم يعُد الانتقال إلى عالم خالٍ من كلمات المرور مجرّد مفهوم أمان نظري للمستقبل.

وهي متوافقة بشكل كبير.

واجهات برمجة التطبيقات فعّالة، وتجربة المستخدم ممتازة.

أشجّعك على البدء في دمج مسارات مفاتيح المرور مع Credential Manager اليوم.

ابدأ بترقية حسابات المستخدمين، ولنتخلّص من كلمات المرور نهائيًا.

شكرًا لك.

والآن، أودّ أن أترك الكلمة لـ "تشيبينغ" ليتحدث عن التطور التالي في نقل البيانات بين الأجهزة وإثبات الهوية.

رائع.

حسنًا، شكرًا لك يا "توم".

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

ولكن ماذا يحدث عندما يحصل المستخدم على هاتف جديد؟

يحدث أكبر انخفاض في تجربة المستخدم اليوم غالبًا عندما يبدّل المستخدمون أجهزتهم.

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

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

ما هي ميزة "تسجيل الدخول بدون أي نقرات"؟

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

كيف يمكننا تنفيذ ذلك؟

الطريقة الأساسية التي ننصح بها لإجراء ذلك هي من خلال "واجهة برمجة التطبيقات لاستعادة بيانات الاعتماد" على Android عبر Credential Manager.

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

ننصح بإنشاء هذا المفتاح في الخلفية بعد تسجيل المستخدم الدخول.

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

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

يتم بعد ذلك تخزين هذا المفتاح على الجهاز أو على السحابة الإلكترونية عن بُعد في حال تفعيل هذه الميزة.

عندما يضبط المستخدم جهازه الجديد، يتم نقل بيانات الاعتماد الخاصة بالاستعادة تلقائيًا في الخلفية أثناء عملية إعداد الجهاز.

ويمكن للمستخدمين اختيار استعادة البيانات من السحابة الإلكترونية أو نقلها من جهاز إلى آخر.

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

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

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

سيسمح ذلك للمستخدم بتسجيل الدخول إلى تطبيقك بدون فتحه يدويًا.

وقد نفّذ بعض شركائنا هذا الإجراء في تطبيقاتهم.

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

من المهم أن يكون الوصول إلى المحتوى بسيطًا.

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

ويشكّل هذا التغيير المتكرّر للأجهزة تحديًا في الحفاظ على المستخدمين.

بعد تقييم طلبات المستخدمين وإنشاء نموذج أوّلي للرمز البرمجي، أضافت Uber ميزة "استعادة بيانات الاعتماد" إلى تطبيق Uber Rider، وكانت النتائج إيجابية للغاية.

وتقدّر الشركة أنّ هذه الميزة ستوفّر 4 ملايين عملية تسجيل دخول يوميًا في المتوسط، وتتوقّع أن يزداد هذا العدد مع زيادة معدّل الاستخدام.

يُرجى الاطّلاع على رمز الاستجابة السريعة هذا والرابط لمعرفة المزيد عن هذه السياسة القادمة وكيفية استيفاء تطبيقك لمتطلبات الاستعادة بدون نقر.

سيتم طرح هذه الميزة في أبريل 2027، لذا يُرجى تدوين ذلك في تقويمك.

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

يمكن استخدام هذه المهارة للمساعدة في تطوير الميزة أو اختبارها بسرعة باستخدام الوكيل الذي تختاره.

والآن، لنلقِ نظرة على المستقبل الواعد للهوية الرقمية: واجهة Digital Credentials API من خلال Credential Manager.

لنتعرّف على "بيانات الاعتماد الرقمية" وطريقة عملها.

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

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

تتعدد الاستخدامات وتتنوع، بدءًا من إثبات الهوية إلى الوصول إلى الخدمات إلى شراء العناصر عبر الإنترنت.

توفّر "بيانات الاعتماد الرقمية" طريقة آمنة ومريحة لمشاركة المعلومات بدون الحاجة إلى بطاقات مطبوعة.

تتضمّن "بيانات الاعتماد الرقمية" ثلاثة أطراف: جهة الإصدار وحامل المستند وجهة التحقّق.

تتدفق دورة حياة بيانات الاعتماد الرقمية بشكل عام من اليسار إلى اليمين.

لنتعرّف على كلّ من هذه الكيانات والدور الذي تؤدّيه.

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

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

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

ما عليك سوى إنشاء بيانات اعتماد وتوقيعها.

حسنًا، تُنشئ جهة الإصدار بيانات الاعتماد وتصدرها، ولكن يجب تخزينها في مكان ما، تمامًا كما تحتاج إلى تخزين مستند التعريف الصادر عن جهة حكومية في محفظتك.

هذا هو الطرف التالي، ويُسمى "الحامل"، ويُشار إليه أيضًا باسم "المحفظة الرقمية".

كما يوحي الاسم، يحتفظ حاملو بيانات الاعتماد بشكل أساسي ببيانات الاعتماد التي تصدرها جهات الإصدار.

ويتم حفظها كتطبيق على جهازك، ويمكنك بعد ذلك تقديمها إلى الجهات التي تطلبها.

وعلى غرار جهات الإصدار، يمكن لأي شخص أن يكون حاملاً.

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

لنفترض أنّ ناديًا رياضيًا يريد إنشاء بيانات اعتماد رقمية خاصة به لإثبات العضوية وإدارتها أيضًا من خلال تطبيقه الخاص.

سيكون ذلك جهة إصدار وحامل بطاقة في آنٍ واحد.

حسنًا، الطرف الثالث هو جهة التحقّق أو الطرف الذي يطلب "مستندات التعريف الرقمية".

يقدّم المدقّقون طلبات الحصول على بيانات الاعتماد عادةً للتحقّق من سمات المستخدم، مثل السن المسموح به أو اسم العائلة وما إلى ذلك.

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

على أجهزة Android، يتم تنسيق التفاعلات بين هذه الأطراف الثلاثة والمستخدم من خلال Credential Manager باستخدام Digital Credentials API.

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

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

تطابق واجهة برمجة التطبيقات Credential Manager الطلب مع جميع حاملي بيانات الاعتماد المتاحين وتعرضهم للمستخدم لاختيار بيانات الاعتماد وتقديم الموافقة.

بعد اختيار جهة الاحتفاظ، يتم استدعاؤها ويمكنها إجراء عمليات تحقّق إضافية إذا لزم الأمر قبل مشاركة بيانات الاعتماد في النهاية مع جهة التحقّق.

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

قد تتساءل الآن عن مدى أمان "مستندات التعريف الرقمية".

في الواقع، هناك ميزات أمان مضمّنة في كل خطوة من العملية، وسنتناول بعضها الآن.

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

كيف يمكنه التحقق من ذلك؟

قبل أن تُصدر جهة الإصدار بيانات الاعتماد، يجب أن يثبت حاملها هويته وأمان الجهاز الذي يستخدمه.

يرسل حامل المحفظة شهادة مصادقة المحفظة، عادةً كسلسلة شهادات يمكن التحقّق منها.

ينشئ الحامل أيضًا مفتاحَي تشفير مرتبطَين بالأجهزة.

ويرسل إلى جهة الإصدار المفتاح العام من مفتاحَي التشفير هذين مع تصديق مفتاح Android، بحيث تتمكّن جهة الإصدار من التحقّق من شرعية الجهاز.

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

من جهة حامل بيانات الاعتماد، بعد حصوله على بيانات اعتماد جديدة، يسجِّل فقط البيانات الوصفية لبيانات الاعتماد في Credential Manager.

يستخدم Credential Manager هذه البيانات الوصفية لتحديد حاملي بيانات الاعتماد الذين سيتم عرضهم عندما يطلب أحد المدقّقين بيانات الاعتماد.

لا يتم تسجيل أي بيانات مستخدم حقيقية في Credential Manager أو عرضها على Google.

وحتى عندما يختار Credential Manager المحافظ التي سيتم عرضها للمستخدم، لا يتم الكشف عن المحتوى داخل كل محفظة في ذلك الوقت.

الآن، عند تقديم طلب للحصول على بيانات الاعتماد وموافقة المستخدم على مشاركتها، يتم استدعاء الحامل المحدّد وتسليم التحكّم في سير العمل إليه.

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

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

ولا يمكن لـ Google الوصول إلى بيانات بيانات الاعتماد نفسها.

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

ويتيح ذلك لحامل بيانات الاعتماد التحكّم في الجهات التي يريد مشاركة بيانات الاعتماد معها.

أخيرًا، من جهة جهة التحقّق، بعد طلب بيانات الاعتماد ومشاركة حاملها لها، تتلقّى جهة التحقّق عرض بيانات الاعتماد من الحامل.

يمكن لجهة التحقّق الآن معرفة ما إذا كان الردّ قد تم إنشاؤه حديثًا من قِبل صاحب بيانات الاعتماد الأصلي للطلب.

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

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

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

بعد أن تناولنا كيفية تأمين "بيانات الاعتماد الرقمية"، لنتعرّف على بعض حالات استخدامها المتاحة اليوم من خلال واجهة Digital Credentials API على Android.

أول هذه الطرق التي سأتناولها هي تأكيد عنوان البريد الإلكتروني.

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

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

إليك عرض توضيحي لتسجيل واجهة برمجة التطبيقات أثناء العمل.

هذا نموذج تطبيق ينفّذ عملية تأكيد عنوان البريد الإلكتروني من خلال Digital Credentials API.

عند النقر على "طلب رسالة تأكيد إلكترونية تم التحقّق منها"، يطلب Credential Manager بيانات اعتماد رقمية لرسالة تأكيد إلكترونية تم التحقّق منها من حاملي هذا النوع من بيانات الاعتماد على الجهاز.

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

هذا هو أحد عناوين البريد الإلكتروني التي سجّل المستخدم الدخول إليها على الجهاز.

وفي الواقع، Google هي جهة إصدار بيانات الاعتماد الرقمية وحاملها في هذه الحالة.

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

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

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

إذا أردت تجربة هذه الميزة، يمكنك الانتقال إلى نموذج GitHub وتثبيته على جهازك.

يُرجى محاولة استخدامها على جهاز فعلي، مع العلم أنّه يجب تسجيل الدخول إلى حساب Gmail واحد على الأقل على جهازك.

لذا، سأمنح المزيد من الوقت إذا كان المستخدمون مهتمين.

حسنًا.

يبدو مثيرًا، أليس كذلك؟

وعندما تفكّر في تأكيد عنوان البريد الإلكتروني، ما هو الشكل التالي من أشكال تأكيد هوية المستخدم الذي يتبادر إلى ذهنك؟

هذا صحيح، تأكيد رقم الهاتف.

تتيح واجهة Digital Credentials API أيضًا تأكيد رقم الهاتف بشكلٍ أصلي، ما يزيل المشاكل والثغرات الأمنية المتعلّقة بكلمات المرور الصالحة لمرة واحدة (OTP) التي يتم إرسالها عبر الرسائل القصيرة.

تعتمد طريقة تأكيد رقم الهاتف أيضًا على واجهة Digital Credentials API، وفي هذه الحالة، يتم طلب رقم الهاتف على الجهاز وتقديمه كمستند تعريف رقمي.

لا يظهر للمستخدم سوى البطاقة السفلية المألوفة في Credential Manager لمشاركة رقم هاتفه أو إثبات صحته، مع البقاء داخل التطبيق، ولا يتطلّب الأمر سوى بضع نقرات لإكمال عملية التحقّق.

في ما يلي مثال على تطبيق يتيح للعميل مشاركة رقم هاتفه بنقرة واحدة بدون مغادرة التطبيق.

إذًا، كيف يعمل هذا الإعداد؟

إذا ربطنا ذلك بأطراف مستندات التعريف الرقمية، ستكون الجهة المُصدِرة في هذه الحالة هي مشغّل شبكة الجوّال لرقم الهاتف على شريحة SIM في الجهاز، وحامل المستند هو Android Telephony.

عندما تطلب جهة التحقّق، مثل تطبيقك، رقم هاتف المستخدم، يتم استرداده من Google Telephony من خلال طلب بيانات من واجهة برمجة التطبيقات Digital Credentials API.

قد تتساءل عن طريقة عمل الفوترة.

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

يحدث ذلك بعد استرداد رقم الهاتف من Google Telephony، حيث يتم تخزينه في حالة مشفّرة.

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

الميزة الرائعة في ذلك هي أنّ مشغّل شبكة الجوّال سيحصّل منك رسومًا مقابل عمليات التحقّق الناجحة فقط، والتي يتم نقلها من خلال البيانات أو شبكة Wi-Fi، وهي أكثر موثوقية من رسائل SMS.

في ما يلي عرض توضيحي لعملية تأكيد رقم الهاتف، باستخدام Firebase كمجمّع لمشغّلي شبكة الجوّال.

يطلب التطبيق رقم هاتف المستخدم كجزء من عملية تسجيل الدخول.

يستخدم هذا المستخدم عدة شرائح SIM، ويختار واحدة لمشاركتها مع التطبيق.

بعد أن يؤكّد المستخدم اختياره، تتم عملية التبادل في الخلفية.

بعد ذلك، ستظهر لك الشاشة التالية مع رقم الهاتف الذي تم استرداده.

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

ما عليك سوى السماح بانتهاء هذه العملية حتى تتمكّن من الاطّلاع على عملية الإكمال مرة أخرى.

وبالتالي، سيظهر رقم الهاتف على تلك الشاشة النهائية.

هذا كل ما في الأمر

لقد قطعنا شوطًا طويلاً اليوم.

لقد استكشفنا أولاً استخدام Credential Manager لتحسين تنفيذ مفتاح المرور والانتقال إلى عالم بلا كلمات مرور.

يُرجى الاطّلاع على مراجعنا حول Credential Manager ومفاتيح المرور هنا لمعرفة المزيد من المعلومات والوصول إلى نماذج التطبيقات.

بعد ذلك، تناولنا متطلبات تسجيل الدخول بدون نقر القادمة لتطبيقاتك، والتي تتيح للمستخدمين تسجيل الدخول بسلاسة عند إعداد جهاز جديد.

سيصبح هذا الإجراء إلزاميًا في "متجر Google Play" بحلول أبريل 2027، لذا يُرجى تدوين ذلك في تقويمك.

أخيرًا، تناولنا طريقة عمل بيانات الاعتماد الرقمية وبعض ميزاتها الأكثر فائدة على Android.

يُرجى الاطّلاع على مراجعنا حول بيانات الاعتماد الرقمية هنا للحصول على نظرة متعمّقة على المحتوى والوصول إلى النماذج.

كل ما شاركناه اليوم متاح الآن وجاهز للاستخدام.

مستقبل الهوية على Android أصبح هنا، وهو أكثر إثارة من أي وقت مضى.

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

ولا تترددوا في التواصل معي أو مع "توم" لطرح أي أسئلة حول مفاتيح المرور أو بيانات الاعتماد الرقمية.

مع أطيب التحيات،