Bezproblemowe logowanie i cyfrowe dokumenty tożsamości na Androidzie

Cześć!

Dziękujemy za udział w dzisiejszych warsztatach.

Dzisiaj chcemy porozmawiać o przyszłości uwierzytelniania i tożsamości cyfrowej.

Nazywam się Tom Colvin.

Jestem dyrektorem ds. technologii w Apptaura i ekspertem Google Developer ds. Androida. Jest ze mną Chiping Yeh, starszy inżynier ds. relacji z programistami aplikacji na Androida w Google.

Tradycyjne hasła odchodzą do lamusa.

A przynajmniej tak powinno być.

Dzisiaj opowiem o świecie bez haseł.

Hasła są dobrze znaną luką w naszej infrastrukturze zabezpieczeń.

Nawet jeśli są bezpiecznie przechowywane, są podatne na phishing, naruszenia bezpieczeństwa serwera i automatyczne ataki, takie jak wykorzystywanie przejętych danych logowania w innych serwisach.

Jako branża próbowaliśmy rozwiązać ten problem, wprowadzając wymóg złożoności: znaki specjalne, cyfry, obowiązkowe zmiany.

Dowody wskazują, że to się nie udało, częściowo dlatego, że im bardziej utrudniasz, tym bardziej, paradoksalnie, zachęcasz do niebezpiecznych zachowań.

Złożone hasło, które jest regularnie zmieniane, prawdopodobnie zostanie zapisane na karteczce.

Nawet uwierzytelnianie dwuskładnikowe oparte na SMS-ach okazało się podatne na przechwycenie, np. przez wymianę karty SIM.

Dziś ten problem jest już w dużej mierze rozwiązany.

Klucze dostępu są oparte na standardach FIDO i wykorzystują kryptografię klucza publicznego i prywatnego.

Są bardzo odporne na phishing, nie są narażone na naruszenie bezpieczeństwa serwera i są bezpośrednio powiązane z zabezpieczeniami telefonu użytkownika za pomocą blokady ekranu, która w większości przypadków opiera się na danych biometrycznych, odciskach palców itp. Aktywnie poprawiają też wrażenia użytkowników dzięki ujednoliconemu działaniu na różnych platformach i braku konieczności zapamiętywania skomplikowanych haseł.

Nasz dzisiejszy manifest jest prosty.

Czas przejść do świata bez haseł.

Narzędzia, które nam to umożliwią, są już w naszych rękach.

Kluczowym elementem, który umożliwia wprowadzenie tej zmiany na Androidzie, jest Menedżer danych logowania Jetpack.

Jest on obsługiwany od Androida 4.4, a klucze dostępu od Androida 9. Zapewnia on jeden ujednolicony interfejs API, który obsługuje klucze dostępu oraz tradycyjne uwierzytelnianie, takie jak logowanie sfederowane, np. Zaloguj się przez Google, a w razie potrzeby umożliwia też płynne przełączenie na hasła.

Wywołujesz interfejs Credential Manager API, który obsługuje interfejs użytkownika, aby wybrać metodę uwierzytelniania, którą użytkownik chce zobaczyć.

Następnie wykonuje całą ciężką pracę, aby zwrócić prawidłowe dane logowania, które zostały bezpiecznie uzyskane.

Obsługuje logowanie, rejestrację i tworzenie kopii zapasowych danych logowania.

Możesz go używać do aktualizowania i usuwania danych logowania.

Pomaga też użytkownikom przenosić hasła i klucze dostępu między dostawcami danych logowania za pomocą kilku kliknięć, bez konieczności pobierania plików.

Została zaprojektowana tak, aby zapewnić użytkownikom pełną kontrolę nad ich danymi i swobodę zmiany dostawców, gdy tylko zajdzie taka potrzeba.

Menedżer danych logowania obsługuje wiele formatów, w tym zegarki, telewizory, XR, samochody, telefony, urządzenia składane i tablety.

Co najważniejsze, ma on specjalny proces dotyczący kluczy dostępu.

Oto jak wygląda proces rejestracji z perspektywy użytkownika.

