身份驗證

四種常見的方法

1.基本身份驗證 (Basic Authentication)

簡單但安全性與使用體驗不良( 每次請求都需要重新輸入憑證)

1. 客戶端發送請求訪問受保護的資源。
2. 伺服器回應 401 Unauthorized 狀態碼，並在 WWW-Authenticate 標頭中指示使用 “Basic” 方案。
3. 客戶端將使用者名稱和密碼進行 Base64 編碼。
4. 客戶端在 Authorization 標頭中包含編碼後的字串，再次發送請求。
5. 伺服器解碼 Authorization 標頭中的 Base64 字串，獲得使用者名稱和密碼。
6. 伺服器驗證使用者名稱和密碼。
7. 如果驗證成功，伺服器返回請求的資源。若驗證失敗，伺服器可能再次返回 401 Unauthorized 狀態碼。

2.基於 Cookie 的身份驗證 (Cookie-Based Authentication)

保持會話，但有跨站攻擊風險

1. 使用者成功登入，伺服器創建一個會話 (Session) 並生成一個唯一的會話 ID (Session ID)。
2. 伺服器將這個 Session ID 儲存在伺服器端的記憶體或資料庫中。
3. 伺服器在 HTTP 回應的 Set-Cookie 標頭中包含這個 Session ID，發送給瀏覽器。
4. 瀏覽器自動儲存這個 Cookie。
5. 瀏覽器在之後每次向同一個伺服器發送請求時，都會在 Cookie 標頭中自動帶上這個 Session ID。
6. 伺服器接收到請求後，通過 Cookie 中的 Session ID 查找伺服器端儲存的會話資訊。
7. 伺服器驗證會話資訊以確定使用者身份。

3.JSON Web Tokens (JWT)

適用分散式系統與API，需要考慮 Token 失效管理和伺服器端驗證開銷

基於 JSON 的RFC 7519標準，包含所有驗證使用者身份所需信息，伺服器不需儲存會話

1. Header (標頭): 包含 JWT 的類型和所使用的簽名演算法。
2. Payload (載荷):
   • Registered claims: 例如 iss (簽發者), sub (主題), exp (過期時間), iat (簽發時間), jti (JWT ID)。
   • Public claims: 可以由 JWT 的使用者隨意定義，但應避免與 Registered claims 衝突。
   • Private claims: 自定義的聲明，用於在應用程式之間傳遞資訊。
3. Signature (簽名): 用於驗證 JWT 的完整性和發送者身份。簽名是通過 Header 中指定的演算法，使用 Header、Payload 和一個 Secret Key (或 Private Key) 計算得出的。

4.令牌基礎身份驗證 (Token-Based Authentication)

伺服器不需維護會話狀態，需防範 XSS 攻擊

1. 使用者成功登入後，伺服器生成一個隨機的、唯一的令牌 (Token)。
2. 伺服器將這個令牌儲存在資料庫中，並與使用者關聯。
3. 伺服器將這個令牌返回給客戶端（可以通過 Cookie 或 HTTP 回應 Body 傳遞）。
4. 客戶端接收到令牌並儲存。
5. 客戶端在後續每次請求受保護資源時，將這個令牌放在 Authorization 標頭中發送給伺服器。
6. 伺服器接收到請求後，從 Authorization 標頭中提取令牌。
7. 伺服器在資料庫中查找這個令牌，以驗證它是否有效及與哪個使用者關聯。
8. 如果令牌驗證成功，允許訪問請求的資源；若驗證失敗，可能返回相應的錯誤狀態碼（如 401 Unauthorized）

基於 Cookie 的身份驗證與令牌基礎身份驗證差異

基於 Cookie 的身份驗證

• 會話管理方式：伺服器生成並存儲 Session ID，客戶端用 Cookie 存儲 Session ID 並隨請求發送。
• 狀態性：狀態性，伺服器需維護使用者的會話狀態。
• 安全性：容易受 CSRF 攻擊，但可通過設置 SameSite 屬性減輕風險。
• 擴展性：需解決會話共享問題（如 Session Stickiness），水平擴展較複雜。

令牌基礎身份驗證

• 會話管理方式：伺服器生成令牌並存儲於資料庫中，客戶端在請求中使用令牌認證。
• 狀態性：可以是無狀態（如JWT），伺服器不需維護會話狀態。
• 安全性：需防範 XSS 攻擊，無狀態令牌需管理過期和刷新。
• 擴展性：無狀態令牌支持分佈式系統，易於水平擴展。

---

如果你覺得這篇文章很棒，請你不吝點讚 (ﾟ∀ﾟ)