相關來源要求解決問題
密碼金鑰會與特定網站連結,只能用於登入建立時所屬的網站。
這是在參考方 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
程式碼集內,將所有必要的 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 中:Digital Asset Links。如要進一步瞭解如何新增 Digital Asset Links 的支援,請參閱這篇文章。
- 在 Safari 中:相關聯的網域。
跨網站共用密碼
相關的來源要求可讓使用者在不同網站上重複使用密碼金鑰。不同網站共用密碼的解決方案因密碼管理工具而異。 如果是 Google 密碼管理工具,請使用 Digital Asset Links 。 Safari 採用不同的系統。
憑證管理工具和使用者代理程式的角色
這超出網站開發人員的範圍,但請注意,長期來說,RP ID 不應是使用者代理程式或使用者所用憑證管理工具中可向使用者顯示的概念。相反地,使用者代理程式和憑證管理工具應向使用者顯示其憑證已被使用於何處。這項變更需要時間才能實施。暫時的解決方法是同時顯示目前網站和原始註冊網站。