Aplikacja informuje Credential Manager, że uwierzytelnianie za pomocą klucza dostępu jest dostępne, i przekazuje mu szczegółowe informacje zebrane z backendu.

Klikasz Zarejestruj, a Credential Manager wyświetla planszę dolną z prośbą o odblokowanie ekranu.

Najczęściej odblokowuje się go za pomocą danych biometrycznych, takich jak odcisk palca lub skan twarzy.

Następnie Credential Manager zajmuje się złożonymi zadaniami kryptograficznymi, takimi jak tworzenie klucza dostępu.

Zapisuje też klucz dostępu w moim Credential Managerze, którym w tym przypadku jest Menedżer haseł Google, ale może to być też inny menedżer.

Oto jak wygląda kod.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

val createCredentialResponse =  credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

Najpierw tworzymy obiekt createPublicKeyCredentialRequest, używając danych dostarczonych przez backend, czyli registerRequestJson.

Następnie wywołujemy metodę magiczną credentialManager.createCredential.

Przekazujemy to żądanie i kontekst lokalny, co umożliwia wyświetlenie interfejsu.

Zauważ, że nie musieliśmy pisać żadnego kodu interfejsu.

Credential Manager zajmuje się tym za nas.

Tak wygląda proces logowania.

Dla użytkownika wygląda to bardzo podobnie do procesu rejestracji.

Wystarczy jedno kliknięcie i gotowe.

Dla deweloperów, tylko nieco inaczej.

val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
   requestJson = authenticationRequestJson
)
val signInRequest =
   GetCredentialRequest(listOf(getPublicKeyCredentialOption))

val result =  credentialManager.getCredential  (
   context = localActivity,
   request = signInRequest
)

Najpierw pobieramy szczegóły logowania z backendu, aby utworzyć instancję GetPublicKeyCredential.

Informujemy Credential Manager, jakie typy danych logowania obsługujemy.

Tutaj są tylko klucze dostępu.

Możemy też dodać inne rodzaje danych uwierzytelniających, jeśli chcemy.

Następnie wywołujemy metodę credentialManager.getCredential, przekazując listę danych logowania, o którą właśnie poprosiliśmy.

I znów – nie ma kodu interfejsu.

Nie musisz pisać żadnego kodu interfejsu.

Credential Manager zajmuje się tym za nas.

Sugeruje użytkownikowi najczęściej używaną opcję, pozostawiając inne opcje jako zapasowe.

To automatycznie rozwiązuje jeden z najbardziej irytujących problemów z uwierzytelnianiem.

Czy zauważyliście?

To zapamiętywanie metody, której ostatnio użyto do zalogowania się.

Odpowiedź jest ładnie przedstawiona na dolnej planszy.

To nie tylko irytuje użytkownika.

To prawdziwa przeszkoda.

Powoduje to niepotrzebne odzyskiwanie kont i ma wpływ na działalność komercyjną, np. porzucone koszyki.

Oto kod mojej aplikacji demonstracyjnej, którego możesz użyć, aby samodzielnie wypróbować Menedżera danych logowania.

Możesz zobaczyć te procesy na swoim urządzeniu.

Po lewej stronie znajdują się oficjalne przykłady kodu Google.

Zajmuje się on tworzeniem kluczy dostępu.

A co z użytkownikami, którzy obecnie używają haseł? Czy mogą przejść na klucze dostępu?

Skutecznym narzędziem do tego jest warunkowe tworzenie.

Jeśli użytkownik właśnie zalogował się przy użyciu hasła, które zostało automatycznie wypełnione przez obsługiwanego dostawcę danych logowania, wiemy, że jest aktywny, i właśnie zweryfikowaliśmy jego tożsamość.

W takim przypadku warunkowe tworzenie pozwala nam poprosić o automatyczne utworzenie klucza dostępu w tle.

Nie przerywa przepływu pracy użytkownika.

Klucz dostępu jest generowany i zapisywany w tle.

Menedżer haseł Google wyświetli powiadomienie z potwierdzeniem.

Inne menedżery haseł mogą działać inaczej.

