簡化跨網域登入程序

Eiji Kitamura

現代企業架構經常涵蓋多個不同的網域。 機構會為不同功能維護專屬環境，例如：brand.example 用於行銷、service-app.example 用於核心產品，以及 support-portal.example 用於客戶服務。理想情況下，您希望使用者在瀏覽這些資源時，能享有統一的單一登入體驗。不過，工程團隊通常會使用臨時技術整合這些網域，導致片段化。這會中斷內建瀏覽器憑證管理功能，導致密碼管理工具自動填入流程中斷，並延緩密碼金鑰的採用。

這張圖說明不同機構網域的跨網域登入片段。
多個網站資源的跨網域身分識別片段。

如果同一個帳戶涵蓋多個網域，使用者必須確認這些網域屬於同一個機構，並在登入時提供相同的憑證。最糟的情況是，使用者建立重複帳戶，或將密碼提供給網路釣魚網站。

瞭解如何運用架構標準和解決方案 (例如中繼資料、跨來源 iframe、身分同盟和子網域合併)，解決跨網域身分識別片段化問題，提供流暢的使用者歷程。

常見解決方法

機構會使用多種既有技術來維持跨網域歷程。雖然這些方法很常見，但隨著瀏覽器強制執行更嚴格的隱私權界線和安全標準，這些方法也面臨結構性障礙。

CORS 擷取要求

網域獨立運作時，前端通常會依賴導向集中式驗證 API 的跨源 fetch() 要求，而這類要求可使用跨源資源共享 (CORS) 安全地允許。由於瀏覽器通常會封鎖或限制跨網站 Cookie，開發人員可能會明確設計這些 API，在 JSON 酬載中傳回驗證權杖 (例如 JSON Web Token (JWT))，而不是依賴 Set-Cookie 標頭。

帳戶資料庫共用

如要在後端統一身分，不必進行複雜的前端整合，可以集中管理使用者資料存放區。雖然多個網域會根據同一個資料庫進行驗證，但前端登入體驗仍會分開。這會導致使用者必須記住使用相同憑證的網域，進而造成不良的使用者體驗。

不連貫的登入問題

雖然技術上的變通方法可以實現基本功能，但無法提供流暢的體驗。不連貫的登入流程會產生摩擦點，導致可用性和安全性雙雙受損。

密碼管理工具分散

最容易造成阻礙的是密碼管理工具中斷運作。密碼管理工具會將儲存的憑證繫結至註冊憑證的特定來源。這樣一來，即使不同網域屬於同一機構，瀏覽器也不會提供自動填入功能。

如果使用者從已儲存憑證的網域，轉換至貴機構的新網域，密碼管理工具無法辨識兩者關係，因此不會觸發自動填入提示。這會造成手動輸入的阻礙。 使用者必須查詢憑證、重設密碼或建立重複帳戶。

由於密碼管理工具在這些資源中不可靠，使用者可能會放棄使用這些網站的工具。他們通常會建立容易記住的弱密碼，並在其他地方重複使用，這會降低貴機構的整體安全性。

網路釣魚閘道

這項中斷功能會做為網路釣魚閘道。如果密碼管理工具拒絕在無法辨識的網域上自動填入密碼，這是主要的防禦機制。要求使用者在不同網址上手動輸入憑證，會無意間訓練使用者落入網路釣魚攻擊的陷阱。

密碼金鑰路障

使用密碼金鑰時，摩擦係數會增加。WebAuthn 的核心安全架構會將密碼金鑰嚴格繫結至指定的信賴方 ID (RP ID)。

這會建立「RP ID 陷阱」。在 brand.example 註冊的密碼金鑰無法在 service-app.example 使用，因為瀏覽器會拒絕跨網域存取。為避免系統提示使用者為每個網站註冊不同的密碼金鑰，您必須將這些屬性整合至單一 RP ID。

如要確保身分連續性，請務必捨棄臨時登入整合，並採用公認的架構標準：

  • 使用中繼資料設定檔：代管 Digital Asset Links 和相關來源要求等中繼資料檔案，建立加密信任鏈結。這樣一來，不同網域和行動應用程式就能順暢共用憑證和密碼金鑰。這種做法可低成本且無聲地修正身分識別片段化問題，不需要對現有網路基礎架構進行複雜的重新架構。
  • 使用跨原始來源 iframe：在依賴方中嵌入集中式驗證原始來源做為 iframe，藉此在不同網站之間橋接已儲存的憑證和密碼金鑰。這種做法會使用權限政策和分割 Cookie，在透過 CSP 和跨文件訊息傳遞維持嚴格的安全界線時，提供流暢的脈絡內登入體驗。
  • 遵循標準身分同盟： 採用 OpenID Connect 等業界標準通訊協定，在專屬的識別資訊提供者 (IdP) 網域集中進行驗證。這項功能會透過安全重新導向，正式化登入程序，以可靠且可擴充的第一方解決方案，取代不穩定的整合。
  • 整合子網域：改用共同根網域下的子網域。這項功能可透過萬用字元 Cookie 順暢分享工作階段，並在整個可註冊網域中延續密碼金鑰。許多密碼管理工具都能辨識共用的根網域，並自動建議相關子網域中已儲存的憑證。

