Приложения Wear OS могут работать автономно, без сопутствующего приложения. Это означает, что приложению Wear OS необходимо самостоятельно управлять аутентификацией при доступе к данным из интернета. Однако небольшой размер экрана часов и ограниченные возможности ввода ограничивают варианты аутентификации, которые может использовать приложение Wear OS.
В этом руководстве описан рекомендуемый метод аутентификации для приложений Wear OS — Менеджер учетных данных.
Чтобы узнать больше о том, как разработать удобный интерфейс авторизации, ознакомьтесь с руководством по пользовательскому интерфейсу авторизации .
Предварительные соображения
Прежде чем приступить к реализации, учтите следующие моменты.
Гостевой режим
Не следует требовать аутентификации для всех функций. Вместо этого предоставьте пользователю как можно больше функций, не требуя от него входа в систему.
Пользователи могут обнаружить и установить ваше приложение Wear, не используя мобильное приложение, поэтому у них может не быть учетной записи, и они могут не знать, какие функции оно предлагает. Убедитесь, что функция гостевого режима точно отображает возможности вашего приложения.
Некоторые устройства могут оставаться разблокированными дольше.
На поддерживаемых устройствах под управлением Wear OS 5 или более поздней версии система определяет, носит ли пользователь устройство на запястье. Если пользователь отключает определение положения на запястье, а затем снимает устройство, система оставляет устройство разблокированным на более длительный период времени, чем обычно.
Если вашему приложению требуется более высокий уровень безопасности, например, при отображении потенциально конфиденциальных или личных данных, сначала проверьте, включена ли функция обнаружения движения запястья:
fun isWristDetectionAutoLockingEnabled(context: Context): Boolean {
Если возвращаемое значение этого метода равно false , предложите пользователю войти в свою учетную запись в вашем приложении, прежде чем отображать контент, предназначенный для конкретного пользователя.
Менеджер учетных данных
Credential Manager — это рекомендуемый API для аутентификации в Wear OS. Он обеспечивает более безопасную среду для входа пользователей в приложения Wear OS в автономном режиме, без необходимости подключения сопряженного телефона и без необходимости запоминать свой пароль.
В этом документе изложена информация, необходимая разработчикам для внедрения решения Credential Manager со стандартными механизмами аутентификации, которые оно поддерживает, а именно:
- Пароли
- Пароли
- Федеративные учетные записи (например, вход через Google)
В этом руководстве также содержатся инструкции по миграции других допустимых методов аутентификации Wear OS ( Data Layer Token Sharing и OAuth ) в качестве резервных для Credential Manager, а также специальные инструкции по переходу от устаревшей автономной кнопки входа Google к встроенной версии Credential Manager.
Ограничения и различия Wear OS
Разработчикам следует учитывать следующие ограничения и различия в Wear OS:
- Менеджер учетных данных доступен только в Wear OS 4 и более поздних версиях.
- В Wear OS невозможно создать учетные данные.
- Ни функция «восстановление учетных данных», ни гибридные сценарии входа в систему не поддерживаются.
- Повторное использование на мобильных устройствах возможно только для поставщиков учетных данных, интегрированных с Wear OS.
Пароли на Wear OS
Разработчикам настоятельно рекомендуется внедрять пароли в свои реализации Wear OS Credential Manager. Пароли — это новый отраслевой стандарт аутентификации конечных пользователей, и они предоставляют пользователям ряд существенных преимуществ .
Ключи от ключей проще.
- Пользователи могут выбрать учетную запись для входа в систему. Им не нужно вводить имя пользователя.
- Пользователи могут пройти аутентификацию с помощью блокировки экрана устройства.
- После создания и регистрации пароля пользователь может беспрепятственно переключиться на новое устройство и сразу же начать им пользоваться без необходимости повторной регистрации.
Пароли — это безопаснее.
- Разработчики сохраняют на сервере только открытый ключ, а не пароль, что значительно снижает ценность взлома для злоумышленника и упрощает очистку в случае утечки данных.
- Пароли обеспечивают защиту от фишинга. Пароли работают только на зарегистрированных сайтах и в приложениях; пользователя невозможно обманом заставить пройти аутентификацию на мошенническом сайте, поскольку проверку выполняет браузер или операционная система.
- Использование паролей снижает необходимость отправки SMS-сообщений, что делает аутентификацию более экономически выгодной.
Реализуйте пароли
Включает настройку и рекомендации для всех типов внедрения.
Настраивать
В файле build.gradle модуля вашего приложения установите целевой уровень API на 35:
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 представляет собой унифицированный API, этапы внедрения для Wear OS такие же, как и для любого другого типа устройств.
Воспользуйтесь инструкциями для мобильного приложения , чтобы начать работу и реализовать поддержку паролей и ключей доступа.
Пошаговая инструкция по добавлению поддержки входа через Google в Credential Manager ориентирована на мобильную разработку, но она также применима и к Wear OS.
Обратите внимание, что поскольку создание учетных данных на Wear OS невозможно, вам не нужно реализовывать методы создания учетных данных, описанные в инструкциях для мобильных устройств.
Резервные методы аутентификации
Для приложений Wear OS существуют еще два допустимых метода аутентификации: OAuth 2.0 (любой из вариантов) и Mobile Auth Token Data Layer Sharing. Хотя эти методы не имеют точек интеграции в API Credential Manager, их можно включить в пользовательский интерфейс Credential Manager в качестве резервных вариантов на случай, если пользователи закроют экран Credential Manager.
Чтобы обработать действие пользователя по закрытию экрана диспетчера учетных данных, перехватите исключение NoCredentialException в рамках вашей логики GetCredential и перейдите к собственному пользовательскому интерфейсу аутентификации.
try { val getCredentialResponse: GetCredentialResponse = credentialManager.getCredential(activity, createGetCredentialRequest()) return authenticate(getCredentialResponse.credential) } catch (_: GetCredentialCancellationException) { navigateToSecondaryAuthentication() }
Затем ваш пользовательский интерфейс аутентификации может предоставлять любой из других допустимых методов аутентификации, описанных в руководстве по пользовательскому интерфейсу входа в систему .
совместное использование токенов уровня данных
Приложение-компаньон для телефона может безопасно передавать данные аутентификации в приложение Wear OS, используя API Wearable Data Layer. Передача учетных данных возможна в виде сообщений или элементов данных.
Этот тип аутентификации обычно не требует от пользователя никаких действий. Однако следует избегать аутентификации без уведомления пользователя о том, что он входит в систему. Можно сообщить пользователю об этом с помощью закрываемого экрана, который покажет, что его учетная запись переносится с мобильного устройства.
Важно: ваше приложение для 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)
Отслеживайте события изменения данных в приложении 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.
Для получения дополнительной информации об использовании уровня данных носимых устройств см. раздел «Отправка и синхронизация данных в 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()
После формирования запроса на аутентификацию отправьте его в сопутствующее приложение, используя метод 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"))) } } )
Этот запрос инициирует вызов сопутствующего приложения, которое затем отображает интерфейс авторизации в веб-браузере на мобильном телефоне пользователя. Провайдер 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, используя API onAuthorizationResponse .
Затем приложение для часов может обменять код авторизации на токен доступа.
Разрешение на использование устройства
При использовании функции Device Authorization Grant пользователь открывает 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 ) }
Если у вас приложение для iOS, используйте универсальные ссылки для перехвата этого намерения в вашем приложении, вместо того чтобы полагаться на браузер для авторизации токена.