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

このページは Cloud Translation API によって翻訳されました。

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

Maud Nalpas

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

これはリライングパーティ ID（RP ID）で指定されます。example.com ドメイン用に作成されたパスキーの場合、www.example.com または example.com になります。

RP ID は、パスキーがどこでも認証するための単一の認証情報として使用されるのを防ぎますが、次のような問題が生じます。

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

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

解決策

関連オリジンリクエストを使用すると、ウェブサイトは RP ID の使用を許可するオリジンを指定できます。

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

関連オリジンリクエストを使用するには、特定の 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 を認識します。ブラウザが関連オリジンリクエストをサポートしている場合、まず https://{RP ID}/.well-known/webauthn で webauthn ファイルを探します。ファイルが存在する場合、ブラウザはリクエストを行うオリジンが allowlist にあるかどうかを確認します。[はい] の場合、パスキーの作成または認証の手順に進みます。

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

ブラウザサポート

Browser Support

Source

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

次のデモでは、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-2 でパスキーを作成して認証できます。
ror-1 または ror-2 のいずれかでパスキーを作成すると、ror-1 と ror-2 の両方でパスキーを使用して認証できます。ror-2 で RP ID として ror-1 が指定されているため、これらのサイトのいずれかからパスキーの作成または認証リクエストを行うことは、ror-1 でリクエストを行うことと同じです。RP ID は、リクエストをオリジンに関連付ける唯一のものです。
ror-1 または ror-2 でパスキーを作成すると、ror-1 と ror-2 の両方で Chrome による自動入力が可能になります。
これらのサイトで作成された認証情報には、RP ID ror-1 が設定されます。

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

コードを参照してください。

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

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

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

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

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

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

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

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

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

ステップ 3: サイト 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 コードベースで、必要なすべての場所で RP ID として site-1.com を設定します。

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

トラブルシューティング

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

その他の考慮事項

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

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

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

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

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

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

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