JWT（JSON Web Token）

是一種讓伺服器和使用者之間安全溝通的方式，是一個獨立的 Token，通常用於「無狀態」的身份驗證。

當你登入成功後，伺服器會幫你生成一個「身份憑證」（也就是這個 Token），接著你每次發送請求（例如：查詢資料、操作功能）時，都要把這個 Token 附上，這樣伺服器就知道是你在操作。
伺服器收到你的請求後，會檢查這個 Token 是不是有效，確定沒問題後才會讓你繼續。

我的理解

去一個景點園區玩的時候，買了門票，園區人員會檢查我的門票才讓我進入園區，出去園區上廁所再進來時，也需要再次查看門票，才能再次進入園區。

JWT 就像你當天購買的「門票」，會有期限。
如果明天要再進來，要重新購買。

JWT 結構的三個部分

Header：

這裡會說明這個 Token 使用什麼編碼方式和類型，通常是像 HS256 這種加密算法，類型就是 "JWT"。

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload：

是一個 JSON 物件。
裡面放的是你的資料，像是使用者ID、名稱、角色等等，稱為 Claims。

1. 註冊的 Claims：

這是一些標準的欄位，例如 iss（發行者）、exp（到期時間）、sub（主題）。

2. 公開的 Claims：

這是可以公開給所有人看的資訊，例如使用者名稱、email。

3. 私有的 Claims：

這是你自訂的資料，用於你的應用程式。

範例：

{
  "sub": "1234567890",
  "name": "Lina",
  "admin": true
}

Signature：

這是伺服器用來保護 Token 不被竄改的關鍵部分。
它是將 Header、Payload 進行編碼，然後使用一個祕密金鑰來生成的。

每次 Token 傳回來，伺服器都會用這個 Signature 來檢查它是否還是原本的樣子，沒有被改過。

JWT 的運作流程

1. 使用者登入：

當使用者成功登入後，伺服器會根據使用者資訊生成一個 JWT，並將它回傳給使用者。

2. 使用者保存 JWT：

通常前端會將這個 Token 保存到 Local Storage 或 Cookie 中。

3. 發送請求時附帶 JWT：

使用者在發送請求時，會將這個 JWT 附加在 Authorization 中（格式：Bearer ），伺服器可以驗證這個 JWT，從而知道請求來自哪個使用者。

4. 伺服器驗證 JWT：

伺服器會根據預設的算法和祕密金鑰來驗證 JWT 是否有效，如果驗證通過，就知道這個請求是沒問題的。

JWT 的優缺點

優點：

• 每次請求都帶上 Token，伺服器只要驗證 Token 就行了，不需要查詢資料庫。
• 不同的服務之間也能共享這個 Token，只要 Token 有效，任何服務都能認出你。

缺點：

• 如果某個 Token 洩漏，伺服器沒辦法馬上把它取消，必須等它自動過期。
• 如果你在 Token 裡存了太多資訊，隨著內容變多，這個 Token 也會越來越大。

那「無狀態」跟「有狀態」是什麼意思？

無狀態身份驗證（Stateless Authentication）

假設你去了一家咖啡店，點了一杯咖啡，店員給你一個小卡片，上面寫著你點的咖啡類型。
每次你想要喝咖啡時，只要把這張卡片給店員，店員就知道你要什麼，「根本不需要記住你是誰」。

伺服器不記錄任何事情：

你每次去都帶著卡片（Token），所以伺服器只需要看這張卡片來確認你的身份。

這樣做很方便，伺服器不需要儲存任何資料，適合需要處理很多請求的情況，像是大型網站或應用程式。

範例：

像是 JWT（JSON Web Token），你登入後會得到一個 Token，之後每次請求都帶著這個 Token。

有狀態身份驗證（Stateful Authentication）

假設你去的是一個小型的咖啡店，店員會記住你的名字和你喜歡的咖啡類型。
當你下次進來時，店員會直接給你你喜歡的那杯咖啡，根本不需要你告訴他。

伺服器會記住你的狀態：

伺服器儲存著每位客人的資訊（Session），像是你的名字和餐點喜好等等。

這對於小型應用程式或使用頻率不高的情境來說很方便，因為伺服器能快速找到使用者的資訊。

範例：

傳統的 Session 機制，登入後伺服器會產生一個 Session，並把 Session ID 回傳給你，接下來每次都帶著這個 ID。
伺服器也能隨時作廢 Session。

更多相關資訊可以參考以下文章：

• 什麼是JWT？認識 JSON Web Token 認證機制
• 關於 JWT 驗證（這篇鐵人賽文章我覺得很好理解！）
• JWT 官方文件
• Laravel HTTP Session