関連送信元リクエストが解決する問題
パスキーは特定のウェブサイトに関連付けられ、作成されたウェブサイトへのログインにのみ使用できます。
これは、リライング パーティ 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
ファイルを探します。ファイルが存在する場合、ブラウザはリクエストを送信した送信元がそのファイルの許可リストに登録されているかどうかを確認します。有効な場合は、パスキーの作成または認証の手順に進みます。ブラウザが関連オリジン リクエストをサポートしていない場合は、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
が RP ID として ror-1.glitch.me
を使用できるようにします。
デモ
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
です。
コードを参照:
- 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 を提供する
次に、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 の場合: Digital Asset Links。詳しくは、デジタル アセット リンクのサポートを追加するをご覧ください。
- Safari の場合: [関連ドメイン]。
サイト間でパスワードを共有する
関連オリジン リクエストを使用すると、ユーザーはサイト間でパスキーを再利用できます。サイト間でパスワードを共有するソリューションは、パスワード マネージャーによって異なります。Google パスワード マネージャーの場合は、デジタル アセット リンク を使用します。Safari は別のシステムを使用しています。
認証情報マネージャーとユーザー エージェントの役割
これはサイト デベロッパーの範囲を超えていますが、長期的には、RP ID はユーザー エージェントまたはユーザーが使用している認証情報マネージャーでユーザーに表示されるコンセプトであってはなりません。代わりに、ユーザー エージェントと認証情報マネージャーは、認証情報が使用された場所をユーザーに表示する必要があります。この変更の実装には時間がかかります。一時的な解決策としては、現在のウェブサイトと元の登録サイトの両方を表示します。