Google I/O にご参加いただきありがとうございました。オンデマンドでコンテンツを視聴できます。

関連するオリジンのリクエストを使用してサイト間でパスキーの再利用を許可する

Maud Nalpas

パスキーは特定のウェブサイトに関連付けられており、作成されたウェブサイトでのみログインに使用できます。

これは、証明書利用者 ID（RP ID）で指定されます。 example.com ドメイン用に作成されたパスキーの場合、RP ID は www.example.com または example.com になります。

RP ID を使用すると、パスキーをどこでも認証に使用できる単一の認証情報として使用できなくなりますが、次の問題が発生します。

複数のドメインを持つサイト: ユーザーは、同じ会社が管理する国別の異なるドメイン（たとえば example.com、example.co.ukなど）で同じパスキーを使用してログインできません。
ブランドドメイン: ユーザーは、1 つのブランドで使用される異なるドメイン（acme.com、 acmerewards.com など）で同じ認証情報を使用できません。
モバイルアプリ: モバイルアプリには独自のドメインがないことが多く、認証情報の管理が困難になります。

ID 連携に基づく回避策や iframe に基づく回避策がありますが、場合によっては不便です。関連オリジンリクエストは、この問題を解決します。

ソリューション

これにより、ユーザーは運営する複数のサイトで同じパスキーを再利用できます。

関連オリジンリクエストを使用するには、特定の URL https://{RP ID}/.well-known/webauthn で特別な JSON ファイルを提供する必要があります。example.com が追加のオリジンで RP ID として使用できるようにする場合は、次のファイルを https://example.com/.well-known/webauthn: で提供する必要があります。

{
  "origins": [
    "https://example.co.uk",
    "https://example.de",
    "https://example-rewards.com"
  ]
}

これらのサイトのいずれかが、example.com を RP ID として使用するパスキーの作成（navigator.credentials.create）または認証（navigator.credentials.get）を呼び出すと、ブラウザはリクエスト元のオリジンと一致しない RP ID に気づきます。ブラウザが関連オリジンリクエストをサポートしている場合は、まず webauthn ファイルを https://{RP ID}/.well-known/webauthn で探します。ファイルが存在する場合、ブラウザはリクエスト元のオリジンが allowlist に登録されているかどうかを確認します。登録されている場合は、パスキーの作成または認証の手順に進みます。

ブラウザが関連オリジンリクエストをサポートしていない場合は、SecurityError がスローされます。

ブラウザサポート

関連オリジンリクエストは、Chrome と Safari でサポートされています。2026 年 1 月の時点で、Firefox はこの機能を検討中です。ステータスは、Mozilla の標準ポジションに関する問題で確認できます。

関連オリジンリクエストを設定する

次のデモでは、https://ror-1.glitch.me と https://ror-2.glitch.me の 2 つのサイトを使用します。ユーザーが両方のサイトで同じパスキーを使用してログインできるように、関連オリジンリクエストを使用して、ror-2.glitch.me が ror-1.glitch.me を RP ID として使用できるようにします。

デモ

https://ror-2.glitch.me は、ror-1.glitch.me を RP ID として使用するために関連オリジンリクエストを実装しているため、パスキーの作成時またはパスキーでの認証時に、ror-1 と ror-2 の両方で ror-1.glitch.me が RP ID として使用されます。また、これらのサイト間で共有されるパスキーデータベースも実装しています。

次のユーザーエクスペリエンスを確認してください。

ror-2 の RP ID が ror-1（ror-2 ではない）であっても、パスキーを作成して認証できます。
ror-1 または ror-2 のいずれかでパスキーを作成すると、ror-1 と ror-2 の両方で認証できます。ror-2 は ror-1 を RP ID として指定するため、これらのサイトのいずれかからパスキーの作成または認証リクエストを行うことは、ror-1 でリクエストを行うのと同じです。リクエストをオリジンに関連付けるのは RP ID のみです。
ror-1 または ror-2 のいずれかでパスキーを作成すると、Chrome は ror-1 と ror-2 の両方で自動入力できます。
これらのサイトのいずれかで作成された認証情報の RP ID は ror-1 になります。

