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 rozmiar ekranu zegarka i ograniczone możliwości wprowadzania danych ograniczają opcje uwierzytelniania, których może używać aplikacja na Wear OS.

Ten przewodnik zawiera wskazówki dotyczące zalecanej metody uwierzytelniania w aplikacjach na Wear OS – Menedżer danych logowania.

Aby dowiedzieć się więcej o tym, jak zaprojektować dobre logowanie, zapoznaj się z przewodnikiem po UX logowania.

Wstępne zagadnienia

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

Tryb gościa

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

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

Niektóre urządzenia mogą pozostać 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 potem zdejmie urządzenie z nadgarstka, system będzie dłużej utrzymywać urządzenie w stanie odblokowanym.

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

val wristDetectionEnabled =
        isWristDetectionAutoLockingEnabled(applicationContext)

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

Credential Manager

Credential Manager to zalecany interfejs API do uwierzytelniania na Wear OS. Zapewnia ono bezpieczniejsze środowisko, w którym użytkownicy mogą logować się w aplikacjach na Wear OS w trybie samodzielnym, bez konieczności korzystania z połączonego telefonu z parowaniem i zapamiętywaniem hasła.

Ten dokument zawiera informacje, których deweloperzy potrzebują do implementacji rozwiązania Credential Manager z wykorzystaniem standardowych mechanizmów uwierzytelniania, takich jak:

  • Klucze dostępu
  • Hasła
  • tożsamości sfederowane (np. logowanie się przez Google);

Znajdziesz w nim też instrukcje migracji innych dozwolonych metod uwierzytelniania w Wear OS (udostępnianie tokenów na poziomie danych i OAuth) jako kopii zapasowych w usłudze Credential Manager. Znajdziesz tu też specjalne instrukcje dotyczące przejścia z niezależnego przycisku logowania Google (którego użycie jest obecnie nieaktualne) do wersji wbudowanej w Credential Manager.

Klucze dostępu na Wear OS

Zdecydowanie zalecamy wdrażanie kluczy dostępu w Menedżerze danych logowania na Wear OS. Klucze dostępu to nowy standard branżowy w zakresie uwierzytelniania użytkowników. Daje to użytkownikom kilka istotnych korzyści.

Klucze dostępu są łatwiejsze

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

Klucze dostępu są bezpieczniejsze

  • Zamiast hasła, deweloperzy zapisują na serwerze tylko klucz publiczny, co oznacza, że hakowanie serwerów jest znacznie mniej opłacalne dla osób niepowołanych, a w przypadku naruszenia bezpieczeństwa nie trzeba będzie robić tak dużo porządków.
  • Klucze dostępu zapewniają ochronę przed phishingiem. Klucze dostępu działają tylko w zarejestrowanych witrynach i aplikacjach. Użytkownik nie może zostać oszukany i zmuszony do uwierzytelnienia się na fałszywej stronie, ponieważ weryfikację przeprowadza przeglądarka lub system operacyjny.
  • Klucze dostępu ograniczają potrzebę wysyłania SMS-ów, dzięki czemu uwierzytelnianie jest bardziej opłacalne.

Wdrażanie kluczy dostępu

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

Skonfiguruj

  1. W pliku build.gradle modułu aplikacji ustaw docelowy poziom interfejsu API na 35:

    android {
    defaultConfig {
        targetSdkVersion(35)
    }
}

  2. Dodaj te wiersze do pliku build.gradle aplikacji lub modułu, używając najnowszej stabilnej wersji z poziomu androidx.credentials wersji referencyjnych.

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

Wbudowane metody uwierzytelniania

Menedżer danych logowania to zintegrowany interfejs API, dlatego kroki implementacji w przypadku Wear OS są takie same jak w przypadku innych typów urządzeń.

Aby rozpocząć korzystanie z kluczy i wdrożyć obsługę haseł i kluczy, skorzystaj z instrukcji dotyczących urządzeń mobilnych.

Instrukcje dodawania obsługi funkcji Zaloguj się przez Google do Credential Managera są przeznaczone dla programistów mobilnych, ale te same czynności można wykonać w przypadku Wear OS. Więcej informacji o tym, co należy wziąć pod uwagę w tym przypadku, znajdziesz w sekcji Przechodzenie z użycia starszej wersji funkcji Logowanie z Google.

Ponieważ nie można tworzyć danych logowania na Wear OS, nie musisz stosować metod tworzenia danych logowania wymienionych w instrukcjach dotyczących urządzeń mobilnych.

