相關來源要求解決的問題
密碼金鑰會與特定網站連結,只能用於登入建立密碼金鑰的網站。
這項資訊會在依賴方 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
。
查看程式碼:
- 請參閱 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
程式碼集中,將 site-1.com
設為所有需要的 RP ID:
- 建立憑證時:
- 將
site-1.com
設為憑證建立options
中的 RP ID,這些憑證會傳遞至navigator.credentials.create
前端呼叫,通常會在伺服器端產生。 - 請將
site-1.com
設為預期的 RP ID,因為您會在執行憑證驗證後,再將其儲存到資料庫。
- 將
- 驗證完成後:
- 將
site-1.com
設為驗證options
中的 RP ID,該 ID 會傳遞至navigator.credentials.get
前端呼叫,通常會在伺服器端產生。 - 請將
site-1.com
設為伺服器上應驗證的預期 RP ID,因為您會在驗證使用者身分之前執行憑證驗證。
- 將
疑難排解
其他注意事項
在各個網站和行動應用程式中分享密碼金鑰
相關的來源要求可讓使用者在多個網站中重複使用密碼金鑰。如要讓使用者在網站和行動應用程式中重複使用密碼金鑰,請使用下列技巧:
- 在 Chrome 中:Digital Asset Links。如要進一步瞭解如何新增 Digital Asset Links 的支援,請參閱這篇文章。
- 在 Safari 中:相關聯的網域。
在不同網站之間分享密碼
相關的來源要求可讓使用者在不同網站上重複使用密碼金鑰。不同密碼管理工具提供的跨網站密碼分享解決方案各有不同。如要使用 Google 密碼管理工具,請使用 Digital Asset Links 。Safari 採用不同的系統。
憑證管理工具和使用者代理程式的角色
這超出您網站開發人員的範圍,但請注意,從長遠來看,RP ID 不應是使用者代理程式或使用者使用的憑證管理工具中的使用者可見概念。相反地,使用者代理程式和憑證管理工具應向使用者顯示其憑證已被使用於何處。這項變更需要時間才能實施。暫時的解決方法是同時顯示目前網站和原始註冊網站。