Proposer une connexion fluide et des identifiants numériques sur Android

Bonjour !

Merci de nous avoir rejoints pour

Aujourd'hui, nous sommes ravis de parler de l'avenir de l'authentification et de l'identité numérique.

Je m'appelle Tom Colvin.

Je suis directeur de la technologie chez Apptaura et GDE pour Android. Je suis accompagné de Chiping Yeh, ingénieur DevRel senior pour Android chez Google.

Le bon vieux mot de passe est mort.

Ou, du moins, elle devrait l'être.

Aujourd'hui, je vais vous parler d'un monde sans mot de passe.

Les mots de passe sont une faille bien connue de notre infrastructure de sécurité.

Même lorsqu'ils sont stockés de manière sécurisée, ils sont vulnérables à l'hameçonnage, aux violations de serveur et aux attaques automatisées telles que le bourrage d'identifiants.

En tant que secteur, nous avons essayé de résoudre ce problème en imposant une certaine complexité : caractères spéciaux, chiffres, rotations obligatoires.

Les faits montrent que cette approche a échoué, en partie parce que plus vous compliquez les choses, plus vous encouragez, paradoxalement, des comportements non sécurisés.

En effet, un mot de passe complexe qui est modifié régulièrement est susceptible d'être écrit sur un post-it.

Même l'authentification à deux facteurs par SMS s'est avérée vulnérable à l'interception, comme l'échange de carte SIM.

Aujourd'hui, ce problème est en grande partie résolu.

Les clés d'accès sont basées sur les normes FIDO et utilisent la cryptographie à clé publique-privée.

Elles sont très résistantes au hameçonnage, ne sont pas exposées en cas de faille de sécurité du serveur et sont directement liées à la sécurité du téléphone de l'utilisateur via le verrouillage de l'écran, qui, dans la plupart des cas, est basé sur nos données biométriques, nos empreintes digitales, etc. De plus, elles améliorent activement l'expérience utilisateur grâce à une expérience unifiée sur toutes les plates-formes et à l'absence de mots de passe complexes à mémoriser.

Notre manifeste d'aujourd'hui est simple.

Il est temps de passer à un monde sans mot de passe.

Et nous avons déjà les outils pour le faire.

Pour effectuer cette transition sur Android, nous disposons de Jetpack Credential Manager.

Il est compatible avec Android 4.4 et les versions ultérieures, et prend en charge les clés d'accès depuis Android 9. Il fournit une API unifiée unique qui prend en charge les clés d'accès ainsi que l'authentification traditionnelle, comme la connexion fédérée (par exemple, Se connecter avec Google), et inclut une solution de remplacement fluide vers les mots de passe si nécessaire.

Vous appelez l'API Credential Manager, qui gère l'UI pour sélectionner la méthode d'authentification que l'utilisateur souhaite voir.

Il se charge ensuite de renvoyer l'identifiant approprié, obtenu de manière sécurisée.

Il permet de se connecter, de s'inscrire et de sauvegarder des identifiants.

Vous pouvez également l'utiliser pour mettre à jour et supprimer des identifiants.

Elle permet également aux utilisateurs de transférer leurs mots de passe et clés d'accès entre fournisseurs d'identifiants en quelques clics, sans avoir à télécharger de fichiers.

Il est conçu pour donner aux utilisateurs un contrôle total sur leurs données et la liberté de changer de fournisseur quand ils le souhaitent.

Le Gestionnaire d'identifiants est compatible avec de nombreux facteurs de forme, y compris les montres, les téléviseurs, les appareils XR, les voitures, les téléphones, les appareils pliables et les tablettes.

Et, plus important encore pour nous, il dispose d'un flux dédié aux clés d'accès.

Voici ce que l'utilisateur voit lors de l'inscription.

Mon application indique à Credential Manager que l'authentification par clé d'accès est disponible et lui fournit les informations recueillies auprès du backend.

Vous appuyez sur "S'inscrire", et Credential Manager affiche une bottom sheet avec une invite de verrouillage de l'écran.

Il est généralement déverrouillé à l'aide de données biométriques, comme une empreinte digitale ou faciale.

Le Gestionnaire d'identifiants gère ensuite les tâches de chiffrement complexes, comme la création de la clé d'accès.

Elle enregistre la clé d'accès dans mon gestionnaire d'identifiants, qui est ici le Gestionnaire de mots de passe de Google, mais qui pourrait être un autre gestionnaire.

