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

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

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

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

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

قبل البدء في التنفيذ، يُرجى مراعاة النقاط التالية.

وضع الضيف

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

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

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

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

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

fun isWristDetectionAutoLockingEnabled(context: Context): Boolean {WristDetectionUtility.kt

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

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

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

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

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

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

القيود والاختلافات في Wear OS

على المطوّرين مراعاة القيود والاختلافات التالية على Wear OS:

لا تتوفّر واجهة برمجة التطبيقات Credential Manager إلا على الإصدار 4 من نظام التشغيل Wear OS والإصدارات الأحدث.
لا يمكن إنشاء بيانات اعتماد على Wear OS
لا تتوفّر إمكانية "استعادة بيانات الاعتماد" أو عمليات تسجيل الدخول المختلطة.
لا يمكن إعادة استخدام "مقدّمي بيانات الاعتماد" إلا إذا كانوا يتضمّنون عمليات تكامل مع Wear OS من الجهاز الجوّال.

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

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

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

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

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

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

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

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

ضبط إعدادات الميزة

اضبط مستوى واجهة برمجة التطبيقات المستهدَف على 35 في ملف build.gradle الخاص بوحدة تطبيقك:
```
android {
    defaultConfig {
        targetSdkVersion(35)
    }
}
```
أضِف الأسطر التالية إلى ملف build.gradle الخاص بتطبيقك أو وحدتك، باستخدام أحدث إصدار ثابت من androidx.credentials إصدارات مرجعية.
```
androidx.credentials:credentials:1.5.0
androidx.credentials:credentials-play-services-auth:1.5.0
```

طُرق المصادقة المدمَجة

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

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

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

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

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

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

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

try {
    val getCredentialResponse: GetCredentialResponse =
        credentialManager.getCredential(activity, createGetCredentialRequest())
    return authenticate(getCredentialResponse.credential)
} catch (_: GetCredentialCancellationException) {
    navigateToSecondaryAuthentication()
}CredentialManager.kt

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

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

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

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

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

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

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

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

class AuthDataListenerService : WearableListenerService() {
    override fun onDataChanged(dataEvents: DataEventBuffer) {
        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.DataLayerService.kt

لمزيد من المعلومات حول استخدام "طبقة بيانات الأجهزة القابلة للارتداء"، راجِع مقالة إرسال البيانات ومزامنتها على 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 oauthRequest = OAuthRequest.Builder(context)
    .setAuthProviderUrl(uri)
    .setCodeChallenge(codeChallenge)
    .setClientId(CLIENT_ID)
    .build()OAuthPKCE.kt

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

RemoteAuthClient.create(context).sendAuthorizationRequest(
    request = oauthRequest,
    executor = { command -> command?.run() },
    clientCallback = object : RemoteAuthClient.Callback() {
        override fun onAuthorizationResponse(
            request: OAuthRequest,
            response: OAuthResponse
        ) {
            // Extract the token from the response, store it, and use it in requests.
            continuation.resume(parseCodeFromResponse(response))
        }
        override fun onAuthorizationError(request: OAuthRequest, errorCode: Int) {
            // Handle Errors
            continuation.resume(Result.failure(IOException("Authorization failed")))
        }
    }
)OAuthPKCE.kt

يؤدي هذا الطلب إلى بدء مكالمة مع التطبيق المصاحب، الذي يعرض بعد ذلك واجهة مستخدم خاصة بالتفويض في متصفّح ويب على هاتف المستخدم الجوّال. يصادق موفّر 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.
private fun verifyDeviceAuthGrant(verificationUri: String) {
    RemoteActivityHelper(context).startRemoteActivity(
        Intent(Intent.ACTION_VIEW).apply {
            addCategory(Intent.CATEGORY_BROWSABLE)
            data = Uri.parse(verificationUri)
        },
        null
    )
}OAuthDAG.kt

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