使用中繼資料設定檔

跨網域身分識別的主要挑戰是儲存的憑證分散各處。密碼管理工具會將不同網域和應用程式視為完全獨立的實體，因此無法將儲存在某個資源的憑證自動填入另一個資源。

如要解決片段化問題，您可以設定密碼管理工具的行為，而不必變更網站結構。只要代管特定中繼資料設定檔，機構就能以密碼學方式聲明不同的網域和應用程式屬於同一機構。作業系統、瀏覽器和密碼管理工具就能辨識這項關係，並自動連結身分情境，在您的資源之間共用密碼和密碼金鑰。即使網域已整合，您也必須採用這種做法，才能與行動應用程式共用網頁密碼和密碼金鑰。

請使用兩個不同的設定檔，確保涵蓋不同平台和生態系統：

  • Android 和 Chrome 上的 Google 密碼管理工具：在 /.well-known/assetlinks.json 代管 Digital Asset Links (DAL) JSON 檔案，在機構的相關應用程式和網站之間建立可驗證的信任關係。這項信任關係可讓應用程式使用深層連結和無縫憑證共用功能，自動填入網頁上儲存的密碼 (不過，在多個網域之間共用密碼金鑰仍需要相關來源要求)。詳情請參閱無縫憑證共用指南。

  • iOS 和 Safari 上的「Apple 密碼」：在 /.well-known/apple-app-site-association 託管 Apple App Site Association (AASA) 檔案，建立必要的加密信任鏈，以便在 iOS 應用程式和 Safari 之間橋接「Apple 密碼」狀態。為支援第三方生態系統，您可以透過眾包存放區集中宣告這些相關聯的網域。這麼做可確保獨立工具 (例如會明確擷取這個存放區的 1Password) 也會辨識共用的身分識別環境。如要進一步瞭解 Apple 應用程式網站關聯，請參閱「支援相關聯的網域」。

如要在不同網域啟用密碼金鑰，並解決密碼金鑰的阻礙，開發人員可以在 /.well-known/webauthn 託管相關來源要求 (ROR) 檔案。ROR 會明確聲明授權網域，允許這些網域安全地共用相同的密碼金鑰 RP ID。如要進一步瞭解相關來源要求，請參閱「透過相關來源要求，允許在網站間重複使用密碼金鑰」。

  • 優點：
    • 為使用者在背景修正：這項功能完全在背景運作，可在 OS 或瀏覽器層級自動解決自動填入功能片段化問題，並建立密碼金鑰連續性，使用者體驗不會有任何明顯變化。
    • 實作簡單：這個解決方案成本低廉，只需要代管靜態 JSON 檔案。不需要重新架構後端，也不需要複雜的權杖交換邏輯。
    • 保留現有基礎架構：您不必變更品牌或合併網域，就能大幅改善跨網域歷程。
  • 缺點：
    • 平台限制：平台通常會嚴格限制 ROR。舉例來說，Chrome 會限制單一 RP ID 最多只能有 5 個相關聯的 eTLD+1 標籤。舉例來說，example.co.uk 和 example.de 共用相同的 example eTLD+1 標籤，但 example-rewards.com 使用不同的 example-rewards 標籤。如果您管理大量或多樣的網域組合，這些限制可能不夠用。
    • 作業延遲時間增加：解析中繼資料檔案需要額外的網路往返，因此瀏覽器處理驗證時會增加延遲時間。
圖表：說明中繼資料設定檔如何建立信任關係，以便在不同網域之間共用已儲存的憑證。
使用中繼資料設定檔啟用憑證共用功能。

使用跨來源 iframe

如果因 ROR 網域限制而無法使用中繼資料設定檔方法，跨來源 iframe 元素可提供強大的標準支援路徑，解決跨網域登入問題。

只要將集中式驗證來源 (例如 auth.brand.example) 嵌入為依賴方 (例如 brand.example) 內的 iframe，即可與一般表單欄位和新式 API 互動。如果是密碼，瀏覽器的憑證管理工具會將自動填入動作與 iframe 的來源 (auth.example) 建立關聯，讓使用者在不同網站上都能順暢存取集中管理的憑證。