Kod warunkowego tworzenia jest bardzo podobny do kodu rejestracji.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson,
   preferImmediatelyAvailableCredentials = false,
   isConditional = true
)

val createCredentialResponse = credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

Flaga magic fla-- ma wartość isConditional true, co gwarantuje, że użytkownik nie zobaczy tego interfejsu.

Ponieważ działa on oportunistycznie, umieścimy go w bloku try-catch.

Błędy będziemy obsługiwać w tle, aby nie przeszkadzać użytkownikowi, jeśli proces się nie powiedzie.

Następnie klucz dostępu jest zapisywany w Menedżerze danych logowania użytkownika i jest tam dostępny przy następnym logowaniu.

Menedżer danych logowania umożliwia też dostawcom danych logowania bezpieczne importowanie i eksportowanie danych logowania.

Wystarczy kilka kliknięć.

Nie musisz nic pobierać.

Zapewnia to większą elastyczność, a jednocześnie chroni dane.

Proces wygląda tak:

Użytkownik prosi o zaimportowanie danych logowania w nowym dostawcy danych logowania.

Następnie Credential Manager obsługuje interfejs importowania, umożliwiając użytkownikowi wybranie źródła danych logowania.

Dostawca danych logowania, który eksportuje dane, może następnie udostępnić własny interfejs, co pozwala mu przekazać użytkownikowi informacje i odpowiednie ostrzeżenia.

Na koniec nowy dostawca danych logowania użytkownika otrzymuje dane przez bezpieczny kanał.

Dzięki temu może je importować bez interakcji ze strony użytkownika.

Ale co się stanie, jeśli użytkownik unieważni klucz dostępu w aplikacji lub witrynie?

Dostawca danych logowania nie musi o tym wiedzieć.

Gdy następnym razem spróbują się zalogować, Credential Manager zaproponuje ten nieaktywny klucz dostępu, a próba logowania zostanie odrzucona.

Podobnie, gdy użytkownik aktualizuje swoją nazwę użytkownika lub wyświetlaną nazwę, wymagana jest synchronizacja.

Teraz dzięki interfejsowi Signal API aplikacja może oznaczać te konkretne stany dla dostawcy danych logowania.

Weźmy na przykład sytuację, w której użytkownik loguje się przy użyciu unieważnionego hasła.

Aplikacja może wykryć ten konkretny stan błędu i użyć go do poinformowania dostawcy danych logowania użytkownika.

Dostawca danych logowania może następnie zaktualizować swoje dane, aby ten klucz dostępu nie był oferowany.

To niektóre z funkcji Menedżera danych logowania. Jest on niezwykle pomocny przy rejestrowaniu użytkowników za pomocą kluczy dostępu i priorytetowym traktowaniu kluczy dostępu nad innymi metodami podczas logowania.

Pamiętaj jednak, że naszym ostatecznym celem jest całkowite wyeliminowanie haseł.

W jaki sposób Credential Manager pomaga osiągnąć ten cel?

Oto proponowany przez nas proces składający się z 5 kroków.

W pierwszych 2 krokach uaktualnisz użytkowników haseł do kluczy dostępu.

Najpierw próbujemy utworzyć zasób, używając warunkowego tworzenia.

Jeśli taka okazja się nie nadarzy, będziemy musieli poprosić użytkownika o interwencję, czyli wyświetlić w aplikacji zaproszenie do skonfigurowania klucza dostępu.

Możemy stopniowo zacząć wyświetlać je coraz częściej i w bardziej widoczny sposób.

Z perspektywy użytkownika zwykle wystarczy tylko podać blokadę ekranu, np. dane biometryczne.

Gdy statystyki wykażą, że zdecydowana większość użytkowników ma konta z kluczami dostępu, można wymagać kluczy dostępu od wszystkich nowych użytkowników.

W ostatnich 3 krokach zajmiemy się tymi starymi użytkownikami.

Zachęcamy użytkowników kluczy dostępu do usunięcia haseł.

Dlatego w kroku 3 umożliwiamy im zrobienie tego ręcznie za pomocą bardzo przejrzystej opcji Usuń hasło w ustawieniach konta.

