المصادقة على الأجهزة القابلة للارتداء: أداة إدارة بيانات الاعتماد

تنظيم صفحاتك في مجموعات يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.

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

يقدّم هذا الدليل تعليمات حول طريقة المصادقة المُقترَحة لتطبيق "مدير بيانات الاعتماد" في تطبيقات Wear OS.

للاطّلاع على مزيد من المعلومات عن كيفية تصميم تجربة تسجيل دخول جيدة، يمكنك الاطّلاع على دليل تجربة المستخدم لتسجيل الدخول.

اعتبارات أولية

قبل بدء عملية التنفيذ، ضَع في اعتبارك النقاط التالية.

وضع الضيف

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

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

قد يظل قفل بعض الأجهزة مفتوحًا لفترة أطول

على الأجهزة المتوافقة التي تعمل بنظام التشغيل Wear OS 5 أو إصدار أحدث، يرصد النظام ما إذا كان المستخدم يرتدي الجهاز على معصمه. إذا أوقف المستخدم ميزة رصد المعصم ثم أزال الجهاز من معصمه، يحافظ النظام على فتح قفل الجهاز لفترة أطول من المعتاد.

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

val wristDetectionEnabled =
        isWristDetectionAutoLockingEnabled(applicationContext)

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

مدير بيانات الاعتماد

Credential Manager هي واجهة برمجة التطبيقات المُقترَحة للقيام بمهام مصادقة على Wear OS. وتوفّر هذه الميزة بيئة أكثر أمانًا للمستخدمين لتسجيل الدخول إلى تطبيقات Wear OS في وضع مستقل، بدون الحاجة إلى هاتف مقترن ومتّصل وبدون الحاجة إلى تذكُّر كلمة المرور.

يوضّح هذا المستند المعلومات التي يحتاجها المطوّرون لتنفيذ حلّ "مدير بيانات الاعتماد" باستخدام آليات المصادقة العادية التي يستضيفها، وهي:

• مفاتيح المرور
• كلمات المرور
• الهويات المُدمَجة (مثل ميزة "تسجيل الدخول باستخدام حساب Google")

يوفّر هذا الدليل أيضًا تعليمات حول كيفية نقل طرق مصادقة نظام التشغيل WearOS المقبولة الأخرى (مشاركة الرموز المميّزة لطبقة البيانات وOAuth) كنسخ احتياطية من Credential Manager، وتعليمات خاصة لمعالجة عملية النقل من زر تسجيل الدخول المستقل الذي تم إيقافه نهائيًا الآن من Google إلى إصدار Credential Manager المضمّن.

مفاتيح المرور على Wear OS

ننصح المطوّرين بشدة بتنفيذ مفاتيح المرور في عمليات تنفيذ "مدير بيانات الاعتماد" على نظام التشغيل Wear OS. مفاتيح المرور هي المعيار الجديد في المجال لمصادقة المستخدم النهائي، وتوفر العديد من المزايا المهمة للمستخدمين.

مفاتيح المرور أسهل

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

مفاتيح المرور أكثر أمانًا

• لا يحفظ المطوّرون سوى مفتاح عام على الخادم بدلاً من حفظ كلمة مرور، ما يعني أنّه يصعب على الجهات الفاعلة السيئة اختراق الخوادم، ويكون من السهل جدًا تنظيف البيانات في حال حدوث اختراق.
• توفّر مفاتيح المرور حماية مقاومة للتصيّد الاحتيالي. لا تعمل مفاتيح المرور إلا على المواقع الإلكترونية والتطبيقات المسجَّلة، ولا يمكن خداع المستخدم لإجراء مصادقة على موقع إلكتروني مخادع لأنّ المتصفّح أو نظام التشغيل يتولّى عملية إثبات الهوية.
• تقلِّل مفاتيح المرور من الحاجة إلى إرسال رسائل قصيرة، ما يجعل المصادقة أكثر فعالية من حيث التكلفة.

تنفيذ مفاتيح المرور

تتضمّن عملية الإعداد وإرشادات لجميع أنواع التنفيذ.

ضبط إعدادات الجهاز

1. اضبط مستوى واجهة برمجة التطبيقات المستهدَف على 35 في ملف build.gradle لوحدة تطبيقك:

   android {
       defaultConfig {
           targetSdkVersion(35)
       }
   }
   

2. أضِف الأسطر التالية إلى ملف build.gradle لتطبيقك أو وحدتك، باستخدام أحدث إصدار ثابت من مرجع إصدارات androidx.credentials.

   androidx.credentials:credentials:1.5.0
   androidx.credentials:credentials-play-services-auth:1.5.0
   

