En tant que développeur Android, vous êtes constamment à la recherche de moyens d'améliorer la sécurité, l'expérience utilisateur et de simplifier le développement. Zoho, une suite logicielle cloud complète axée sur la sécurité et les expériences fluides, a réalisé des améliorations significatives en adoptant les clés d'accès dans son application Android OneAuth.

Depuis l'intégration des clés d'accès en 2024, Zoho a multiplié par six la vitesse de connexion par rapport aux méthodes précédentes et a enregistré une augmentation mensuelle de 31 % de l'adoption des clés d'accès.

Cette étude de cas examine l'adoption des clés d'accès par Zoho et l'API Credential Manager d'Android pour résoudre les difficultés d'authentification. Elle détaille le processus d'implémentation technique et met en évidence les résultats obtenus.

Résoudre les problèmes d'authentification

Zoho utilise une combinaison de méthodes d'authentification pour protéger les comptes utilisateur. Cela inclut Zoho OneAuth, sa propre solution d'authentification multifacteur (MFA), qui prend en charge l'authentification par mot de passe et sans mot de passe à l'aide de notifications push, de codes QR et de mots de passe à usage unique basés sur le temps (TOTP). Zoho prend également en charge les connexions fédérées, ce qui permet l'authentification via SAML (Security Assertion Markup Language) et d'autres fournisseurs d'identité tiers.

Défis

Comme de nombreuses organisations, Zoho souhaitait améliorer la sécurité de l'authentification et l'expérience utilisateur tout en réduisant les charges opérationnelles. Les principaux défis qui ont conduit à l'adoption des clés d'accès sont les suivants :

• Vulnérabilités de sécurité : les méthodes traditionnelles basées sur les mots de passe ont rendu les utilisateurs vulnérables aux attaques par hameçonnage et aux violations de mots de passe.
• Friction utilisateur : la fatigue liée aux mots de passe a entraîné des oublis, de la frustration et une dépendance accrue à des processus de récupération complexes.
• Inefficacités opérationnelles : la gestion des réinitialisations de mots de passe et des problèmes liés à l'authentification multifacteur a généré des frais d'assistance importants.
• Problèmes d'évolutivité : une base d'utilisateurs croissante exigeait une solution d'authentification plus sécurisée et plus efficace.

Pourquoi passer aux clés d'accès ?

Les clés d'accès ont été implémentées dans les applications de Zoho pour résoudre les problèmes d'authentification en offrant une approche sans mot de passe qui améliore considérablement la sécurité et l'expérience utilisateur. Cette solution exploite l'authentification résistante à l'hameçonnage, les identifiants synchronisés dans le cloud pour un accès facile sur plusieurs appareils, ainsi que les données biométriques (comme une empreinte digitale ou la reconnaissance faciale), un code PIN ou un schéma pour des connexions sécurisées. Elle réduit ainsi les vulnérabilités et les inconvénients associés aux mots de passe traditionnels.

En adoptant les clés d'accès avec le Gestionnaire d'identifiants, Zoho a divisé par six les temps de connexion, réduit considérablement les coûts d'assistance liés aux mots de passe et a constaté une forte adoption par les utilisateurs : les connexions par clé d'accès ont doublé en quatre mois, avec une augmentation mensuelle de 31 %. Les utilisateurs de Zoho bénéficient désormais de connexions plus rapides et plus faciles, ainsi que d'une sécurité résistante à l'hameçonnage.

Implémentation avec le Gestionnaire d'identifiants sur Android

Alors, comment Zoho a-t-il obtenu ces résultats ? L'entreprise a utilisé l'API Credential Manager d'Android, la bibliothèque Jetpack recommandée pour implémenter l'authentification sur Android.

Le Gestionnaire d'identifiants fournit une API unifiée qui simplifie la gestion des différentes méthodes d'authentification. Au lieu de jongler avec différentes API pour les mots de passe, les clés d'accès et les connexions fédérées (comme Se connecter avec Google), vous utilisez une seule interface.

L'implémentation des clés d'accès chez Zoho a nécessité des ajustements côté client et côté serveur. Voici une présentation détaillée du processus de création, de connexion et d'implémentation côté serveur des clés d'accès.

Création de clés d'accès

Pour créer une clé d'accès, l'application récupère d'abord les détails de configuration sur le serveur de Zoho. Ce processus inclut une validation unique, telle qu'une empreinte digitale ou la reconnaissance faciale. Ces données de validation, mises en forme en tant que chaîne requestJson, sont utilisées par l'application pour créer une CreatePublicKeyCredentialRequest. L'application appelle ensuite la méthode credentialManager.createCredential, qui invite l'utilisateur à s'authentifier à l'aide du verrouillage de l'écran de son appareil (données biométriques, empreinte digitale, code PIN, etc.).