W kroku 4 zaczynamy zachęcać do usunięcia hasła, na przykład za pomocą powiadomień w aplikacji i materiałów edukacyjnych.

Na koniec zmieniasz ustawienie usuwania haseł z opcji wymagającej zgody na opcję wymagającą rezygnacji.

Z czasem nawet ta ostatnia opcja rezygnacji może zniknąć.

Dzięki statystykom będziemy mogli bez obaw całkowicie usunąć z aplikacji procesy związane z hasłami.

Przejście na świat bez haseł nie jest już więc teoretyczną koncepcją bezpieczeństwa, która może kiedyś zostanie zrealizowana.

Jest to bardzo popularny format.

Interfejsy API są niezawodne, a wrażenia użytkowników – doskonałe.

Zachęcam do rozpoczęcia integracji procesów kluczy dostępu z Credential Manager już dziś.

Zacznij uaktualniać konta użytkowników i pożegnaj się z hasłami.

Dziękujemy.

Teraz przekażę głos Chipingowi, który opowie o kolejnym etapie rozwoju migracji i tożsamości urządzeń.

Świetnie.

Dziękuję, Tom.

Jak podkreślił Tom, płynne uwierzytelnianie na urządzeniach użytkowników ma kluczowe znaczenie.

Ale co się stanie, gdy użytkownik zmieni telefon na nowy?

Obecnie największy spadek na ścieżce użytkownika występuje często, gdy przełącza się on między urządzeniami.

Dzisiaj chcę najpierw opowiedzieć o tym, jak rozwiązujemy ten problem, a potem krótko omówić nadchodzące wymaganie Sklepu Play dotyczące przywracania danych logowania.

Od kwietnia 2027 r. Google Play będzie wymagać, aby aplikacje spełniały wymagania dotyczące logowania bez interakcji, aby zachować pełne możliwości publikowania i optymalną widoczność w Sklepie Play.

Czym jest logowanie bez interakcji?

W praktyce oznacza to, że użytkownicy nie muszą ręcznie ponownie uwierzytelniać się w aplikacji po przejściu na nowe urządzenie.

Jak to zrobić?

Zalecamy korzystanie z interfejsu Android Restore Credentials API za pomocą Menedżera danych logowania.

Ten interfejs API umożliwia wygenerowanie tzw. klucza przywracania, który jest zapisywany na urządzeniu użytkownika lub w chmurze na podstawie ustawień kopii zapasowej użytkownika.

Zalecamy wygenerowanie tego klucza w tle po zalogowaniu się użytkownika.

Na tym diagramie przedstawiamy użytkownika logującego się w aplikacji.

Następnie klucz przywracania jest tworzony, gdy użytkownik korzysta z aplikacji.

Ten klucz jest następnie przechowywany lokalnie lub, jeśli ta opcja jest włączona, zdalnie w chmurze.

Gdy użytkownik konfiguruje nowe urządzenie, dane logowania do przywracania są w sposób niezauważalny dla użytkownika przenoszone w tle podczas procesu konfiguracji urządzenia.

Użytkownicy mogą przywrócić dane z chmury lub przenieść je bezpośrednio z innego urządzenia.

Następnie, gdy aplikacja zostanie otwarta, możesz wywołać interfejs Credential Manager API, aby użyć tego klucza przywracania do zalogowania użytkownika na nowym urządzeniu przy pierwszym uruchomieniu.

Dzięki temu użytkownik może szybko i bezpiecznie zalogować się w aplikacji.

Jeśli chcesz, aby aplikacja została przywrócona natychmiast po konfiguracji bez otwierania, możesz w tym celu wdrożyć niestandardowego agenta kopii zapasowej.

Dzięki temu użytkownik będzie mógł zalogować się w aplikacji bez konieczności jej ręcznego otwierania.

Niektórzy z naszych partnerów już wdrożyli to rozwiązanie w swoich aplikacjach.

Uber to największa na świecie firma oferująca wspólne przejazdy, która zapewnia transport milionom osób, a także wspiera dostawę jedzenia, transport medyczny i logistykę towarową.

Łatwy dostęp jest kluczowy.

