本頁面由 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 提出要求。RP 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 檔案。

例如，在 Express 中：

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

這裡我們使用的是 express 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 不應是使用者代理程式或使用者所用憑證管理工具中可向使用者顯示的概念。相反地，使用者代理程式和憑證管理工具應向使用者顯示其憑證已被使用於何處。這項變更需要時間才能實施。暫時的解決方法是同時顯示目前網站和原始註冊網站。