Ofrece acceso sin interrupciones y credenciales digitales en Android

Hola a todos.

Gracias por acompañarnos hoy.

Hoy, nos complace hablar sobre el futuro de la autenticación y la identidad digital.

Soy Tom Colvin.

Soy director de tecnología de Apptaura y GDE de Android. Me acompaña Chiping Yeh, ingeniero sénior de Relaciones con Desarrolladores de Android en Google.

La venerable contraseña está muerta.

O, al menos, debería serlo.

Hoy les hablaré sobre un mundo sin contraseñas.

Las contraseñas son una vulnerabilidad bien conocida en nuestra infraestructura de seguridad.

Incluso cuando se almacenan de forma segura, son vulnerables al phishing, a las violaciones de la seguridad de los servidores y a los ataques automatizados, como el uso de credenciales robadas.

Como industria, intentamos abordar este problema aplicando la complejidad: caracteres especiales, números y rotaciones obligatorias.

La evidencia demuestra que esto no funciona, en parte porque, paradójicamente, cuanto más difícil lo haces, más fomentas el comportamiento inseguro.

Porque una contraseña compleja que se cambia con frecuencia es probable que se anote en una nota adhesiva.

Incluso la autenticación de dos factores basada en SMS demostró ser vulnerable a la intercepción, como el intercambio de SIM.

Sin embargo, hoy en día, este problema está prácticamente resuelto.

Las llaves de acceso se basan en los estándares de FIDO y usan la criptografía de clave pública-privada.

Son muy resistentes al phishing, no se exponen en una violación de la seguridad del servidor y están vinculadas directamente a la seguridad del teléfono del usuario a través del bloqueo de pantalla, que, en la mayoría de los casos, se basa en nuestros datos biométricos, huellas dactilares, etc. Además, mejoran activamente la experiencia del usuario con una experiencia unificada en todas las plataformas y sin necesidad de recordar contraseñas complejas.

Nuestro manifiesto de hoy es simple.

Es hora de pasar a un mundo sin contraseñas.

Y las herramientas para hacerlo ya están en nuestras manos.

Para dar este salto en Android, contamos con el Administrador de credenciales de Jetpack.

Es compatible con versiones anteriores hasta Android 4.4, y con llaves de acceso desde Android 9. Proporciona una sola API unificada que admite llaves de acceso y autenticación tradicional, como el acceso federado, como Acceder con Google, y que incluye un resguardo elegante a las contraseñas si es necesario.

Llamas a la API de Credential Manager, y esta controla la IU para seleccionar el método de autenticación que el usuario quiere ver.

Luego, hace el trabajo pesado para devolver la credencial correcta, obtenida de forma segura.

Admite el acceso, el registro y la copia de seguridad de las credenciales.

También puedes usarla para actualizar y borrar credenciales.

También ayuda a los usuarios a mover sus contraseñas y llaves de acceso entre proveedores de credenciales con solo unos clics y sin necesidad de descargar archivos.

Está diseñada para brindarles a los usuarios control total sobre sus datos y la libertad de cambiar de proveedor cuando lo necesiten.

Además, el Administrador de credenciales admite muchos factores de forma, como relojes, TVs, RE, vehículos, teléfonos, plegables y tablets.

Y, lo más importante para nosotros, tiene un flujo dedicado para las llaves de acceso.

Así es como se ve para el usuario durante el registro.

Mi app le indica al Credential Manager que la autenticación con llave de acceso está disponible y le proporciona detalles recopilados del backend.

Presionas Registrar y el Administrador de credenciales te muestra una hoja inferior con un mensaje de bloqueo de pantalla.

Por lo general, se desbloquea con datos biométricos, como la huella dactilar o el escaneo facial.

Luego, el Administrador de credenciales se encarga del trabajo criptográfico complejo, como crear la llave de acceso.

Y guarda la llave de acceso en mi administrador de credenciales, que, en este caso, es el Administrador de contraseñas de Google, pero podría ser otro.

Así se ve el código.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

val createCredentialResponse =  credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

