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

Uwierzytelnianie na urządzeniach do noszenia: Menedżer danych logowania

Aplikacje na Wear OS mogą działać samodzielnie, bez aplikacji towarzyszącej. Oznacza to, że aplikacja na Wear OS musi samodzielnie zarządzać uwierzytelnianiem podczas uzyskiwania dostępu do danych z internetu. Jednak mały ekran zegarka i ograniczone możliwości wprowadzania danych ograniczają opcje uwierzytelniania, z których może korzystać aplikacja na Wear OS.

W tym przewodniku znajdziesz instrukcje dotyczące zalecanej metody uwierzytelniania w aplikacjach na Wear OS, czyli Credential Manager.

Aby dowiedzieć się więcej o projektowaniu dobrych wrażeń podczas logowania, zapoznaj się z przewodnikiem po logowaniu.

Wstępne uwagi

Zanim zaczniesz wdrażać, weź pod uwagę te kwestie.

Tryb gościa

Nie wymagaj uwierzytelniania w przypadku wszystkich funkcji. Zamiast tego udostępnij użytkownikowi jak najwięcej funkcji bez konieczności logowania.

Użytkownicy mogą odkryć i zainstalować aplikację na Wear OS bez korzystania z aplikacji mobilnej, więc mogą nie mieć konta i nie wiedzieć, jakie funkcje oferuje aplikacja. Upewnij się, że funkcje trybu gościa dokładnie prezentują funkcje aplikacji.

Niektóre urządzenia mogą pozostawać odblokowane dłużej

Na obsługiwanych urządzeniach z Wear OS 5 lub nowszym system wykrywa, czy użytkownik ma urządzenie na nadgarstku. Jeśli użytkownik wyłączy wykrywanie nadgarstka, a następnie zdejmie urządzenie z nadgarstka, system będzie utrzymywać urządzenie odblokowane przez dłuższy czas niż zwykle.

Jeśli Twoja aplikacja wymaga wyższego poziomu bezpieczeństwa, np. podczas wyświetlania potencjalnie poufnych lub prywatnych danych, najpierw sprawdź, czy wykrywanie nadgarstka jest włączone:

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

Jeśli wartość zwracana przez tę metodę to false, poproś użytkownika o zalogowanie się na konto w aplikacji przed wyświetleniem treści specyficznych dla użytkownika.

Credential Manager

Credential Manager to zalecany interfejs API do uwierzytelniania na Wear OS. Zapewnia on użytkownikom bezpieczniejsze środowisko do logowania się w aplikacjach na Wear OS w trybie samodzielnym, bez konieczności łączenia się z sparowanym telefonem i bez konieczności zapamiętywania hasła.

W tym dokumencie opisujemy informacje, których deweloperzy potrzebują do wdrożenia rozwiązania Credential Manager ze standardowymi mechanizmami uwierzytelniania, które obsługuje, czyli:

klucze dostępu,
hasła,
tożsamości sfederowane (np. Zaloguj się przez Google).

Ten przewodnik zawiera też instrukcje dotyczące migracji innych akceptowalnych metod uwierzytelniania na Wear OS (udostępnianie tokena warstwy danych i OAuth) jako kopii zapasowych Credential Manager oraz specjalne instrukcje dotyczące przejścia z wycofanego samodzielnego przycisku logowania przez Google na wbudowaną wersję Credential Manager.

Ograniczenia i różnice w Wear OS

Deweloperzy powinni pamiętać o tych ograniczeniach i różnicach w Wear OS:

Credential Manager jest dostępny w Wear OS 3 i nowszych wersjach.
Nie można tworzyć danych logowania w Wear OS.
Nie są obsługiwane ani przywracanie danych logowania, ani hybrydowe procesy logowania.
Z urządzeń mobilnych można ponownie korzystać tylko z dostawców danych logowania z integracjami Wear OS.

Klucze dostępu w Wear OS

Deweloperzy są zdecydowanie zachęcani do wdrażania kluczy dostępu w implementacjach Credential Manager na Wear OS. Klucze dostępu to nowy standard branżowy w zakresie uwierzytelniania użytkowników, który zapewnia użytkownikom wiele istotnych korzyści.

