Uwierzytelnianie na różnych urządzeniach

Credential Manager upraszcza uwierzytelnianie w całym ekosystemie Androida. Zapewnia użytkownikom spójne wrażenia, a deweloperom – ujednolicony interfejs API do korzystania z kluczy dostępu, haseł i mechanizmów logowania federacyjnego, takich jak Zaloguj się przez Google. Podstawowy interfejs programowania pozostaje spójny na różnych urządzeniach, ale każde z nich ma unikalne aspekty interfejsu i wrażeń użytkownika. Aby implementacja była skuteczna, musisz dostosować procesy uwierzytelniania w aplikacji do konkretnych metod wprowadzania danych, rozmiarów ekranu i kontekstów użytkownika na każdym urządzeniu.

Ten przewodnik zawiera omówienie sposobu implementacji Credential Managera na różnych urządzeniach z Androidem. Znajdziesz tu najważniejsze kwestie i linki do bardziej szczegółowej dokumentacji.

Urządzenia mobilne

Urządzenia mobilne, w tym telefony, tablety i urządzenia składane, są najczęstszym celem tworzenia aplikacji na Androida. Standardowa implementacja Credential Managera dobrze sprawdza się na tych urządzeniach, które zwykle mają ekrany dotykowe i klawiatury na urządzeniu. Wrażenia użytkownika na tych urządzeniach stanowią podstawę, na której możesz się opierać, dostosowując aplikację do innych urządzeń. Procesy uwierzytelniania powinny być dostosowane do urządzenia i wykorzystywać pełne możliwości ekranu oraz metod wprowadzania danych.

Wear OS

Urządzenia z Wear OS charakteryzują się małymi ekranami i ograniczonymi możliwościami wprowadzania danych na urządzeniu. Implementacja kluczy dostępu w Credential Managerze zapewnia użytkownikom bezpieczne środowisko do logowania się w aplikacjach bez konieczności łączenia się ze sparowanym telefonem i zapamiętywania hasła.

Interfejs API na Wear OS jest identyczny jak na urządzeniach mobilnych, więc możesz ponownie użyć istniejącej integracji mobilnej. Oprócz kluczy dostępu, funkcji Zaloguj się przez Google i haseł w Credential Managerze możesz używać innych metod uwierzytelniania, w tym udostępniania tokenów w warstwie danych, OAuth lub dotychczasowych rozwiązań. Możesz ich używać jako kopii zapasowych podczas przechodzenia użytkowników na Credential Managera lub, w przypadku udostępniania tokenów w warstwie danych, jako rozwiązania długoterminowego.

Korzystanie z Credential Managera na Wear OS wymaga spełnienia tych warunków:

  • Minimalny poziom API: minSdkVersion 33 lub nowszy.
    • Obsługuje hasła, klucze dostępu i funkcję Zaloguj się przez Google.
  • Wersja GMS: taka sama jak w przypadku aplikacji mobilnych.

Interfejs użytkownika na urządzeniach z Wear OS wygląda tak:

Ekran logowania za pomocą klucza dostępu wyświetlany jako preferowana metoda uwierzytelniania na Wear OS.
Rysunek 1a. Klucze dostępu.
Klucze dostępu, hasła i opcje funkcji Zaloguj się przez Google dostępne dla użytkownika na Wear OS.
Rysunek 1b. Klucze dostępu, hasła i funkcja Zaloguj się przez Google.

Szczegółowe wskazówki dotyczące implementacji i przykłady kodu znajdziesz w tych materiałach:

Ograniczenia

Korzystanie z Credential Managera na Wear OS ma te ograniczenia:

Android XR

W Androidzie XR (który obejmuje rzeczywistość wirtualną i rozszerzoną) aplikacje są renderowane w przestrzeni 3D. Wprowadzanie danych przez użytkownika różni się zasadniczo od tego na innych urządzeniach, ponieważ opiera się na naturalnych metodach, takich jak gesty dłoni.