Primero, creamos este objeto createPublicKeyCredentialRequest con los detalles que proporciona el backend, que es este registerRequestJson.

Luego, llamamos al método mágico credentialManager.createCredential.

Pasamos esa solicitud y el contexto local, lo que permite que se muestre la IU.

Por cierto, observa que no tuve que escribir ningún código de IU aquí.

Credential Manager se encarga de eso por completo.

Este es el proceso de acceso.

Para el usuario, se parece mucho al proceso de registro.

Solo hay un mensaje de desbloqueo y listo.

Para los desarrolladores, solo un poco diferente.

val getPublicKeyCredentialOption = GetPublicKeyCredentialOption(
   requestJson = authenticationRequestJson
)
val signInRequest =
   GetCredentialRequest(listOf(getPublicKeyCredentialOption))

val result =  credentialManager.getCredential  (
   context = localActivity,
   request = signInRequest
)

Primero, obtenemos los detalles del acceso desde el backend para compilar una instancia de GetPublicKeyCredential.

Le indicamos al Administrador de credenciales qué tipos de credenciales admitimos.

Aquí solo se muestran las llaves de acceso.

Pero también podemos agregar otros tipos de credenciales si queremos.

Luego, llamamos a credentialManager.getCredential y pasamos esa lista de credenciales que acabamos de solicitar.

De nuevo, no hay código de IU.

No es necesario escribir ningún código de IU.

El Administrador de credenciales se encarga de eso por nosotros.

Guía al usuario hacia la opción que se usa con más frecuencia y deja las demás disponibles como respaldo.

Esto resuelve automáticamente uno de los problemas de autenticación más molestos de la actualidad.

¿Notaste que…?

Es decir, recordar qué método usé por última vez para acceder.

Mira, ahí está la respuesta presentada de forma ordenada en una hoja inferior.

Por cierto, esto no solo es una molestia para el usuario.

Es un punto de fricción real.

Genera recuperaciones de cuentas innecesarias y tiene un impacto comercial, como carritos de compras abandonados.

Aquí tienes el código de mi aplicación de demostración, que puedes usar para probar el Administrador de credenciales por tu cuenta.

Puedes ver estos flujos en tu propio dispositivo.

Y, a la izquierda, están las muestras de código oficiales de Google.

Se encarga de crear llaves de acceso.

¿Qué sucede con la actualización de los usuarios que usan contraseñas a las llaves de acceso?

Una herramienta potente para eso es la creación condicional.

Si el usuario acaba de acceder con su contraseña y un proveedor de credenciales compatible la completó automáticamente, sabemos que está participando de forma activa y que acabamos de verificar su identidad.

En ese caso, la creación condicional nos permite solicitar la creación de una llave de acceso automáticamente en segundo plano.

No interrumpe el flujo de trabajo del usuario.

La llave de acceso se genera de forma silenciosa y se almacena.

El Administrador de contraseñas de Google muestra una notificación para confirmar que esto sucedió.

Otros administradores de contraseñas podrían hacerlo de otra manera.

El código para la creación condicional se parece mucho al código para registrarse.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson,
   preferImmediatelyAvailableCredentials = false,
   isConditional = true
)

val createCredentialResponse = credentialManager.createCredential  (
   context = localActivity,
   request = createPublicKeyCredentialRequest
)

La marca mágica es isConditional true, lo que garantiza que el usuario no vea esa IU.

Y, como funciona de manera oportunista, lo colocaremos en un bloque try-catch.

Controlaremos los errores de forma silenciosa para no molestar al usuario si el proceso falla.

Luego, la llave de acceso se guarda en el Administrador de credenciales del usuario y estará disponible para la próxima vez.

El Administrador de credenciales también permite que los proveedores de credenciales importen y exporten sus credenciales de forma segura.

Solo unos pocos clics.

No se necesitan descargas.

Esto brinda más flexib-- flexibilidad, a la vez que mantiene la información segura.

El flujo se ve de la siguiente manera.

