Assurer la cohérence de vos identifiants avec les fournisseurs d'identifiants

Lorsqu'un utilisateur crée une clé d'accès, le serveur de la partie de confiance enregistre certains détails, tandis que le fournisseur d'identifiants, tel que le Gestionnaire de mots de passe de Google, en enregistre d'autres. Plus spécifiquement :

  • Le serveur de la partie de confiance enregistre l'identifiant de clé publique.
  • Le fournisseur d'identifiants enregistre le nom d'utilisateur, le nom à afficher, la clé privée et d'autres métadonnées associées. Ces métadonnées aident les utilisateurs à identifier et à sélectionner la clé d'accès requise lors de la connexion.

Des incohérences potentielles entre les données enregistrées sur le serveur de la partie de confiance et le fournisseur d'identifiants peuvent nuire à l'expérience utilisateur. Des problèmes peuvent survenir dans les scénarios suivants :

  • Un identifiant est supprimé sur le serveur de la partie de confiance, mais pas sur le fournisseur d'identifiants, ce qui fait que le fournisseur d'identifiants affiche l'identifiant supprimé à l'utilisateur.
  • Un nom d'utilisateur ou un nom à afficher est mis à jour sur le serveur de la partie de confiance, mais pas sur le fournisseur d'identifiants, ce qui fait que le fournisseur d'identifiants affiche les informations obsolètes.

L'API Signal du Gestionnaire d'identifiants permet aux parties de confiance de communiquer avec les fournisseurs d'identifiants pour supprimer des identifiants et mettre à jour les métadonnées utilisateur, telles que le nom d'utilisateur et le nom à afficher. Trois types de demandes sont acceptés pour différents scénarios :

  • SignalUnknownCredentialRequest

    • Indique qu'un identifiant spécifique n'est plus valide et doit être masqué ou supprimé du fournisseur d'identifiants.

  • SignalAllAcceptedCredentialIdsRequest

    • Fournit une liste d'ID d'identifiants acceptés au fournisseur d'identifiants.

  • SignalCurrentUserDetailsRequest

    • Met à jour les détails des métadonnées de l'utilisateur.

Compatibilité des versions

L'API Signal est disponible sur les appareils équipés d'Android 15 ou version ultérieure, et à partir de la version 1.6.0-beta03 de la bibliothèque androidx.credentials.

Implémentation