Zastępcze metody uwierzytelniania

W przypadku aplikacji na Wear OS akceptowane są 2 inne metody uwierzytelniania: OAuth 2.0 (dowolna wersja) i udostępnianie warstwy danych tokena uwierzytelniania mobilnego. Chociaż te metody nie mają punktów integracji w interfejsie Credential Manager API, można je uwzględnić w procesie obsługi Credential Manager jako metody zapasowe na wypadek, gdyby użytkownicy zamknęli ekran Credential Manager.

Aby obsłużyć działanie użytkownika polegające na odrzuceniu ekranu Menedżera danych logowania, użyj w swojej logice funkcji NoCredentialException i przejdź do niestandardowego interfejsu uwierzytelniania.GetCredential

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

Twój interfejs uwierzytelniania niestandardowego może oferować dowolną z dostępnych metod uwierzytelniania opisanych w przewodniku po interfejsie logowania.

Udostępnianie tokenów warstwy danych

Aplikacja towarzysząca na telefonie może bezpiecznie przesyłać dane uwierzytelniania do aplikacji na Wear OS za pomocą interfejsu API warstwy danych na urządzeniach noszonych. Przenoszenie danych logowania jako wiadomości lub elementów danych.

Ten typ uwierzytelniania zwykle nie wymaga od użytkownika żadnych działań. 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: aplikacja Wear OS musi oferować co najmniej 1 inną metodę uwierzytelniania, ponieważ ta opcja działa tylko na zegarkach sparowanych z Androidem, gdy zainstalowana jest 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.

Przekazywanie tokenów 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 dataClient: DataClient = Wearable.getDataClient(context)
val putDataReq: PutDataRequest = PutDataMapRequest.create("/auth").run {
    dataMap.putString("token", token)
    asPutDataRequest()
}
val putDataTask: Task<DataItem> = dataClient.putDataItem(putDataReq)

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

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.
            }
        }
    }
}

Więcej informacji o używaniu warstwy danych na urządzeniach noszonych znajdziesz w artykule Wysyłanie i synchronizowanie danych na Wear OS.

Korzystanie z protokołu OAuth 2.0

Wear OS obsługuje 2 przepływy OAuth 2.0, które są opisane w następnych sekcjach:

  • Przyznawanie kodu autoryzacji z Proof Key for Code Exchange (PKCE) zgodnie z definicją w RFC 7636
  • Uprawnienia do autoryzacji na urządzeniu (DAG) zgodnie z definicją w RFC 8628
.
Proof Key for Code Exchange (PKCE)

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

Poniższy kod pokazuje przykład tworzenia żądania uwierzytelniania:

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

Po utworzeniu żądania uwierzytelniania wyślij je do aplikacji towarzyszącej, używając metody 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.
        }
    }
)

To żądanie powoduje wywołanie aplikacji towarzyszącej, która wyświetla interfejs autoryzacji w przeglądarce na telefonie użytkownika. Dostawca OAuth 2.0 uwierzytelnia użytkownika i uzyskiwanie jego zgody na żądane uprawnienia. Odpowiedź jest wysyłana na automatycznie wygenerowany adres URL przekierowania.

Po pomyślnej lub nieudanej autoryzacji serwer OAuth 2.0 przekierowuje do adresu URL podanego w żądaniu. Jeśli użytkownik zaakceptuje prośbę o dostęp, 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 załadowanie strony, która przekieruje użytkownika do aplikacji towarzyszącej. Aplikacja towarzysząca zweryfikuje adres URL odpowiedzi i przekaże odpowiedź do aplikacji na Wear OS za pomocą interfejsu API onAuthorizationResponse.

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

Przyznanie uprawnień do urządzenia

W przypadku przyznawania uprawnień do autoryzacji urządzenia użytkownik otwiera identyfikator URI weryfikacji na innym urządzeniu. Następnie serwer autoryzacji prosi ich o zatwierdzenie lub odrzucenie prośby.

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

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

Przejście z funkcji Zaloguj się przez Google w starszej wersji

Credential Manager ma specjalny punkt integracji z przyciskiem Zaloguj się przez Google. Wcześniej ten przycisk można było dodać w dowolnym miejscu w interfejsie logowania aplikacji, ale ze względu na jego uwzględnienie w Menedżerze danych logowania stara opcja została wycofana.

// 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+")
  }
)