Gdy użytkownicy przechodzą na nowe urządzenie, oczekują płynnego przejścia bez konieczności ponownego logowania się w aplikacji Uber lub przechodzenia przez jednorazowe uwierzytelnianie SMS-em za każdym razem.

Częsta wymiana urządzeń stanowi wyzwanie dla utrzymania użytkowników.

Po ocenie zapotrzebowania użytkowników i prototypowaniu kodu Uber wprowadził obsługę przywracania danych logowania w aplikacji Uber Rider, co przyniosło bardzo pozytywne wyniki.

Szacują, że pozwoli to zaoszczędzić 4 miliony średnich dziennych logowań, i spodziewają się, że ta liczba będzie rosła wraz ze wzrostem popularności.

Zeskanuj ten kod QR i kliknij link, aby dowiedzieć się więcej o tych nowych zasadach i o tym, jak Twoja aplikacja może spełnić wymagania dotyczące przywracania bez kliknięcia.

Przypominamy, że nastąpi to w kwietniu 2027 r., więc zaznacz tę datę w kalendarzu.

Jeśli chcesz zacząć wdrażać funkcję przywracania danych logowania w swojej aplikacji, zeskanuj ten kod QR i kliknij link, aby uzyskać dostęp do umiejętności przywracania danych logowania.

Możesz jej użyć, aby szybko opracować lub przetestować funkcję z wybranym agentem.

Teraz przyjrzyjmy się kolejnemu etapowi rozwoju tożsamości cyfrowej: interfejsowi Digital Credentials API w ramach Menedżera danych logowania.

Omówimy, czym są cyfrowe plakietki i jak działają.

Cyfrowe dokumenty tożsamości to dokumenty cyfrowe, które można zweryfikować kryptograficznie i których użytkownicy mogą używać do podawania informacji o sobie.

Te dokumenty są przechowywane w cyfrowych uchwytach na urządzeniu użytkownika i mogą być wymagane przez inne aplikacje na urządzeniu lub prezentowane światu w sposób hybrydowy, np. za pomocą kodu QR.

Zastosowania są szerokie i różnorodne – od weryfikacji tożsamości po dostęp do usług i zakupy online.

Cyfrowe dokumenty tożsamości to bezpieczny i wygodny sposób udostępniania informacji bez konieczności posiadania fizycznych kart.

W przypadku cyfrowych dokumentów tożsamości występują 3 strony: wydawca, posiadacz i weryfikator.

Cykl życia cyfrowego dokumentu tożsamości przebiega zwykle od lewej do prawej.

Omówmy każdy z tych podmiotów i jego rolę.

Pierwszy to wydawca, czyli podmiot, który wydaje dokument, tak jak urząd wydaje paszport.

Jednak w świecie cyfrowym, aby zapobiec podszywaniu się, te dane uwierzytelniające są również podpisywane przez wydawcę za pomocą certyfikatu cyfrowego, dzięki czemu każdy, kto je otrzyma, może dokładnie wiedzieć, od kogo pochodzą.

Wydawcą może być każdy – siłownia, hotel, a nawet Ty.

Wystarczy utworzyć dane logowania i je podpisać.

Wydawca tworzy i wydaje dane uwierzytelniające, ale muszą one być gdzieś przechowywane, tak jak dokument tożsamości w portfelu.

Jest to kolejna strona, która jest nazywana posiadaczem, a często też cyfrowym portfelem.

Posiadacze, jak sama nazwa wskazuje, przechowują głównie dane uwierzytelniające wydane przez wydawców.

Są one przechowywane w aplikacji na urządzeniu i można je okazywać osobom, które o to poproszą.

Podobnie jak w przypadku wydawców, posiadaczem może być każdy.

Wydawcy i posiadacze są często zarządzani przez ten sam podmiot.

Wyobraź sobie siłownię, która chce utworzyć własną cyfrową kartę członkowską i zarządzać nią za pomocą własnej aplikacji.

To byłby zarówno wydawca, jak i posiadacz.

Weryfikator to firma zewnętrzna, która prosi o cyfrowe dokumenty tożsamości.