En su nuevo proveedor de credenciales, el usuario solicita importar credenciales.

Luego, el Administrador de credenciales controla la IU de importación, lo que permite que el usuario seleccione la fuente de los datos de las credenciales.

Luego, el proveedor de credenciales de exportación puede proporcionar su propia IU, lo que le permite educar al usuario y proporcionar las advertencias pertinentes.

Por último, el nuevo proveedor de credenciales del usuario recibe los datos a través de un canal seguro.

Por lo tanto, puede importarlo sin que haya interacción del usuario.

Pero ¿qué sucede si el usuario revoca una llave de acceso de su app o sitio web?

Entonces, el proveedor de credenciales no necesariamente sabe que eso sucedió.

La próxima vez que intenten acceder, el Credential Manager ofrecerá esa llave de acceso inactiva y solo tendrán un intento rechazado.

Del mismo modo, cuando un usuario actualiza su nombre de usuario o nombre visible, se requiere una sincronización.

Ahora, con la API de Signal, tu app puede marcar estos estados específicos para el proveedor de credenciales.

Tomemos como ejemplo el caso de acceder con una contraseña revocada.

Tu app puede detectar ese estado de error específico y usarlo para informar al proveedor de credenciales del usuario.

Luego, el proveedor de credenciales puede actualizarse para que no se ofrezca esa llave de acceso en particular.

Esas son algunas de las funciones del Administrador de credenciales, que es increíblemente útil para que los usuarios se registren con llaves de acceso y para priorizarlas por sobre otros métodos cuando accedemos.

Pero recuerda que nuestro objetivo final es dejar de usar contraseñas por completo.

¿Cómo ayuda Credential Manager a lograr ese objetivo?

Este es nuestro proceso de cinco pasos propuesto.

En los primeros dos pasos, actualizas a los usuarios de contraseñas a llaves de acceso.

Primero, intentamos de forma oportunista, con la creación condicional.

Luego, si no se presenta esa oportunidad, necesitaremos la intervención del usuario, por lo que se enviarán invitaciones en la app para que los usuarios configuren la llave de acceso.

Podemos empezar a mostrarlos de forma gradual y cada vez más destacada.

Después de todo, desde la perspectiva del usuario, por lo general, solo necesita proporcionar su bloqueo de pantalla, como los datos biométricos.

Una vez que las estadísticas muestren que la gran mayoría de tus usuarios tienen cuentas que usan llaves de acceso, estas se podrán exigir para todos los usuarios nuevos.

Pero esos usuarios antiguos, con ellos lidiamos en estos últimos tres pasos.

Recomendamos a los usuarios de llaves de acceso que quiten sus contraseñas.

Por lo tanto, en el paso 3, les permitimos hacerlo de forma manual, con una opción muy clara para borrar la contraseña en la configuración de su cuenta.

En el paso 4, comenzamos a impulsar la eliminación de contraseñas, por ejemplo, con notificaciones en la app, junto con un texto educativo.

Por último, cambias la eliminación de contraseñas de habilitación a inhabilitación.

Con el tiempo, incluso esa última opción de inhabilitación puede desaparecer.

Analytics nos dará la confianza necesaria para quitar por completo los flujos de contraseñas de la app.

Por lo tanto, avanzar hacia un mundo sin contraseñas ya no es un concepto de seguridad teórico para algún momento en el futuro.

Tiene una gran compatibilidad.

Las APIs son sólidas y la experiencia del usuario es excelente.

Te recomendamos que comiences a integrar los flujos de llaves de acceso con el Administrador de credenciales hoy mismo.

Comienza a actualizar a tus usuarios y, por fin, dejemos las contraseñas en el pasado.

Gracias.

Ahora, le daré la palabra a Chiping para que hable sobre la próxima evolución en la migración y la identidad de los dispositivos.

Genial.

Muy bien, gracias, Tom.

Como destacó Tom, la autenticación fluida en los dispositivos de los usuarios es fundamental.

Pero ¿qué sucede cuando un usuario adquiere un teléfono nuevo?

