S'authentifier sur différents facteurs de forme

Le Gestionnaire d'identifiants simplifie l'authentification dans l'ensemble de l'écosystème Android. Il offre une expérience cohérente aux utilisateurs et une surface d'API unifiée aux développeurs pour utiliser des clés d'accès, des mots de passe et des mécanismes de connexion fédérée tels que Se connecter avec Google. Bien que l'interface de programmation de base reste cohérente pour tous les facteurs de forme, chacun d'eux présente des considérations uniques en termes d'interface utilisateur et d'expérience utilisateur. Pour une implémentation réussie, vous devez adapter les flux d'authentification de votre application aux méthodes de saisie, aux tailles d'écran et aux contextes utilisateur spécifiques de chaque appareil.

Ce guide explique comment implémenter le Gestionnaire d'identifiants sur différents facteurs de forme Android, en mettant en évidence les points clés et en fournissant des liens vers une documentation plus détaillée.

Appareils mobiles

Les appareils mobiles, y compris les téléphones, les tablettes et les appareils pliables, représentent la cible la plus courante pour le développement Android. L'implémentation standard du Gestionnaire d'identifiants est adaptée à ces appareils, qui disposent généralement d'écrans tactiles et de claviers intégrés. L'expérience utilisateur sur ce facteur de forme sert de référence pour l'adaptation aux autres. Les flux d'authentification doivent être adaptés au facteur de forme et utiliser toutes les capacités de l'écran et des méthodes de saisie de l'appareil.

Wear OS

Les appareils Wear OS se caractérisent par leurs petits écrans et leurs capacités de saisie limitées sur l'appareil. L'implémentation des clés d'accès du Gestionnaire d'identifiants offre aux utilisateurs un environnement sécurisé pour se connecter aux applications, sans avoir besoin d'un téléphone associé connecté ni de se souvenir d'un mot de passe.

L'API pour Wear OS est identique à celle pour mobile. Vous pouvez donc réutiliser une intégration mobile existante. En plus des clés d'accès, de Se connecter avec Google et des mots de passe avec le Gestionnaire d'identifiants, vous pouvez utiliser d'autres méthodes d'authentification, y compris le partage de jetons de la couche de données, OAuth ou vos solutions existantes. Vous pouvez les utiliser comme sauvegardes pendant que vous migrez vos utilisateurs vers le Credential Manager ou, dans le cas du partage de jetons de la couche de données, comme solution à long terme.

L'utilisation du Gestionnaire d'identifiants pour Wear OS est soumise aux exigences suivantes :

  • Niveau d'API minimal : minSdkVersion 33 ou supérieur
    • Inclut la prise en charge des mots de passe, des clés d'accès et de Se connecter avec Google
  • Version de GMS : identique à celle requise pour les applications mobiles

L'interface utilisateur sur les appareils Wear OS est la suivante :

Écran de connexion par clé d'accès affiché comme méthode d'authentification préférée sur Wear OS.
Figure 1a. Clés d'accès.
Options de clés d'accès, de mots de passe et de connexion avec Google disponibles pour un utilisateur sur Wear OS.
Figure 1b. Clés d'accès, mots de passe et Se connecter avec Google.

Pour obtenir des conseils d'implémentation détaillés et des exemples de code, consultez les ressources suivantes :

Limites

L'utilisation du Gestionnaire d'identifiants sur Wear OS présente les limites suivantes :

Android XR

Avec Android XR (qui inclut la réalité virtuelle et augmentée), les applications s'affichent dans un espace 3D. La saisie utilisateur est fondamentalement différente de celle des autres facteurs de forme, car elle repose sur des entrées naturelles telles que les gestes de la main.

Adapter le Gestionnaire d'identifiants pour la XR signifie repenser l'interface utilisateur d'authentification (que ce soit avec des clés d'accès, des mots de passe ou des méthodes de connexion fédérée) pour un espace 3D. Par exemple, les invites d'authentification s'affichent dans des panneaux flottants, et les utilisateurs effectuent des sélections à l'aide de gestes de la main. Vous devez également tenir compte des prérequis matériels ou logiciels spécifiques pour vos appareils XR cibles.

Un défi de conception essentiel consiste à créer une expérience d'authentification intuitive et sécurisée dans un environnement de RV ou de RA. Vous devez également réfléchir à la manière de gérer l'identité dans les scénarios XR multi-utilisateurs, où différentes personnes peuvent utiliser le même appareil.

