Como desarrollador de Android, siempre buscas formas de mejorar la seguridad, la experiencia de usuario y el desarrollo. Zoho, una completa suite de software basada en la nube centrada en la seguridad y las experiencias fluidas, ha conseguido mejoras significativas al adoptar las llaves de acceso en su aplicación Android OneAuth.

Desde que integró las llaves de acceso en el 2024, Zoho ha conseguido velocidades de inicio de sesión hasta 6 veces más rápidas que con los métodos anteriores y un aumento del 31% en la adopción de llaves de acceso de un mes a otro.

En este caso de éxito se analiza la adopción de llaves de acceso por parte de Zoho y la API de Gestor de credenciales de Android para solucionar los problemas de autenticación. Se detalla el proceso de implementación técnica y se destacan los resultados.

Superar los retos de autenticación

Zoho utiliza una combinación de métodos de autenticación para proteger las cuentas de usuario. Esto incluía Zoho OneAuth, su propia solución de autenticación multifactor (MFA), que admitía la autenticación basada en contraseñas y sin contraseñas mediante notificaciones push, códigos QR y contraseñas temporales de un solo uso (TOTP). Zoho también admitía inicios de sesión federados, lo que permitía la autenticación mediante el lenguaje de marcado para confirmaciones de seguridad (SAML) y otros proveedores de identidades de terceros.

Retos

Zoho, como muchas otras organizaciones, quería mejorar la seguridad de la autenticación y la experiencia de usuario, así como reducir la carga operativa. Los principales retos que llevaron a la adopción de las llaves de acceso fueron los siguientes:

• Vulnerabilidades de seguridad: los métodos tradicionales basados en contraseñas hacían que los usuarios fueran vulnerables a los ataques de phishing y a las brechas de seguridad de contraseñas.
• Fricción de los usuarios: la fatiga de contraseñas provocaba que los usuarios olvidaran sus contraseñas, se frustraran y dependieran cada vez más de procesos de recuperación engorrosos.
• Ineficiencias operativas: la gestión de los restablecimientos de contraseñas y los problemas de MFA generaba una sobrecarga de asistencia significativa.
• Problemas de escalabilidad: una base de usuarios cada vez mayor exigía una solución de autenticación más segura y eficiente.

¿Por qué se ha cambiado a las llaves de acceso?

Las llaves de acceso se implementaron en las aplicaciones de Zoho para abordar los problemas de autenticación ofreciendo un método sin contraseñas que mejora significativamente la seguridad y la experiencia de usuario. Esta solución aprovecha la autenticación resistente al phishing, las credenciales sincronizadas en la nube para facilitar el acceso multidispositivo y los datos biométricos (como la huella digital o el reconocimiento facial), el PIN o el patrón para iniciar sesión de forma segura. De esta forma, se reducen las vulnerabilidades y los inconvenientes asociados a las contraseñas tradicionales.

Al adoptar las llaves de acceso con Gestor de credenciales, Zoho ha reducido los tiempos de inicio de sesión hasta 6 veces, ha disminuido los costes de asistencia relacionados con las contraseñas y ha observado una gran adopción por parte de los usuarios, ya que se han duplicado los inicios de sesión con llaves de acceso en 4 meses, con un crecimiento del 31% intermensual. Los usuarios de Zoho ahora disfrutan de inicios de sesión más rápidos y sencillos, así como de una seguridad resistente al phishing.

Implementación con Gestor de credenciales en Android

¿Cómo ha conseguido Zoho estos resultados? Utilizaron la API de Gestor de credenciales de Android, la biblioteca Jetpack recomendada para implementar la autenticación en Android.

Gestor de credenciales proporciona una API unificada que simplifica la gestión de los distintos métodos de autenticación. En lugar de usar diferentes APIs para contraseñas, llaves de acceso e inicios de sesión federados (como Iniciar sesión con Google), puedes usar una sola interfaz.

Para implementar las llaves de acceso en Zoho, se tuvieron que hacer ajustes tanto en el lado del cliente como en el del servidor. A continuación, se explica detalladamente el desglose del proceso de creación, inicio de sesión e implementación del lado del servidor de las llaves de acceso.

Creación de llaves de acceso