Actualmente, la mayor pérdida de usuarios en el recorrido del usuario se produce cuando cambian de dispositivo.

Hoy, primero quiero hablar sobre cómo estamos resolviendo ese problema y, luego, abordar rápidamente un próximo requisito de Play Store relacionado con el restablecimiento de credenciales.

A partir de abril de 2027, Google Play exigirá que las apps cumplan con los requisitos de acceso sin presionar para mantener todas las funciones de publicación y una visibilidad óptima en Play Store.

¿Qué es el acceso sin presionar?

En la práctica, esto significa que los usuarios no necesitan volver a autenticarse de forma manual en tu app cuando se cambian a un dispositivo nuevo.

¿Cómo implementamos esto?

El método principal que recomendamos para hacerlo es a través de la API de Restore Credentials de Android con el Administrador de credenciales.

Esta API te permite generar lo que se conoce como una clave de restablecimiento, que se guarda en el dispositivo del usuario o en la nube según la configuración de copia de seguridad del usuario.

Te recomendamos que generes esta clave en segundo plano una vez que el usuario haya accedido.

En este diagrama, ilustramos a un usuario que accede a la app.

Luego, la clave de restablecimiento se crea mientras usan la app en algún momento.

Luego, esta clave se almacena de forma local o, si está habilitada, de forma remota en la nube.

Cuando el usuario configura su dispositivo nuevo, la credencial de restablecimiento se transfiere de forma silenciosa en segundo plano durante el proceso de configuración del dispositivo.

Los usuarios pueden elegir restablecer los datos desde la nube o mediante la transferencia de dispositivo a dispositivo.

Luego, cuando se abra tu app, podrás llamar a la API de Credential Manager para usar esta clave de restablecimiento y permitir que el usuario acceda en el dispositivo nuevo la primera vez que lo inicie.

Esto permite que el usuario acceda de forma rápida y segura a tu app de inmediato.

Si quieres que tu app se restablezca inmediatamente después de la configuración sin que se abra, puedes implementar un agente de copia de seguridad personalizado para hacerlo.

Esto permitirá que el usuario acceda a tu app sin abrirla manualmente.

Algunos de nuestros socios ya implementaron esto en su app.

Uber es la empresa de viajes compartidos más grande del mundo, que proporciona transporte a millones de personas y, al mismo tiempo, ofrece servicios de entrega de comida, transporte para atención médica y logística de carga.

La simplicidad del acceso es fundamental.

Además, cuando los usuarios cambian de dispositivo, esperan una transición fluida sin tener que volver a acceder a la app de Uber ni pasar por la autenticación única basada en SMS cada vez.

Esta rotación frecuente de dispositivos presenta un desafío para la retención de usuarios.

Después de evaluar la demanda de los usuarios y crear prototipos de código, Uber introdujo la compatibilidad con Restore Credentials en la app de Uber para pasajeros, y los resultados fueron muy positivos.

Estiman que se ahorrarán 4 millones de accesos diarios promedio por día y esperan que esta cifra aumente a medida que crezca la adopción.

Consulta este código QR y el vínculo para obtener más información sobre esta próxima política y cómo tu app puede cumplir con los requisitos de restablecimiento sin presionar.

Nuevamente, esto se implementará en abril de 2027, así que asegúrate de marcarlo en tu calendario.

Si quieres comenzar a implementar Restore Credentials en tu app, consulta este código QR y el vínculo para acceder a nuestra habilidad de Restore Credentials.

Esta habilidad se puede usar para ayudar a desarrollar o probar rápidamente la función con el agente que elijas.

Ahora, veamos la próxima frontera de la identidad digital: la API de Digital Credentials a través de Credential Manager.

Repasemos qué son las credenciales digitales y cómo funcionan.

Las credenciales digitales son documentos digitales verificables criptográficamente que los usuarios pueden usar para proporcionar información sobre sí mismos.

Estos documentos se almacenan en contenedores digitales en el dispositivo del usuario y otras apps del dispositivo pueden solicitarlos o presentarlos al mundo de forma híbrida, por ejemplo, a través de un código QR.