Voici à quoi ressemble le code.

val createPublicKeyCredentialRequest = CreatePublicKeyCredentialRequest(
   requestJson = registerRequestJson
)

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

Tout d'abord, nous créons cet objet createPublicKeyCredentialRequest à l'aide des détails fournis par le backend, à savoir registerRequestJson.

Ensuite, nous appelons la méthode magique credentialManager.createCredential.

Nous transmettons cette requête et le contexte local, ce qui permet d'afficher l'UI.

Notez d'ailleurs que je n'ai pas eu à écrire de code d'interface utilisateur ici.

Le Gestionnaire d'identifiants s'en charge entièrement pour nous.

Voici le processus de connexion.

Pour l'utilisateur, cela ressemble beaucoup au processus d'inscription.

Il vous suffit de déverrouiller votre appareil une seule fois.

Pour les développeurs, la différence est minime.

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

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

Tout d'abord, nous récupérons les détails de la connexion à partir du backend pour créer une instance GetPublicKeyCredential.

Nous indiquons à Credential Manager les types d'identifiants que nous acceptons.

Ici, il s'agit simplement de clés d'accès.

Mais nous pouvons également ajouter d'autres types d'identifiants si nous le souhaitons.

Ensuite, nous appelons credentialManager.getCredential en transmettant la liste d'identifiants que nous venons de demander.

Encore une fois, aucun code d'interface utilisateur n'est nécessaire.

Inutile d'écrire du code d'UI.

Le Gestionnaire d'identifiants s'en charge entièrement pour nous.

Il incite l'utilisateur à choisir l'option la plus fréquemment utilisée, tout en laissant les autres disponibles en tant qu'options de secours.

Cela résout automatiquement l'un des problèmes d'authentification les plus ennuyeux aujourd'hui.

Avez-vous remarqué ?

Il se souvient de la dernière méthode que j'ai utilisée pour me connecter.

La réponse s'affiche clairement dans une bottom sheet.

Ce n'est pas seulement une gêne pour l'utilisateur.

C'est un véritable point de friction.

Cela entraîne des récupérations de compte inutiles et a un impact commercial, comme l'abandon de paniers d'achat.

Voici mon code d'application de démonstration, que vous pouvez utiliser pour tester Credential Manager par vous-même.

Vous pouvez voir ces flux sur votre propre appareil.

Et vous avez les exemples de code officiels de Google sur la gauche.

qui gère la création de clés d'accès.

Qu'en est-il de la migration des utilisateurs de mots de passe existants vers les clés d'accès ?

Pour cela, vous pouvez utiliser un outil puissant : la création conditionnelle.

Si l'utilisateur vient de se connecter à l'aide de son mot de passe et que celui-ci a été renseigné automatiquement par un fournisseur d'identifiants compatible, nous savons qu'il est actif et nous venons de vérifier son identité.

Dans ce cas, la création conditionnelle nous permet de demander la création d'une clé d'accès automatiquement en arrière-plan.

Il n'interrompt pas le workflow de l'utilisateur.

La clé d'accès est générée de manière silencieuse et stockée.

Le Gestionnaire de mots de passe de Google affiche une notification pour confirmer que l'opération a été effectuée.

D'autres gestionnaires de mots de passe peuvent fonctionner différemment.

Le code de la création conditionnelle ressemble beaucoup à celui de l'inscription.

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

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

L'option magique est définie sur isConditional, ce qui garantit que l'utilisateur ne voit pas cette UI.

Comme il fonctionne de manière opportuniste, nous allons le placer dans un bloc try-catch.

Nous traiterons les erreurs de manière silencieuse afin de ne pas déranger l'utilisateur en cas d'échec du processus.

La clé d'accès est ensuite enregistrée dans le Credential Manager de l'utilisateur, et elle est disponible pour la prochaine fois.

Credential Manager permet également aux fournisseurs d'identifiants d'importer et d'exporter leurs identifiants de manière sécurisée.

en quelques clics seulement.

Aucun téléchargement n'est nécessaire.

Cela offre plus de flexibilité, tout en protégeant les informations.

Le flux se présente comme suit :

Dans son nouveau fournisseur d'identifiants, l'utilisateur demande à importer des identifiants.

Ensuite, Credential Manager gère l'interface utilisateur d'importation, ce qui permet à l'utilisateur de sélectionner la source des données d'identification.