Para crear una llave de acceso, la aplicación primero obtiene los detalles de configuración del servidor de Zoho. Este proceso incluye una verificación única, como una huella digital o el reconocimiento facial. La aplicación usa estos datos de verificación, que tienen el formato de una cadena requestJson, para crear un CreatePublicKeyCredentialRequest. A continuación, la aplicación llama al método credentialManager.createCredential, que pide al usuario que se autentique mediante el método de desbloqueo de pantalla de su dispositivo (datos biométricos, huella digital, PIN, etc.).

Una vez que el usuario haya confirmado la operación, la aplicación recibirá los nuevos datos de la credencial de llave de acceso, los enviará de vuelta al servidor de Zoho para que los verifique y, a continuación, el servidor almacenará la información de la llave de acceso vinculada a la cuenta del usuario. La aplicación detecta y gestiona los errores o las cancelaciones de los usuarios durante el proceso.

Iniciar sesión

La aplicación Android de Zoho inicia el proceso de inicio de sesión con llave de acceso solicitando opciones de inicio de sesión, incluida una challenge única, al servidor backend de Zoho. A continuación, la aplicación usa estos datos para crear un GetCredentialRequest, lo que indica que se autenticará con una llave de acceso. A continuación, invoca la API CredentialManager.getCredential() de Android con esta solicitud. Esta acción activa una interfaz de sistema Android estandarizada que pide al usuario que elija su cuenta de Zoho (si hay varias llaves de acceso) y que se autentique con el método de desbloqueo de pantalla configurado en su dispositivo (huella digital, escaneo facial o PIN). Una vez que se haya autenticado correctamente, Gestor de credenciales devolverá una aserción firmada (prueba de inicio de sesión) a la aplicación de Zoho. La aplicación reenviará esta aserción al servidor de Zoho, que verificará la firma con la clave pública almacenada del usuario y validará el reto, completando el proceso de inicio de sesión seguro.

Implementación del lado del servidor

La transición de Zoho a la compatibilidad con las llaves de acceso se benefició de que sus sistemas backend ya cumplían el estándar FIDO WebAuthn, lo que agilizó el proceso de implementación del lado del servidor. Sin embargo, aún eran necesarias modificaciones específicas para integrar completamente la función de llave de acceso.

El mayor reto fue adaptar el sistema de almacenamiento de credenciales. Los métodos de autenticación de Zoho, que utilizaban principalmente contraseñas y llaves de seguridad FIDO para la autenticación multifactor, requerían enfoques de almacenamiento diferentes a las llaves de acceso, que se basan en claves públicas criptográficas. Para solucionar este problema, Zoho ha implementado un nuevo esquema de base de datos diseñado específicamente para almacenar de forma segura las claves públicas de las llaves de acceso y los datos relacionados de acuerdo con los protocolos de WebAuthn. Este nuevo sistema se ha creado junto con un mecanismo de búsqueda para validar y recuperar credenciales basadas en la información del usuario y del dispositivo, lo que garantiza la retrocompatibilidad con métodos de autenticación anteriores.

