Case Studies
Dzięki integracji kluczy dostępu i Menedżera danych logowania firma Zoho 6-krotnie przyspieszyła logowanie
10 min czytania
Jako deweloper Androida nieustannie szukasz sposobów na zwiększenie bezpieczeństwa, poprawę wrażeń użytkowników i usprawnienie procesu tworzenia aplikacji. Firma Zoho, która oferuje kompleksowy pakiet oprogramowania w chmurze, skupia się na bezpieczeństwie i płynnej obsłudze. Dzięki wprowadzeniu kluczy dostępu w aplikacji na Androida OneAuth firma ta osiągnęła znaczną poprawę.
Od czasu zintegrowania kluczy dostępu w 2024 r. firma Zoho osiągnęła szybkość logowania nawet 6-krotnie większą niż w przypadku poprzednich metod oraz 31% wzrost liczby użytkowników korzystających z kluczy dostępu w porównaniu z poprzednim miesiącem.
W tym studium przypadku analizujemy, jak firma Zoho wdrożyła klucze dostępu i interfejs Credential Manager API na Androidzie, aby rozwiązać problemy z uwierzytelnianiem. Opisujemy w nim proces implementacji technicznej i podkreślamy znaczące rezultaty.
Pokonywanie wyzwań związanych z uwierzytelnianiem
Firma Zoho stosuje kombinację metod uwierzytelniania, aby chronić konta użytkowników. Obejmuje to Zoho OneAuth, czyli własne rozwiązanie do uwierzytelniania wieloskładnikowego, które obsługuje uwierzytelnianie za pomocą hasła i bez hasła przy użyciu powiadomień push, kodów QR i jednorazowych haseł czasowych. Firma Zoho obsługuje też logowanie federacyjne, które umożliwia uwierzytelnianie za pomocą języka SAML i innych dostawców tożsamości.
Wyzwania
Firma Zoho, podobnie jak wiele innych organizacji, chciała zwiększyć bezpieczeństwo uwierzytelniania i poprawić wrażenia użytkowników, a jednocześnie zmniejszyć obciążenie operacyjne. Główne wyzwania, które doprowadziły do wprowadzenia kluczy dostępu, to:
- Luki w zabezpieczeniach: tradycyjne metody oparte na hasłach narażały użytkowników na ataki phishingowe i naruszenia bezpieczeństwa haseł.
- Problemy z użytkownikami: zmęczenie hasłami prowadziło do zapominania haseł, frustracji i większego polegania na uciążliwych procesach odzyskiwania.
- Niska wydajność operacyjna: obsługa resetowania haseł i problemów z uwierzytelnianiem wieloskładnikowym generowała znaczne koszty związane z obsługą.
- Problemy ze skalowalnością: rosnąca baza użytkowników wymagała bezpieczniejszego i wydajniejszego rozwiązania do uwierzytelniania.
Dlaczego warto przejść na klucze dostępu?
Klucze dostępu zostały wdrożone w aplikacjach Zoho, aby rozwiązać problemy z uwierzytelnianiem. Oferują one podejście bez hasła, które znacznie zwiększa bezpieczeństwo i poprawia wrażenia użytkowników. To rozwiązanie wykorzystuje uwierzytelnianie odporne na phishing, dane logowania synchronizowane w chmurze, które umożliwiają łatwy dostęp na różnych urządzeniach, oraz dane biometryczne (np. odcisk palca lub rozpoznawanie twarzy), kod PIN lub wzór do bezpiecznego logowania. Dzięki temu zmniejsza się liczba luk w zabezpieczeniach i niedogodności związanych z tradycyjnymi hasłami.
Dzięki wprowadzeniu kluczy dostępu za pomocą Menedżera danych logowania firma Zoho skróciła czas logowania nawet 6-krotnie, zmniejszyła koszty związane z obsługą haseł i odnotowała duże zainteresowanie użytkowników – podwoiła liczbę logowań za pomocą kluczy dostępu w ciągu 4 miesięcy, osiągając 31% wzrost w porównaniu z poprzednim miesiącem. Użytkownicy Zoho mogą teraz korzystać z szybszego i łatwiejszego logowania oraz zabezpieczeń odpornych na phishing.
Implementacja za pomocą Menedżera danych logowania na Androidzie
Jak firma Zoho osiągnęła te wyniki? Użyła interfejsu Credential Manager API na Androidzie, czyli zalecanej biblioteki Jetpack do implementowania uwierzytelniania na Androidzie.
Menedżer danych logowania udostępnia ujednolicony interfejs API, który upraszcza obsługę różnych metod uwierzytelniania. Zamiast korzystać z różnych interfejsów API do obsługi haseł, kluczy dostępu i logowania federacyjnego (np. Zaloguj się przez Google), możesz używać jednego interfejsu.
Wdrożenie kluczy dostępu w Zoho wymagało wprowadzenia zmian zarówno po stronie klienta, jak i serwera. Oto szczegółowe omówienie procesu tworzenia kluczy dostępu, logowania i implementacji po stronie serwera.
Tworzenie kluczy dostępu
Aby utworzyć klucz dostępu, aplikacja najpierw pobiera szczegóły konfiguracji z serwera Zoho. Ten proces obejmuje unikalną weryfikację, np. za pomocą odcisku palca lub rozpoznawania twarzy. Te dane weryfikacyjne, sformatowane jako ciąg requestJson, są używane przez aplikację do utworzenia CreatePublicKeyCredentialRequest. Następnie aplikacja wywołuje metodę credentialManager.createCredential, która wyświetla użytkownikowi prośbę o uwierzytelnienie za pomocą blokady ekranu urządzenia (danych biometrycznych, odcisku palca, kodu PIN itp.).
Po pomyślnym potwierdzeniu przez użytkownika aplikacja otrzymuje nowe dane logowania za pomocą klucza dostępu, wysyła je z powrotem na serwer Zoho w celu weryfikacji, a serwer zapisuje informacje o kluczu dostępu powiązane z kontem użytkownika. Aplikacja wykrywa i obsługuje błędy lub anulowanie przez użytkownika podczas tego procesu.
Zaloguj się
Aplikacja Zoho na Androida inicjuje proces logowania za pomocą klucza dostępu, wysyłając do serwera backendu Zoho prośbę o opcje logowania, w tym unikalne challenge. Następnie aplikacja używa tych danych do utworzenia GetCredentialRequest, wskazując, że będzie uwierzytelniać się za pomocą klucza dostępu. Następnie wywołuje interfejs CredentialManager.getCredential() API na Androidzie z tym żądaniem. Ta czynność powoduje wyświetlenie standardowego interfejsu systemu Android, który prosi użytkownika o wybranie konta Zoho (jeśli istnieje kilka kluczy dostępu) i uwierzytelnienie za pomocą skonfigurowanej blokady ekranu urządzenia (odcisku palca, skanu twarzy lub kodu PIN). Po pomyślnym uwierzytelnieniu Menedżer danych logowania zwraca do aplikacji Zoho podpisane potwierdzenie (dowód logowania). Aplikacja przekazuje to potwierdzenie na serwer Zoho, który weryfikuje podpis za pomocą zapisanego klucza publicznego użytkownika i sprawdza challenge, co kończy bezpieczny proces logowania.
Implementacja po stronie serwera
Przejście firmy Zoho na obsługę kluczy dostępu było łatwiejsze dzięki temu, że systemy backendu były już zgodne ze standardem FIDO WebAuthn, co usprawniło proces implementacji po stronie serwera. Aby w pełni zintegrować funkcję kluczy dostępu, konieczne było jednak wprowadzenie pewnych zmian.
Największym wyzwaniem było dostosowanie magazynu danych logowania. Dotychczasowe metody uwierzytelniania w Zoho, które do uwierzytelniania wieloskładnikowego wykorzystywały głównie hasła i klucze bezpieczeństwa FIDO, wymagały innych metod przechowywania niż klucze dostępu, które są oparte na kryptograficznych kluczach publicznych. Aby rozwiązać ten problem, firma Zoho wdrożyła nowy schemat bazy danych, który został zaprojektowany specjalnie do bezpiecznego przechowywania kluczy publicznych kluczy dostępu i powiązanych danych zgodnie z protokołami WebAuthn. Ten nowy system został zbudowany wraz z mechanizmem wyszukiwania, który umożliwia sprawdzanie i pobieranie danych logowania na podstawie informacji o użytkowniku i urządzeniu, co zapewnia zgodność wsteczną ze starszymi metodami uwierzytelniania.
Kolejną zmianą po stronie serwera było wdrożenie możliwości obsługi żądań z urządzeń z Androidem. Żądania kluczy dostępu pochodzące z aplikacji na Androida używają unikalnego formatu źródła (android:apk-key-hash:example), który różni się od standardowych źródeł internetowych używających formatu opartego na URI (https://example.com/app). Logika serwera musiała zostać zaktualizowana, aby prawidłowo analizować ten format, wyodrębniać skrót SHA-256 certyfikatu podpisywania aplikacji i sprawdzać go na podstawie wstępnie zarejestrowanej listy. Ten krok weryfikacji zapewnia, że żądania uwierzytelniania rzeczywiście pochodzą z aplikacji Zoho na Androida, i chroni przed atakami phishingowymi.
Ten fragment kodu pokazuje, jak serwer sprawdza format źródła specyficzny dla Androida i weryfikuje skrót certyfikatu:
val origin: String = clientData.getString("origin")
if (origin.startsWith("android:apk-key-hash:")) {
val originSplit: List<String> = origin.split(":")
if (originSplit.size > 3) {
val androidOriginHashDecoded: ByteArray = Base64.getDecoder().decode(originSplit[3])
if (!androidOriginHashDecoded.contentEquals(oneAuthSha256FingerPrint)) {
throw IAMException(IAMErrorCode.WEBAUTH003)
}
} else {
// Optional: Handle the case where the origin string is malformed }
}
Obsługa błędów
Firma Zoho wdrożyła niezawodne mechanizmy obsługi błędów, aby zarządzać błędami widocznymi dla użytkowników i deweloperów. Częsty błąd CreateCredentialCancellationException pojawiał się, gdy użytkownicy ręcznie anulowali konfigurację klucza dostępu. Firma Zoho śledziła częstotliwość występowania tego błędu, aby ocenić potencjalne ulepszenia UX. Na podstawie zaleceń dotyczących UX na Androidzie firma Zoho podjęła kroki, aby lepiej informować użytkowników o kluczach dostępu, upewnić się, że użytkownicy wiedzą o dostępności kluczy dostępu, i zachęcać do ich używania podczas kolejnych prób logowania.
Ten przykład kodu pokazuje, jak firma Zoho obsługiwała najczęstsze błędy tworzenia kluczy dostępu:
private fun handleFailure(e: CreateCredentialException) {
val msg = when (e) {
is CreateCredentialCancellationException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_CANCELLED", GROUP_NAME)
Analytics.addNonFatalException(e)
"The operation was canceled by the user."
}
is CreateCredentialInterruptedException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_INTERRUPTED", GROUP_NAME)
Analytics.addNonFatalException(e)
"Passkey setup was interrupted. Please try again."
}
is CreateCredentialProviderConfigurationException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_PROVIDER_MISCONFIGURED", GROUP_NAME)
Analytics.addNonFatalException(e)
"Credential provider misconfigured. Contact support."
}
is CreateCredentialUnknownException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_UNKNOWN_ERROR", GROUP_NAME)
Analytics.addNonFatalException(e)
"An unknown error occurred during Passkey setup."
}
is CreatePublicKeyCredentialDomException -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_WEB_AUTHN_ERROR", GROUP_NAME)
Analytics.addNonFatalException(e)
"Passkey creation failed: ${e.domError}"
}
else -> {
Analytics.addAnalyticsEvent(eventProtocol: "PASSKEY_SETUP_FAILED", GROUP_NAME)
Analytics.addNonFatalException(e)
"An unexpected error occurred. Please try again."
}
}
}
Testowanie kluczy dostępu w środowiskach intranetowych
Początkowo firma Zoho miała problem z testowaniem kluczy dostępu w zamkniętym środowisku intranetowym. Proces weryfikacji kluczy dostępu w Menedżerze haseł Google wymaga dostępu do domeny publicznej, aby sprawdzić domenę strony ufającej. Jednak wewnętrzne środowisko testowe Zoho nie miało dostępu do publicznego internetu, co powodowało niepowodzenie procesu weryfikacji i utrudniało testowanie uwierzytelniania za pomocą kluczy dostępu. Aby rozwiązać ten problem, firma Zoho utworzyła publicznie dostępne środowisko testowe, które obejmowało hostowanie tymczasowego serwera z plikiem assetlinks i weryfikacją domeny.
Ten przykład z pliku assetlinks.json używanego w publicznym środowisku testowym Zoho pokazuje, jak powiązać domenę strony ufającej z określoną aplikacją na Androida na potrzeby weryfikacji klucza dostępu.
[
{
"relation": [
"delegate_permission/common.handle_all_urls",
"delegate_permission/common.get_login_creds"
],
"target": {
"namespace": "android_app",
"package_name": "com.zoho.accounts.oneauth",
"sha256_cert_fingerprints": [
"SHA_HEX_VALUE"
]
}
}
]
Integracja z istniejącym serwerem FIDO
System kluczy dostępu na Androidzie korzysta z nowoczesnego standardu FIDO2 WebAuthn. Ten standard wymaga, aby żądania były w określonym formacie JSON, co pomaga zachować spójność między aplikacjami natywnymi a platformami internetowymi. Aby włączyć obsługę kluczy dostępu na Androidzie, firma Zoho wprowadziła drobne zmiany w zakresie zgodności i struktury, aby prawidłowo generować i przetwarzać żądania zgodne z wymaganą strukturą JSON FIDO2.
Ta aktualizacja serwera obejmowała kilka konkretnych zmian technicznych:
1. Konwersja kodowania: serwer konwertuje kodowanie Base64 URL (często używane w WebAuthn w przypadku pól takich jak identyfikatory danych logowania) na standardowe kodowanie Base64 przed zapisaniem odpowiednich danych. Poniższy fragment kodu pokazuje, jak można zakodować rawId do standardowego formatu Base64:
// Convert rawId bytes to a standard Base64 encoded string for storage val base64RawId: String = Base64.getEncoder().encodeToString(rawId.toByteArray())
2. Format listy transportu: aby zapewnić spójne przetwarzanie danych, logika serwera obsługuje listy mechanizmów transportu (takich jak USB, NFC i Bluetooth, które określają sposób komunikacji uwierzytelniania) jako tablice JSON.
3. Dopasowanie danych klienta: zespół Zoho dostosował sposób kodowania i dekodowania pola clientDataJson przez serwer. Dzięki temu struktura danych jest dokładnie zgodna z oczekiwaniami istniejących wewnętrznych interfejsów API Zoho. Poniższy przykład ilustruje część logiki konwersji stosowanej do danych klienta przed ich przetworzeniem przez serwer:
private fun convertForServer(type: String): String {
val clientDataBytes = BaseEncoding.base64().decode(type)
val clientDataJson = JSONObject(String(clientDataBytes, StandardCharsets.UTF_8))
val clientJson = JSONObject()
val challengeFromJson = clientDataJson.getString("challenge")
// 'challenge' is a technical identifier/token, not localizable text.
clientJson.put("challenge", BaseEncoding.base64Url()
.encode(challengeFromJson.toByteArray(StandardCharsets.UTF_8)))
clientJson.put("origin", clientDataJson.getString("origin"))
clientJson.put("type", clientDataJson.getString("type"))
clientJson.put("androidPackageName", clientDataJson.getString("androidPackageName"))
return BaseEncoding.base64().encode(clientJson.toString().toByteArray())
}
Wskazówki dla użytkowników i ustawienia uwierzytelniania
Kluczowym elementem strategii Zoho dotyczącej kluczy dostępu było zachęcanie użytkowników do ich używania przy jednoczesnym zapewnieniu elastyczności, która pozwoli dostosować się do różnych wymagań organizacyjnych. Osiągnięto to dzięki starannemu projektowi interfejsu i kontroli zasad.
Firma Zoho zdawała sobie sprawę, że organizacje mają różne potrzeby w zakresie bezpieczeństwa. Aby to uwzględnić, firma Zoho wdrożyła:
- Wymuszanie przez administratora: w panelu administracyjnym Zoho Directory administratorzy mogą określić klucze dostępu jako obowiązkową domyślną metodę uwierzytelniania w całej organizacji. Gdy ta zasada jest włączona, pracownicy muszą skonfigurować klucz dostępu przy następnym logowaniu i używać go w przyszłości.
- Wybór użytkownika: jeśli organizacja nie wymusza określonej zasady, kontrolę zachowują poszczególni użytkownicy. Podczas logowania mogą wybrać preferowaną metodę uwierzytelniania, wybierając klucze dostępu lub inne skonfigurowane opcje w ustawieniach uwierzytelniania.
Aby zachęcić użytkowników do korzystania z kluczy dostępu i ułatwić im to, firma Zoho wdrożyła:
- Łatwa konfiguracja: firma Zoho zintegrowała konfigurację kluczy dostępu bezpośrednio z aplikacją mobilną Zoho OneAuth (dostępną na Androida i iOS). Użytkownicy mogą w każdej chwili wygodnie skonfigurować klucze dostępu w aplikacji, co ułatwia przejście.
- Spójny dostęp: obsługa kluczy dostępu została wdrożona w kluczowych punktach kontaktu z użytkownikiem, dzięki czemu użytkownicy mogą rejestrować się i uwierzytelniać za pomocą kluczy dostępu:
- w aplikacji mobilnej Zoho OneAuth (Android i iOS);
- na stronie kont internetowych Zoho.
Dzięki tej metodzie proces konfigurowania i używania kluczy dostępu był dostępny i zintegrowany z platformami, których użytkownicy już używają, niezależnie od tego, czy został on narzucony przez administratora, czy wybrany przez użytkownika. Więcej informacji o tworzeniu płynnych ścieżek użytkownika na potrzeby uwierzytelniania za pomocą kluczy dostępu znajdziesz w naszym obszernym przewodniku po wrażeniach użytkowników związanych z kluczami dostępu.
Wpływ na szybkość pracy deweloperów i wydajność integracji
Menedżer danych logowania jako ujednolicony interfejs API pomógł też zwiększyć produktywność deweloperów w porównaniu ze starszymi procesami logowania. Zmniejszył złożoność obsługi wielu metod uwierzytelniania i interfejsów API oddzielnie, co przyspieszyło integrację z miesięcy do tygodni i zmniejszyło liczbę błędów implementacji. Wszystko to usprawniło proces logowania i zwiększyło ogólną niezawodność.
Dzięki wdrożeniu kluczy dostępu za pomocą Menedżera danych logowania firma Zoho osiągnęła znaczną, mierzalną poprawę we wszystkich obszarach:
- Znaczne zwiększenie szybkości
- Logowanie 2-krotnie szybsze niż w przypadku tradycyjnego uwierzytelniania za pomocą hasła.
- Logowanie 4-krotnie szybsze niż w przypadku uwierzytelniania za pomocą nazwy użytkownika lub numeru telefonu komórkowego z hasłem jednorazowym wysyłanym e-mailem lub SMS-em.
- Logowanie 6-krotnie szybsze niż w przypadku uwierzytelniania za pomocą nazwy użytkownika, hasła i hasła jednorazowego wysyłanego SMS-em lub generowanego przez aplikację Authenticator.
- Niższe koszty obsługi
- Mniej zgłoszeń do pomocy związanych z hasłami, zwłaszcza w przypadku zapomnianych haseł.
- Niższe koszty związane z uwierzytelnianiem dwuskładnikowym opartym na SMS-ach, ponieważ dotychczasowi użytkownicy mogą bezpośrednio korzystać z kluczy dostępu.
- Duże zainteresowanie użytkowników i większe bezpieczeństwo:
- Liczba logowań za pomocą kluczy dostępu podwoiła się w ciągu zaledwie 4 miesięcy, co świadczy o dużym zainteresowaniu użytkowników.
- Użytkownicy, którzy przechodzą na klucze dostępu, są w pełni chronieni przed typowymi zagrożeniami związanymi z phishingiem i naruszeniem bezpieczeństwa haseł.
- Dzięki 31% wzrostowi liczby użytkowników korzystających z kluczy dostępu w porównaniu z poprzednim miesiącem coraz więcej użytkowników codziennie korzysta z większego bezpieczeństwa przed lukami w zabezpieczeniach, takimi jak phishing i zamiana karty SIM.
Rekomendacje i sprawdzone metody
Aby skutecznie wdrożyć klucze dostępu na Androidzie, deweloperzy powinni stosować te sprawdzone metody:
- Korzystaj z interfejsu Credential Manager API na Androidzie:
- Credential Manager upraszcza pobieranie danych logowania, zmniejszając nakład pracy deweloperów i zapewniając ujednolicone uwierzytelnianie.
- Obsługuje hasła, klucze dostępu i procesy logowania federacyjnego w jednym interfejsie.
- Podczas migracji z innych rozwiązań uwierzytelniania FIDO zadbaj o spójność kodowania danych:
- Podczas migracji z innych rozwiązań uwierzytelniania FIDO, takich jak klucze bezpieczeństwa FIDO, zadbaj o spójny format wszystkich danych wejściowych i wyjściowych.
- Zoptymalizuj obsługę błędów i logowanie:
- Wdróż niezawodną obsługę błędów, aby zapewnić użytkownikom płynną obsługę.
- Używaj zlokalizowanych komunikatów o błędach i szczegółowych logów, aby debugować i rozwiązywać nieoczekiwane błędy.
- Poinformuj użytkowników o opcjach odzyskiwania kluczy dostępu:
- Zapobiegaj blokowaniu dostępu, proaktywnie informując użytkowników o opcjach odzyskiwania.
- Monitoruj dane o wdrożeniu i opinie użytkowników:
- Śledź zaangażowanie użytkowników, wskaźniki wdrożenia kluczy dostępu i wskaźniki skuteczności logowania, aby stale optymalizować wrażenia użytkowników.
- Przeprowadzaj testy A/B różnych procesów uwierzytelniania, aby zwiększyć współczynnik konwersji i utrzymania użytkowników.
Klucze dostępu w połączeniu z interfejsem Credential Manager API na Androidzie to zaawansowane, ujednolicone rozwiązanie do uwierzytelniania, które zwiększa bezpieczeństwo i upraszcza obsługę. Klucze dostępu znacznie zmniejszają ryzyko phishingu, kradzieży danych logowania i nieautoryzowanego dostępu. Zachęcamy deweloperów do wypróbowania tego rozwiązania w swoich aplikacjach i zapewnienia użytkownikom najbezpieczniejszego uwierzytelniania.
Pierwsze kroki z kluczami dostępu i Menedżerem danych logowania
Zapoznaj się z kluczami dostępu i Menedżerem danych logowania na Androidzie, korzystając z naszego publicznego przykładowego kodu.
Czytaj dalej
-
Case Studies
Firma Uber wykorzystała interfejs Restore Credentials API na Androidzie, aby usprawnić logowanie na nowych urządzeniach. Przewiduje, że zmniejszy to liczbę ręcznych logowań o 4 miliony rocznie i zwiększy wskaźnik utrzymania użytkowników.
Niharika Arora • 5 min czytania
-
Case Studies
X to aplikacja społecznościowa, która ma na celu pomóc prawie 500 milionom użytkowników na całym świecie w uzyskaniu pełnych informacji dzięki komentarzom na żywo.
Niharika Arora • 3 min czytania
-
r.r.
Case Studies
Karrot to hiperlokalna, społecznościowa aplikacja typu peer-to-peer, która umożliwia użytkownikom kupowanie, sprzedawanie i wymienianie przedmiotów z innymi zweryfikowanymi użytkownikami. Od czasu uruchomienia w Korei Południowej w 2015 r. platforma rozszerzyła się na rynki globalne, zdobywając ponad 43 miliony zarejestrowanych użytkowników.
Thomas Ezan, Tracy Agyemang • 2 min czytania
Bądź na bieżąco
Otrzymuj co tydzień najnowsze informacje o tworzeniu aplikacji na Androida na swoją skrzynkę odbiorczą.