Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

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

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

وضع الضيف

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

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

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

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

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

fun isWristDetectionAutoLockingEnabled(context: Context): Boolean {
    // Use the keyguard manager to check for the presence of a lock mechanism
    val keyguardManager = context.getSystemService<KeyguardManager>()
    val isSecured = keyguardManager?.isDeviceSecure == true

    // Use OEM-specific system settings to verify that on-body autolock is enabled.
    val isWristDetectionOn = android.provider.Settings.Global.getInt(
        context.contentResolver, PIXEL_WRIST_AUTOLOCK_SETTING_STATE,
        0
    ) == 1

    return isSecured && isWristDetectionOn
}WristDetectionUtility.kt

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

Credential Manager

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

الإعداد

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

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

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

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

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

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

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

هناك طريقتان أخريان مقبولتان للمصادقة لتطبيقات Wear OS، وهما OAuth 2.0 (أي من النوعَين) ومشاركة رمز المصادقة المميّز في طبقة بيانات مصادقة الأجهزة الجوّالة. على الرغم من أنّ هاتَين الطريقتَين لا تتضمّنان نقاط دمج في Credential Manager API، يمكن تضمينهما في مسار تجربة المستخدم في Credential Manager كطريقتَين احتياطيتَين في حال إغلاق المستخدمين شاشة 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.
                    handleSignInSequence(token)
                }
            }
        }
    }

    /** placeholder sign in handler. */
    fun handleSignInSequence(token: String?) {}
}DataLayerService.kt

لمزيد من المعلومات عن استخدام Wearable Data Layer، يُرجى الاطّلاع على إرسال البيانات ومزامنتها على 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 API.

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

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

عند استخدام "منح تفويض الجهاز"، يفتح المستخدم عنوان 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، استخدِم الروابط العامة لاعتراض هذا الهدف في تطبيقك بدلاً من الاعتماد على المتصفّح لتفويض الرمز المميّز.