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

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

Maud Nalpas

関連送信元リクエストが解決する問題

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

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

RP ID を使用すると、パスキーをあらゆる場所で認証するための単一の認証情報として使用できなくなりますが、次のような問題が発生します。

複数のドメインを使用するサイト: 同じ会社が管理する異なる国固有のドメイン（example.com、example.co.uk など）に同じパスキーを使用してログインすることはできません。
ブランドドメイン: ユーザーは、1 つのブランドで使用されている異なるドメイン（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 ファイルを探します。ファイルが存在する場合、ブラウザはリクエストを送信した送信元がそのファイルの許可リストに登録されているかどうかを確認します。その場合は、パスキーの作成または認証の手順に進みます。ブラウザが関連オリジンリクエストをサポートしていない場合は、SecurityError がスローされます。

ブラウザサポート

Chrome: Chrome 128 以降でサポートされています。
Safari: macOS 15 ベータ版 3 以降、モバイルでは iOS 18 ベータ版 3 以降でサポートされています。
Firefox: Awaiting position（待機中の位置）。

関連する送信元リクエストを設定する方法

次のデモでは、2 つのサイト（https://ror-1.glitch.me と https://ror-2.glitch.me）の例を使用します。
ユーザーが両方のサイトで同じパスキーでログインできるように、関連するオリジンリクエストを使用して、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 の両方が、パスキーの作成時またはパスキーによる認証時に RP ID として ror-1.glitch.me を使用します。
また、これらのサイト間で共有パスキーデータベースを実装しました。

次のユーザーエクスペリエンスを確認します。

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: site-1 に .well-known/webauthn JSON ファイルを設定する

まず、site-2.com が RP ID として使用できるように site-1.com を構成します。そのためには、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 を提供する

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

たとえば、express では次のようにします。

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

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

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

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

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

トラブルシューティング

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

その他の考慮事項

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

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

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

複数のサイトでパスワードを共有する

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

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

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