Dostosowanie Credential Managera do XR wymaga przemyślenia interfejsu uwierzytelniania (czy to za pomocą kluczy dostępu, haseł czy metod logowania federacyjnego) pod kątem przestrzeni 3D. Na przykład monity uwierzytelniania pojawiają się w pływających panelach, a użytkownicy dokonują wyborów za pomocą gestów dłoni. Musisz też wziąć pod uwagę wszelkie konkretne wymagania sprzętowe lub programowe dotyczące urządzeń XR, na które kierujesz aplikację.

Kluczowym wyzwaniem projektowym jest stworzenie intuicyjnego i bezpiecznego procesu uwierzytelniania w środowisku VR lub AR. Musisz też zastanowić się, jak zarządzać tożsamością w scenariuszach XR z wieloma użytkownikami, w których różne osoby mogą korzystać z tego samego urządzenia.

Korzystanie z Credential Managera na Androidzie XR wymaga spełnienia tych warunków:

  • Minimalny poziom API: minSdkVersion 34 lub nowszy.
  • Wersja GMS: taka sama jak w przypadku aplikacji mobilnych.
  • Emulator:
    • Minimalny obraz systemu emulatora:
      • macOS: obraz systemu Google Play XR ARM 64 v8a w wersji 7.
      • Windows: obraz systemu Google Play XR Intel x86_64 Atom w wersji 7.
    • Wersje emulatora nowsze niż 35.6.11 Stable.

Proces logowania w XR może wyglądać tak:

Prośba o zalogowanie się w Menedżerze danych logowania wyświetlana w pływającym panelu 3D na Androidzie XR.
Rysunek 2. Interfejs Credential Managera w XR.

Procesy nieobsługiwane przez XR

Credential Manager na Androidzie XR nie obsługuje procesów uwierzytelniania, które wymagają zeskanowania kodu QR na innym urządzeniu. Można to zaobserwować podczas logowania się na goglach XR i podczas testowania za pomocą emulatora.

Więcej informacji o XR znajdziesz w artykule Android XR.

Android TV

Urządzenia z Androidem TV są zwykle używane przez wiele osób, oglądane z daleka i obsługiwane za pomocą pilotów z padem kierunkowym. Wpisywanie nazw użytkowników i haseł w tym środowisku może być dla użytkowników trudne. Credential Manager upraszcza uwierzytelnianie na Androidzie TV, obsługując funkcję Zaloguj się przez Google, zapisane hasła i klucze dostępu na różnych urządzeniach. Ponieważ na wspólnym telewizorze często jest kilka profili Google, Credential Manager dostosowuje się do tego ustawienia, pobierając i wyświetlając wszystkie dane uwierzytelniające dostępne na urządzeniu, a nie ograniczając wyborów tylko do aktualnie aktywnego konta.

Prośba o zalogowanie się w Credential Manager na Androidzie TV, która wyświetla zapisane konta do funkcji Zaloguj się przez Google i hasła, a także opcję użycia klucza dostępu.
Rysunek 3. Interfejs Credential Managera na Androidzie TV z opcjami Zaloguj się przez Google, zapisane hasła i klucze dostępu.

Ten wspólny charakter urządzenia decyduje też o sposobie obsługi kluczy dostępu. Ponieważ telewizory nie mają osobistego czynnika wiedzy o ekranie blokady (LSKF), klucze dostępu nie są przechowywane ani tworzone bezpośrednio na telewizorze. Zamiast tego uwierzytelnianie za pomocą klucza dostępu wykorzystuje hybrydowy proces na różnych urządzeniach, w którym na telewizorze wyświetlany jest kod QR, a użytkownik skanuje go za pomocą urządzenia mobilnego, aby dokończyć uwierzytelnianie biometryczne.

