En tant que développeur Android, vous cherchez constamment des moyens d'améliorer la sécurité, l'expérience utilisateur et 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 de 31% de l'adoption des clés d'accès d'un mois à l'autre.

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

Surmonter les problèmes d'authentification

Zoho utilise une combinaison de méthodes d'authentification pour protéger les comptes utilisateur. Cela inclut Zoho OneAuth, leur 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 était également compatible avec les connexions fédérées, ce qui permettait 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 la charge opérationnelle. Voici les principaux défis qui ont conduit à l'adoption des clés d'accès :

• Failles de sécurité : les méthodes traditionnelles basées sur les mots de passe laissaient les utilisateurs vulnérables aux attaques par hameçonnage et aux piratages de mots de passe.
• Friction pour les utilisateurs : 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 mot de passe et des problèmes liés à l'authentification multifacteur a généré des frais généraux d'assistance importants.
• Problèmes d'évolutivité : une base d'utilisateurs en pleine croissance nécessitait 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 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 utilise une authentification résistante au hameçonnage, des identifiants synchronisés dans le cloud pour un accès facile sur plusieurs appareils, ainsi que des données biométriques (comme une empreinte digitale ou la reconnaissance faciale), un code ou un schéma pour des connexions sécurisées. Elle réduit ainsi les failles et les inconvénients associés aux mots de passe traditionnels.

En adoptant les clés d'accès avec Credential Manager, 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 constaté une forte adoption par les utilisateurs, avec un doublement des connexions par clé d'accès en quatre mois et une croissance de 31% d'un mois sur l'autre. Les utilisateurs de Zoho bénéficient désormais d'une connexion plus rapide et plus facile, et d'une sécurité résistante à l'hameçonnage.

Implémentation avec Credential Manager sur Android

Comment Zoho a-t-il obtenu ces résultats ? Ils ont 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 identifiants fédérés (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 et de connexion avec une clé d'accès, ainsi que de l'implémentation côté serveur.

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 du serveur de Zoho. Cette procédure inclut une validation unique, comme une empreinte digitale ou la reconnaissance faciale. Ces données de validation, mises en forme sous forme de chaîne requestJson, sont utilisées par l'application pour créer un 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 (biométrie, empreinte digitale, code, etc.).

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

Connexion

L'application Zoho pour Android lance le processus de connexion par clé d'accès en demandant des options de connexion, y compris un challenge unique, au serveur backend de Zoho. L'application utilise ensuite ces données pour construire un GetCredentialRequest, indiquant qu'elle s'authentifiera avec une clé d'accès. Il 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, reconnaissance faciale ou code). Une fois l'authentification réussie, Credential Manager renvoie une assertion signée (preuve de connexion) à l'application Zoho. L'application transmet cette assertion au serveur de Zoho, qui vérifie la signature par rapport à la clé publique stockée de l'utilisateur et valide le défi, ce qui termine le processus de connexion sécurisée.

Implémentation côté serveur

La transition de Zoho vers la prise en charge des clés d'accès a été facilitée par 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 étaient encore 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 multifactorielle, 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 avec un mécanisme de recherche pour valider et récupérer les identifiants en fonction des informations sur l'utilisateur et l'appareil, ce qui garantit la rétrocompatibilité avec les anciennes méthodes d'authentification.

Un autre ajustement côté serveur a consisté à implémenter la capacité à 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 différent 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 permet de s'assurer que les demandes d'authentification proviennent bien de l'application Android de Zoho et de se protéger contre les attaques de 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 mis en place des mécanismes de gestion des erreurs robustes pour gérer les erreurs destinées aux utilisateurs et aux développeurs. L'erreur courante CreateCredentialCancellationException s'affichait lorsque les utilisateurs annulaient 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 UX d'Android, Zoho a pris des mesures pour mieux informer ses utilisateurs sur les clés d'accès, s'assurer qu'ils étaient au courant de leur disponibilité et promouvoir leur adoption lors des tentatives de connexion ultérieures.

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 premier défi lors du test des clés d'accès dans un environnement intranet fermé. La procédure 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 (RP, Relying Party). Toutefois, l'environnement de test interne de Zoho ne disposait pas de cet accès à Internet public, ce qui a entraîné l'échec du processus de validation et a empêché de tester correctement l'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 liens d'association et la validation du 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 des clés 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és d'accès d'Android utilise la norme WebAuthn FIDO2 moderne. Cette norme exige que les requêtes soient au 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 qui respectent la structure JSON FIDO2 requise.

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