Le fournisseur d'identifiants d'exportation peut alors fournir sa propre UI, ce qui lui permet d'informer l'utilisateur et de lui fournir les avertissements appropriés.

Enfin, le nouveau fournisseur d'identifiants de l'utilisateur reçoit les données via un canal sécurisé.

Il peut donc l'importer sans aucune interaction de l'utilisateur.

Mais que se passe-t-il si l'utilisateur révoque une clé d'accès depuis son application ou son site Web ?

Le fournisseur d'identifiants ne sait pas nécessairement que cela s'est produit.

La prochaine fois qu'il essaiera de se connecter, le Credential Manager lui proposera cette clé d'accès obsolète, et sa tentative sera rejetée.

De même, lorsqu'un utilisateur modifie son nom d'utilisateur ou son nom à afficher, une synchronisation est nécessaire.

Désormais, grâce à l'API Signal, votre application peut signaler ces états spécifiques au fournisseur d'identifiants.

Prenons l'exemple d'une connexion avec un mot de passe révoqué.

Votre application peut détecter cet état d'erreur spécifique et l'utiliser pour en informer le fournisseur d'identifiants de l'utilisateur.

Le fournisseur d'identifiants peut alors se mettre à jour pour que cette clé d'accès ne soit pas proposée.

Voilà quelques-unes des fonctionnalités de Credential Manager. Il est incroyablement utile pour inciter les utilisateurs à s'inscrire à l'aide de clés d'accès et pour donner la priorité aux clés d'accès par rapport aux autres méthodes lors de la connexion.

Mais n'oubliez pas que notre objectif ultime est de nous passer complètement des mots de passe.

Comment le Gestionnaire d'identifiants peut-il vous aider à atteindre cet objectif ?

Voici le processus en cinq étapes que nous vous proposons.

Lors des deux premières étapes, vous allez faire passer les utilisateurs de mots de passe aux clés d'accès.

Tout d'abord, nous essayons de manière opportuniste, en utilisant la création conditionnelle.

Si aucune opportunité de ce type ne se présente, nous finirons par avoir besoin de l'intervention de l'utilisateur. Nous lui enverrons donc des invitations dans l'application lui demandant de configurer une clé d'accès.

Nous pouvons progressivement commencer à les afficher de manière de plus en plus visible.

Après tout, du point de vue de l'utilisateur, il lui suffit généralement de fournir son verrouillage de l'écran, comme ses données biométriques.

Une fois que les données analytiques montrent que la grande majorité de vos utilisateurs ont des comptes utilisant des clés d'accès, vous pouvez imposer l'utilisation de clés d'accès à tous les nouveaux utilisateurs.

Mais ces anciens utilisateurs, c'est d'eux dont nous nous occupons dans ces trois dernières étapes.

Nous encourageons les utilisateurs de clés d'accès à supprimer leurs mots de passe.

À l'étape 3, nous leur permettons de le faire manuellement, grâce à une option "Supprimer le mot de passe" très claire dans les paramètres de leur compte.

À l'étape 4, nous commençons à encourager la suppression des mots de passe, par exemple à l'aide de notifications dans l'application, associées à un texte explicatif.

Enfin, vous passez d'une logique d'activation à une logique de désactivation pour la suppression des mots de passe.

À terme, même cette dernière option de désactivation peut disparaître.

Analytics nous donnera la confiance nécessaire pour supprimer complètement les flux de mots de passe de l'application.

La transition vers un monde sans mot de passe n'est donc plus un concept de sécurité théorique pour un avenir lointain.

Il est largement pris en charge.

Les API sont robustes et l'expérience utilisateur est excellente.

Je vous encourage à commencer à intégrer les flux de clés d'accès à Credential Manager dès aujourd'hui.

Commencez à faire migrer vos utilisateurs et laissez enfin les mots de passe derrière vous.

Merci.

Je vais maintenant laisser la parole à Chiping, qui va vous parler de la prochaine évolution de la migration et de l'identité des appareils.

Parfait.

Merci, Tom.

Comme l'a souligné Tom, l'authentification fluide sur les appareils des utilisateurs est essentielle.

Mais que se passe-t-il lorsqu'un utilisateur change de téléphone ?

Aujourd'hui, la plus forte baisse dans le parcours utilisateur se produit souvent lorsqu'il change d'appareil.