Los usos son amplios y variados, desde verificar la identidad hasta acceder a servicios y comprar artículos en línea.

Las credenciales digitales ofrecen una forma segura y conveniente de compartir información sin necesidad de usar tarjetas físicas.

Las credenciales digitales involucran a tres partes: la entidad emisora, el titular y el verificador.

La vida de una credencial digital suele fluir de izquierda a derecha.

Repasemos cada una de estas entidades y el rol que desempeñan.

El primero es el emisor, que, como su nombre lo indica, es una parte que emite una credencial, tal como el Gobierno emite tu pasaporte.

Sin embargo, en el mundo digital, para evitar la falsificación de identidad, estas credenciales también están firmadas por la entidad emisora con su certificado digital, de modo que cualquier persona que reciba la credencial pueda saber exactamente de quién proviene.

De hecho, cualquier persona puede ser emisora, ya sea un gimnasio, un hotel o incluso tú.

Solo debes crear una credencial y firmarla.

Bien, la entidad emisora crea y emite credenciales, pero estas deben almacenarse en algún lugar, tal como necesitas guardar tu documento de identidad emitido por el Gobierno en tu propia billetera.

Esta es la siguiente parte, que se denomina titular y que también se suele describir como una billetera digital.

Los titulares, como su nombre lo indica, principalmente conservan las credenciales que emiten las entidades emisoras.

Se almacenan como una app en tu dispositivo y, luego, puedes presentarlos a las partes solicitantes.

Al igual que con las entidades emisoras, cualquier persona puede ser titular.

De hecho, no es raro que la misma entidad administre a las entidades emisoras y a los titulares.

Piensa en un gimnasio que quiere crear su propia credencial de membresía digital y también administrarla a través de su propia app.

Eso sería un emisor y un titular en uno.

Bien, el tercero es el verificador, es decir, la parte que solicita las credenciales digitales.

Los verificadores realizan solicitudes de credenciales, por lo general, para comprobar atributos de un usuario, como los requisitos de edad, el apellido, etcétera.

Estas son las empresas o apps que necesitan datos adicionales de los usuarios para realizar un servicio, como comprar bebidas alcohólicas o verificar una edad mínima.

En Android, las interacciones entre estas tres partes y el usuario se coordinan a través de Credential Manager con la API de Digital Credentials.

La entidad emisora puede llamar a la API para emitir credenciales a un titular, aunque esto no es necesario si se trata de la misma entidad.

Después de que se emite la credencial, un verificador puede llamar a una API para solicitarla.

El Administrador de credenciales hace coincidir la solicitud con todos los titulares disponibles y se los presenta al usuario para que seleccione la credencial y otorgue su consentimiento.

Una vez que se selecciona un titular, se lo invoca y puede realizar verificaciones adicionales si es necesario antes de compartir la credencial con el verificador.

Una vez que el verificador recibe la credencial, también puede realizar varias comprobaciones sobre la legitimidad de la credencial, incluida la verificación de la entidad emisora original.

Ahora, tal vez te preguntes cómo se protegen exactamente las credenciales digitales.

Bueno, la seguridad está integrada en cada paso del proceso, y ahora veremos algunos de ellos.

Por lo tanto, en el lado de la entidad emisora, cuando esta quiere compartir una credencial con un titular, debe verificar que el titular no se pueda alterar ni copiar, básicamente que sea de confianza.

¿Cómo puede verificarlo?

Antes de que una entidad emisora publique la credencial, necesita que el titular demuestre su propia identidad y la seguridad del dispositivo en el que opera.

El titular envía la certificación de su billetera, por lo general, como una cadena de certificados verificable.

El titular también genera un par de claves vinculadas al hardware.

Envía al emisor la clave pública de este par de claves con la certificación de claves de Android, de modo que el emisor pueda validar la legitimidad del hardware.

La entidad emisora firmará esta clave pública en la credencial emitida, de modo que la credencial quede vinculada oficialmente al dispositivo único.