L'utilisation du Gestionnaire d'identifiants pour Android XR est soumise aux exigences suivantes :

  • Niveau d'API minimal : minSdkVersion 34 ou supérieur
  • Version de GMS : identique à celle requise pour les applications mobiles
  • Émulateur :
    • Image système d'émulateur minimale :
      • macOS : image système Google Play XR ARM 64 v8a, révision 7
      • Windows : image système Google Play XR Intel x86_64 Atom, révision 7
    • Versions d'émulateur supérieures à la version stable 35.6.11

Une expérience de connexion sur XR peut se présenter comme suit :

Invite de connexion de Credential Manager affichée dans un panneau 3D flottant dans Android XR.
Figure 2. Interface utilisateur du Gestionnaire d'identifiants dans XR.

Flux non compatibles avec XR

Le Gestionnaire d'identifiants dans Android XR ne prend pas en charge les flux d'authentification qui nécessitent qu'un autre appareil scanne un QR code. Cela est observable lors des processus de connexion sur les casques XR et lors des tests avec l'émulateur.

Pour en savoir plus sur la XR, consultez Android XR.

Android TV

Les appareils Android TV sont généralement partagés, regardés à distance et contrôlés à l'aide de télécommandes avec pavé directionnel. Dans cet environnement, les utilisateurs peuvent avoir du mal à saisir des noms d'utilisateur et des mots de passe. Le Gestionnaire d'identifiants simplifie l'authentification sur Android TV en prenant en charge Se connecter avec Google, les mots de passe enregistrés et les clés d'accès inter-appareils. Étant donné que plusieurs profils Google existent souvent sur un téléviseur partagé, le Credential Manager s'adapte à ce paramètre partagé en récupérant et en affichant tous les identifiants disponibles sur l'appareil, au lieu de limiter les choix au seul compte actuellement actif.

Invite de connexion du Gestionnaire d'identifiants sur Android TV affichant les comptes enregistrés pour Se connecter avec Google et les mots de passe, ainsi qu'une option permettant d'utiliser une clé d'accès.
Figure 3. Interface utilisateur du Gestionnaire d'identifiants sur Android TV affichant les options Se connecter avec Google, Mots de passe enregistrés et Clé d'accès.

Cette nature partagée dicte également la manière dont les clés d'accès sont gérées. Comme les téléviseurs ne disposent pas d'un facteur de connaissance de l'écran de verrouillage personnel (LSKF), les clés d'accès ne sont pas stockées ni créées directement sur le téléviseur. L'authentification par clé d'accès utilise plutôt un flux hybride inter-appareils dans lequel un QR code est présenté sur le téléviseur, et l'utilisateur le scanne avec son appareil mobile pour effectuer l'authentification biométrique.

Un flux sans clic est possible sur Google TV si vous définissez isAutoSelectAllowed = true, mais uniquement s'il n'existe qu'un seul identifiant correspondant. La feuille inférieure native du téléviseur s'affiche toujours, indiquant la confirmation du compte de l'utilisateur. Si l'utilisateur n'annule pas, l'identifiant est automatiquement renvoyé sans nécessiter de clic sur la télécommande. S'il existe plusieurs identifiants correspondants, la sélection automatique n'est pas effectuée et l'utilisateur est invité à choisir.

Si vos applications mobiles et TV partagent exactement le même nom de package Android et la même clé de signature, le Gestionnaire de mots de passe de Google les reconnaît comme la même identité d'application. Par conséquent, un mot de passe enregistré sur un appareil mobile peut être proposé directement sur le téléviseur sans nécessiter de configuration de Digital Asset Links (asset_statements). Les Digital Asset Links ne sont requis que lorsque vous partagez des identifiants entre des limites, par exemple entre une application et un site Web, ou entre des applications avec des noms de package différents.

L'utilisation du Gestionnaire d'identifiants pour Android TV est soumise aux exigences suivantes :

  • Niveau d'API minimal : Android 14 (niveau d'API 34, minSdkVersion 34) ou supérieur
  • Version de GMS : 2026W30 ou supérieure
  • Matériel pour les clés d'accès : un appareil mobile secondaire avec un appareil photo et le Bluetooth est requis pour scanner le QR code et effectuer le flux hybride FIDO

Limites

Étant donné qu'Android TV est un appareil partagé, l'utilisation du Gestionnaire d'identifiants sur cette plate-forme présente les limites intentionnelles suivantes pour protéger la confidentialité et la sécurité des utilisateurs :

  • Aucune création ni stockage de clés d'accès locaux : les clés d'accès ne peuvent pas être créées ni stockées directement sur le téléviseur. Comme les identifiants locaux ne sont pas compatibles, ne définissez pas preferImmediatelyAvailableCredentials sur true dans vos requêtes. Cela filtre les clés d'accès inter-appareils et ne renvoie pas d'identifiants.
  • Aucun fournisseur d'identifiants tiers : Android TV ne prend pas en charge la saisie automatique. Les gestionnaires de mots de passe tiers ne sont donc pas disponibles sur la plate-forme. Les utilisateurs doivent utiliser le Gestionnaire de mots de passe de Google.
  • Aucune restauration des identifiants : la connexion automatique aux nouveaux appareils à l'aide de À propos de la restauration des identifiants n'est pas compatible avec Android TV.

