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. Mały ekran zegarka i ograniczone możliwości wprowadzania danych ograniczają jednak opcje uwierzytelniania, z których może korzystać aplikacja na Wear OS.
Ten przewodnik zawiera instrukcje dotyczące zalecanej metody uwierzytelniania w przypadku aplikacji na Wear OS, czyli Menedżera danych logowania.
Więcej informacji o projektowaniu dobrego procesu logowania znajdziesz w przewodniku po UX logowania.
Wstępne uwagi
Zanim rozpoczniesz wdrażanie, weź pod uwagę te kwestie.
Tryb gościa
Nie wymaga uwierzytelniania w przypadku wszystkich funkcji. Zamiast tego udostępnij użytkownikowi jak najwięcej funkcji bez konieczności logowania się.
Użytkownicy mogą odkryć i zainstalować aplikację na Wear bez używania aplikacji mobilnej, więc mogą nie mieć konta i nie wiedzieć, jakie funkcje oferuje aplikacja. Upewnij się, że funkcje trybu gościa dokładnie przedstawiają 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 następnie zdejmie urządzenie z nadgarstka, system utrzyma urządzenie w stanie odblokowanym przez dłuższy czas niż w innych przypadkach.
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:
val wristDetectionEnabled =
isWristDetectionAutoLockingEnabled(applicationContext)
Jeśli ta metoda zwraca wartość false, poproś użytkownika o zalogowanie się na konto w aplikacji przed wyświetleniem treści dostosowanych do jego potrzeb.
Credential Manager
Credential Manager to zalecany interfejs API do uwierzytelniania w Wear OS. Zapewnia użytkownikom bezpieczniejsze środowisko logowania się w aplikacjach na Wear OS w trybie samodzielnym, bez konieczności łączenia się ze sparowanym telefonem i zapamiętywania hasła.
Ten dokument zawiera informacje, których deweloperzy potrzebują do wdrożenia rozwiązania Credential Manager z standardowymi mechanizmami uwierzytelniania, które obsługuje, czyli:
- Klucze dostępu
- Hasła
- Tożsamości sfederowane (np. logowanie się przez Google)
Ten przewodnik zawiera też instrukcje migracji innych akceptowanych 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 już samodzielnego przycisku logowania przez Google na wbudowaną wersję Credential Manager.
Klucze dostępu na Wear OS
Zdecydowanie zachęcamy programistów do wdrażania kluczy dostępu w implementacjach Menedżera danych logowania na Wear OS. Klucze dostępu to nowy standard branżowy uwierzytelniania użytkowników, który przynosi im wiele istotnych korzyści.
Klucze dostępu są łatwiejsze w użyciu
- Użytkownicy mogą wybrać konto, za pomocą którego 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, co oznacza, że włamanie się na serwery jest znacznie mniej opłacalne dla hakerów, a w przypadku naruszenia bezpieczeństwa wymaga znacznie mniej pracy.
- 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ę w fałszywej witrynie, ponieważ weryfikacją zajmuje się przeglądarka lub system operacyjny.
- Klucze dostępu zmniejszają potrzebę wysyłania SMS-ów, dzięki czemu uwierzytelnianie jest bardziej opłacalne.
Wdrażanie kluczy dostępu
Zawiera konfigurację i wskazówki dotyczące wszystkich typów wdrożeń.
Konfiguracja
W pliku build.gradle modułu aplikacji ustaw docelowy poziom interfejsu API na 35:
android { defaultConfig { targetSdkVersion(35) } }Dodaj te wiersze do pliku build.gradle aplikacji lub modułu, używając najnowszej stabilnej wersji z
androidx.credentialswydań.androidx.credentials:credentials:1.5.0 androidx.credentials:credentials-play-services-auth:1.5.0
Wbudowane metody uwierzytelniania
Credential Manager to ujednolicony interfejs API, więc kroki implementacji w przypadku 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ł, skorzystaj z instrukcji dotyczących urządzeń mobilnych.
Czynności związane z dodawaniem obsługi logowania przez Google do Credential Manager są przeznaczone dla programistów mobilnych, ale na Wear OS są takie same. W sekcji Przejście z starszej wersji logowania przez Google znajdziesz specjalne uwagi dotyczące tego przypadku.
Pamiętaj, że na 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.
Zapasowe metody uwierzytelniania
Istnieją 2 inne dopuszczalne metody uwierzytelniania w przypadku aplikacji na Wear OS: OAuth 2.0 (w dowolnej wersji) 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 UX Menedżera danych logowania jako opcje rezerwowe na wypadek, gdyby użytkownicy zamknęli ekran Menedżera danych logowania.
Aby obsłużyć działanie użytkownika polegające na zamknięciu ekranu Menedżera danych logowania, przechwyć element NoCredentialException w ramach logiki GetCredential i przejdź do własnego interfejsu uwierzytelniania.
yourCoroutineScope.launch {
try {
val response = credentialManager.getCredential(activity, request)
signInWithCredential(response.credential)
} catch (e: GetCredentialCancellationException) {
navigateToFallbackAuthMethods()
}
}
Niestandardowy interfejs uwierzytelniania może wtedy udostępniać inne akceptowane metody uwierzytelniania opisane w przewodniku po logowaniu.
Udostępnianie tokenów warstwy danych
Aplikacja towarzysząca na telefon może bezpiecznie przesyłać dane uwierzytelniające do aplikacji 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 telefonu komórkowego.
Ważne: aplikacja Wear OS musi oferować co najmniej 1 inną metodę uwierzytelniania, ponieważ ta opcja działa tylko na zegarkach sparowanych z Androidem, na których jest zainstalowana odpowiednia aplikacja mobilna. Zapewnij 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 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 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ądzenia do noszenia znajdziesz w artykule Wysyłanie i synchronizowanie danych na Wear OS.
Korzystanie z OAuth 2.0
Wear OS obsługuje 2 przepływy oparte na OAuth 2.0, które opisujemy w kolejnych sekcjach:
- Przyznawanie kodu autoryzacji z PKCE (Proof Key for Code Exchange) zgodnie z definicją w RFC 7636.
- Przyznanie autoryzacji urządzenia (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 autoryzacji z aplikacji na Wear OS do dostawcy 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.
Poniższy kod pokazuje przykład tworzenia żądania autoryzacji:
val request = OAuthRequest.Builder(this.applicationContext)
.setAuthProviderUrl(Uri.parse("https://...."))
.setClientId(clientId)
.setCodeChallenge(codeChallenge)
.build()
Po utworzeniu żądania autoryzacji wyślij je do aplikacji towarzyszącej za pomocą 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 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 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 do adresu URL podanego w żądaniu. Jeśli użytkownik zatwierdzi prośbę o dostęp, odpowiedź będzie zawierać kod autoryzacji. Jeśli użytkownik nie zatwierdzi prośby, 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 onAuthorizationResponse API.
Aplikacja na zegarek może następnie wymienić kod autoryzacji na token dostępu.
Przyznanie autoryzacji urządzenia
W przypadku używania uprawnień do autoryzacji urządzenia użytkownik otwiera identyfikator URI weryfikacji na innym urządzeniu. Następnie serwer autoryzacji prosi użytkownika 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 przykładzie poniżej:
// 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żywaj linków uniwersalnych, aby przechwytywać ten zamiar w aplikacji, zamiast polegać na przeglądarce w zakresie autoryzacji tokena.
Przejście z starszej wersji funkcji Zaloguj się przez Google
Credential Manager ma specjalny punkt integracji z przyciskiem Zaloguj się przez Google. Wcześniej ten przycisk można było dodać w dowolnym miejscu interfejsu uwierzytelniania aplikacji, ale po dodaniu go do Menedżera danych logowania ta 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+")
}
)