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

Maud Nalpas

関連オリジン リクエストで解決できる問題

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

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

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

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

ID 連携に基づく回避策と、ID 連携に基づく回避策があります。 使用できますが、場合によっては不便になります。関連するオリジンのリクエストの提供 説明します。

注: RP ID はウェブサイト間で別個の認証情報として機能しますが、フィッシングは 実際の保護は、CollectedClientData フィールドでウェブサイトのオリジンを検証することによって行われます。

解決策

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

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

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

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

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

ブラウザ サポート

• Chrome: Chrome 以降でサポート 128。
• Safari: macOS 15 ベータ版 3 以降、モバイル iOS 18 ベータ版 3 以降でサポートされています。
• Firefox: 待機中のポジション。

で確認できます。

警告: 2024 年 8 月現在、関連するオリジンのリクエストは Firefox でサポートされていません。 getClientCapabilities 見当たらない機能を検出して実装するための 使用します。関連オリジン リクエストを実装すると、Firefox ユーザーは 別のサイトを RP ID と SecurityError がスローされます。

関連オリジン リクエストの設定方法

次のデモでは、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 の両方が、パスキーの作成時またはパスキーによる認証時に RP ID として ror-1.glitch.me を使用します。
また、これらのサイトには共有パスキー データベースも実装しています。

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

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

で確認できます。 <ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> 関連オリジン リクエストにより、ユーザーは ror-1 と ror-2 で同じパスキー認証情報を使用できるようになりました。認証情報は自動入力されます。

コードをご覧ください。

• ror-1 コードベースで設定されている ./well-known/webauthn ファイルを参照してください。
• ror-2 コードベースの 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 の配列です。 ウェブオリジンを含む 1 つ以上の文字列を抽出できます。

重要な制限: ラベルは最大 5 個までです

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

警告: リストにラベルが多すぎる（5 個を超える）場合、余分な要素は無視されます。

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

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

注意: ファイルはコンテンツ タイプ application/json で提供し、 単一の JSON オブジェクトの一覧表示 表示されます。ファイルの正しい形式は /.well-known/webauthn です（.json 拡張子は含めないでください）。

たとえば、express では以下のようになります。

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

ここでは、エクスプレス res.json を使用しています。これにより、 正しいcontent-type（'application/json'）;

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

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

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

で確認できます。

注: origin についてはどうでしょうか。RP name はどう？site-2 コードベースでは、想定される origin は変更せずに（https://site-2.com）残しておきます。これは、リクエストの送信元を指定するためです。RP 名（rp.name）のとおり、実際には使用されていません。空欄にしておいてもかまいません。

トラブルシューティング

<ph type="x-smartling-placeholder">

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

で確認できます。

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

</ph> 認証情報の作成時に Chrome に表示されるエラー メッセージ。このエラーは、「.well-known/webauthn」ファイルが見つかっても、認証情報の作成元となるオリジンがリストされていない場合にスローされます。

その他の考慮事項

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

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

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

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

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

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

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