相關來源要求解決問題
密碼金鑰會綁定至特定網站,只能用於在建立密碼金鑰的網站上登入。
(由信賴方指定)
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"
]
}
下次這些網站提出密碼金鑰建立要求時
(navigator.credentials.create
) 或驗證 (navigator.credentials.get
)
使用 example.com
做為 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 會在兩個網站上自動填入內容。](https://web.developers.google.cn/static/articles/webauthn-related-origin-requests/image/chrome-autofill.jpg?hl=zh-tw)
查看程式碼:
- 請參閱 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);
});
這裡,我們使用速成 res.json
,
正確content-type
('application/json'
);
步驟 4:在 site-2 中指定所需的 RP ID
在 site-2
程式碼集內,將所有必要的 RP ID 設為 site-1.com
:
- 建立憑證後:
- 在建立憑證時將
site-1.com
設為 RP ID 傳遞至navigator.credentials.create
的options
前端呼叫,通常是產生的伺服器端。 - 在執行憑證時,將
site-1.com
設為預期的 RP ID 才能儲存至資料庫
- 在建立憑證時將
- 驗證完成後:
- 將
site-1.com
設為驗證options
中的 RP ID 傳遞到navigator.credentials.get
前端呼叫;以及 通常是伺服器端產生的 - 將
site-1.com
設為要在網站上驗證的預期 RP ID 您在驗證使用者之前就執行憑證驗證。
- 將
疑難排解
![Chrome 的錯誤訊息彈出式視窗。](https://web.developers.google.cn/static/articles/webauthn-related-origin-requests/image/error-file-not-found.jpg?hl=zh-tw)
![Chrome 的錯誤訊息彈出式視窗。](https://web.developers.google.cn/static/articles/webauthn-related-origin-requests/image/error-file-incorrect.jpg?hl=zh-tw)
其他注意事項
在網站和行動應用程式之間共用密碼金鑰
相關來源要求可讓使用者在多個項目之間重複使用密碼金鑰 網站。 如要允許使用者在網站和行動應用程式中重複使用密碼金鑰, 使用下列技巧:
- Chrome:數位資產 連結。瞭解詳情: 新增 Digital Asset Links 的支援。
- 在 Safari 中: 關聯網域。
跨網站共用密碼
相關來源要求可讓使用者在各網站上重複使用密碼金鑰。 在不同網站共用密碼的解決方案會因密碼管理工具而異。 如果是 Google 密碼管理工具,請使用 Digital Asset Links 。 Safari 有不同的系統。
憑證管理工具和使用者代理程式的角色
這超出網站開發人員所負責的範圍 但請注意, RP ID 不應是使用者代理程式中向使用者顯示的概念 憑證管理工具。而是使用使用者代理程式和憑證 管理員應向使用者顯示憑證的使用「位置」。這項異動 導入程序要花時間暫時的解決方法是同時顯示 目前的網站和原始註冊網站。