طرق المصادقة المضمّنة

بما أنّ "مدير بيانات الاعتماد" هو واجهة برمجة تطبيقات موحّدة، فإنّ خطوات التنفيذ لنظام التشغيل Wear OS هي نفسها خطوات أي نوع آخر من الأجهزة.

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

إنّ خطوات إتاحة ميزة "تسجيل الدخول باستخدام حساب Google" في "مدير بيانات الاعتماد" هي مخصّصة لتطوير التطبيقات المتوافقة مع الأجهزة الجوّالة، ولكنّ الخطوات متطابقة على نظام التشغيل Wear OS. اطّلِع على القسم الانتقال من ميزة "تسجيل الدخول باستخدام حساب Google" القديمة للاطّلاع على اعتبارات خاصة بهذه الحالة.

يُرجى العِلم أنّه لا يمكن إنشاء بيانات الاعتماد على نظام التشغيل Wear OS، لذا لا تحتاج إلى تنفيذ طُرق إنشاء بيانات الاعتماد المذكورة في تعليمات الأجهزة الجوّالة.

طرق المصادقة الاحتياطية

هناك طريقتان مقبولتان آخرتان للمصادقة في تطبيقات Wear OS: بروتوكول OAuth 2.0 (أي من الصيغتَين) ومشاركة طبقة بيانات رمز مميّز للمصادقة على الأجهزة الجوّالة. على الرغم من أنّ هذه الطرائق لا تتضمّن نقاط دمج في واجهة برمجة التطبيقات Credential Manager API، يمكن إدراجها في مسار تجربة المستخدم في Credential Manager كخيارات احتياطية في حال إغلاق المستخدمين لشاشة Credential Manager.

لمعالجة إجراء المستخدم بإغلاق شاشة "مدير بيانات الاعتماد"، عليك معالجة رمز برمجي NoCredentialException كجزء من منطق GetCredential ، والانتقال إلى واجهة مستخدم المصادقة المخصّصة.

yourCoroutineScope.launch {
    try {
      val response = credentialManager.getCredential(activity, request)
      signInWithCredential(response.credential)
    } catch (e: GetCredentialCancellationException) {
      navigateToFallbackAuthMethods()
    }
}

يمكن أن تقدّم واجهة مستخدِم المصادقة المخصّصة بعد ذلك أيًا من METHODS المعتمَدة الأخرى للمصادقة والتي يتم وصفها في دليل تجربة مستخدِم تسجيل الدخول.

مشاركة الرموز المميّزة لطبقة البيانات

يمكن لتطبيق الهاتف المصاحب نقل بيانات المصادقة بأمان إلى تطبيق Wear OS باستخدام واجهة برمجة التطبيقات Wearable Data Layer API. نقل بيانات الاعتماد كرسائل أو كعناصر بيانات

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

ملاحظة مهمة: يجب أن يقدّم تطبيق Wear OS طريقة مصادقة أخرى واحدة على الأقل، لأنّ هذا الخيار لا يعمل إلا على الساعات المقترنة بأجهزة Android عند تثبيت التطبيق المتوافق مع الأجهزة الجوّالة. قدِّم طريقة مصادقة بديلة للمستخدمين الذين ليس لديهم التطبيق المتوافق للأجهزة الجوّالة أو الذين تم إقران جهاز Wear OS لديهم بجهاز iOS.

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

val token = "..." // Auth token to transmit to the Wear OS device.
val dataClient: DataClient = Wearable.getDataClient(context)
val putDataReq: PutDataRequest = PutDataMapRequest.create("/auth").run {
    dataMap.putString("token", token)
    asPutDataRequest()
}
val putDataTask: Task<DataItem> = dataClient.putDataItem(putDataReq)

راقِب أحداث تغيير البيانات في تطبيق Wear OS، كما هو موضّح في المثال التالي:

val dataClient: DataClient = Wearable.getDataClient(context)
dataClient.addListener{ dataEvents ->
    dataEvents.forEach { event ->
        if (event.type == DataEvent.TYPE_CHANGED) {
            val dataItemPath = event.dataItem.uri.path ?: ""
            if (dataItemPath.startsWith("/auth")) {
                val token = DataMapItem.fromDataItem(event.dataItem).dataMap.getString("token")
                // Display an interstitial screen to notify the user that
                // they're being signed in.
                // Then, store the token and use it in network requests.
            }
        }
    }
}

