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

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。如果 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。

查看程式碼：

• 請參閱 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 將其做為 受限方 ID。如要這麼做，請建立 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 檔案。

例如，

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：

• 建立憑證後：
  • 將 site-1.com 設為憑證建立 options 中的 RP ID，這些憑證會傳遞至 navigator.credentials.create 前端呼叫，並通常由伺服器端產生。
  • 請將 site-1.com 設為預期的 RP ID，因為您必須先執行憑證驗證，才能將其儲存到資料庫。
• 驗證完成後：
  • 將 site-1.com 設為驗證 options 中的 RP ID 傳遞到 navigator.credentials.get 前端呼叫；以及 通常是伺服器端產生的
  • 將 site-1.com 設為要在網站上驗證的預期 RP ID 您在驗證使用者之前就執行憑證驗證。

疑難排解

，瞭解如何調查及移除這項存取權。

其他注意事項

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

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

• Chrome：數位資產 連結。瞭解詳情： 新增 Digital Asset Links 的支援。
• 在 Safari 中： 關聯網域。

跨網站共用密碼

相關的來源要求可讓使用者在不同網站上重複使用密碼金鑰。不同密碼管理工具提供的密碼分享解決方案各有不同。如要使用 Google 密碼管理工具，請使用 Digital Asset Links。Safari 有不同的系統。

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

這超出網站開發人員所負責的範圍 但請注意， RP ID 不應是使用者代理程式中向使用者顯示的概念 憑證管理工具。而是使用使用者代理程式和憑證 管理員應向使用者顯示憑證的使用「位置」。這項異動 導入程序要花時間暫時的解決方法是同時顯示 目前的網站和原始註冊網站。