Aujourd'hui, je souhaite d'abord vous expliquer comment nous résolvons ce problème, puis aborder rapidement une prochaine exigence du Play Store concernant la restauration des identifiants.

À partir d'avril 2027, Google Play exigera que les applications respectent les exigences de connexion sans interaction pour conserver toutes leurs fonctionnalités de publication et une visibilité optimale sur le Play Store.

Qu'est-ce que la connexion sans interaction ?

En pratique, cela signifie que les utilisateurs n'ont pas besoin de se réauthentifier manuellement dans votre application lorsqu'ils passent à un nouvel appareil.

Comment implémenter cela ?

La principale méthode que nous recommandons pour ce faire est l'API Restore Credentials d'Android via le Gestionnaire d'identifiants.

Cette API vous permet de générer une clé de restauration, qui est enregistrée sur l'appareil de l'utilisateur ou dans le cloud en fonction de ses paramètres de sauvegarde.

Nous vous recommandons de générer cette clé en arrière-plan une fois que l'utilisateur est connecté.

Dans ce diagramme, nous illustrons un utilisateur qui se connecte à l'application.

La clé de restauration est ensuite créée pendant qu'ils utilisent l'application.

Cette clé est ensuite stockée localement ou, si cette option est activée, à distance dans le cloud.

Lorsque l'utilisateur configure son nouvel appareil, l'identifiant de restauration est transféré en arrière-plan pendant le processus de configuration de l'appareil.

Les utilisateurs peuvent choisir de restaurer les données à partir du cloud ou d'un transfert d'appareil à appareil.

Ensuite, lorsque votre application est ouverte, vous pouvez appeler l'API Credential Manager pour utiliser cette clé de restauration afin de connecter l'utilisateur sur le nouvel appareil lors du premier lancement.

L'utilisateur peut ainsi se connecter rapidement et de manière sécurisée à votre application.

Si vous souhaitez que votre application soit restaurée immédiatement après la configuration sans être ouverte, vous pouvez implémenter un agent de sauvegarde personnalisé pour ce faire.

Cela permettra à l'utilisateur de se connecter à votre application sans l'ouvrir manuellement.

Certains de nos partenaires ont déjà implémenté cette fonctionnalité dans leur application.

Uber est la plus grande entreprise de covoiturage au monde. Elle fournit des services de transport à des millions de personnes, tout en proposant des services de livraison de repas, de transport médical et de logistique de fret.

La simplicité d'accès est cruciale.

Lorsqu'ils changent d'appareil, ils s'attendent à une transition fluide, sans avoir à se reconnecter à l'application Uber ni à passer par une authentification unique par SMS à chaque fois.

Ce renouvellement fréquent des appareils pose un problème pour la rétention des utilisateurs.

Après avoir évalué la demande des utilisateurs et prototypé le code, Uber a intégré la prise en charge de Restore Credentials dans l'application Uber Rider, et les résultats ont été très positifs.

Elle estime que cela permettra d'économiser quatre millions de connexions quotidiennes en moyenne par jour, et s'attend à ce que ce nombre augmente à mesure que l'adoption se développe.

Veuillez consulter ce QR code et ce lien pour en savoir plus sur ce règlement à venir et sur la manière dont votre application peut répondre aux exigences de restauration sans clic.

Encore une fois, cela aura lieu en avril 2027. Veuillez donc noter cette date dans votre agenda.

Si vous souhaitez prendre de l'avance pour implémenter la restauration des identifiants dans votre application, veuillez consulter ce QR code et ce lien pour accéder à notre compétence "Restaurer les identifiants".

Cette compétence peut être utilisée pour développer ou tester rapidement la fonctionnalité avec l'agent de votre choix.

Examinons maintenant la prochaine étape de l'identité numérique : l'API Digital Credentials via Credential Manager.

Voyons ce que sont les identifiants numériques et comment ils fonctionnent.

Les identifiants numériques sont des documents numériques vérifiables par cryptographie que les utilisateurs peuvent utiliser pour fournir des informations les concernant.

Ces documents sont stockés dans des supports numériques sur l'appareil d'un utilisateur et peuvent être demandés par d'autres applications sur l'appareil ou présentés au monde de manière hybride, par exemple via un QR code.

Les utilisations sont nombreuses et variées, de la validation de l'identité à l'accès aux services, en passant par l'achat d'articles en ligne.

Les identifiants numériques offrent un moyen sécurisé et pratique de partager des informations sans avoir besoin de cartes physiques.