Klucze dostępu są łatwiejsze w użyciu

Użytkownicy mogą wybrać konto, na które chcą się zalogować. Nie muszą wpisywać nazwy użytkownika.
Użytkownicy mogą uwierzytelniać się za pomocą blokady ekranu urządzenia.
Po utworzeniu i zarejestrowaniu klucza dostępu użytkownik może bezproblemowo przełączyć się na nowe urządzenie i od razu zacząć z niego korzystać bez konieczności ponownej rejestracji.

Klucze dostępu są bezpieczniejsze

Deweloperzy zapisują na serwerze tylko klucz publiczny, a nie hasło. Oznacza to, że nieuczciwe podmioty mają znacznie mniejszą motywację do włamywania się na serwery, a w przypadku naruszenia bezpieczeństwa trzeba wykonać znacznie mniej czynności.
Klucze dostępu zapewniają ochronę przed wyłudzaniem informacji. Klucze dostępu działają tylko w zarejestrowanych witrynach i aplikacjach. Nie można nakłonić użytkownika do uwierzytelnienia się w oszukańczej witrynie, ponieważ weryfikacją zajmuje się przeglądarka lub system operacyjny.
Klucze dostępu zmniejszają potrzebę wysyłania SMS-ów, co sprawia, że uwierzytelnianie jest bardziej opłacalne.

Implementowanie kluczy dostępu

Obejmuje konfigurację i wskazówki dotyczące wszystkich typów implementacji.

Konfiguracja

W pliku build.gradle modułu aplikacji ustaw poziom interfejsu API na 35:
```
android {
    defaultConfig {
        targetSdk(35)
    }
}
```
Dodaj te wiersze do pliku build.gradle aplikacji lub modułu, używając najnowszej stabilnej wersji z androidx.credentials wersji odniesienia.
```
androidx.credentials:credentials:1.6.0
androidx.credentials:credentials-play-services-auth:1.6.0
```

Wbudowane metody uwierzytelniania

Credential Manager to ujednolicony interfejs API, więc kroki implementacji w Wear OS są takie same jak w przypadku każdego innego typu urządzenia.

Aby rozpocząć i wdrożyć obsługę kluczy dostępu i haseł, postępuj zgodnie z instrukcjami dotyczącymi urządzeń mobilnych.

Kroki dodawania obsługi funkcji Zaloguj się przez Google do Credential Manager są przeznaczone dla deweloperów aplikacji mobilnych, ale są takie same w Wear OS.

Pamiętaj, że w Wear OS nie można tworzyć danych logowania, więc nie musisz implementować metod tworzenia danych logowania wymienionych w instrukcjach dotyczących urządzeń mobilnych.

Metody uwierzytelniania zapasowego

Istnieją 2 inne akceptowalne metody uwierzytelniania w aplikacjach na Wear OS: OAuth 2.0 (w obu wariantach) i udostępnianie tokena uwierzytelniania mobilnego w warstwie danych. Chociaż te metody nie mają punktów integracji w interfejsie Credential Manager API, można je uwzględnić w procesie UX Credential Manager jako rezerwowe na wypadek, gdy użytkownicy zamkną ekran Credential Manager.

Aby obsłużyć działanie użytkownika polegające na zamknięciu ekranu Credential Manager, przechwyć a NoCredentialException w ramach swojej GetCredential logiki i przejdź do własnego niestandardowego interfejsu uwierzytelniania.

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

Twój niestandardowy interfejs uwierzytelniania może wtedy udostępnić dowolną z innych akceptowalnych metod uwierzytelniania opisanych w przewodniku po logowaniu.

Udostępnianie tokena warstwy danych

Aplikacja towarzysząca na telefonie może bezpiecznie przesyłać dane uwierzytelniania do aplikacji na Wear OS za pomocą interfejsu Wearable Data Layer API. Przesyłaj dane logowania jako wiadomości lub elementy danych.

Ten typ uwierzytelniania zwykle nie wymaga żadnych działań ze strony użytkownika. Unikaj jednak uwierzytelniania bez informowania użytkownika o tym, że jest logowany. Możesz poinformować użytkownika za pomocą ekranu, który można zamknąć, że jego konto jest przenoszone z urządzenia mobilnego.

