無狀態和有狀態架構

指的是應用程式的狀態，即給定時間的條件或品質。在無狀態身份驗證中，不儲存會話或用戶，僅包含靜態內容。這與有狀態不同，有狀態是動態內容。

無狀態處理程序是一種孤立的資源，它不引用任何其他服務或與另一個系統的交互作用。它僅在代碼的該部分中運行，不會從舊事務中引入信息，因為無狀態身份驗證不存儲此類數據；每個操作都是從頭開始完成 。

狀態驗證允許資訊多次使用，並基於先前事務的上下文執行。因此，在需要等待回應或預先存在的資料的應用程式中，無論是否存在於另一個系統或資料庫中，都使用有狀態。

無狀態認證

無狀態驗證包含一種策略，在該策略中，使用者在提供憑證後會收到存取權杖作為回應。此令牌已包含識別產生它的使用者所需的所有信息，而無需不斷查詢頒發令牌的服務或資料庫。

此令牌儲存在客戶端（瀏覽器），因此伺服器只能透過確認有效負載和簽章匹配來檢查令牌的有效性。

無狀態認證 JWT

JSON Web Token (JWT) 是具有RFC-7519 中建立的標準​​的密鑰，包含聲明形式的實體，這些實體是獨立的，無需調用伺服器重新驗證令牌。

是使用密鑰以base64標準編碼的字串，如範例所示：

優點和缺點

優點：

• 伺服器記憶體消耗低。
• 在可擴展性方面非常出色。
• 非常適合分散式應用程序，例如 API 和微服務。
• 在獨立的應用程式中產生和分發令牌，不依賴第三方。
• 輕鬆解釋和驗證代幣用戶資料。

缺點：

• 存取控制困難。
• 無法隨時輕易撤銷令牌。
• 如果有人有權存取令牌，它可以促進惡意第三方的進入。
• 在令牌過期之前，會話無法變更。
• JWT 令牌更加複雜，在中心化應用程式（例如整體式應用程式）中可能變得不必要。

狀態認證

常用於各種應用程序，尤其是那些不需要太多可擴展性的應用程序，有狀態會話在應用程序的後端中創建，並將會話引用發送回相應的用戶。每次使用者發出請求時，應用程式的一部分都會產生令牌。從那時起，對於每個新請求，該令牌將再次發送到應用程式以重新驗證存取權限。在這個模型中，如果使用者資料發生任何變化，令牌可以很容易地被撤銷。

這些是不透明的存取令牌，即專有格式的簡單字串，不包含與該令牌相關的任何識別碼或使用者資料。接收者需要呼叫創建令牌的伺服器來驗證它。

範例代幣：8c90e55a-e867-45d5-9e42-8fcbd9c30a74

此 ID 必須與擁有該令牌的使用者一起儲存在資料庫中。

優點和缺點

優點：

• 集中實作邏輯。
• 簡化存取管理和控制。
• 非常適合單體應用、MVC 應用程式和內部流程。
• 更安全地抵禦惡意第三方。

缺點：

• 負責驗證令牌的 API 中可能存在過載。
• 可擴展性方面失敗。
• 在微服務之間分配身份驗證的難度更高。
• 在分散式應用程式中，如果身分驗證服務失敗，則所有其他服務將變得不可用。
• 更高的實施複雜性。
• 與第三方系統整合難度較高。

何時使用每種方法？

何時使用 JWT 令牌和無狀態身份驗證

• 當需要更高的效能而不用擔心 API 過載時。
• 當服務之間分佈有多個通訊時。
• 當需要識別哪個使用者在不同服務中的系統中執行操作時。
• 當不打算保留用戶的資料時，僅保留他們的初始註冊。
• 如果需要產生對服務的外部存取。
• 如果有必要在對系統影響最小的情況下操縱執行特定操作的人員的資料。

何時使用不透明令牌和狀態身份驗證

• 如果需要對系統使用者進行完全存取控制，主要是定義存取層次結構。
• 在集中式應用程式中，沒有分散式服務，也沒有與外部服務通訊。

最終考慮因素：

• 在某些地方，例如“API 壓力”，為了清楚起見，該術語可能會替換為“API 開銷”。
• 如果目標受眾需要更多上下文，「JWT 令牌」部分可以包含對 RFC-7519 中提到的「聲明」內容的更詳細解釋。
• 在狀態身份驗證部分中，可以透過解釋應用程式的哪個特定部分負責這一點來澄清「應用程式的一部分將產生令牌」這一短語。