Les identifiants numériques impliquent trois parties : l'émetteur, le titulaire et le vérificateur.

Le cycle de vie d'un identifiant numérique se déroule généralement de gauche à droite.

Examinons chacune de ces entités et le rôle qu'elles jouent.

Le premier est l'émetteur, qui, comme son nom l'indique, est une partie qui émet un justificatif, tout comme le gouvernement émet votre passeport.

Cependant, dans le monde numérique, pour éviter l'usurpation d'identité, ces identifiants sont également signés par l'émetteur avec son certificat numérique, de sorte que toute personne recevant l'identifiant peut savoir exactement de qui il provient.

En fait, n'importe qui peut être un émetteur, qu'il s'agisse d'une salle de sport, d'un hôtel ou même de vous-même.

Il vous suffit de créer un identifiant et de le signer.

L'émetteur crée et émet des identifiants, mais ceux-ci doivent être stockés quelque part, tout comme vous devez ranger votre pièce d'identité officielle dans votre portefeuille.

Il s'agit de la partie suivante, appelée "titulaire", qui est également communément décrite comme un portefeuille numérique.

Comme leur nom l'indique, les titulaires détiennent principalement des identifiants émis par les émetteurs.

Ils sont stockés dans une application sur votre appareil, et vous pouvez ensuite les présenter aux personnes qui les demandent.

De même, n'importe qui peut être un titulaire.

En fait, il n'est pas rare que les émetteurs et les titulaires soient gérés par la même entité.

Prenons l'exemple d'une salle de sport qui souhaite créer sa propre carte de membre numérique et la gérer via sa propre application.

Il s'agirait à la fois d'un émetteur et d'un titulaire.

La troisième partie est le vérificateur, c'est-à-dire la partie qui demande les identifiants numériques.

Les vérificateurs envoient des demandes d'identifiants, généralement pour vérifier des attributs concernant un utilisateur, comme l'âge requis, le nom de famille, etc.

Il s'agit des entreprises ou des applications qui ont besoin de données utilisateur supplémentaires pour fournir un service, comme l'achat d'alcool ou la vérification d'un âge minimum.

Sur Android, les interactions entre ces trois parties et l'utilisateur sont coordonnées par le Gestionnaire d'identifiants avec l'API Digital Credentials.

L'émetteur peut appeler l'API pour émettre des identifiants pour un titulaire, bien que cela ne soit pas nécessaire s'il s'agit de la même entité.

Une fois l'identifiant émis, un vérificateur peut appeler une API pour le demander.

Le Gestionnaire d'identifiants met en correspondance la requête avec tous les titulaires disponibles et les présente à l'utilisateur pour qu'il sélectionne l'identifiant et donne son consentement.

Une fois qu'un titulaire est sélectionné, il est appelé et peut effectuer des vérifications supplémentaires si nécessaire avant de partager l'identifiant avec le vérificateur.

Une fois que le vérificateur reçoit l'identifiant, il peut également effectuer diverses vérifications sur la légitimité de l'identifiant, y compris vérifier l'émetteur d'origine.

Vous vous demandez peut-être comment les identifiants numériques sont sécurisés.

La sécurité est intégrée à chaque étape du processus. Nous allons en examiner quelques-unes.

Ainsi, du côté de l'émetteur, lorsque celui-ci souhaite partager un justificatif avec un titulaire, il doit vérifier que le titulaire ne peut pas être falsifié ni copié, c'est-à-dire qu'il est fiable.

Comment peut-elle le vérifier ?

Avant qu'un émetteur ne délivre l'identifiant, il doit demander au titulaire de prouver son identité et la sécurité de l'appareil qu'il utilise.

Le titulaire envoie l'attestation de son portefeuille, généralement sous la forme d'une chaîne de certificats vérifiable.

Le titulaire génère également une paire de clés liée au matériel.

Il envoie à l'émetteur la clé publique de cette paire de clés avec l'attestation de clé Android, de sorte que l'émetteur puisse valider la légitimité du matériel.

L'émetteur signera cette clé publique dans l'identifiant émis, de sorte que l'identifiant soit officiellement lié à l'appareil unique.

Une fois que le titulaire dispose d'un nouvel identifiant, il n'enregistre que ses métadonnées d'identifiant auprès de Credential Manager.