لمزيد من المعلومات عن استخدام "طبقة بيانات الأجهزة القابلة للارتداء"، يُرجى الاطّلاع على مقالة إرسال البيانات ومزامنتها على نظام التشغيل Wear OS.

استخدام بروتوكول OAuth 2.0

يتيح نظام التشغيل Wear OS مسارَين مستندَين إلى OAuth 2.0، كما هو موضّح في الأقسام التالية:

• منح رمز التفويض باستخدام مفتاح حماية تبادل الرموز (PKCE) على النحو المحدّد في RFC 7636
• منح الإذن بالوصول إلى الجهاز (DAG)، على النحو المحدّد في RFC 8628

مفتاح الحماية لتبادل الرموز (PKCE)

لاستخدام بروتوكول PKCE بفعالية، استخدِم RemoteAuthClient. بعد ذلك، لتنفيذ طلب مصادقة من تطبيق Wear OS إلى مقدّم خدمة OAuth، أنشئ عنصر OAuthRequest. يتألّف هذا العنصر من عنوان URL لنقطة نهاية OAuth للحصول على رمز مميز وموضوع CodeChallenge.

تعرِض التعليمة البرمجية التالية مثالاً لإنشاء طلب مصادقة:

val request = OAuthRequest.Builder(this.applicationContext)
    .setAuthProviderUrl(Uri.parse("https://...."))
    .setClientId(clientId)
    .setCodeChallenge(codeChallenge)
    .build()

بعد إنشاء طلب المصادقة، أرسِله إلى التطبيق المصاحب باستخدام الطريقة sendAuthorizationRequest():

val client = RemoteAuthClient.create(this)
client.sendAuthorizationRequest(request,
    { command -> command?.run() },
    object : RemoteAuthClient.Callback() {
        override fun onAuthorizationResponse(
            request: OAuthRequest,
            response: OAuthResponse
        ) {
            // Extract the token from the response, store it, and use it in
            // network requests.
        }

        override fun onAuthorizationError(errorCode: Int) {
            // Handle any errors.
        }
    }
)

يؤدي هذا الطلب إلى إرسال طلب إلى التطبيق المصاحب الذي يعرض بعد ذلك واجهة مستخدم التفويض في متصفّح ويب على هاتف المستخدم الجوّال. يُثبِّت موفِّر OAuth 2.0 هوية المستخدم ويحصل على موافقته على الأذونات المطلوبة. يتم إرسال الردّ إلى عنوان URL لإعادة التوجيه الذي تم إنشاؤه تلقائيًا.

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

تكون الاستجابة في شكل سلسلة طلب وتبدو مثل أحد المثالين التاليين:

  https://wear.googleapis.com/3p_auth/com.your.package.name?code=xyz
  https://wear.googleapis-cn.com/3p_auth/com.your.package.name?code=xyz

يؤدي ذلك إلى تحميل صفحة توجّه المستخدم إلى التطبيق المصاحب. ويتحقق التطبيق المصاحب من عنوان URL للاستجابة ويعيد توجيه الاستجابة إلى تطبيق Wear OS. باستخدام واجهة برمجة التطبيقات onAuthorizationResponse.

يمكن بعد ذلك لتطبيق الساعة استبدال رمز التفويض برمز مميّز للوصول.

منح تفويض الجهاز

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

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

// Request access from the authorization server and receive Device Authorization
// Response.
val verificationUri = "..." // Extracted from the Device Authorization Response.
RemoteActivityHelper.startRemoteActivity(
    this,
    Intent(Intent.ACTION_VIEW)
        .addCategory(Intent.CATEGORY_BROWSABLE)
        .setData(Uri.parse(verificationUri)),
    null
)
// Poll the authorization server to find out if the user completed the user
// authorization step on their mobile device.

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

إيقاف ميزة "تسجيل الدخول باستخدام حساب Google" القديمة

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

// Define a basic SDK check.
fun isCredentialManagerAvailable(): Boolean {
 return android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.VANILLA_ICE_CREAM
}

// Elsewhere in the code, use it to selectively disable the legacy option.
Button(
  onClick = {
    if (isCredentialManagerAvailable()) {
      Log.w(TAG, "Devices on API level 35 or higher should use
                  Credential Manager for Sign in with Google")
    } else {
      navigateToSignInWithGoogle()
    }},
  enabled = !isCredentialManagerAvailable(),
  label = { Text(text = stringResource(R.string.sign_in_with_google)) },
  secondaryLabel = { Text(text = "Disabled on API level 35+")
  }
)