Zoho erzielt mit der Integration von Passkeys und dem Credential Manager 6‑mal schnellere Anmeldungen
10 Minuten Lesezeit
Als Android-Entwickler sind Sie ständig auf der Suche nach Möglichkeiten, die Sicherheit zu erhöhen, die Nutzerfreundlichkeit zu verbessern und die Entwicklung zu optimieren. Zoho, eine umfassende cloudbasierte Software-Suite mit Schwerpunkt auf Sicherheit und nahtlosen Abläufen, hat durch die Einführung von Passkeys in der OneAuth Android-App erhebliche Verbesserungen erzielt.
Seit der Integration von Passkeys im Jahr 2024 hat Zoho Anmeldegeschwindigkeiten erreicht, die bis zu 6‑mal schneller sind als bei früheren Methoden, und eine Steigerung der Passkey-Nutzung um 31% im Vergleich zum Vormonat.
In dieser Fallstudie wird untersucht, wie Zoho Passkeys und die Android Credential Manager API eingeführt hat, um Authentifizierungsprobleme zu lösen. Dabei wird der technische Implementierungsprozess detailliert beschrieben und die wirkungsvollen Ergebnisse hervorgehoben.
Herausforderungen bei der Authentifizierung meistern
Zoho verwendet eine Kombination aus Authentifizierungsmethoden, um Nutzerkonten zu schützen. Dazu gehörte Zoho OneAuth, die eigene Multi-Faktor-Authentifizierungslösung (MFA), die sowohl die passwortbasierte als auch die passwortlose Authentifizierung mithilfe von Push-Benachrichtigungen, QR-Codes und zeitbasierten Einmalpasswörtern (TOTP) unterstützte. Zoho unterstützte auch Verbundanmeldungen, die die Authentifizierung über Security Assertion Markup Language (SAML) und andere Identitätsanbieter von Drittanbietern ermöglichten.
Herausforderungen
Wie viele andere Unternehmen wollte auch Zoho die Sicherheit und Nutzerfreundlichkeit bei der Authentifizierung verbessern und gleichzeitig den Betriebsaufwand reduzieren. Zu den wichtigsten Herausforderungen, die zur Einführung von Passkeys führten, gehörten:
- Sicherheitslücken: Bei herkömmlichen passwortbasierten Methoden waren Nutzer anfällig für Phishing-Angriffe und Passwortlecks.
- Nutzerprobleme: Passwortmüdigkeit führte zu vergessenen Passwörtern, Frustration und einer verstärkten Abhängigkeit von umständlichen Wiederherstellungsprozessen.
- Betriebliche Ineffizienzen: Die Bearbeitung von Passwortzurücksetzungen und MFA-Problemen verursachte erhebliche Supportkosten.
- Skalierbarkeitsprobleme: Eine wachsende Nutzerbasis erforderte eine sicherere und effizientere Authentifizierungslösung.
Warum der Wechsel zu Passkeys?
Passkeys wurden in den Apps von Zoho implementiert, um Authentifizierungsprobleme zu lösen. Sie bieten einen passwortlosen Ansatz, der die Sicherheit und Nutzerfreundlichkeit erheblich verbessert. Diese Lösung nutzt eine phishingresistente Authentifizierung, cloudsynchronisierte Anmeldedaten für den mühelosen geräteübergreifenden Zugriff und biometrische Daten (z. B. Fingerabdruck oder Gesichtserkennung), eine PIN oder ein Muster für sichere Anmeldungen. So werden die Schwachstellen und Unannehmlichkeiten reduziert, die mit herkömmlichen Passwörtern verbunden sind.
Durch die Einführung von Passkeys mit dem Credential Manager konnte Zoho die Anmeldezeiten um das bis zu 6‑Fache verkürzen, die supportbezogenen Kosten für Passwörter senken und eine starke Nutzerakzeptanz verzeichnen. Die Anzahl der Passkey-Anmeldungen verdoppelte sich in 4 Monaten und es gab ein monatliches Wachstum von 31% . Zoho-Nutzer profitieren jetzt von schnelleren, einfacheren Anmeldungen und phishingresistenter Sicherheit.
Implementierung mit dem Credential Manager unter Android
Wie hat Zoho diese Ergebnisse erzielt? Das Unternehmen hat die Android Credential Manager API verwendet, die empfohlene Jetpack-Bibliothek für die Implementierung der Authentifizierung unter Android.
Credential Manager bietet eine einheitliche API, die die Handhabung der verschiedenen Authentifizierungsmethoden vereinfacht. Statt verschiedene APIs für Passwörter, Passkeys und Verbundanmeldungen (z. B. „Über Google anmelden“) zu verwenden, nutzen Sie eine einzige Schnittstelle.
Die Implementierung von Passkeys bei Zoho erforderte sowohl clientseitige als auch serverseitige Anpassungen. Hier finden Sie eine detaillierte Aufschlüsselung des Prozesses zur Erstellung von Passkeys, zur Anmeldung und zur serverseitigen Implementierung.
Passkey erstellen
Um einen Passkey zu erstellen, ruft die App zuerst Konfigurationsdetails vom Server von Zoho ab. Dieser Prozess umfasst eine eindeutige Bestätigung, z. B. per Fingerabdruck oder Gesichtserkennung. Diese Daten zur Identitätsbestätigung, die als requestJson-String formatiert sind, werden von der App verwendet, um eine CreatePublicKeyCredentialRequest zu erstellen. Die App ruft dann die Methode credentialManager.createCredential auf, die den Nutzer auffordert, sich mit der Displaysperre seines Geräts zu authentifizieren (biometrische Daten, Fingerabdruck, PIN usw.).
Nach der erfolgreichen Bestätigung durch den Nutzer empfängt die App die neuen Passkey-Anmeldedaten, sendet sie zur Bestätigung an den Server von Zoho zurück und der Server speichert die Passkey-Informationen, die mit dem Konto des Nutzers verknüpft sind. Fehler oder Nutzerabbrüche während des Prozesses werden von der App erkannt und behandelt.
Anmeldung
Die Android-App von Zoho initiiert den Passkey-Anmelde-Prozess, indem sie Anmeldeoptionen, einschließlich einer eindeutigen challenge, vom Backend-Server von Zoho anfordert. Die App verwendet diese Daten dann, um eine GetCredentialRequest zu erstellen, die angibt, dass die Authentifizierung mit einem Passkey erfolgt. Anschließend ruft sie die Android CredentialManager.getCredential() API mit dieser Anfrage auf. Diese Aktion löst eine standardisierte Android-Systemoberfläche aus, die den Nutzer auffordert, sein Zoho-Konto auszuwählen (wenn mehrere Passkeys vorhanden sind) und sich mit der konfigurierten Displaysperre seines Geräts zu authentifizieren (Fingerabdruck, Gesichtsscan oder PIN). Nach der erfolgreichen Authentifizierung gibt der Credential Manager eine signierte Assertion (Anmeldebestätigung) an die Zoho-App zurück. Die App leitet diese Assertion an den Server von Zoho weiter, der die Signatur mit dem gespeicherten öffentlichen Schlüssel des Nutzers vergleicht und die Challenge bestätigt. So wird der sichere Anmeldeprozess abgeschlossen.
Serverseitige Implementierung
Der Übergang von Zoho zur Unterstützung von Passkeys wurde dadurch erleichtert, dass die Backend-Systeme bereits FIDO WebAuthn-konform waren. Das vereinfachte den serverseitigen Implementierungsprozess. Dennoch waren bestimmte Änderungen erforderlich, um die Passkey-Funktionalität vollständig zu integrieren.
Die größte Herausforderung bestand darin, das System zur Speicherung von Anmeldedaten anzupassen. Die vorhandenen Authentifizierungsmethoden von Zoho, bei denen hauptsächlich Passwörter und FIDO-Sicherheitsschlüssel für die Multi-Faktor-Authentifizierung verwendet wurden, erforderten andere Speicheransätze als Passkeys, die auf kryptografischen öffentlichen Schlüsseln basieren. Um dieses Problem zu lösen, hat Zoho ein neues Datenbankschema implementiert, das speziell für die sichere Speicherung von öffentlichen Passkey-Schlüsseln und zugehörigen Daten gemäß den WebAuthn-Protokollen entwickelt wurde. Dieses neue System wurde zusammen mit einem Suchmechanismus entwickelt, um Anmeldedaten basierend auf Nutzer- und Geräteinformationen zu bestätigen und abzurufen. So wurde die Abwärtskompatibilität mit älteren Authentifizierungsmethoden sichergestellt.
Eine weitere serverseitige Anpassung bestand darin, die Möglichkeit zur Verarbeitung von Anfragen von Android-Geräten zu implementieren. Passkey-Anfragen, die von Android-Apps stammen, verwenden ein eindeutiges Ursprungsformat (android:apk-key-hash:example), das sich von Standard-Webursprüngen unterscheidet, die ein URI-basiertes Format (https://example.com/app) verwenden. Die Serverlogik musste aktualisiert werden, um dieses Format korrekt zu parsen, den SHA-256-Fingerabdruck-Hash des Signaturzertifikats der App zu extrahieren und ihn mit einer vorregistrierten Liste zu vergleichen. Dieser Bestätigungsschritt stellt sicher, dass Authentifizierungsanfragen tatsächlich von der Android-App von Zoho stammen, und schützt vor Phishing-Angriffen.
Dieser Code-Snippet zeigt, wie der Server nach dem Android-spezifischen Ursprungsformat sucht und den Zertifikats-Hash bestätigt:
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 }
}Fehlerbehandlung
Zoho hat robuste Mechanismen zur Fehlerbehandlung implementiert, um sowohl nutzer- als auch entwicklerbezogene Fehler zu verwalten. Ein häufiger Fehler, CreateCredentialCancellationException, trat auf, wenn Nutzer die Passkey-Einrichtung manuell abgebrochen haben. Zoho hat die Häufigkeit dieses Fehlers erfasst, um potenzielle Verbesserungen der Nutzerfreundlichkeit zu bewerten. Basierend auf den UX-Empfehlungen von Android hat Zoho Maßnahmen ergriffen, um Nutzer besser über Passkeys zu informieren, sie auf die Verfügbarkeit von Passkeys aufmerksam zu machen und die Einführung von Passkeys bei nachfolgenden Anmeldeversuchen zu fördern.
Dieses Codebeispiel zeigt, wie Zoho die häufigsten Fehler bei der Passkey-Erstellung behandelt hat:
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."
}
}
}Passkeys in Intranet-Umgebungen testen
Zoho stand vor einer ersten Herausforderung beim Testen von Passkeys in einer geschlossenen Intranet-Umgebung. Für den Bestätigungsprozess von Passkeys im Google Passwortmanager ist ein öffentlicher Domainzugriff erforderlich, um die Domain der vertrauenden Partei zu bestätigen. In der internen Testumgebung von Zoho fehlte jedoch dieser öffentliche Internetzugriff, was dazu führte, dass der Bestätigungsprozess fehlschlug und erfolgreiche Tests der Passkey-Authentifizierung verhindert wurden. Um dieses Problem zu lösen, hat Zoho eine öffentlich zugängliche Testumgebung erstellt, in der ein temporärer Server mit einer Asset-Link-Datei und Domainbestätigung gehostet wurde.
Dieses Beispiel aus der Datei assetlinks.json, die in der öffentlichen Testumgebung von Zoho verwendet wird, zeigt, wie die Domain der vertrauenden Partei mit der angegebenen Android-App für die Passkey-Bestätigung verknüpft wird.
[
{
"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"
]
}
}
]In einen vorhandenen FIDO-Server einbinden
Das Passkey-System von Android verwendet den modernen FIDO2 WebAuthn-Standard. Dieser Standard erfordert Anfragen in einem bestimmten JSON-Format, was dazu beiträgt, die Konsistenz zwischen nativen Anwendungen und Webplattformen aufrechtzuerhalten. Um die Android-Passkey-Unterstützung zu aktivieren, hat Zoho geringfügige Kompatibilitäts- und Strukturänderungen vorgenommen, um Anfragen, die der erforderlichen FIDO2-JSON-Struktur entsprechen, korrekt zu generieren und zu verarbeiten.
Dieses Serverupdate umfasste mehrere spezifische technische Anpassungen:
1. Codierungskonvertierung:Der Server konvertiert die Base64-URL-Codierung (die in WebAuthn häufig für Felder wie Anmeldedaten-IDs verwendet wird) in die Standard-Base64-Codierung, bevor er die relevanten Daten speichert. Der folgende Snippet zeigt, wie eine rawId in Standard-Base64 codiert werden kann:
// Convert rawId bytes to a standard Base64 encoded string for storage val base64RawId: String = Base64.getEncoder().encodeToString(rawId.toByteArray())
2. Transportlistenformat:Um eine konsistente Datenverarbeitung zu gewährleisten, verarbeitet die Serverlogik Listen von Transportmechanismen (z. B. USB, NFC und Bluetooth, die angeben, wie der Authentifikator kommuniziert) als JSON-Arrays.
3. Abstimmung der Clientdaten:Das Zoho-Team hat angepasst, wie der Server das Feld „clientDataJson“ codiert und decodiert. So wird sichergestellt, dass die Datenstruktur genau den Erwartungen der vorhandenen internen APIs von Zoho entspricht. Das folgende Beispiel veranschaulicht einen Teil der Konvertierungslogik, die auf Clientdaten angewendet wird, bevor der Server sie verarbeitet:
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())
}Nutzeranleitung und Authentifizierungseinstellungen
Ein zentraler Bestandteil der Passkey-Strategie von Zoho war es, die Nutzerakzeptanz zu fördern und gleichzeitig Flexibilität zu bieten, um unterschiedlichen Organisationsanforderungen gerecht zu werden. Dies wurde durch ein sorgfältiges UI-Design und Richtlinienkontrollen erreicht.
Zoho war sich bewusst, dass Organisationen unterschiedliche Sicherheitsanforderungen haben. Um dem gerecht zu werden, hat Zoho Folgendes implementiert:
- Administratorerzwingung: Über das Admin-Panel von Zoho Directory können Administratoren Passkeys als obligatorische Standardauthentifizierungsmethode für die gesamte Organisation festlegen. Wenn diese Richtlinie aktiviert ist, müssen Mitarbeiter bei der nächsten Anmeldung einen Passkey einrichten und ihn in Zukunft verwenden.
- Nutzerwahl:Wenn eine Organisation keine bestimmte Richtlinie erzwingt, behalten einzelne Nutzer die Kontrolle. Sie können bei der Anmeldung ihre bevorzugte Authentifizierungsmethode auswählen und in den Authentifizierungseinstellungen zwischen Passkeys oder anderen konfigurierten Optionen wählen.
Um die Einführung von Passkeys für Endnutzer attraktiv und einfach zu gestalten, hat Zoho Folgendes implementiert:
- Einfache Einrichtung: Zoho hat die Passkey-Einrichtung direkt in die mobile App Zoho OneAuth eingebunden (verfügbar für Android und iOS). Nutzer können ihre Passkeys jederzeit bequem in der App konfigurieren, was den Übergang erleichtert.
- Konsistenter Zugriff:Die Passkey-Unterstützung wurde an wichtigen Nutzer-Touchpoints implementiert, sodass Nutzer sich über folgende Möglichkeiten mit Passkeys registrieren und authentifizieren können:
- Die mobile App Zoho OneAuth (Android und iOS)
- Die Seite mit ihren Zoho-Webkonten
So wurde sichergestellt, dass der Prozess zum Einrichten und Verwenden von Passkeys zugänglich ist und in die bereits verwendeten Plattformen eingebunden wurde, unabhängig davon, ob er von einem Administrator vorgeschrieben oder vom Nutzer ausgewählt wurde. Weitere Informationen zum Erstellen reibungsloser Nutzerabläufe für die Passkey-Authentifizierung finden Sie in unserem umfassenden Leitfaden zur Nutzererfahrung mit Passkeys.
Auswirkungen auf die Entwicklergeschwindigkeit und die Effizienz der Integration
Der Credential Manager als einheitliche API hat auch die Produktivität der Entwickler im Vergleich zu älteren Anmeldeabläufen verbessert. Er hat die Komplexität der separaten Handhabung mehrerer Authentifizierungsmethoden und APIs reduziert, was zu einer schnelleren Integration (von Monaten auf Wochen) und weniger Implementierungsfehlern geführt hat. Insgesamt wurde so der Anmeldeprozess optimiert und die Zuverlässigkeit verbessert.
Durch die Implementierung von Passkeys mit dem Credential Manager hat Zoho in allen Bereichen erhebliche, messbare Verbesserungen erzielt:
- Erhebliche Geschwindigkeitsverbesserungen
- 2‑mal schnellere Anmeldung im Vergleich zur herkömmlichen Passwortauthentifizierung
- 4‑mal schnellere Anmeldung im Vergleich zu Nutzername oder Mobiltelefonnummer mit E‑Mail- oder SMS-OTP-Authentifizierung
- 6‑mal schnellere Anmeldung im Vergleich zu Nutzername, Passwort und SMS- oder Authenticator-OTP-Authentifizierung
- Geringere Supportkosten
- Weniger supportbezogene Anfragen zu Passwörtern, insbesondere zu vergessenen Passwörtern.
- Geringere Kosten im Zusammenhang mit der SMS-basierten 2‑Faktor-Authentifizierung, da bestehende Nutzer direkt mit Passkeys einsteigen können
- Starke Nutzerakzeptanz und erhöhte Sicherheit
- Die Anzahl der Passkey-Anmeldungen hat sich in nur 4 Monaten verdoppelt, was auf eine hohe Nutzerakzeptanz hindeutet.
- Nutzer, die zu Passkeys wechseln, sind vollständig vor häufigen Phishing- und Passwortlecks geschützt.
- Mit einem monatlichen Wachstum von 31% profitieren täglich mehr Nutzer von den erweiterten Sicherheitsfunktionen vor Sicherheitslücken wie Phishing und SIM-Swaps.
Empfehlungen und Best Practices
Für die erfolgreiche Implementierung von Passkeys unter Android sollten Entwickler die folgenden Best Practices berücksichtigen:
- Android Credential Manager API nutzen:
- Credential Manager vereinfacht das Abrufen von Anmeldedaten, reduziert den Aufwand für Entwickler und sorgt für eine einheitliche Authentifizierung.
- Passwörter, Passkeys und Verbundanmeldeabläufe werden über eine einzige Schnittstelle verwaltet.
- Bei der Migration von anderen FIDO-Authentifizierungslösungen für eine konsistente Datencodierung sorgen
- Achten Sie darauf, dass bei der Migration von anderen FIDO-Authentifizierungslösungen wie FIDO-Sicherheitsschlüsseln ein einheitliches Format für alle Ein- und Ausgaben verwendet wird.
- Fehlerbehandlung und Logging optimieren:
- Implementieren Sie eine robuste Fehlerbehandlung für eine nahtlose Nutzererfahrung.
- Stellen Sie lokalisierte Fehlermeldungen bereit und verwenden Sie detaillierte Logs, um unerwartete Fehler zu beheben.
- Nutzer über Optionen zur Passkey-Wiederherstellung informieren:
- Verhindern Sie Sperrszenarien, indem Sie Nutzer proaktiv über Wiederherstellungsoptionen informieren.
- Einführungsstatistiken und Nutzerfeedback im Blick behalten:
- Erfassen Sie Nutzerinteraktionen, Passkey-Einführungsraten und Anmeldeerfolgsraten, um die Nutzererfahrung weiter zu optimieren.
- Führen Sie A/B-Tests für verschiedene Authentifizierungsabläufe durch, um die Conversion- und Bindungsraten zu verbessern.
Passkeys bieten in Kombination mit der Android Credential Manager API eine leistungsstarke, einheitliche Authentifizierungslösung, die die Sicherheit erhöht und gleichzeitig die Nutzererfahrung vereinfacht. Passkeys reduzieren das Risiko von Phishing, Anmeldedatendiebstahl und unbefugtem Zugriff erheblich. Wir empfehlen Entwicklern, die Lösung in ihrer App auszuprobieren und ihren Nutzern die sicherste Authentifizierung zu bieten.
Erste Schritte mit Passkeys und dem Credential Manager
Mit unserem öffentlichen Beispielcode können Sie Passkeys und den Credential Manager unter Android ausprobieren.
Bei Fragen oder Problemen können Sie uns über den Android Credentials-Issue-Tracker informieren.
-
FallstudienUber hat die Android Restore Credentials API genutzt, um die Anmeldung auf neuen Geräten zu optimieren. Das Unternehmen rechnet mit einer Reduzierung von 4 Millionen manuellen Anmeldungen pro Jahr und einer höheren Nutzerbindung.
Niharika Arora, Tracy Agyemang • 5 Minuten Lesezeit -
FallstudienX ist eine Social-Media-App, die fast 500 Millionen Nutzern weltweit die Möglichkeit bietet, sich über Eilmeldungen, Unterhaltung, Sport und Politik zu informieren und die vollständige Story mit allen Livekommentaren zu erhalten.
Niharika Arora, Tracy Agyemang • 3 Minuten Lesezeit -
FallstudienLeistungsregressionen sind bekanntermaßen schwer zu reproduzieren, was sie zu einem großen Engpass für mobile Entwickler macht.
Alice Yuan, Arti Arutiunov, Nikita Ogorodnikov • 4 Minuten Lesezeit
Lassen Sie sich Woche für Woche die neuesten Informationen zur Android-Entwicklung zusenden.