Le gestionnaire d'identifiants utilise ces métadonnées pour déterminer les titulaires à afficher lorsqu'un vérificateur demande un identifiant.

Aucune donnée utilisateur réelle n'est enregistrée dans Credential Manager ni exposée à Google.

Même lorsque Credential Manager sélectionne les portefeuilles à afficher à l'utilisateur, le contenu de chaque portefeuille n'est pas révélé à ce moment-là.

Désormais, lorsqu'une demande d'identifiant est effectuée et qu'un utilisateur accepte de partager un identifiant, le titulaire sélectionné est appelé et le contrôle du workflow lui est confié.

Comme vous vous en souvenez peut-être, un titulaire n'est qu'une application. L'application est donc appelée.

À ce moment-là, le titulaire peut voir des informations telles que le vérificateur demandeur et l'identifiant demandé, et décider s'il souhaite partager cet identifiant avec ce vérificateur, même si l'utilisateur a déjà donné son autorisation.

Les données d'identification elles-mêmes ne sont pas accessibles à Google.

Seules les métadonnées de routage sont enregistrées, et la charge utile est chiffrée de bout en bout entre le titulaire et le vérificateur.

Le titulaire peut ainsi contrôler avec quelles parties il souhaite partager ses identifiants.

Enfin, du côté du vérificateur, une fois que l'identifiant a été demandé et que le titulaire l'a partagé, le vérificateur reçoit la présentation de l'identifiant de la part du titulaire.

Le vérificateur peut maintenant vérifier si la réponse a été générée récemment par le titulaire d'origine des identifiants pour la requête.

Il peut confirmer que la réponse d'identification est signée à l'aide de la clé liée à l'appareil du titulaire, y compris en demandant un jeton à usage unique et en appelant l'origine observée par le titulaire.

Le vérificateur peut également vérifier l'authenticité de l'émetteur de l'identifiant en vérifiant le certificat de l'émetteur, afin de s'assurer qu'il provient d'une source fiable.

En résumé, les émetteurs bénéficient de garanties matérielles, les titulaires contrôlent les identifiants qu'ils souhaitent partager, les vérificateurs obtiennent une preuve cryptographique de l'émetteur et du titulaire, et les utilisateurs conservent un contrôle total sur les données qu'ils souhaitent partager.

Maintenant que nous avons vu comment les identifiants numériques sont sécurisés, examinons certains des cas d'utilisation des identifiants numériques actuellement disponibles via l'API Digital Credentials sur Android.

La première que je vais aborder est la validation de l'adresse e-mail.

Cette API récupère l'adresse Gmail de l'utilisateur connecté directement depuis son appareil et la présente à votre application comme un identifiant numérique validé par Google, ce qui évite d'avoir à envoyer des mots de passe à usage unique ou des liens magiques.

Ainsi, l'utilisateur ne quitte jamais votre application et n'a qu'à appuyer une fois sur la bottom sheet familière du Gestionnaire d'identifiants pour donner son consentement.

Voici une démonstration de l'API en action.

Il s'agit d'un exemple d'application qui implémente la validation de l'adresse e-mail via l'API Digital Credentials.

Lorsque j'appuie sur "Demander une adresse e-mail validée", Credential Manager demande un identifiant numérique d'adresse e-mail validée aux titulaires de ce type d'identifiant sur l'appareil.

Dans ce cas, seul Google est le détenteur de ces identifiants d'adresse e-mail validée, que vous voyez s'afficher dans la bottom sheet.

Il s'agit de l'une des adresses e-mail auxquelles l'utilisateur est connecté sur l'appareil.

En fait, Google est à la fois l'émetteur et le titulaire de l'identifiant numérique dans ce cas.

Une fois que j'ai sélectionné l'identifiant que je souhaite partager, il est renvoyé à l'application, qui n'affiche actuellement que les champs contenus dans l'identifiant, à savoir l'adresse e-mail validée.

Dans votre application, vous pouvez utiliser ces informations pour passer à l'écran suivant, par exemple pour créer une clé d'accès ou effectuer d'autres étapes de création de compte.

Pour l'utilisateur, il suffit de donner son consentement, puis de passer à l'écran suivant.

Si vous souhaitez l'essayer, vous pouvez accéder à notre exemple GitHub et l'installer sur votre propre appareil.

Veuillez l'utiliser sur un appareil physique. Notez que vous devez être connecté à au moins un compte Gmail sur votre appareil.