Pour en savoir plus sur le développement pour TV, consultez Présentation d'Android TV.

Android Automotive OS

Les appareils Android Automotive OS (AAOS) sont des systèmes partagés intégrés aux véhicules. Adapter le Gestionnaire d'identifiants pour AAOS nécessite de prendre en charge l'authentification sécurisée (généralement lorsque le véhicule est garé) et d'accepter plusieurs profils utilisateur sur un appareil partagé.

Si vous proposez une application optimisée pour les grands écrans ou les tablettes dans les voitures, et que votre application est déjà compatible avec le Credential Manager et les clés d'accès sur les appareils mobiles ou les tablettes, elle fonctionne sur Android Automotive OS sans nécessiter de modifications de vos flux d'authentification.

L'authentification sur Android Automotive OS est compatible avec les méthodes suivantes :

  • Clés d'accès (flux hybride inter-appareils) : les utilisateurs peuvent s'authentifier avec des clés d'accès existantes via un flux inter-appareils. Le système affiche un QR code sur l'écran de la voiture que l'utilisateur scanne avec son appareil mobile. Comme la vérification biométrique et le verrouillage de l'écran ont lieu sur le téléphone de l'utilisateur, il n'a pas besoin de configurer un verrouillage de l'écran sur l'écran de la voiture.
  • Se connecter avec Google : affiche l'écran natif Se connecter avec Google directement sur l'écran de la voiture.
  • Mots de passe enregistrés : les utilisateurs peuvent récupérer les mots de passe enregistrés dans le Gestionnaire de mots de passe de Google pour se connecter sans avoir à saisir manuellement leurs identifiants sur l'écran du véhicule.
Invite de clé d'accès du Credential Manager affichée sur un écran embarqué dans Android Automotive OS.
Figure 5. Invite de clé d'accès du Credential Manager sur Android Automotive OS.

Android Automotive OS gère les sessions et les identifiants par profil, en isolant les données de session spécifiques à l'utilisateur entre les profils (par exemple, le profil A, le profil B ou un profil invité).

L'utilisation du Credential Manager pour Android Automotive OS est soumise aux exigences suivantes :

  • Niveau d'API minimal : Android 9 (niveau d'API 28, minSdkVersion 28) ou supérieur. La récupération des clés d'accès inter-appareils nécessite Android 14 (niveau d'API 34) ou supérieur.
  • Version de GMS : identique à celle requise pour les applications mobiles.

Limites de test

Pour tester les clés d'accès, vous devez utiliser un appareil physique exécutant une version d'Android Automotive OS comme surface principale. Pour obtenir des instructions de configuration, consultez Tester Android Automotive OS sur la Pixel Tablet. Les émulateurs ne peuvent pas être utilisés pour tester les clés d'accès, car ils ne sont pas compatibles avec le Bluetooth à basse consommation (BLE), qui est requis pour le flux hybride FIDO.

Limites et flux non compatibles

L'utilisation du Gestionnaire d'identifiants sur Android Automotive OS présente les limites suivantes :

  • Aucun stockage ni récupération de clés d'accès locaux : la récupération directe des clés d'accès locales n'est pas compatible, car les véhicules sont des appareils partagés. La synchronisation directe des clés d'accès avec le véhicule présente un risque de sécurité. Les clés d'accès doivent donc être utilisées via le flux hybride inter-appareils.
  • Identifiants immédiatement disponibles non compatibles : si votre application demande une clé d'accès et définit preferImmediatelyAvailableCredentials sur true, l'interface utilisateur automobile se ferme immédiatement et génère une NoCredentialException. Fournissez une expérience utilisateur de secours appropriée pour ce scénario.
  • Aucun fournisseur d'identifiants tiers : les gestionnaires de mots de passe tiers ne sont pas compatibles avec Android Automotive OS. Les utilisateurs doivent utiliser le Gestionnaire de mots de passe de Google ou des flux hybrides inter-appareils pour s'authentifier.
  • Aucune création de mot de passe stocké : l'API ne permet pas de créer et d'enregistrer un nouveau mot de passe stocké directement à partir de l'interface de la voiture. La création d'identifiants est limitée aux nouvelles clés d'accès à l'aide du flux hybride FIDO.

Pour en savoir plus sur le développement pour Automotive OS, consultez Android Automotive OS overview.

Ressources supplémentaires