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

Maud Nalpas
Maud Nalpas
X GitHub

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

これは証明書利用者 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 の使用を許可するオリジンを指定できます。

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

関連オリジン リクエストを使用するには、特別な 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 がスローされます。

ブラウザ サポート

で確認できます。

次のデモでは、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 として使用します。
また、これらのサイトには共有パスキー データベースも実装しています。

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

  • RP ID が（ror-2 ではなく）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 でパスキーを作成すると、ror-1 と ror-2 の両方で Chrome によってパスキーを自動入力できます。
  • これらのサイトのいずれかで作成された認証情報の RP ID は ror-1 になります。
で確認できます。 <ph type="x-smartling-placeholder">
</ph> 両方のサイトで Chrome が自動入力されます。 <ph type="x-smartling-placeholder">
</ph> 関連オリジン リクエストにより、ユーザーは ror-1 と ror-2 で同じパスキー認証情報を使用できるようになりました。認証情報は自動入力されます。

コードをご覧ください。

で確認できます。

ステップ 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 個です。

ステップ 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);
});

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

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

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

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

トラブルシューティング

<ph type="x-smartling-placeholder">
</ph> Chrome のエラー メッセージのポップアップ。 <ph type="x-smartling-placeholder">
</ph> 認証情報の作成時に Chrome に表示されるエラー メッセージ。このエラーは、.well-known/webauthn ファイルが `https://{RP ID}/.well-known/webauthn` で見つからない場合にスローされます。
で確認できます。
<ph type="x-smartling-placeholder">
</ph> Chrome のエラー メッセージのポップアップ。 <ph type="x-smartling-placeholder">
</ph> 認証情報の作成時に Chrome に表示されるエラー メッセージ。このエラーは、「.well-known/webauthn」ファイルが見つかっても、認証情報の作成元となるオリジンがリストされていない場合にスローされます。

その他の考慮事項

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

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

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

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

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

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