Jeśli ustawisz isAutoSelectAllowed = true, na Google TV możliwy jest proces bez klikania, ale tylko wtedy, gdy dostępny jest dokładnie 1 pasujący zestaw danych uwierzytelniających. Nadal będzie się wyświetlać natywna plansza dolna telewizora z potwierdzeniem konta użytkownika. Jeśli użytkownik nie anuluje, dane uwierzytelniające zostaną automatycznie zwrócone bez konieczności klikania na pilocie. Jeśli jest więcej pasujących danych uwierzytelniających, nie zostaną one wybrane automatycznie, a użytkownik zostanie poproszony o dokonanie wyboru.

Jeśli aplikacje mobilne i aplikacje TV mają dokładnie taką samą nazwę pakietu Androida i klucz podpisywania, Menedżer haseł Google rozpoznaje je jako tę samą tożsamość aplikacji. Dzięki temu hasło zapisane na urządzeniu mobilnym może być oferowane bezpośrednio na telewizorze bez konieczności konfigurowania Digital Asset Links (asset_statements). Digital Asset Links są wymagane tylko wtedy, gdy dane uwierzytelniające są udostępniane między różnymi granicami, np. między aplikacją a witryną lub między aplikacjami o różnych nazwach pakietów.

Korzystanie z Credential Managera na Androidzie TV wymaga spełnienia tych warunków:

  • Minimalny poziom API: Android 14 (poziom 34 interfejsu API, minSdkVersion 34) lub nowszy.
  • Wersja GMS: 2026W30 lub nowsza.
  • Sprzęt do kluczy dostępu: do zeskanowania kodu QR i dokończenia hybrydowego procesu FIDO wymagane jest dodatkowe urządzenie mobilne z aparatem i Bluetooth.

Ograniczenia

Ponieważ Android TV jest urządzeniem wspólnym, korzystanie z Credential Managera na tej platformie ma te celowe ograniczenia, które chronią prywatność i bezpieczeństwo użytkowników:

  • Brak lokalnego tworzenia i przechowywania kluczy dostępu: klucze dostępu nie mogą być tworzone ani przechowywane bezpośrednio na telewizorze. Ponieważ lokalne dane uwierzytelniające nie są obsługiwane, nie ustawiaj w żądaniach wartości preferImmediatelyAvailableCredentials na true. Spowoduje to odfiltrowanie kluczy dostępu na różnych urządzeniach i nie zwróci danych uwierzytelniających.
  • Brak dostawców danych uwierzytelniających innych firm: Android TV nie obsługuje autouzupełniania, więc menedżerowie haseł innych firm są na tej platformie niedostępni. Użytkownicy muszą korzystać z Menedżera haseł Google.
  • Brak funkcji Przywracanie danych uwierzytelniających: logowanie automatyczne na nowych urządzeniach za pomocą funkcji Przywracanie danych uwierzytelniających nie jest obsługiwane na Androidzie TV.

Więcej informacji o tworzeniu aplikacji na telewizory znajdziesz w artykule Omówienie Androida TV.

System operacyjny Android Automotive

Urządzenia z systemem operacyjnym Android Automotive (AAOS) to systemy wspólne zintegrowane z pojazdami. Dostosowanie Credential Managera do AAOS wymaga obsługi bezpiecznego uwierzytelniania (zwykle gdy pojazd jest zaparkowany) i obsługi wielu profili użytkowników na wspólnym urządzeniu.

Jeśli przenosisz do samochodów aplikację zoptymalizowaną pod kątem dużych ekranów lub tabletów, a Twoja aplikacja obsługuje już Credential Managera i klucze dostępu na urządzeniach mobilnych lub tabletach, będzie działać na systemie operacyjnym Android Automotive bez konieczności wprowadzania zmian w procesach uwierzytelniania.