Otro ajuste del lado del servidor consistió en implementar la capacidad de gestionar solicitudes de dispositivos Android. Las solicitudes de llave de acceso que proceden de aplicaciones Android usan un formato de origen único (android:apk-key-hash:example) que es distinto de los orígenes web estándar, que usan un formato basado en URI (https://example.com/app). La lógica del servidor se ha actualizado para analizar correctamente este formato, extraer el hash de la huella digital SHA-256 del certificado de firma de la aplicación y validarlo con una lista registrada previamente. Este paso de verificación asegura que las solicitudes de autenticación procedan realmente de la aplicación Android de Zoho y protege contra los ataques de phishing.

En este fragmento de código se muestra cómo comprueba el servidor el formato de origen específico de Android y valida el hash del certificado:

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

Gestión de errores

Zoho ha implementado mecanismos de gestión de errores sólidos para gestionar los errores que ven los usuarios y los que ven los desarrolladores. Se ha producido un error habitual, CreateCredentialCancellationException, cuando los usuarios han cancelado manualmente la configuración de su llave de acceso. Zoho ha monitorizado la frecuencia de este error para evaluar posibles mejoras en la experiencia de usuario. De acuerdo con las recomendaciones de experiencia de usuario de Android, Zoho tomó medidas para informar mejor a sus usuarios sobre las llaves de acceso, asegurarse de que conocieran su disponibilidad y fomentar su adopción durante los intentos de inicio de sesión posteriores.

En este ejemplo de código se muestra el enfoque de Zoho para gestionar los errores más habituales en la creación de llaves de acceso:

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

Probar llaves de acceso en entornos de intranet

Zoho se enfrentó a un reto inicial al probar las llaves de acceso en un entorno de intranet cerrado. El proceso de verificación del Gestor de contraseñas de Google para las llaves de acceso requiere acceso al dominio público para validar el dominio de la parte verificadora (RP). Sin embargo, el entorno de pruebas interno de Zoho no tenía este acceso público a Internet, lo que provocó que el proceso de verificación fallara y que no se pudieran realizar pruebas de autenticación con llave de acceso. Para solucionar este problema, Zoho creó un entorno de prueba de acceso público, que incluía el alojamiento de un servidor temporal con un archivo de enlace de recurso y la validación del dominio.

En este ejemplo del archivo assetlinks.json usado en el entorno de prueba público de Zoho se muestra cómo asociar el dominio de la parte verificadora con la aplicación Android especificada para la validación de la llave de acceso.

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

Integración con un servidor FIDO

El sistema de llaves de acceso de Android utiliza el estándar moderno WebAuthn de FIDO2. Este estándar requiere que las solicitudes tengan un formato JSON específico, lo que ayuda a mantener la coherencia entre las aplicaciones nativas y las plataformas web. Para habilitar la compatibilidad con llaves de acceso de Android, Zoho ha hecho pequeños cambios en la compatibilidad y la estructura para generar y procesar correctamente las solicitudes que cumplen la estructura JSON de FIDO2.

Esta actualización del servidor ha implicado varios ajustes técnicos específicos:

1. Conversión de codificación: el servidor convierte la codificación de URL Base64 (que se usa habitualmente en WebAuthn para campos como los IDs de credenciales) en codificación Base64 estándar antes de almacenar los datos pertinentes. En el siguiente fragmento se muestra cómo se puede codificar un rawId en Base64 estándar:

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

2. Formato de la lista de transportes: para asegurar un procesamiento de datos coherente, la lógica del servidor gestiona las listas de mecanismos de transporte (como USB, NFC y Bluetooth, que especifican cómo se ha comunicado el autenticador) como arrays JSON.

3. Alineación de los datos de cliente: el equipo de Zoho ha ajustado la forma en que el servidor codifica y decodifica el campo clientDataJson. De esta forma, la estructura de los datos se ajusta exactamente a las expectativas de las APIs internas de Zoho. En el ejemplo que se incluye a continuación, se muestra parte de la lógica de conversión aplicada a los datos del cliente antes de que el servidor los procese:

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

Guía para usuarios y preferencias de autenticación

Una parte fundamental de la estrategia de llaves de acceso de Zoho consistía en fomentar la adopción por parte de los usuarios y, al mismo tiempo, ofrecer flexibilidad para adaptarse a los diferentes requisitos de las organizaciones. Esto se ha conseguido gracias a un diseño de interfaz de usuario y a controles de políticas muy cuidados.

Zoho se dio cuenta de que las organizaciones tienen necesidades de seguridad diferentes. Para ello, Zoho ha implementado lo siguiente:

• Implementación por parte del administrador: a través del panel de administración de Zoho Directory, los administradores pueden designar las llaves de acceso como método de autenticación predeterminado y obligatorio para toda su organización. Si esta política está habilitada, los empleados deberán configurar una llave de acceso la próxima vez que inicien sesión y usarla a partir de entonces.
• Elección del usuario: si una organización no aplica una política específica, los usuarios individuales mantienen el control. Pueden elegir el método de autenticación que prefieran durante el inicio de sesión. Para ello, pueden seleccionar entre las llaves de acceso u otras opciones configuradas en los ajustes de autenticación.

Para que los usuarios finales puedan adoptar las llaves de acceso de forma sencilla y atractiva, Zoho ha implementado lo siguiente:

• Configuración sencilla: Zoho ha integrado la configuración de llaves de acceso directamente en la aplicación móvil Zoho OneAuth (disponible para Android y iOS). Los usuarios pueden configurar sus llaves de acceso en la aplicación en cualquier momento, lo que facilita la transición.
• Acceso coherente: se ha implementado la compatibilidad con llaves de acceso en los principales puntos de contacto con los usuarios, lo que permite a los usuarios registrarse y autenticarse con llaves de acceso a través de los siguientes medios:
• La aplicación móvil Zoho OneAuth (Android y iOS).
• Su página de cuentas web de Zoho.

De esta forma, el proceso de configuración y uso de las llaves de acceso era accesible y se integraba en las plataformas que ya utilizaban, independientemente de si lo había impuesto un administrador o lo había elegido el usuario. Para obtener más información sobre cómo crear flujos de usuario fluidos para la autenticación con llaves de acceso, consulta nuestra completa guía de experiencia de usuario con llaves de acceso.

Impacto en la velocidad de desarrollo y la eficiencia de la integración

El Gestor de credenciales, como API unificada, también ha ayudado a mejorar la productividad de los desarrolladores en comparación con los antiguos flujos de inicio de sesión. Se redujo la complejidad de gestionar varios métodos de autenticación y APIs por separado, lo que permitió acelerar la integración (de meses a semanas) y reducir los errores de implementación. De esta forma, se ha optimizado el proceso de inicio de sesión y se ha mejorado la fiabilidad general.

Al implementar llaves de acceso con Gestor de credenciales, Zoho ha conseguido mejoras significativas y cuantificables en todos los aspectos:

• Mejoras drásticas en la velocidad
  • Inicio de sesión dos veces más rápido que con la autenticación tradicional con contraseña.
  • Inicio de sesión cuatro veces más rápido que con el nombre de usuario o el número de móvil con autenticación por correo electrónico o SMS con OTP.
  • Inicio de sesión 6 veces más rápido que con la autenticación mediante nombre de usuario, contraseña y OTP por SMS o aplicación Authenticator.
• Reducción de los costes de asistencia
  • Reducción de las solicitudes de asistencia relacionadas con contraseñas, sobre todo las de contraseñas olvidadas.
  • Costes más bajos asociados a la autenticación de dos factores basada en SMS, ya que los usuarios pueden incorporar directamente las llaves de acceso.
• Gran adopción por parte de los usuarios y seguridad mejorada:
  • El inicio de sesión con llave de acceso se ha duplicado en solo 4 meses, lo que demuestra que los usuarios lo aceptan.
  • Los usuarios que migren a las llaves de acceso estarán totalmente protegidos frente a las amenazas habituales de phishing y vulneración de contraseñas.
  • Con un crecimiento de la adopción del 31% mes a mes, cada día más usuarios se benefician de una mayor seguridad frente a vulnerabilidades como el phishing y el cambio de SIM.

sugerencias y prácticas recomendadas

Para implementar correctamente las llaves de acceso en Android, los desarrolladores deben tener en cuenta las siguientes prácticas recomendadas:

• Aprovecha la API de Gestor de credenciales de Android:
  • Gestor de credenciales simplifica la recuperación de credenciales, lo que reduce el esfuerzo de los desarrolladores y garantiza una experiencia de autenticación unificada.
  • Gestiona contraseñas, llaves de acceso y flujos de inicio de sesión federado en una sola interfaz.
• Asegúrate de que la codificación de datos sea coherente al migrar desde otras soluciones de autenticación FIDO:
  • Asegúrate de que el formato sea coherente en todas las entradas y salidas al migrar desde otras soluciones de autenticación FIDO, como las llaves de seguridad FIDO.
• Optimiza la gestión de errores y el registro:
  • Implementa una gestión de errores sólida para ofrecer una experiencia de usuario fluida.
  • Proporciona mensajes de error localizados y usa registros detallados para depurar y resolver fallos inesperados.
• Informa a los usuarios sobre las opciones de recuperación de llaves de acceso:
  • Evita que los usuarios se queden sin acceso guiándolos de forma proactiva sobre las opciones de recuperación.
• Monitoriza las métricas de adopción y los comentarios de los usuarios:
  • Monitoriza la interacción de los usuarios, los porcentajes de adopción de llaves de acceso y los porcentajes de éxito de inicio de sesión para seguir optimizando la experiencia de usuario.
  • Realiza pruebas A/B en diferentes flujos de autenticación para mejorar la conversión y la retención.

Las llaves de acceso, combinadas con la API de Gestor de credenciales de Android, ofrecen una solución de autenticación potente y unificada que mejora la seguridad y simplifica la experiencia de usuario. Las llaves de acceso reducen significativamente los riesgos de phishing, robo de credenciales y accesos no autorizados. Animamos a los desarrolladores a probar la experiencia en su aplicación y ofrecer la autenticación más segura a sus usuarios.

Empezar a usar llaves de acceso y el Gestor de credenciales

Descubre las llaves de acceso y Gestor de credenciales en Android con nuestro código de muestra público.

Si tienes alguna pregunta o problema, puedes comunicárnoslo a través del gestor de problemas de credenciales de Android.