Une fois la confirmation de l'utilisateur reçue, l'application reçoit les nouvelles données d'identifiants de clé d'accès, les renvoie au serveur de Zoho pour validation, puis le serveur stocke les informations de clé d'accès associées au compte de l'utilisateur. Les échecs ou les annulations de l'utilisateur au cours du processus sont détectés et gérés par l'application.

Se connecter

L'application Android Zoho lance le processus de connexion par clé d'accès en demandant des options de connexion, y compris un challenge, au serveur backend de Zoho. L'application utilise ensuite ces données pour créer une GetCredentialRequest, indiquant qu'elle s'authentifiera avec une clé d'accès. Elle appelle ensuite l'API Android CredentialManager.getCredential() avec cette requête. Cette action déclenche une interface système Android standardisée, invitant l'utilisateur à choisir son compte Zoho (si plusieurs clés d'accès existent) et à s'authentifier à l'aide du verrouillage de l'écran configuré sur son appareil (empreinte digitale, scan du visage ou code PIN). Une fois l'authentification réussie, le Gestionnaire d'identifiants renvoie une assertion signée (preuve de connexion) à l'application Zoho. L'application transfère cette assertion au serveur de Zoho, qui vérifie la signature par rapport à la clé publique stockée de l'utilisateur et valide le challenge, ce qui termine le processus de connexion sécurisé.

Implémentation côté serveur

La transition de Zoho vers la prise en charge des clés d'accès a bénéficié de la conformité de ses systèmes backend à FIDO WebAuthn, ce qui a simplifié le processus d'implémentation côté serveur. Toutefois, des modifications spécifiques ont été nécessaires pour intégrer pleinement la fonctionnalité de clé d'accès.

Le défi le plus important a consisté à adapter le système de stockage des identifiants. Les méthodes d'authentification existantes de Zoho, qui utilisaient principalement des mots de passe et des clés de sécurité FIDO pour l'authentification multifacteur, nécessitaient des approches de stockage différentes de celles des clés d'accès, qui sont basées sur des clés publiques cryptographiques. Pour résoudre ce problème, Zoho a implémenté un nouveau schéma de base de données spécialement conçu pour stocker de manière sécurisée les clés publiques des clés d'accès et les données associées conformément aux protocoles WebAuthn. Ce nouveau système a été conçu en parallèle d'un mécanisme de recherche pour valider et récupérer les identifiants en fonction des informations sur l'utilisateur et l'appareil, garantissant ainsi la rétrocompatibilité avec les anciennes méthodes d'authentification.

Un autre ajustement côté serveur a consisté à implémenter la possibilité de gérer les requêtes provenant d'appareils Android. Les requêtes de clé d'accès provenant d'applications Android utilisent un format d'origine unique (android:apk-key-hash:example) qui est distinct des origines Web standards qui utilisent un format basé sur un URI (https://example.com/app). La logique du serveur devait être mise à jour pour analyser correctement ce format, extraire le hachage d'empreinte SHA-256 du certificat de signature de l'application et le valider par rapport à une liste préenregistrée. Cette étape de validation garantit que les requêtes d'authentification proviennent réellement de l'application Android de Zoho et protège contre les attaques par hameçonnage.

Cet extrait de code montre comment le serveur vérifie le format d'origine spécifique à Android et valide le hachage du certificat :

  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    }
}

Gestion des exceptions

Zoho a implémenté des mécanismes robustes de gestion des exceptions pour gérer les erreurs destinées aux utilisateurs et aux développeurs. Une erreur courante, CreateCredentialCancellationException, s'est produite lorsque les utilisateurs ont annulé manuellement la configuration de leur clé d'accès. Zoho a suivi la fréquence de cette erreur pour évaluer les améliorations potentielles de l'expérience utilisateur. Sur la base des recommandations d'Android en matière d'expérience utilisateur, Zoho a pris des mesures pour mieux informer ses utilisateurs sur les clés d'accès, s'assurer qu'ils étaient conscients de leur disponibilité et promouvoir leur adoption lors des tentatives de connexion suivantes.

Cet exemple de code montre l'approche de Zoho pour gérer les erreurs de création de clés d'accès les plus courantes :

  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."
        }
    }
}

Tester les clés d'accès dans des environnements intranet