1. Conversion de l'encodage : le serveur convertit l'encodage Base64 adapté aux URL (couramment utilisé dans WebAuthn pour les champs tels que les ID d'identifiants) en encodage Base64 standard avant de stocker les données concernées. 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 des transports : 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 Zoho concernant les clés d'accès consistait à encourager l'adoption par les utilisateurs tout en offrant la flexibilité nécessaire pour s'adapter aux différentes exigences organisationnelles. Pour ce faire, nous avons conçu l'UI et les contrôles des règles avec soin.

Zoho a reconnu que les besoins des organisations en termes de sécurité varient. Pour s'adapter à cette situation, Zoho a mis en place les mesures suivantes :

• Application par l'administrateur : dans le panneau d'administration 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 doivent configurer une clé d'accès lors de leur prochaine connexion et l'utiliser par la suite.
• Choix 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 mis en place 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 configurer facilement 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 au niveau des principaux points de contact avec les utilisateurs. Les utilisateurs peuvent ainsi s'inscrire et s'authentifier à l'aide de clés d'accès :
• L'application mobile Zoho OneAuth (Android et iOS) ;
• La page Comptes Web Zoho

Cette méthode garantissait 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 ait été imposé par un administrateur ou choisi par l'utilisateur. Pour savoir comment créer des parcours utilisateur fluides pour l'authentification par clé d'accès, consultez notre guide complet sur l'expérience utilisateur avec les clés d'accès.

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

En tant qu'API unifiée, Credential Manager a également contribué à améliorer la productivité des développeurs par rapport aux anciens flux de connexion. Cela a permis de réduire la complexité de la gestion séparée de plusieurs méthodes d'authentification et API, ce qui a accéléré l'intégration (de plusieurs mois à quelques semaines) et réduit le nombre d'erreurs d'implémentation. Cela a permis de simplifier le processus de connexion et d'améliorer la fiabilité globale.

En implémentant des clés d'accès avec Credential Manager, Zoho a obtenu des améliorations significatives et mesurables à tous les niveaux :

• Améliorations spectaculaires de la vitesse
  • La connexion est deux fois plus rapide qu'avec l'authentification par mot de passe traditionnelle.
  • La connexion est quatre fois plus rapide qu'avec un nom d'utilisateur ou un numéro de mobile avec authentification par e-mail ou OTP par SMS.
  • Connexion six fois plus rapide qu'avec l'authentification par nom d'utilisateur, mot de passe et mot de passe à usage unique par SMS ou application d'authentification.
• Coûts d'assistance réduits
  • Réduction des demandes d'assistance liées aux mots de passe, en particulier pour les mots de passe oubliés.
  • Coûts réduits 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 montre que les utilisateurs les acceptent bien.
  • 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 piratage de mots de passe.
  • Avec une croissance de l'adoption de 31% d'un mois sur l'autre, de plus en plus d'utilisateurs bénéficient chaque jour d'une sécurité renforcée contre les failles 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 :

• Exploitez l'API Credential Manager d'Android :
  • Le Gestionnaire d'identifiants simplifie la récupération des identifiants, ce qui réduit l'effort 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ée dans une seule interface.
• Assurez-vous que l'encodage des données est cohérent lorsque vous migrez 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.
• Optimisez la gestion des erreurs et la journalisation :
  • Implémentez une gestion des erreurs 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.
• Informez 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.
• Surveillez 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.

Les clés d'accès, combinées à l'API Android Credential Manager, offrent une solution d'authentification puissante et unifiée qui améliore 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 à proposer 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 Credential Manager sur Android en utilisant 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.