Weryfikatorzy wysyłają żądania dotyczące danych uwierzytelniających, aby sprawdzić atrybuty użytkownika, takie jak wymagania dotyczące wieku czy nazwisko.

Są to firmy lub aplikacje, które potrzebują dodatkowych danych użytkownika, aby świadczyć usługę, np. zakup alkoholu lub weryfikację minimalnego wieku.

Na Androidzie interakcje między tymi 3 stronami a użytkownikiem są koordynowane przez Credential Manager za pomocą interfejsu Digital Credentials API.

Wydawca może wywołać interfejs API, aby wydać dane uwierzytelniające posiadaczowi, chociaż nie jest to konieczne, jeśli jest to ten sam podmiot.

Po wydaniu dokumentu weryfikator może wywołać interfejs API, aby poprosić o dokument.

Credential Manager dopasowuje żądanie do wszystkich dostępnych posiadaczy i prezentuje je użytkownikowi, aby mógł wybrać dane logowania i wyrazić zgodę.

Po wybraniu posiadacza jest on wywoływany i w razie potrzeby może przeprowadzić dodatkowe kontrole, zanim ostatecznie udostępni dane weryfikatorowi.

Po otrzymaniu dokumentu weryfikator może też przeprowadzić różne kontrole jego autentyczności, w tym sprawdzić pierwotnego wystawcę.

Być może zastanawiasz się, jak dokładnie zabezpieczone są cyfrowe dokumenty tożsamości.

Zabezpieczenia są wbudowane w każdy etap tego procesu. Omówimy teraz niektóre z nich.

Dlatego po stronie wydawcy, gdy chce on udostępnić dokument posiadaczowi, musi sprawdzić, czy nie można go sfałszować ani skopiować, czyli czy można mu zaufać.

Jak może to zweryfikować?

Zanim wydawca wyda dokument, musi poprosić posiadacza o potwierdzenie tożsamości i bezpieczeństwa urządzenia, na którym działa.

Posiadacz wysyła atestację portfela, zwykle w postaci możliwego do zweryfikowania łańcucha certyfikatów.

Posiadacz generuje też parę kluczy powiązanych ze sprzętem.

Wysyła do wydawcy klucz publiczny z tej pary kluczy z atestacją kluczy Androida, aby wydawca mógł zweryfikować autentyczność sprzętu.

Wydawca podpisze ten klucz publiczny w wydanym dokumencie, aby dokument był oficjalnie powiązany z jednym urządzeniem.

Po stronie posiadacza, gdy ma on nowe dane logowania, rejestruje on tylko metadane danych logowania w Credential Manager.

Credential Manager używa tych metadanych do określenia, które dokumenty mają być wyświetlane, gdy weryfikator wysyła żądanie danych logowania.

Żadne rzeczywiste dane użytkownika nie są rejestrowane w Credential Manager ani ujawniane Google.

Nawet gdy Menedżer danych logowania wybiera portfele, które mają być wyświetlane użytkownikowi, zawartość każdego portfela nie jest w tym momencie ujawniana.

Teraz, gdy zostanie wysłane żądanie danych logowania, a użytkownik wyrazi zgodę na ich udostępnienie, zostanie wywołany wybrany posiadacz, a kontrola nad przepływem pracy zostanie mu przekazana.

Jak pamiętasz, posiadacz to tylko aplikacja, więc aplikacja jest wywoływana.

W tym momencie posiadacz może zobaczyć m.in. weryfikatora, który wysłał prośbę, oraz żądane dane uwierzytelniające. Może też zdecydować, czy chce udostępnić te dane weryfikatorowi, nawet jeśli użytkownik już wyraził na to zgodę.

Google nie ma dostępu do samych danych logowania.

Rejestrowane są tylko metadane routingu, a ładunek jest w pełni szyfrowany między posiadaczem a weryfikatorem.

Dzięki temu posiadacz ma kontrolę nad tym, komu chce udostępniać swoje dane uwierzytelniające.

Na koniec, po stronie weryfikatora, po przesłaniu prośby o dokument i udostępnieniu go przez posiadacza, weryfikator otrzymuje dokument od posiadacza.

