工作階段策略

當使用者瀏覽您的應用程式時，您會希望他們不必每次都登入。在登入一次後，您的應用程式應儲存一些關於使用者的資料，並允許他們在下次瀏覽時繼續上次的進度。這稱為工作階段。Auth.js 支援 2 種主要的工作階段策略，即基於 JWT 的工作階段和資料庫工作階段。

您可以使用 Auth.js 主要設定檔中的 session.strategy 選項來設定工作階段策略。

JWT 工作階段

Auth.js 可以使用 JSON Web Token (JWT) 建立工作階段。除非設定了資料庫提供者，否則這是 Auth.js 的預設工作階段策略。當使用者登入時，會在 HttpOnly cookie 中建立 JWT。將 cookie 設定為 HttpOnly 可以防止 JavaScript 從用戶端存取它（例如，透過 document.cookie），這使得攻擊者更難以竊取該值。此外，JWT 使用只有伺服器知道的密鑰進行加密。因此，即使攻擊者從 cookie 中竊取了 JWT，他們也無法解密它。結合較短的到期時間，這使得 JWT 成為建立工作階段的安全方式。

當使用者登出時，Auth.js 會從 cookie 中刪除 JWT，從而銷毀工作階段。

優點

• 作為工作階段的 JWT 不需要資料庫來儲存工作階段；這可以更快、更便宜且更容易擴展。
• 此策略所需的資源較少，因為您不需要管理額外的資料庫/服務。
• 然後，您可以使用建立的權杖在同一網域上的服務和 API 之間傳遞資訊，而無需聯絡資料庫來驗證包含的資訊。
• 您可以使用 JWT 安全地儲存資訊，而無需將其暴露給在您的網站上執行的第三方 JavaScript。

缺點

• 無法在編碼的到期時間之前使 JSON Web Token 過期 - 這樣做需要維護一個無效權杖的伺服器端黑名單（至少在它們真正過期之前），並且每次呈現權杖時都要針對該列表檢查每個權杖。Auth.js 會銷毀 cookie，但是如果使用者在其他地方儲存了 JWT，則它將在到期之前有效（伺服器將接受它）。（當使用 JSON Web Token 作為工作階段權杖時，會使用較短的工作階段到期時間，以便盡早使工作階段無效並簡化此問題。）
• Auth.js 啟用進階功能來減輕在使用者體驗上使用較短工作階段到期時間的缺點，包括自動工作階段權杖輪換、選擇性地傳送保持連線訊息（工作階段輪詢）以防止短暫工作階段在有視窗或標籤開啟時過期、背景重新驗證以及自動標籤/視窗同步，這可以在任何工作階段狀態變更或視窗或標籤獲得或失去焦點時保持跨視窗的工作階段同步。
• 與資料庫工作階段權杖一樣，JSON Web Token 可以儲存的資料量有限。每個 cookie 通常有約 4096 個位元組的限制，儘管確切的限制因瀏覽器而異。您嘗試在權杖中儲存的資料越多，以及您設定的其他 cookie 越多，您就越接近此限制。Auth.js 實作工作階段 cookie 分塊，因此超過 4kb 限制的 cookie 將在剖析時被分割和重新組合。但是，由於此資料需要在每次請求時傳輸，因此您需要注意您想要使用此技術傳輸多少資料。
• 即使配置正確，也不應假設儲存在加密 JWT 中的資訊在某個時間點不可能被解密 - 例如，由於發現缺陷或技術進步。儲存在加密 JSON Web Token (JWE) 中的資料可能會在某個時間點遭到洩露。建議產生具有高熵的 密碼。

資料庫工作階段

除了 JWT 工作階段策略外，Auth.js 也支援資料庫工作階段。在這種情況下，Auth.js 不會在登入後儲存包含使用者資料的 JWT，而是在您的資料庫中建立工作階段。然後，工作階段 ID 會儲存在 HttpOnly cookie 中。這與 JWT 工作階段策略類似，但它不是將使用者資料儲存在 cookie 中，而只是儲存一個指向資料庫中工作階段的模糊值。因此，每當您嘗試存取使用者工作階段時，您都會查詢資料庫以取得資料。

當使用者登出時，工作階段會從資料庫中刪除，並且工作階段 ID 會從 cookie 中刪除。

優點

• 資料庫工作階段可以隨時在伺服器端修改，因此您可以使用 JWT 策略實作可能更困難 - 但並非不可能 - 的功能，等等：「在任何地方登出」，或限制並行登入
• Auth.js 對您正在使用的資料庫類型沒有意見；我們有大量的官方資料庫介面卡，但您也可以實作您自己的介面卡

缺點

• 資料庫工作階段需要往返您的資料庫，因此除非您的連線/資料庫能夠容納，否則它們在規模上可能會比較慢
• 許多資料庫介面卡尚未與 Edge 相容，這將允許更快、更便宜的工作階段擷取
• 與無狀態 JWT 策略相比，設定資料庫需要更多工作，並且需要額外的服務來管理