Je vais donc accorder un peu plus de temps si cela vous intéresse.

Très bien.

Intéressant, n'est-ce pas ?

Et quand vous pensez à la validation de l'adresse e-mail, quelle est la prochaine forme de validation de l'utilisateur qui vous vient à l'esprit ?

C'est bien ça, la vérification du numéro de téléphone.

L'API Digital Credentials accepte également de manière native la vérification du numéro de téléphone, ce qui élimine les frictions et la vulnérabilité des mots de passe à usage unique par SMS.

La vérification du numéro de téléphone s'effectue également via l'API Digital Credentials. Dans ce cas, le numéro de téléphone de l'appareil est demandé et présenté comme un identifiant numérique.

L'utilisateur ne voit que la bottom sheet habituelle du Gestionnaire d'identifiants pour partager ou valider son numéro de téléphone, sans quitter l'application et en n'effectuant que quelques gestes pour terminer la validation.

Voici un exemple d'application dans laquelle le client peut partager son numéro de téléphone d'un simple geste, sans quitter l'application.

Comment fonctionne cette configuration ?

Si nous appliquons cela aux parties impliquées dans les identifiants numériques, l'émetteur est, dans ce cas, l'opérateur téléphonique du numéro de téléphone de la carte SIM de l'appareil, et le titulaire est Android Telephony.

Lorsqu'un vérificateur, tel que votre application, demande le numéro de téléphone de l'utilisateur, il est récupéré auprès de Google Telephony à l'aide d'un appel d'API Digital Credentials.

Vous vous demandez peut-être comment fonctionne la facturation.

Une étape supplémentaire est propre à ce flux : l'identifiant est transmis à votre opérateur ou agrégateur à des fins de facturation.

Cela se produit après que le numéro de téléphone a été récupéré auprès de Google Telephony, où il est stocké sous forme chiffrée.

Il est ensuite transmis à l'opérateur, qui le déchiffre et renvoie le numéro de téléphone directement au backend de votre application. Vous êtes alors facturé.

L'avantage, c'est que l'opérateur ne vous facturera que les validations réussies, qui sont transférées via les données ou le Wi-Fi, et qui sont beaucoup plus fiables que les SMS.

Voici une démonstration de la vérification du numéro de téléphone en action, avec Firebase comme agrégateur d'opérateurs.

L'application demande le numéro de téléphone de l'utilisateur lors de la procédure de connexion.

Cet utilisateur possède plusieurs cartes SIM et en choisit une à partager avec l'application.

Une fois que l'utilisateur a confirmé son choix, l'échange se fait en arrière-plan.

Ensuite, l'écran suivant s'affiche avec le numéro de téléphone récupéré.

L'utilisateur n'a jamais eu à quitter l'application. Il lui a suffi de sélectionner et de confirmer le numéro de téléphone à partager pour suivre le parcours sans problème, en quelques clics.

Laissez-le se terminer pour voir une dernière fois le message de fin.

Le numéro de téléphone s'affiche sur ce dernier écran.

C'est aussi simple que ça.

Nous avons abordé de nombreux sujets aujourd'hui.

Nous avons d'abord vu comment utiliser Credential Manager pour améliorer l'implémentation de vos clés d'accès et passer à un monde sans mot de passe.

Pour en savoir plus et accéder à nos exemples d'applications, consultez nos ressources sur Credential Manager et les clés d'accès.

Nous avons ensuite abordé la prochaine exigence de connexion sans pression pour vos applications, qui permet aux utilisateurs de se connecter facilement lorsqu'ils configurent un nouvel appareil.

Cette exigence sera obligatoire sur le Play Store d'ici avril 2027. Veuillez donc noter cette date dans votre agenda.

Enfin, nous avons vu comment fonctionnent les identifiants numériques et certaines de leurs fonctionnalités les plus utiles sur Android.

Pour une présentation détaillée du contenu et pour accéder à nos exemples, consultez nos ressources sur les identifiants numériques.

Tout ce que nous avons présenté aujourd'hui est disponible et prêt à être utilisé.

L'avenir de l'identité sur Android est là, et il est plus prometteur que jamais.

Merci de votre attention. Je sais que c'est l'heure du déjeuner, alors profitez de la nourriture à l'extérieur.

N'hésitez pas à venir me voir ou à contacter Tom si vous avez des questions sur les clés d'accès ou les identifiants numériques.

Cordialement.