Teraz weryfikator może sprawdzić, czy odpowiedź została wygenerowana przez pierwotnego posiadacza dokumentu tożsamości na potrzeby żądania.

Może potwierdzić, że odpowiedź dotycząca danych uwierzytelniających jest podpisana za pomocą klucza powiązanego z urządzeniem posiadacza, w tym poprosić o token jednorazowy i wywołać źródło obserwowane przez posiadacza.

Weryfikator może też sprawdzić autentyczność wydawcy dokumentu, weryfikując jego certyfikat i upewniając się, że pochodzi on z zaufanego źródła.

Krótko mówiąc, wydawcy otrzymują gwarancje sprzętowe, posiadacze mają kontrolę nad tym, które dane uwierzytelniające chcą udostępniać, weryfikatorzy otrzymują kryptograficzny dowód wydawcy i posiadacza, a użytkownicy zachowują pełną kontrolę nad tym, które dane chcą udostępniać.

Wiemy już, dlaczego cyfrowe dokumenty tożsamości są bezpieczne. Teraz omówmy niektóre przypadki użycia cyfrowych dokumentów tożsamości, które są obecnie dostępne za pomocą interfejsu Digital Credentials API na Androidzie.

Pierwsza z nich to potwierdzanie adresu e-mail.

Ten interfejs API pobiera adres Gmail zalogowanego użytkownika bezpośrednio z jego urządzenia i przedstawia go aplikacji jako zweryfikowane przez Google cyfrowe dane uwierzytelniające, co eliminuje konieczność wysyłania haseł jednorazowych lub magicznych linków.

Oznacza to, że użytkownik nigdy nie opuszcza aplikacji i musi tylko raz kliknąć, aby wyrazić zgodę na znanej mu dolnej planszy Credential Manager.

Oto nagranie demonstracyjne interfejsu API w działaniu.

To jest przykładowa aplikacja, która implementuje potwierdzanie adresu e-mail za pomocą interfejsu Digital Credentials API.

Gdy kliknę „Poproś o zweryfikowany adres e-mail”, Credential Manager poprosi o zweryfikowany cyfrowy dokument tożsamości z adresem e-mail z posiadaczy na urządzeniu, którzy mają ten typ dokumentu.

W tym przypadku tylko Google jest posiadaczem tych zweryfikowanych danych logowania, które są widoczne na planszy dolnej.

Jest to jeden z adresów e-mail, na które użytkownik jest zalogowany na urządzeniu.

W tym przypadku Google jest zarówno wydawcą, jak i posiadaczem cyfrowego dokumentu tożsamości.

Gdy wybiorę dane logowania, które chcę udostępnić, zostaną one zwrócone do aplikacji, która obecnie wyświetla tylko pola zawarte w danych logowania, czyli zweryfikowany adres e-mail.

W aplikacji możesz użyć tych informacji, aby przejść do następnego ekranu, np. do tworzenia klucza dostępu lub innych kroków tworzenia konta.

Dla użytkownika jest to bardzo proste – wystarczy, że wyrazi zgodę i przejdzie do następnego ekranu.

Jeśli chcesz wypróbować tę funkcję, możesz przejść do naszego przykładu na GitHubie i zainstalować go na swoim urządzeniu.

Spróbuj użyć jej na urządzeniu fizycznym. Pamiętaj, że musisz zalogować się na co najmniej 1 konto Gmail na urządzeniu.

Jeśli więc ktoś jest zainteresowany, dam mu trochę więcej czasu.

OK.

Brzmi ekscytująco, prawda?

A gdy myślisz o potwierdzaniu adresu e-mail, jaka jest następna forma weryfikacji użytkownika, która przychodzi Ci na myśl?

Zgadza się, weryfikacja numeru telefonu.

Interfejs Digital Credentials API obsługuje też natywnie weryfikację numeru telefonu, co eliminuje problemy i luki w zabezpieczeniach związane z hasłami jednorazowymi wysyłanymi SMS-em.

Weryfikacja numeru telefonu również odbywa się za pomocą interfejsu Digital Credentials API. W tym przypadku numer telefonu na urządzeniu jest żądany i prezentowany jako cyfrowy dokument tożsamości.