Uwierzytelnianie w systemie operacyjnym Android Automotive obsługuje te metody:

  • Klucze dostępu (hybrydowy proces na różnych urządzeniach): użytkownicy mogą uwierzytelniać się za pomocą istniejących kluczy dostępu w procesie na różnych urządzeniach. System wyświetla na ekranie samochodu kod QR, który użytkownik skanuje za pomocą urządzenia mobilnego. Ponieważ weryfikacja biometryczna i weryfikacja blokady ekranu odbywa się na telefonie użytkownika, nie musi on konfigurować blokady ekranu na wyświetlaczu samochodowym.
  • Zaloguj się przez Google: wyświetla natywny ekran Zaloguj się przez Google bezpośrednio na wyświetlaczu samochodowym.
  • Zapisane hasła: użytkownicy mogą pobierać zapisane hasła z Menedżera haseł Google, aby logować się bez ręcznego wpisywania danych uwierzytelniających na ekranie pojazdu.
Prośba o klucz dostępu w Credential Manager wyświetlana na ekranie w pojeździe z systemem operacyjnym Android Automotive.
Rysunek 5. Prośba o klucz dostępu w Credential Managerze w systemie operacyjnym Android Automotive.

System operacyjny Android Automotive zarządza sesjami i danymi uwierzytelniającymi w ramach profilu, izolując dane sesji specyficzne dla użytkownika między profilami (np. profil A, profil B lub profil gościa).

Korzystanie z Credential Managera w systemie operacyjnym Android Automotive wymaga spełnienia tych warunków:

  • Minimalny poziom API: Android 9 (poziom 28 interfejsu API, minSdkVersion 28) lub nowszy. Pobieranie kluczy dostępu na różnych urządzeniach wymaga Androida 14 (poziom 34 interfejsu API) lub nowszego.
  • Wersja GMS: taka sama jak w przypadku aplikacji mobilnych.

Ograniczenia testowania

Do testowania kluczy dostępu wymagane jest fizyczne urządzenie z systemem operacyjnym Android Automotive jako główny ekran. Instrukcje konfiguracji znajdziesz w artykule Testowanie za pomocą systemu operacyjnego Android Automotive na tablecie Pixel. Emulatorów nie można używać do testowania kluczy dostępu, ponieważ nie obsługują one technologii Bluetooth Low Energy (BLE), która jest wymagana w przypadku hybrydowego procesu FIDO.

Ograniczenia i nieobsługiwane procesy

Korzystanie z Credential Managera w systemie operacyjnym Android Automotive ma te ograniczenia:

  • Brak lokalnego przechowywania i pobierania kluczy dostępu: bezpośrednie lokalne pobieranie kluczy dostępu nie jest obsługiwane, ponieważ pojazdy są urządzeniami wspólnymi. Synchronizowanie kluczy dostępu bezpośrednio z pojazdem stwarza zagrożenie bezpieczeństwa, dlatego klucze dostępu muszą być używane w hybrydowym procesie na różnych urządzeniach.
  • Dane uwierzytelniające dostępne od razu nie są obsługiwane: jeśli aplikacja prosi o klucz dostępu i ustawia wartość preferImmediatelyAvailableCredentials na true, interfejs samochodowy natychmiast się zamyka i zgłasza wyjątek NoCredentialException. W tym scenariuszu zapewnij odpowiedni proces rezerwowy.
  • Brak dostawców danych uwierzytelniających innych firm: menedżerowie haseł innych firm nie są obsługiwani w systemie operacyjnym Android Automotive. Użytkownicy muszą uwierzytelniać się za pomocą Menedżera haseł Google lub hybrydowych procesów na różnych urządzeniach.
  • Brak tworzenia zapisanych haseł: interfejs API nie obsługuje tworzenia i zapisywania nowych zapisanych haseł bezpośrednio z interfejsu samochodu. Tworzenie danych uwierzytelniających jest ograniczone do nowych kluczy dostępu za pomocą hybrydowego procesu FIDO.

Więcej informacji o tworzeniu aplikacji na system operacyjny Automotive znajdziesz w artykule Omówienie systemu operacyjnego Android Automotive overview.

Dodatkowe materiały