裝置繫結工作階段憑證 (DBSC)

裝置繫結工作階段憑證 (DBSC) 可透過新增硬體支援的工作階段安全性，強化驗證機制。

Daniel Rubery
Daniel Rubery
José Luis Zapata

簡介

許多網站都會使用長效 Cookie 進行使用者驗證，但這些 Cookie 容易遭到工作階段劫持。裝置繫結工作階段憑證 (DBSC) 會加入一層硬體支援安全性，以降低這類風險，確保工作階段繫結至特定裝置。

本指南適用於在網路應用程式中維護驗證流程的開發人員。說明 DBSC 的運作方式，以及如何將 DBSC 整合至網站。

DBSC 的運作方式

大致來說，DBSC 會引入與使用者裝置相關聯的密碼編譯金鑰組。Chrome 會在登入期間產生這個金鑰組，並將私密金鑰儲存在安全的硬體中 (例如可信平台模組 (TPM))。工作階段會使用短效 Cookie。當其中一個 Cookie 到期時，Chrome 會先證明自己擁有私密金鑰，再進行重新整理。這項程序會將工作階段連續性連結至原始裝置。

如果使用者的裝置不支援安全金鑰儲存空間，DBSC 會順利切換回標準行為，不會中斷驗證流程。

導入總覽

如要將 DBSC 整合至應用程式，您必須進行下列變更：

  • 修改登入流程，加入 Sec-Session-Registration 標頭。
  • 新增工作階段註冊端點，以便執行下列操作：
    • 將公開金鑰與使用者的工作階段建立關聯。
    • 提供工作階段設定。
    • 改用短效 Cookie。
  • 新增重新整理端點，以便處理 Cookie 續約和金鑰擁有權驗證。

您現有的大多數端點都不需要進行任何變更。DBSC 的設計原則是輔助性且不中斷。

當缺少必要的短效 Cookie 或 Cookie 已過期時，Chrome 會暫停要求並嘗試重新整理 Cookie。這樣一來，應用程式就能繼續使用其慣用的 Cookie 檢查，確認使用者是否已登入。由於這項功能與一般驗證流程相符，DBSC 只需對登入邏輯進行少許變更即可運作。

導入步驟

本節將逐步說明驗證系統的必要變更，包括如何修改登入流程、處理工作階段註冊，以及管理短效 Cookie 重新整理。每個步驟都旨在與現有基礎架構順利整合。

實作步驟會遵循 DBSC 啟用時登入使用者所體驗的常見流程：登入時註冊，然後定期重新整理短效 Cookie。您可以視應用程式的工作階段敏感度，分別測試及實作各個步驟。

顯示 DBSC 流程的圖表

1. 修改登入流程

使用者登入後，請傳回長效 Cookie 和 Sec-Session-Registration 標頭。例如：

在成功註冊工作階段後，系統會傳回下列 HTTP 回應標頭：

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

如果裝置支援安全金鑰儲存空間，Chrome 會透過 JSON Web Token (JWT) 中的公開金鑰與 /StartSession 端點聯繫。

本例中的 auth_cookie 代表您的工作階段權杖。您可以為此 Cookie 命名，只要名稱與工作階段設定中的 name 欄位相符，且在整個應用程式中一致使用即可。

2. 實作工作階段註冊端點

在 /StartSession 中，您的伺服器應：

  • 將收到的公開金鑰與使用者的工作階段建立關聯。
  • 回傳工作階段設定。
  • 將長效 Cookie 換成短效 Cookie。

在下列範例中，短效 cookie 會設為在 10 分鐘後到期：

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. 實作重新整理端點

當短效 Cookie 到期時，Chrome 會啟動重新整理流程，證明擁有私密金鑰。這項程序包含 Chrome 和伺服器的協調動作：

  1. Chrome 會將使用者的要求延後至您的應用程式，並傳送重新整理要求給 /RefreshEndpoint：

    POST /RefreshEndpoint HTTP/1.1
Sec-Session-Id: session_id

  2. 您的伺服器會傳回挑戰：

    HTTP/1.1 401 Unauthorized
Sec-Session-Challenge: "challenge_value"

  3. Chrome 會使用儲存的私密金鑰簽署挑戰，並重試要求：

    POST /RefreshEndpoint HTTP/1.1
Sec-Session-Id: session_id
Sec-Session-Response: <JWT proof>

  4. 您的伺服器會驗證已簽署的證明，並發出已更新的短效 Cookie：

    HTTP/1.1 200 OK

Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax

  5. Chrome 會收到重新整理的 Cookie，並恢復原始的延遲要求。

替代整合模式

為提高復原能力，網站可在短效 Cookie 旁邊加入第二個非 DBSC Cookie。這個長效 Cookie 僅用於發出新的短效權杖，有助於區分真正未經驗證的要求，以及暫時性 DBSC 失敗。

  • 即使 DBSC 失敗，長效 Cookie 仍會持續存在。
  • 短期 Cookie 會使用 DBSC 進行重新整理，並且必須用於敏感作業。

這個模式可讓網站進一步控管邊緣案例的處理方式。

注意事項和備用行為

在下列情況下，Chrome 可能會略過 DBSC 作業，並傳送不含 DBSC 管理的短效 Cookie 的要求：

  • 由於網路錯誤或伺服器問題，無法連線至重新整理端點。
  • TPM 忙碌或發生簽署錯誤。由於 TPM 會在系統程序之間共用，因此過度重新整理可能會超出頻率限制。
  • DBSC 管理的短效 Cookie 是第三方 Cookie，而使用者已在瀏覽器設定中封鎖第三方 Cookie。

在這種情況下，如果仍有長效 Cookie，Chrome 會改用該 Cookie。只有在實作項目同時包含長效和短效 Cookie 時，這個備用方案才會生效。如果不是，Chrome 會傳送不含 Cookie 的要求。

摘要

裝置繫結工作階段憑證可在對應用程式進行最少變更的情況下，提升工作階段安全性。這類機制可將工作階段繫結至特定裝置，提供更強大的防範工作階段劫持的保護措施。大多數使用者都能獲得好處，且不會遇到任何中斷情形，而 DBSC 會在未支援的硬體上順利回復。

詳情請參閱 DBSC 規範。