RP ID を使用して複数のドメインとアプリでパスキーを管理する

Eiji Kitamura

WebAuthn とパスキーでは、リライング パーティ ID（RP ID）によって、ドメイン名で認証情報のスコープが指定されます。パスキーを作成すると、ブラウザはそれを特定の RP ID に関連付けます。ブラウザは、その ID の範囲外のドメインでそのパスキーを使用できないようにします。RP ID を正しく定義すると、サブドメイン、クロスサイト オリジン、ファースト パーティ モバイルアプリ全体でシームレスなパスキー エクスペリエンスが実現します。

RP ID の基本

証明書利用者 ID（RP ID）は、サービスまたはウェブサイトを識別する一意の文字列です。RP ID はドメイン文字列である必要があります。eTLD+1 以上であれば、現在のホスト名と完全に一致するものでも、より広範な親ドメインでもかまいません。IP アドレスとパブリック サフィックス（eTLD）を RP ID として使用することはできません。

たとえば、サーバーを https://www.example.com でホストしている場合、特定のニーズに応じて example.com または www.example.com を RP ID として使用できます。次の表に、オリジン ホストに応じた許可される RP ID の例を示します。

送信元のホスト 許可される RP ID（eTLD+1）
https://login.example.com example.com または login.example.com
https://example.com:8080 example.com（ポート番号は除外）
https://mobile.example.co.jp example.co.jp または mobile.example.co.jp
https://sub.project.org.uk project.org.uk または sub.project.org.uk
https://user.github.io user.github.io（github.io は eTLD）
https://myapp.pages.dev myapp.pages.dev（pages.dev は eTLD）
http://localhost localhost（HTTPS 要件の例外）

ブラウザは、パスキーを作成するときに、パスキーを RP ID に暗号的に関連付けます。認証情報を使用するには、認証リクエストのオリジンがその RP ID と一致している必要があります。

eTLD+1 を RP ID として使用すると、パスキーは関連するサブドメイン全体で機能します。たとえば、RP ID が example.com の場合、https://login.example.com と https://shop.example.com で動作します。login.example.com のようなより具体的な RP ID は、その正確なオリジンでは機能しますが、https://shop.example.com では機能しません。

クロスサイト コンテキストでの RP ID

サービスが複数の eTLD+1 にまたがる場合（example.com と example.co.jp など）、クロスサイト構成になります。標準 RP ID は、クロスサイト設定をサポートしていません。

異なるサイト間でパスキーを共有するには、関連オリジン リクエスト（ROR）を使用します。ROR を使用すると、クライアント（ブラウザ）が異なるオリジンを同じ論理サービスの一部として認識するため、異なるサイト間でパスキーを共有できます。

ROR の要件:

  • RP ID を 1 つ選択する: 1 つの RP ID を選択し、すべてのサイトで使用する必要があります。
  • 構成ファイルをホストする: プライマリ RP ID ドメインは、承認済みのオリジンをリストする構成ファイルを /.well-known/webauthn でホストする必要があります。
  • 一貫性を維持する: ユーザーが https://www.example.co.jp を使用している場合でも、WebAuthn 呼び出しの rpId は、作成時と認証時の両方でプライマリ（example.com など）である必要があります。

RP ID example.com の ROR の例: https://example.com/.well-known/webauthn

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

関連オリジン リクエストの実装の詳細については、関連オリジン リクエストを使用してサイト間でパスキーを再利用できるようにするをご覧ください。

モバイルアプリの RP ID

モバイル アプリケーションは、ウェブ ドメインと関連付けることでパスキーを使用できます。この関係を確立するには、サーバーで確認ファイルをホストする必要があります。

Android の認証情報マネージャーでは、アプリと関連付けるために RP ID ドメインに Digital Asset Link（DAL）ファイルが必要です。

  • ホスティング: https://<RP ID>/.well-known/assetlinks.json でファイルをホストします。
  • 検証: clientDataJSON の origin を検証します。Android の場合、これは android:apk-key-hash:<hash> などの文字列です。

RP ID example.com の DAL の例（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"
      ]
    }
  }
]

詳しくは、アプリとウェブサイト間のデジタル アセット リンクを設定するをご覧ください。

iOS: 関連付けられたドメイン

Apple プラットフォームでは、アプリに関連付けるために RP ID ドメインに apple-app-site-association（AASA）ファイルが必要です。

  • AASA ファイル: ホスト https://<RP_ID>/.well-known/apple-app-site-association。
  • 利用資格: アプリの利用資格に webcredentials:<app info> を追加します。

RP ID example.com の AASA の例: https://example.com/.well-known/apple-app-site-association:

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

詳しくは、Apple Developer Documentation のパスキーでサービスに接続するをご覧ください。

概要

RP ID は、ユーザーがパスキーにアクセスする場所を決定します。実装する際は、次の点に注意してください。

  • 階層とサブドメイン: RP ID はドメイン文字列（eTLD+1 以上）である必要があります。example.com のような広範なドメインを使用すると、パスキーはすべてのサブドメイン（login.example.com や shop.example.com など）で機能します。
  • クロスサイト ソリューション: 複数の eTLD+1 にまたがるサービスには、関連オリジン リクエスト（ROR）を使用します。これには、1 つの RP ID と /.well-known/webauthn の構成ファイルが必要です。
  • モバイル統合: Android の場合は /.well-known/assetlinks.json の Digital Asset Links（DAL）ファイル、iOS の場合は /.well-known/apple-app-site-association の apple-app-site-association（AASA）ファイルを使用して、ウェブサイトとモバイルアプリ間の確認済みの関係を確立します。

詳細