如果是密碼金鑰，父項視窗必須使用「權限政策」架構授予 iframe 存取權，iframe 才能叫用 WebAuthn，根據自身來源的 RP ID 進行驗證。在這兩種流程中，內容安全政策 (CSP) 有助於保護使用者免於點擊劫持和跨網站指令碼等攻擊。驗證成功後，系統會使用分割 Cookie 建立工作階段，並使用 postMessage() 將權杖安全地傳回父項視窗。

  • 優點：
    • 集中管理憑證：避免憑證分散各處。單一集中式來源會管理已儲存的密碼和統一的密碼金鑰 RP ID，讓不同網域共用這些憑證，不必合併網域。
    • 情境式驗證：無論是自動填入密碼或使用密碼金鑰驗證，整個登入流程都會在父項網頁中順暢進行，避免聯合重新導向造成中斷。
    • 不受追蹤保護措施影響：即使使用分割 Cookie 嚴格防範跨網站追蹤，這種做法仍能正常運作。
  • 缺點：
    • 實作限制：這項架構需要專業的工程技術。這項功能需要嚴格的 CSP (frame-ancestors)，才能將嵌入限制在受信任的父項網域，並防止點擊劫持；此外，還需要設定 HTTP 權限政策來啟用 WebAuthn API，以及使用經過驗證的安全跨文件訊息 (postMessage())，才能防範來源偽造和 CSRF 攻擊。如要瞭解最佳做法，請參閱「iframe 中的密碼金鑰」。
圖表：顯示跨來源 iframe 驗證流程，在不同網站之間橋接憑證和密碼金鑰。
跨原始來源 iframe 驗證流程。

遵循標準身分聯盟

採用 OpenID Connect 等標準身分識別聯盟，是維護帳戶系統的穩健且永續做法。這種做法會將驗證工作流程整合至單一專屬的識別資訊提供者 (IdP) 網域 (例如 auth.brand.example)，藉此正式化驗證工作流程。應用程式會透過既定通訊協定將使用者重新導向至這個中央中樞進行驗證，然後安全地接收權杖轉移，完成目標網域的登入程序。雖然標準同盟通常與第三方登入 (例如使用 Google 帳戶登入) 相關聯，但標準同盟完全有效，且廣泛用做第一方解決方案，可取代不穩定的變通方法。

  • 優點：
    • 通用工程語言：開發人員不必學習或維護特定的自訂通訊協定，而是可以運用既有的產業知識和完整的程式庫。此外，我們也提供套裝解決方案。
    • 經過實戰考驗的可靠性：標準通訊協定經過驗證，安全無虞，且遠比臨時實作更穩定。
    • 輕鬆擴充：如果機構日後需要與新的第三方服務聯合，或是整合收購項目，身分基礎架構已準備好提供憑證。
    • 一致的使用者體驗：使用者會將集中式 IdP 頁面視為品牌的權威來源，清楚瞭解何時及何處需要憑證。
  • 缺點：
    • 整合成本高昂：開發或遷移至集中式 IdP 的整合成本高昂，且需要專業的安全性知識。機構必須投入資源，安全地重構所有連線的應用程式，以支援安全重新導向模式。
    • 干擾性重新導向：驗證流程會將使用者從原始網站重新導向至集中式身分識別提供者頁面，導致無法順暢地在情境中登入。
這張圖顯示使用 OpenID Connect 等標準通訊協定進行身分同盟的流程，以便集中驗證。
標準身分聯盟流程。

合併子網域

另一種結構性做法是將所有網域統一，方法是將不同的數位資源移至可註冊的通用根網域 (eTLD+1) 下方。也就是將 brand.example 和 service-app.example 等個別網域轉換為 www.brand.example 和 service.brand.example 等子網域。

  • 優點：
    • 統一管理憑證：密碼管理工具可辨識根網域，並將所有子網域視為單一項目，避免重複提示及手動輸入密碼。
    • 密碼金鑰連續性：開發人員可將密碼金鑰 RP ID 原生範圍設定為可註冊的網域，立即在所有相關聯的子網域中擴展密碼金鑰支援。在本例中，brand.example 的 RP ID 會在 www.brand.example 和 service.brand.example 中運作。
    • 輕鬆共用工作階段：整合網域結構後，即可使用萬用字元 Cookie 共用單一工作階段 (例如將 Cookie 範圍設為 Domain=brand.example)。
  • 缺點：
    • 品牌和遷移限制：如果貴機構強制使用不同的頂層網域，這種做法可能會造成潛在的品牌限制。遷移作業相當複雜，需要仔細管理 HTTP 重新導向，並大幅修正舊版跨來源設定。
圖表：說明如何將子網域整合至可註冊的通用根網域，以啟用工作階段和密碼金鑰共用功能。
將子網域整合至通用根目錄。

結論

如要確保身分連續性，您必須從臨時登入整合服務，轉換為採用既有的驗證標準。評估業務限制與這些既有做法 (例如同盟、網域整併、iframe 或中繼資料) 的差異，即可消除使用者體驗摩擦，並改善整個生態系統的驗證程序。

如要進一步瞭解相關主題，請務必追蹤我們的網誌，並在 Chrome 的身分識別入口網站中探索更多資源。