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 aplikacjach 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 funkcja trybu gościa dokładnie prezentuje 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 będzie utrzymywać 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:
fun isWristDetectionAutoLockingEnabled(context: Context): Boolean {
Jeśli wartość zwracana przez tę metodę to 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 na 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.
W tym dokumencie opisujemy informacje, które deweloperzy muszą znać, aby wdrożyć rozwiązanie Credential Manager z standardowymi mechanizmami uwierzytelniania, które obsługuje:
- Klucze dostępu
- Hasła
- Tożsamości sfederowane (np. Zaloguj 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.
Ograniczenia i różnice w Wear OS
Deweloperzy powinni pamiętać o tych ograniczeniach i różnicach w przypadku Wear OS:
- Menedżer danych logowania jest dostępny tylko na urządzeniach z Wear OS 4 lub nowszym.
- Nie można tworzyć danych logowania na Wear OS
- Nie są obsługiwane ani procesy „przywracania danych logowania”, ani hybrydowe procesy logowania.
- Z telefonu komórkowego można ponownie używać tylko dostawców danych logowania zintegrowanych z Wear OS.
Klucze dostępu na Wear OS
Zdecydowanie zachęcamy deweloperó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. Oznacza to, że w przypadku włamania na serwery hakerzy nie zyskają zbyt wiele, a w razie naruszenia bezpieczeństwa nie trzeba będzie przeprowadzać tak wielu działań naprawczych.
- 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 innych typów urządzeń.
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 aplikacji mobilnych, ale na Wear OS są takie same.
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 niestandardowego.
try { val getCredentialResponse: GetCredentialResponse = credentialManager.getCredential(activity, createGetCredentialRequest()) return authenticate(getCredentialResponse.credential) } catch (_: GetCredentialCancellationException) { navigateToSecondaryAuthentication() }
Niestandardowy interfejs uwierzytelniania może wtedy udostępniać inne akceptowane metody uwierzytelniania opisane w przewodniku po UX logowania.
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 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, 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 putDataReq: PutDataRequest = PutDataMapRequest.create("/auth").run { dataMap.putString("token", token) asPutDataRequest() } val putDataTask: Task<DataItem> = Wearable.getDataClient(this).putDataItem(putDataReq)
Nasłuchuj zdarzeń zmiany danych w aplikacji 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.
Więcej informacji o korzystaniu z warstwy danych na urządzenia do noszenia 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 oparte na OAuth 2.0, które opisano w sekcjach poniżej:
- Przyznawanie kodu autoryzacji z PKCE (Proof Key for Code Exchange) zgodnie z normą 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 oauthRequest = OAuthRequest.Builder(context) .setAuthProviderUrl(uri) .setCodeChallenge(codeChallenge) .setClientId(CLIENT_ID) .build()
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"))) } } )
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 udanej 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 żą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 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. private fun verifyDeviceAuthGrant(verificationUri: String) { RemoteActivityHelper(context).startRemoteActivity( Intent(Intent.ACTION_VIEW).apply { addCategory(Intent.CATEGORY_BROWSABLE) data = Uri.parse(verificationUri) }, null ) }
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.