En el lado del titular, una vez que este tiene una credencial nueva, registra solo los metadatos de la credencial con el Administrador de credenciales.

El Administrador de credenciales usa estos metadatos para determinar qué titulares mostrar cuando un verificador realiza una solicitud de credenciales.

No se registran datos reales de los usuarios en el Administrador de credenciales ni se exponen a Google.

Incluso cuando el Administrador de credenciales selecciona billeteras para mostrarle al usuario, el contenido de cada billetera no se revela en ese momento.

Ahora, cuando se realiza una solicitud de credencial y un usuario da su consentimiento para compartir una credencial, se invoca al titular seleccionado y se le entrega el control del flujo de trabajo.

Como recordarás, un titular es solo una app, por lo que se invoca la app.

En este momento, el titular puede ver elementos como el verificador que realiza la solicitud y la credencial solicitada, y puede decidir si quiere compartir esa credencial con ese verificador, incluso si el usuario ya otorgó el permiso.

Google no puede acceder a los datos de las credenciales.

Solo se registran los metadatos de enrutamiento, y la carga útil se encripta de extremo a extremo entre el titular y el verificador.

Esto le da al titular el control sobre con qué partes quiere compartir sus credenciales.

Por último, en el lado del verificador, después de que se solicita la credencial y el titular la comparte, el verificador recibe la presentación de la credencial de un titular.

Ahora, el verificador puede comprobar si el titular original de la credencial generó la respuesta recientemente para la solicitud.

Puede confirmar que la respuesta de la credencial se firmó con la clave vinculada al dispositivo del titular, lo que incluye solicitar un token de un solo uso y llamar al origen observado por el titular.

El verificador también puede comprobar la autenticidad de la entidad emisora de la credencial verificando su certificado, lo que garantiza que provenga de una fuente de confianza.

En resumen, las entidades emisoras obtienen garantías de hardware, los titulares obtienen el control de las credenciales que quieren compartir, los verificadores obtienen pruebas criptográficas de la entidad emisora y del titular, y los usuarios conservan el consentimiento total sobre los datos que quieren compartir.

Ahora que explicamos cómo se protegen las credenciales digitales, veamos algunos de los casos de uso de las credenciales digitales que están disponibles hoy en día a través de la API de Digital Credentials en Android.

El primero que abordaré se llama verificación por correo electrónico.

Esta API toma la cuenta de Gmail con la que accedió el usuario directamente desde su dispositivo y la presenta como una credencial digital verificada por Google a tu app, lo que elimina la necesidad de enviar contraseñas de un solo uso o vínculos mágicos.

Esto significa que el usuario nunca abandona tu app y solo necesita dar su consentimiento con un toque en la hoja inferior conocida del Administrador de credenciales.

Aquí tienes una grabación de demostración de la API en acción.

Esta es una app de ejemplo que implementa la verificación por correo electrónico a través de la API de Digital Credentials.

Cuando presiono "Solicitar correo electrónico verificado", el Administrador de credenciales solicita una credencial digital de correo electrónico verificado a los titulares del dispositivo que tienen este tipo de credencial.

En este caso, solo Google es el titular de esta credencial de correo electrónico verificada, que se muestra en la hoja inferior.

Este es uno de los correos electrónicos con los que el usuario accedió al dispositivo.

De hecho, en este caso, Google es tanto el emisor como el titular de la credencial digital.

Una vez que selecciono la credencial que quiero compartir, se devuelve a la app, que actualmente solo muestra los campos que contiene la credencial, que es el correo electrónico verificado.

En tu app, puedes usar esta información para continuar a la siguiente pantalla, como crear una llave de acceso o realizar otros pasos de creación de cuentas.

Para el usuario, es tan sencillo como otorgar el consentimiento y, luego, pasar a la siguiente pantalla.

Si quieres probarla, puedes navegar a nuestro ejemplo de GitHub y, luego, instalarla en tu propio dispositivo.