Pour utiliser l'API Signals, procédez comme suit :

  1. Ajoutez la dépendance Credential Manager à votre projet.

    Kotlin

    dependencies {
    implementation("androidx.credentials:credentials:1.6.0-rc01")
}

    Groovy

    dependencies {
    implementation "androidx.credentials:credentials:1.6.0-rc01"
}

  2. Appeler l'API Signal

    Pour envoyer une demande de signal au fournisseur d'identifiants, utilisez une demande de signal compatible. Chacun des types de demandes de signaux nécessite une requête JSON, comme illustré dans les exemples suivants :

    • Justificatif d'identité inconnu (SignalUnknownCredentialRequest)

      Utilisez SignalUnknownCredentialRequest pour indiquer qu'un identifiant est refusé et considéré comme inconnu. Lorsque le fournisseur d'identifiants reçoit ce signal, il masque ou supprime l'identifiant.

      Utilisation

      Utilisez ce signal lorsque la partie de confiance ne parvient pas à valider une assertion de clé d'accès. Cela signifie que la clé d'accès n'est pas valide et doit être masquée ou supprimée par le fournisseur d'identifiants.

      Les paramètres JSON requis pour cette requête sont rpId et credentialId. Pour en savoir plus sur la structure JSON, consultez les options signalUnknownCredential.

      credentialManager.signalCredentialState(
    SignalUnknownCredentialRequest(
        requestJson = JSONObject().apply {
            put("rpId", rpId /* [String] RP ID of the relying party */)
            put("credentialId", credentialId /* [String] Credential ID of the credential to be hidden or deleted */)
        }.toString()
    )
)

    • Tous les identifiants acceptés (SignalAllAcceptedCredentialIdsRequest)

      Utilisez SignalAllAcceptedCredentialIdsRequest pour informer les fournisseurs d'identifiants de l'ensemble des identifiants acceptés. Une fois le signal reçu par le fournisseur d'identifiants, celui-ci masque ou supprime les identifiants qui ne figurent pas dans cette liste, ou affiche les identifiants précédemment masqués qui y figurent désormais.

      Utilisation

      Utilisez ce signal lorsque la validation d'une clé d'accès par la partie de confiance échoue. Cet échec signifie que la clé d'accès n'est pas valide et doit être masquée ou supprimée par le fournisseur d'identifiants. Vous pouvez également utiliser ce signal chaque fois que vous devez diffuser l'ensemble des ID d'identifiants connus aux fournisseurs d'identifiants.

      Les paramètres JSON requis pour cette requête sont rpId, userId et allAcceptedCredentialIds. Pour en savoir plus sur la structure JSON, consultez Options signalAllAcceptedCredential.

      credentialManager.signalCredentialState(
    SignalAllAcceptedCredentialIdsRequest(
        requestJson = JSONObject().apply {
            put("rpId", rpId /* [String] RP ID of the relying party */)
            put("userId", userId /* [String] User ID of the current user */)
            put(
                "allAcceptedCredentialIds",
                JSONArray(credentialIdsList /* [List<String>] List of accepted Credential IDs */)
            )
        }.toString()
    )
)

    • Informations sur l'utilisateur actuel (SignalCurrentUserDetailsRequest)

      Utilisez SignalCurrentUserDetailsRequest pour informer les fournisseurs d'identifiants que les métadonnées, telles que le nom d'utilisateur et le nom à afficher pour un utilisateur donné, ont été mises à jour et doivent apparaître dans le fournisseur d'identifiants.

      Utilisation

      Utilisez ce signal lorsque l'utilisateur ou la partie de confiance mettent à jour les métadonnées de la clé d'accès associées au compte utilisateur.

      Les paramètres JSON requis pour cette requête sont rpId, userId, name et displayName. Pour en savoir plus sur la structure JSON, consultez les options signalCurrentUserDetails.

      credentialManager.signalCredentialState(
    SignalCurrentUserDetailsRequest(
        requestJson = JSONObject().apply {
            put("rpId", rpId /* [String] RP ID of the relying party */)
            put("userId", userId /* [String] User ID of the current user */)
            put("name", name /* [String] New Name to be updated for the current user */)
            put("displayName", displayName /* [String] New display name to be updated for the current user */)
        }.toString()
    )
)

Tester l'implémentation

Pour tester votre implémentation de l'API Signals, procédez comme suit :

  1. Installez l'exemple de fournisseur d'informations d'identification nommé MyVault.

  2. Activez MyVault en tant que fournisseur d'identifiants dans Paramètres > Mots de passe, clés d'accès et comptes > Service préféré.

    Menu &quot;Service préféré&quot; dans les paramètres Android, avec MyVault activé en tant que fournisseur d&#39;identifiants.

  3. Activez toutes les notifications pour MyVault dans Paramètres > Applications > MyVault > Notifications.

    Menu &quot;Notifications&quot; de l&#39;application MyVault, affichant toutes les notifications activées.

  4. Vérifiez que l'option Afficher sur l'écran est activée pour les notifications dans Paramètres > Applications > MyVault > Notifications > Catégories > Canal de notification de l'API Signal.

    Paramètres du canal de notification de l&#39;API Signal pour MyVault, avec l&#39;option &quot;Afficher à l&#39;écran&quot; activée.

  5. Dans votre application, déclenchez les flux qui envoient les demandes de signal au fournisseur d'identifiants. Des notifications de MyVault devraient s'afficher à l'écran. Cela permet de vérifier que le fournisseur d'identifiants a bien reçu les requêtes.