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

Maud Nalpas
Maud Nalpas

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

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

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

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

ブラウザ サポート

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

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

デモ

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

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

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

コードを参照:

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

ユーザーが site-1site-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.ukexample.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);
});

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

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

site-2 コードベースで、必要に応じて RP ID として site-1.com を設定します。

  • 認証情報の作成時:
    • 認証情報の作成 options で RP ID として site-1.com を設定し、navigator.credentials.create フロントエンド呼び出しに渡します。通常はサーバーサイドで生成されます。
    • 認証情報をデータベースに保存する前に認証情報の検証を実行するため、想定される RP ID として site-1.com を設定します。
  • 認証時:
    • 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 に表示されるエラー メッセージのポップアップ。
認証情報の作成時に Chrome に表示されるエラー メッセージ。このエラーは、`.well-known/webauthn` ファイルが見つかったものの、認証情報を作成しようとしているオリジンがリストにない場合にスローされます。

その他の考慮事項

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

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

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

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

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

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