Zoho a rencontré un défi initial lors du test des clés d'accès dans un environnement intranet fermé. Le processus de validation du Gestionnaire de mots de passe de Google pour les clés d'accès nécessite un accès au domaine public pour valider le domaine de la partie de confiance. Toutefois, l'environnement de test interne de Zoho ne disposait pas de cet accès public à Internet, ce qui a entraîné l'échec du processus de validation et a entravé la réussite des tests d'authentification par clé d'accès. Pour résoudre ce problème, Zoho a créé un environnement de test accessible au public, qui comprenait l'hébergement d'un serveur temporaire avec un fichier de lien d'asset et une validation de domaine.

Cet exemple du fichier assetlinks.json utilisé dans l'environnement de test public de Zoho montre comment associer le domaine de la partie de confiance à l'application Android spécifiée pour la validation de la clé d'accès.

  [
    {
        "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" 
            ]
        }
    }
]

Intégrer un serveur FIDO existant

Le système de clé d'accès d'Android utilise la norme FIDO2 WebAuthn moderne. Cette norme nécessite des requêtes dans un format JSON spécifique, ce qui permet de maintenir la cohérence entre les applications natives et les plates-formes Web. Pour activer la prise en charge des clés d'accès Android, Zoho a apporté des modifications mineures en termes de compatibilité et de structure afin de générer et de traiter correctement les requêtes conformes à la structure JSON FIDO2 requise.

Cette mise à jour du serveur a impliqué plusieurs ajustements techniques spécifiques :

1. Conversion d'encodage : le serveur convertit l'encodage d'URL Base64 (couramment utilisé dans WebAuthn pour des champs tels que les ID d'identifiants) en encodage Base64 standard avant de stocker les données pertinentes. L'extrait ci-dessous montre comment un rawId peut être encodé au format Base64 standard :

  // Convert rawId bytes to a standard Base64 encoded string for storage
val base64RawId: String = Base64.getEncoder().encodeToString(rawId.toByteArray())

2. Format de la liste de transport : pour garantir un traitement cohérent des données, la logique du serveur gère les listes de mécanismes de transport (tels que USB, NFC et Bluetooth, qui spécifient le mode de communication de l'authentificateur) en tant que tableaux JSON.

3. Alignement des données client : l'équipe Zoho a ajusté la façon dont le serveur encode et décode le champ clientDataJson. Cela garantit que la structure des données correspond précisément aux attentes des API internes existantes de Zoho. L'exemple ci-dessous illustre une partie de la logique de conversion appliquée aux données client avant que le serveur ne les traite :

  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())
}

Conseils aux utilisateurs et préférences d'authentification

Un élément central de la stratégie de clé d'accès de Zoho consistait à encourager l'adoption par les utilisateurs tout en offrant une flexibilité permettant de s'adapter aux différentes exigences organisationnelles. Pour ce faire, l'entreprise a mis en place une conception d'interface utilisateur et des contrôles de règles minutieux.

Zoho a reconnu que les organisations ont des besoins de sécurité différents. Pour s'adapter à cette situation, Zoho a implémenté les éléments suivants :

• Application par l'administrateur : via le panneau d'administration de Zoho Directory, les administrateurs peuvent désigner les clés d'accès comme méthode d'authentification obligatoire par défaut pour l'ensemble de leur organisation. Lorsque cette règle est activée, les employés sont tenus de configurer une clé d'accès lors de leur prochaine connexion et de l'utiliser à l'avenir.
• Choix de l'utilisateur : si une organisation n'applique pas de règle spécifique, les utilisateurs individuels conservent le contrôle. Ils peuvent choisir leur méthode d'authentification préférée lors de la connexion, en sélectionnant des clés d'accès ou d'autres options configurées dans leurs paramètres d'authentification.

Pour rendre l'adoption des clés d'accès attrayante et simple pour les utilisateurs finaux, Zoho a implémenté les éléments suivants :

• Configuration facile : Zoho a intégré la configuration des clés d'accès directement dans l'application mobile Zoho OneAuth (disponible pour Android et iOS). Les utilisateurs peuvent facilement configurer leurs clés d'accès dans l'application à tout moment, ce qui facilite la transition.
• Accès cohérent : la prise en charge des clés d'accès a été implémentée sur les principaux points de contact des utilisateurs, ce qui leur permet de s'inscrire et de s'authentifier à l'aide de clés d'accès via :
• l'application mobile Zoho OneAuth (Android et iOS) ;
• la page de leurs comptes Web Zoho.

Cette méthode a permis de s'assurer que le processus de configuration et d'utilisation des clés d'accès était accessible et intégré aux plates-formes qu'ils utilisaient déjà, qu'il soit imposé par un administrateur ou choisi par l'utilisateur. Pour en savoir plus sur la création de flux utilisateur fluides pour l'authentification par clé d'accès, consultez notre guide complet sur l'expérience utilisateur des clés d'accès.

