Gérer les clés d'accès sur plusieurs domaines et applications avec l'ID de partie de confiance

Eiji Kitamura

Dans WebAuthn et les clés d'accès, l'ID de la partie de confiance (RP ID) spécifie le champ d'application d'un identifiant par nom de domaine. Lorsque vous créez une clé d'accès, le navigateur l'associe à un ID de RP spécifique. Le navigateur empêche ensuite l'utilisation de cette clé d'accès sur un domaine qui ne correspond pas à cet ID ou qui n'en relève pas. Définir correctement votre RPID garantit une expérience fluide avec les clés d'accès sur les sous-domaines, les origines multisites et les applications mobiles first party.

Principes de base de l'identification RP

L'ID de partie de confiance (RP ID) est une chaîne unique qui identifie votre service ou votre site Web. Un ID de RP doit être une chaîne de domaine. Il peut s'agir du nom d'hôte actuel exact ou d'un domaine parent plus large, à condition qu'il s'agisse d'un eTLD+1 ou d'un domaine de niveau supérieur. Vous ne pouvez pas utiliser d'adresses IP ni de suffixes publics (TLD-e) comme ID de partie de confiance.

Par exemple, si vous hébergez votre serveur sur https://www.example.com, vous pouvez utiliser example.com ou www.example.com comme ID de partie de confiance, en fonction de vos besoins spécifiques. Le tableau suivant présente des exemples d'ID de RP autorisés en fonction de votre hôte d'origine :

Hôte d'origine ID du tiers assujetti à des restrictions autorisé (eTLD+1)
https://login.example.com example.com ou login.example.com
https://example.com:8080 example.com (les numéros de port sont exclus)
https://mobile.example.co.jp example.co.jp ou mobile.example.co.jp
https://sub.project.org.uk project.org.uk ou sub.project.org.uk
https://user.github.io user.github.io (github.io est un eTLD)
https://myapp.pages.dev myapp.pages.dev (pages.dev est un eTLD)
http://localhost localhost (exception à l'exigence HTTPS)

Lorsque vous créez des clés d'accès, le navigateur les associe de manière cryptographique à l'ID de la partie de confiance. Pour utiliser un identifiant, l'origine de la demande d'authentification doit correspondre à cet RPID.

Lorsque vous utilisez un eTLD+1 comme ID de partie de confiance, la clé d'accès fonctionne sur les sous-domaines associés. Par exemple, un ID de RP de example.com fonctionne pour https://login.example.com et https://shop.example.com. Un ID de RP plus spécifique, tel que login.example.com, fonctionne sur son origine exacte, mais pas sur https://shop.example.com.

ID du tiers assujetti à des restrictions dans les contextes multisites

Si votre service s'étend sur plusieurs eTLD+1 (par exemple, example.com et example.co.jp), il s'agit d'une configuration multisite. Les ID de tiers assujettis à des restrictions standards ne sont pas compatibles avec les configurations multisites.

Pour partager des clés d'accès entre différents sites, utilisez les requêtes d'origine associée. ROR vous permet de partager des clés d'accès entre différents sites, car le client (navigateur) reconnaît différentes origines comme faisant partie du même service logique.

Conditions requises pour le ROR :

  • Choisissez un ID de RP : vous devez choisir un seul ID de RP et l'utiliser sur tous les sites.
  • Hébergez un fichier de configuration : le domaine de l'ID RP principal doit héberger un fichier de configuration à l'adresse /.well-known/webauthn qui liste les origines autorisées.
  • Cohérence : même si l'utilisateur est sur https://www.example.co.jp, le rpId dans l'appel WebAuthn doit être le principal (par exemple, example.com) à la fois lors de la création et de l'authentification.

Exemple de ROR pour l'ID de tiers assujetti à des restrictions example.com : https://example.com/.well-known/webauthn

{
  "origins": [
    "https://www.example.co.jp",
    "https://shop.example"
  ]
}

Pour en savoir plus sur l'implémentation des requêtes d'origine associées, consultez Autoriser la réutilisation des clés d'accès sur vos sites avec les requêtes d'origine associées.

ID de tiers assujetti à des restrictions dans les applications mobiles

Les applications mobiles peuvent utiliser des clés d'accès en s'associant à un domaine Web. Pour établir cette relation, vous devez héberger un fichier de validation sur votre serveur.

Le Gestionnaire d'identifiants Android nécessite un fichier Digital Asset Links (DAL) sur le domaine de l'ID de partie de confiance (RP) pour l'associer à l'application.

  • Hébergement : hébergez le fichier sur https://<RP ID>/.well-known/assetlinks.json.
  • Validation : validez le origin dans clientDataJSON. Pour Android, il s'agit d'une chaîne telle que android:apk-key-hash:<hash>.

Exemple de DAL pour l'ID de RP example.com (hébergé sur https://example.com/.well-known/assetlinks.json)

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "com.google.credentialmanager.sample",
      "sha256_cert_fingerprints": [
        "4F:20:47:1F:D9:9A:BA:96:47:8D:59:27:C2:C8:A6:EA:8E:D2:8D:14:C0:B6:A2:39:99:9F:A3:4D:47:3D:FA:11"
      ]
    }
  }
]

Pour en savoir plus, consultez Configurer Digital Asset Links entre votre application et votre site Web.

iOS : domaines associés

Les plates-formes Apple nécessitent un fichier apple-app-site-association (AASA) sur le domaine RP ID pour s'associer à l'application.

  • Fichier AASA : hôte https://<RP_ID>/.well-known/apple-app-site-association.
  • Droits d'accès : ajoutez webcredentials:<app info> aux droits d'accès de l'application.

Exemple d'AASA pour l'ID de tiers assujetti à des restrictions example.com : https://example.com/.well-known/apple-app-site-association :

{
  "webcredentials":
    {
      "apps": ["EXAMPLE123.com.example.passkey"]
    }
}

Pour en savoir plus, consultez Se connecter à un service avec des clés d'accès dans la documentation Apple Developer.

Résumé

L'ID RP détermine où vos utilisateurs accèdent à leurs clés d'accès. Gardez ces points à l'esprit lorsque vous implémenterez la fonctionnalité :

  • Hiérarchie et sous-domaines : l'ID de RP doit être une chaîne de domaine (eTLD+1 ou plus). L'utilisation d'un domaine plus large tel que example.com permet aux clés d'accès de fonctionner sur tous les sous-domaines (par exemple, login.example.com et shop.example.com).
  • Solutions multisites : utilisez les demandes d'origine associée (ROR) pour les services couvrant plusieurs eTLD+1. Cela nécessite un ID RP et un fichier de configuration à l'adresse /.well-known/webauthn.
  • Intégration mobile : établissez une relation validée entre votre site Web et vos applications mobiles à l'aide d'un fichier Digital Asset Links (DAL) à l'adresse /.well-known/assetlinks.json pour Android et d'un fichier apple-app-site-association (AASA) à l'adresse /.well-known/apple-app-site-association pour iOS.

En savoir plus