Intenta usarlo en un dispositivo físico y ten en cuenta que deberás acceder a, al menos, una cuenta de Gmail en tu dispositivo.

Así que les daré un poco más de tiempo si les interesa.

Bien.

Suena emocionante, ¿no?

Y cuando piensas en la verificación por correo electrónico, ¿cuál es la siguiente forma de verificación de usuarios que se te viene a la mente?

Así es, la verificación del número de teléfono.

La API de Digital Credentials también admite de forma nativa la verificación del número de teléfono, lo que elimina las complicaciones y la vulnerabilidad de las OTP por SMS.

La verificación del número de teléfono también funciona a través de la API de Digital Credentials y, en este caso, el número de teléfono del dispositivo se solicita y se presenta como una credencial digital.

El usuario solo ve la conocida hoja inferior de Credential Manager para compartir o verificar su número de teléfono, permanece en la app y solo necesita presionar unas pocas veces para completar la verificación.

Aquí, puedes ver una app de ejemplo en la que el cliente puede compartir su número de teléfono con un solo toque, sin salir de la app.

¿Cómo funciona esta configuración?

Si asignamos esto a las partes de las credenciales digitales, la entidad emisora, en este caso, es el operador telefónico del número de teléfono de la tarjeta SIM del dispositivo, y el titular es Android Telephony.

Cuando un verificador, como tu app, solicita el número de teléfono del usuario, este se recupera de la telefonía de Google con una llamada a la API de Digital Credentials.

Tal vez te preguntes cómo funciona la facturación.

Hay un paso adicional que es exclusivo de este flujo, en el que la credencial se pasa a tu operador o agregador para fines de facturación.

Esto sucede después de que se recupera el número de teléfono de Google Telephony, donde se almacena en un estado encriptado.

Luego, se pasa al operador, que desencripta y devuelve el número de teléfono directamente al backend de tu app, durante lo cual se te factura.

Lo mejor de esto es que el operador solo te cobrará por las verificaciones exitosas, que se transfieren a través de datos o Wi-Fi, y son mucho más confiables que los SMS.

Aquí, tenemos una demostración de la verificación del número de teléfono en acción, con Firebase como agregador de operadores.

La app solicita el número de teléfono del usuario como parte del proceso de acceso.

Este usuario tiene varias tarjetas SIM y elige una para compartirla con la app.

Una vez que el usuario confirma su elección, el intercambio se produce en segundo plano.

Luego, verás la siguiente pantalla con el número de teléfono recuperado propagado.

El usuario nunca tuvo que salir de la app y solo tuvo que seleccionar y confirmar el número de teléfono que quería compartir para avanzar por el flujo sin problemas, todo en unos pocos toques.

Solo deja que termine para que puedas ver la finalización una vez más.

Y, luego, verás el número de teléfono en esa pantalla final.

Eso es todo.

Hoy cubrimos muchos temas.

Primero, exploramos el uso de Credential Manager para mejorar la implementación de llaves de acceso y avanzar hacia un mundo sin contraseñas.

Consulta nuestros recursos sobre Credential Manager y las llaves de acceso aquí para obtener más información y acceder a nuestras apps de ejemplo.

Luego, hablamos del próximo requisito de acceso sin presionar para tus apps, que permite que los usuarios accedan sin problemas cuando configuran un dispositivo nuevo.

Esto será obligatorio en Play Store a partir de abril de 2027, así que toma nota de esta fecha en tu calendario.

Por último, abordamos cómo funcionan las credenciales digitales y algunas de sus funciones más útiles en Android.

Consulta nuestros recursos sobre credenciales digitales aquí para profundizar en el contenido y acceder a nuestros ejemplos.

Todo lo que compartimos hoy está disponible y listo para que lo uses en tus compilaciones.

El futuro de la identidad en Android ya está aquí y es más emocionante que nunca.

Gracias por su tiempo. Sé que es hora de almorzar, así que disfruten de la comida que está afuera.

No duden en acercarse a mí o a Tom para hacernos preguntas sobre las llaves de acceso o las credenciales digitales.

Saludos,