Impact sur la vitesse des développeurs et l'efficacité de l'intégration

Le Gestionnaire d'identifiants, en tant qu'API unifiée, a également contribué à améliorer la productivité des développeurs par rapport aux anciens flux de connexion. Il a réduit la complexité de la gestion séparée de plusieurs méthodes d'authentification et API, ce qui a permis une intégration plus rapide (de plusieurs mois à plusieurs semaines) et moins d'erreurs d'implémentation. Dans l'ensemble, cela a simplifié le processus de connexion et amélioré la fiabilité globale.

En implémentant les clés d'accès avec le Gestionnaire d'identifiants, Zoho a réalisé des améliorations significatives et mesurables dans tous les domaines :

• Améliorations spectaculaires de la vitesse
  • Connexion deux fois plus rapide qu'avec l'authentification par mot de passe traditionnelle.
  • Connexion quatre fois plus rapide qu'avec un nom d'utilisateur ou un numéro de mobile avec authentification par OTP par e-mail ou SMS.
  • Connexion six fois plus rapide qu'avec un nom d'utilisateur, un mot de passe et une authentification par OTP par SMS ou authentificateur.
• Réduction des coûts d'assistance
  • Réduction des demandes d'assistance liées aux mots de passe, en particulier pour les mots de passe oubliés.
  • Réduction des coûts associés à l'authentification à deux facteurs par SMS, car les utilisateurs existants peuvent s'intégrer directement avec des clés d'accès.
• Forte adoption par les utilisateurs et sécurité renforcée :
  • Les connexions par clé d'accès ont doublé en seulement quatre mois, ce qui témoigne d'une forte acceptation par les utilisateurs.
  • Les utilisateurs qui migrent vers les clés d'accès sont entièrement protégés contre les menaces courantes d'hameçonnage et de violation de mots de passe.
  • Avec une augmentation mensuelle de 31 % de l'adoption, de plus en plus d'utilisateurs bénéficient chaque jour d'une sécurité renforcée contre les vulnérabilités telles que l'hameçonnage et l'échange de carte SIM.

Recommandations et bonnes pratiques

Pour implémenter correctement les clés d'accès sur Android, les développeurs doivent tenir compte des bonnes pratiques suivantes :

• Exploiter l'API Credential Manager d'Android :
  • Le Gestionnaire d'identifiants simplifie la récupération des identifiants, ce qui réduit les efforts des développeurs et garantit une expérience d'authentification unifiée.
  • Gère les mots de passe, les clés d'accès et les flux de connexion fédérés dans une seule interface.
• Assurer la cohérence de l'encodage des données lors de la migration depuis d'autres solutions d'authentification FIDO
  • Assurez-vous de gérer une mise en forme cohérente pour toutes les entrées/sorties lors de la migration depuis d'autres solutions d'authentification FIDO, telles que les clés de sécurité FIDO.
• Optimiser la gestion des exceptions et la journalisation :
  • Implémentez une gestion des exceptions robuste pour une expérience utilisateur fluide.
  • Fournissez des messages d'erreur localisés et utilisez des journaux détaillés pour déboguer et résoudre les échecs inattendus.
• Informer les utilisateurs sur les options de récupération des clés d'accès
  • Évitez les scénarios de verrouillage en guidant de manière proactive les utilisateurs sur les options de récupération.
• Surveiller les métriques d'adoption et les commentaires des utilisateurs :
  • Suivez l'engagement des utilisateurs, les taux d'adoption des clés d'accès et les taux de réussite des connexions pour continuer à optimiser l'expérience utilisateur.
  • Effectuez des tests A/B sur différents flux d'authentification pour améliorer la conversion et la fidélisation.

Combinées à l'API Credential Manager d'Android, les clés d'accès offrent une solution d'authentification puissante et unifiée qui renforce la sécurité tout en simplifiant l'expérience utilisateur. Les clés d'accès réduisent considérablement les risques d'hameçonnage, de vol d'identifiants et d'accès non autorisés. Nous encourageons les développeurs à tester l'expérience dans leur application et à offrir l'authentification la plus sécurisée à leurs utilisateurs.

Premiers pas avec les clés d'accès et le Gestionnaire d'identifiants

Découvrez les clés d'accès et le Gestionnaire d'identifiants sur Android à l'aide de notre exemple de code public.

Si vous avez des questions ou des problèmes, vous pouvez nous en faire part via l'outil de suivi des problèmes liés aux identifiants Android.