両方のサイトで Chrome の自動入力が機能します。 — 関連オリジンリクエストにより、ユーザーは ror-1 と ror-2 で同じパスキー認証情報を使用できます。Chrome は認証情報も自動入力します。

コードをご覧ください。

ror-1 コードベースで設定された /.well-known/webauthn ファイルをご覧ください。
ror-2 codebase の RP_ID_ROR の出現箇所をご覧ください。

ステップ 1: 共有アカウントデータベースを実装する

ユーザーが site-1 と site-2 で同じパスキーを使用してログインできるようにするには、これら 2 つのサイトで共有されるアカウントデータベースを実装します。

ステップ 2: site-1 で .well-known/webauthn JSON ファイルを設定する

まず、site-1.com が site-2.com を RP ID として使用できるように構成します。そのためには、webauthn JSON ファイルを作成します。

{
    "origins": [
        "https://site-2.com"
    ]
}

JSON オブジェクトには、キー名が origins で、値がウェブオリジンを含む 1 つ以上の文字列の配列である必要があります。

重要な制限事項: 最大 5 個のラベル

このリストの各要素は、処理されて eTLD + 1 ラベルが抽出されます。たとえば、example.co.uk と example.de の eTLD + 1 ラベルはどちらも example です。ただし、example-rewards.com の eTLD + 1 ラベルは example-rewards です。 Chrome では、ラベルの最大数は 5 です。

ステップ 3: site-1 で .well-known/webauthn JSON を提供する

次に、site-1.com/.well-known/webauthn に JSON ファイルを提供します。

たとえば、express の場合:

app.get("/.well-known/webauthn", (req, res) => {
  const origins = {
    origins: ["https://site-2.com"],
  };
  return res.json(origins);
});

ここでは、express res.json を使用しています。これにより、正しい content-type（'application/json'）がすでに設定されています。

ステップ 4: site-2 で RP ID を指定する

site-2 コードベースで、必要なすべての場所に site-1.com を RP ID として設定します。

認証情報の作成時:
- 認証情報作成 options で site-1.com を RP ID として設定します。これは navigator.credentials.create フロントエンド呼び出しに渡され、通常はサーバーサイドで生成されます。
- データベースに保存する前に認証情報の検証を行うため、site-1.com を想定される RP ID として設定します。
認証時:
- navigator.credentials.get フロントエンド呼び出しに渡され、通常はサーバーサイドで生成される認証 options で、site-1.com を RP ID として設定します。
- ユーザーを認証する前に認証情報の検証を行うため、サーバーで検証される想定される RP ID として site-1.com を設定します。

トラブルシューティング

Chrome に表示されるエラーメッセージのポップアップ。 — 認証情報の作成時に Chrome に表示されるエラーメッセージ。このエラーは、`.well-known/webauthn` ファイルが `https://{RP ID}/.well-known/webauthn` に見つからない場合にスローされます。

その他の考慮事項

サイトとモバイルアプリでパスキーを共有する

関連オリジンリクエストを使用すると、ユーザーは複数のサイトでパスキーを再利用できます。ユーザーがウェブサイトとモバイルアプリでパスキーを再利用できるようにするには、次の方法を使用します。

Chrome の場合: デジタルアセットリンク。詳しくは、デジタルアセットリンクのサポートを追加するをご覧ください。
Safari の場合: 関連ドメイン。

サイト間でパスワードを共有する

関連オリジンリクエストを使用すると、ユーザーはサイト間でパスキーを再利用できます。サイト間でパスワードを共有するためのソリューションは、パスワードマネージャーによって異なります。 Google パスワードマネージャーの場合は、デジタルアセットリンクを使用します。 Safari には別のシステムがあります。

認証情報マネージャーとユーザーエージェントの役割

これはサイトデベロッパーの範囲を超えますが、長期的には、RP ID はユーザーが使用しているユーザーエージェントまたは認証情報マネージャーでユーザーに表示されるコンセプトにすべきではありません。代わりに、ユーザーエージェントと認証情報マネージャーは、認証情報が使用された場所をユーザーに表示する必要があります。この変更の実装には時間がかかります。一時的な解決策として、現在のウェブサイトと元の登録サイトの両方を表示する方法があります。