本頁面由 Cloud Translation API 翻譯而成。

允許透過相關來源要求，在網站上重複使用密碼金鑰

Maud Nalpas

相關來源要求解決問題

密碼金鑰會與特定網站連結，只能用於登入建立時所屬的網站。

這項資訊會在依賴方 ID (RP ID) 中指定，如果是為 example.com 網域建立的密碼金鑰，則可能為 www.example.com 或 example.com。

雖然 RP ID 可防止密碼金鑰用於所有地方的單一驗證憑證，但會導致以下問題：

網站有多個網域：使用者無法使用相同的密碼金鑰，在由同一家公司管理的不同國家/地區專屬網域 (例如 example.com 和 example.co.uk) 登入。
品牌網域：使用者無法在單一品牌使用的不同網域 (例如 acme.com 和 acmerewards.com) 中使用相同的憑證。
行動應用程式：行動應用程式通常沒有自己的網域，因此憑證管理作業相當困難。

有幾種解決方法可用於身分聯盟，也有其他方法可用於 iframe，但在某些情況下，這些方法都很不方便。相關的來源要求會提供解決方案

解決方案

透過相關來源要求，網站可以指定允許使用其 RP ID 的來源。

這樣一來，使用者就能在您經營的多個網站上重複使用同一個密碼金鑰。

如要使用相關來源要求，您必須於特定網址 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 Beta 3 起，支援行動裝置 iOS 18 Beta 3。
Firefox：等待位置。

如何設定相關來源要求

以下示範使用兩個網站的例子：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 在建立密碼金鑰或使用密碼金鑰進行驗證時，都會使用 ror-1.glitch.me 做為 RP ID。
我們也已在這些網站上實作共用密碼金鑰資料庫。

觀察下列使用者體驗：

您可以在 ror-2 上成功建立密碼金鑰，並使用密碼金鑰進行驗證，即使其 RP ID 為 ror-1 (而非 ror-2) 也一樣。
在 ror-1 或 ror-2 上建立密碼金鑰後，您就可以在 ror-1 和 ror-2 上使用密碼金鑰進行驗證。由於 ror-2 將 ror-1 指定為 RP ID，因此從任何一個網站提出密碼金鑰建立或驗證要求，都等同於在 ror-1 提出要求。受限方 ID 是唯一會將要求與來源建立繫結。
在 ror-1 或 ror-2 上建立密碼金鑰後，Chrome 就能在 ror-1 和 ror-2 上自動填入密碼金鑰。
在任何一個網站上建立的憑證，其 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：在 site-1 中設定 .well-known/webauthn JSON 檔案

首先，請設定 site-1.com，讓 site-2.com 可將其用作 RP ID。如要這麼做，請建立 webauthn JSON 檔案：

{
    "origins": [
        "https://site-2.com"
    ]
}

JSON 物件必須包含名稱為 origins 的鍵，其值為包含一個或多個包含網址來源的字串陣列。

重要限制：最多 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 檔案。

例如，

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 程式碼集內，將所有必要的 RP ID 設為 site-1.com：

建立憑證時：
- 在憑證建立 options 中將 site-1.com 設為 RP ID，這些 site-1.com 會傳遞至 navigator.credentials.create 前端呼叫，通常會在伺服器端產生。
- 請將 site-1.com 設為預期的 RP ID，因為您會在執行憑證驗證後，再將其儲存到資料庫。
驗證時：
- 將 site-1.com 設為驗證 options 中的 RP ID，該 ID 會傳遞至 navigator.credentials.get 前端呼叫，通常會在伺服器端產生。
- 請將 site-1.com 設為伺服器上應驗證的預期 RP ID，因為您會在驗證使用者身分之前執行憑證驗證。

疑難排解

Chrome 的錯誤訊息彈出式視窗。 — 建立憑證時，Chrome 會顯示錯誤訊息。如果在「https://{RP ID}/.well-known/webauthn」中找不到「.well-known/webauthn」檔案，系統就會擲回這個錯誤。

其他注意事項

在不同網站和行動應用程式之間共用密碼金鑰

相關來源要求可讓使用者在多個網站中重複使用密碼金鑰。如要讓使用者在網站和行動應用程式中重複使用密碼金鑰，請使用下列技術：

在 Chrome 中：Digital Asset Links。如要進一步瞭解如何新增 Digital Asset Links 的支援，請參閱這篇文章。
在 Safari 中：相關聯的網域。

在不同網站之間分享密碼

相關的來源要求可讓使用者在不同網站上重複使用密碼金鑰。不同網站共用密碼的解決方案因密碼管理工具而異。如要使用 Google 密碼管理工具，請使用 Digital Asset Links。Safari 採用不同的系統。

憑證管理工具和使用者代理程式的角色

這超出您網站開發人員的範圍，但請注意，從長遠來看，RP ID 不應是使用者代理程式或使用者使用的憑證管理工具中的使用者可見概念。相反地，使用者代理程式和憑證管理工具應向使用者顯示其憑證已被使用於何處。這項變更需要一段時間才會生效。暫時的解決方法是同時顯示目前網站和原始註冊網站。