Użytkownik widzi tylko znaną planszę dolną Credential Managera, na której może udostępnić lub zweryfikować swój numer telefonu. Nie musi opuszczać aplikacji, a do ukończenia weryfikacji wystarczy kilka kliknięć.

Oto przykładowa aplikacja, w której klient może udostępnić swój numer telefonu jednym kliknięciem, bez opuszczania aplikacji.

Jak działa ta konfiguracja?

Jeśli przypiszemy to do stron cyfrowych dokumentów tożsamości, wydawcą w tym przypadku jest operator numeru telefonu na karcie SIM urządzenia, a posiadaczem jest Android Telephony.

Gdy weryfikator, np. Twoja aplikacja, prosi o numer telefonu użytkownika, jest on pobierany z Google Telephony za pomocą wywołania interfejsu Digital Credentials API.

Możesz się zastanawiać, jak działają płatności.

W tym procesie występuje dodatkowy krok, który polega na przekazaniu danych uwierzytelniających operatorowi lub agregatorowi na potrzeby rozliczeń.

Dzieje się tak po pobraniu numeru telefonu z usługi Google Telephony, gdzie jest on przechowywany w zaszyfrowanej postaci.

Następnie jest on przekazywany operatorowi, który go odszyfrowuje i zwraca numer telefonu bezpośrednio do backendu aplikacji. W tym momencie następuje naliczenie opłaty.

Zaletą tego rozwiązania jest to, że operator pobiera opłaty tylko za udane weryfikacje, które są przesyłane przez transmisję danych lub Wi-Fi i są znacznie bardziej niezawodne niż SMS-y.

Oto demonstracja weryfikacji numeru telefonu w działaniu, w której Firebase jest używany jako agregator operatorów.

Aplikacja prosi o numer telefonu użytkownika w ramach procesu logowania.

Użytkownik ma kilka kart SIM i wybiera jedną, którą chce udostępnić aplikacji.

Gdy użytkownik potwierdzi swój wybór, wymiana nastąpi w tle.

Następnie zobaczysz kolejny ekran z pobranym numerem telefonu.

Użytkownik nie musiał opuszczać aplikacji, a jedynie wybrać i potwierdzić numer telefonu, który chciał udostępnić, aby płynnie przejść przez cały proces za pomocą kilku kliknięć.

Poczekaj, aż się zakończy, aby zobaczyć, jak to wygląda.

Na ostatnim ekranie zobaczysz numer telefonu.

To wszystko.

Omówiliśmy dziś wiele zagadnień.

Najpierw omówiliśmy użycie Menedżera danych logowania do ulepszenia implementacji kluczy dostępu i przejścia do świata bez haseł.

Więcej informacji o Menedżerze danych logowania i kluczach dostępu oraz dostęp do przykładowych aplikacji znajdziesz w naszych materiałach.

Następnie omówiliśmy nadchodzące wymaganie dotyczące logowania jednym kliknięciem w aplikacjach, które ułatwia użytkownikom logowanie się podczas konfigurowania nowego urządzenia.

W Sklepie Play będzie to obowiązkowe od kwietnia 2027 r., więc warto zapisać tę datę w kalendarzu.

Na koniec omówiliśmy, jak działają cyfrowe dokumenty tożsamości i jakie są ich najbardziej przydatne funkcje na Androidzie.

Aby dowiedzieć się więcej o treściach i uzyskać dostęp do naszych przykładów, zapoznaj się z naszymi materiałami na temat cyfrowych dokumentów tożsamości.

Wszystko, o czym dzisiaj mówiliśmy, jest już dostępne i możesz z tego korzystać.

Przyszłość tożsamości na Androidzie jest już tutaj i jest bardziej ekscytująca niż kiedykolwiek wcześniej.

Dziękuję za poświęcony czas. Wiem, że jest pora lunchu, więc zapraszam na poczęstunek na zewnątrz.

Jeśli masz pytania dotyczące kluczy dostępu lub cyfrowych danych uwierzytelniających, nie wahaj się skontaktować ze mną lub z Tomem.

Pozdrawiam