Ważne: Twoja aplikacja na Wear OS musi oferować co najmniej 1 inną metodę uwierzytelniania, ponieważ ta opcja działa tylko na zegarkach sparowanych z Androidem, gdy jest zainstalowana odpowiednia aplikacja mobilna. Udostępnij alternatywną metodę uwierzytelniania użytkownikom, którzy nie mają odpowiedniej aplikacji mobilnej lub których urządzenie z Wear OS jest sparowane z urządzeniem z iOS.

Przekazuj tokeny za pomocą warstwy danych z aplikacji mobilnej, jak pokazano w tym przykładzie:

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

Nasłuchuj zdarzeń zmiany danych w aplikacji na Wear OS, jak pokazano w tym przykładzie:

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

Więcej informacji o korzystaniu z warstwy danych Wearable znajdziesz w artykule Wysyłanie i synchronizowanie danych w Wear OS.

Korzystanie z protokołu OAuth 2.0

Wear OS obsługuje 2 procesy oparte na OAuth 2.0, które są opisane w kolejnych sekcjach:

przyznawanie kodu autoryzacji z PKCE (Proof Key for Code Exchange) zgodnie z definicją w RFC 7636
przyznawanie autoryzacji urządzenia (DAG) zgodnie z RFC 8628.

PKCE (Proof Key for Code Exchange)

Aby efektywnie korzystać z PKCE, użyj RemoteAuthClient. Następnie, aby wysłać żądanie uwierzytelnienia z aplikacji na Wear OS do dostawcy protokołu OAuth, utwórz obiekt OAuthRequest. Ten obiekt składa się z adresu URL punktu końcowego OAuth służącego do uzyskiwania tokena oraz obiektu CodeChallenge.

Ten kod pokazuje przykład tworzenia żądania autoryzacji:

val oauthRequest = OAuthRequest.Builder(context)
    .setAuthProviderUrl(uri)
    .setCodeChallenge(codeChallenge)
    .setClientId(CLIENT_ID)
    .build()OAuthPKCE.kt

Po utworzeniu żądania autoryzacji wyślij je do aplikacji towarzyszącej za pomocą metody 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

To żądanie wywołuje połączenie z aplikacją towarzyszącą, która następnie wyświetla interfejs autoryzacji w przeglądarce internetowej na telefonie komórkowym użytkownika. Dostawca protokołu OAuth 2.0 uwierzytelnia użytkownika i uzyskuje jego zgodę na żądane uprawnienia. Odpowiedź jest wysyłana na automatycznie wygenerowany adres URL przekierowania.

Po pomyślnej lub nieudanej autoryzacji serwer OAuth 2.0 przekierowuje na adres URL określony w żądaniu. Jeśli użytkownik zatwierdzi żądanie dostępu, odpowiedź będzie zawierać kod autoryzacji. Jeśli użytkownik nie zatwierdzi żądania, odpowiedź będzie zawierać komunikat o błędzie.

Odpowiedź ma postać ciągu zapytania i wygląda jak jeden z tych przykładów:

  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

Spowoduje to wczytanie strony, która przekierowuje użytkownika do aplikacji towarzyszącej. Aplikacja towarzysząca weryfikuje adres URL odpowiedzi i przekazuje ją do aplikacji na Wear OS za pomocą interfejsu onAuthorizationResponse API.

Aplikacja na zegarku może następnie wymienić kod autoryzacji na token dostępu.

Przyznawanie autoryzacji urządzenia

W przypadku przyznawania autoryzacji urządzenia użytkownik otwiera identyfikator URI weryfikacji na innym urządzeniu. Następnie serwer autoryzacji prosi go o zatwierdzenie lub odrzucenie żądania.

Aby ułatwić ten proces, użyj RemoteActivityHelper, aby otworzyć stronę internetową na sparowanym urządzeniu mobilnym użytkownika, jak pokazano w tym przykładzie:

// 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

Jeśli masz aplikację na iOS, użyj linków uniwersalnych, aby przechwycić ten intencję w aplikacji, zamiast polegać na przeglądarce w zakresie autoryzacji tokena.