關於這篇文章：
在現代應用程式中，使用者認證是不可或缺的一部分。本文將為您深入淺出地介紹兩個重要的認證工具：Passport 和 JWT。本篇文章將帶你了解：
- Passport 是什麼？ 簡單的身份驗證中介軟體，讓多種登入方式變得容易。
- JWT 是什麼？ 一種 stateless 認證方式，能減輕伺服器負擔。
- 傳統 Session-based 與 Token-based 認證方式的區別。
- Stateful（有狀態）與 Stateless（無狀態）認證方式的區別。
- Passport 和 JWT 如何協同工作？無論您是初學者還是有經驗的開發者，希望這篇文章都能幫助您更好地理解現代web認證機制。讓我們開始吧！
在解釋 Passport 跟 JWT 之間的流程前，讓我們先來了解它們各自的角色：
- Passport：
是一個用於Node.js的身份驗證中介軟體，提供了多種身份驗證方式，無論是傳統的帳號密碼，還是通過Google、Facebook等第三方登入，Passport都能輕鬆應對。它就像一個智慧門鎖，幫助開發者快速整合各種登入方式。 - JWT (JSON Web Token)：
JWT則像是一個智能通行證，它是一種 token-based 的 stateless 認證方式。當用戶成功登入後，伺服器會發出一個加密過的 token，這個 token 包含了用戶的驗證信息，並儲存在客戶端。每次請求時，客戶端會將這個 token 附帶在請求中，伺服器則用這個 token 來驗證用戶身份。
傳統 Session vs. 現代 Token
在JWT出現之前，伺服器最常使用 session-based 的傳統認證方式，這種方法需要依賴伺服器來保存用戶的登入狀態，以下會以圖書館的借書證系統白話舉例：
- 用戶登入：
就像你去圖書館辦借書證。
（用戶提供憑證（如帳號和密碼），伺服器驗證後，會創建一個 session 並儲存用戶相關的狀態資訊。） - 伺服器創建session：
圖書館為你建立一個借書記錄。 - 發送 session ID：
你得到一張借書證（存在cookie裡）。
（伺服器將生成的一個唯一的 session ID 存儲在 cookie 中，並發送給用戶。） - 用戶每次請求時攜帶 session ID：
你每次借書都要出示這張借書證。
（之後每次請求用戶都會攜帶這個 session ID，伺服器則透過這個 ID 查找用戶的會話資料。） - 伺服器驗證 session：
圖書館查你的借書記錄來確認身份。
（伺服器根據 session ID 來驗證用戶的身份。）
而這種方法就稱為 stateful（有狀態）認證，因為伺服器需要記住每個用戶的狀態，就像圖書館要記住每個人的借書情況。
但是隨著應用規模越來越大，這種方法開始力不從心：
- 擴展困難：
想像一下，如果圖書館分店越開越多，要同步所有人的借書記錄會有多麻煩。
（每個伺服器需要保存大量的 session，且在多個伺服器之間同步 session 變得複雜。） - 伺服器負擔重：
記錄太多，圖書館的電腦可能會變得很慢。
（伺服器需要處理和管理大量的會話資料，當用戶增多時，性能就會下降。）
為了解決上面這些問題，JWT 這種 stateless 認證的機制就此而生。
Token-based 認證：智能通行證時代
Token-based 顧名思義，就是一種通過發送短暫的憑證（token）來驗證使用者身份的方式，就像是使用智能的通行證：
- 用戶登入：
你還是要先證明身份。
（使用者提供憑證，也就是輸入帳號和密碼，並成功通過伺服器的認證。） - 伺服器發送 token：
但這次你得到的是一個智能通行證（JWT）。
（伺服器產生一個唯一的 token，發送給用戶。這個 token 是一串由伺服器簽發的字元，包含用戶的相關資訊和認證有效期。） - 用戶持有 token：
你把這個通行證存在手機裡。
（之後用戶在每次向伺服器發送請求時，會將這個 token 作為身份驗證憑證。） - 每次請求帶上token：你要用服務時，出示這個通行證就行。
- 伺服器驗證 token：最後伺服器只需要檢查 token 是否有效來確認用戶的身份，而不再需要反覆檢查用戶名和密碼。
Token-based 的『優點』：
- token 是一次性生成的，並且有時效性，當 token 過期時就需要重新認證。
- token 可以儲存在瀏覽器的本地存儲、cookie 等中，避免每次都要重新登入。
Stateless（無狀態）認證 就是服務器不記得你是誰，但它相信你的通行證（token）。每次你來，它只看通行證，不查詢歷史記錄。
（伺服器不會儲存用戶的狀態資訊。當每次用戶發出請求時，伺服器不需要查看以前的登入紀錄或狀態，而是依靠每次請求攜帶的 token 來進行身份驗證。）
Stateless 的『優點』：
- 減少伺服器負擔：因為伺服器不需要記住誰是誰（不需要保存用戶的 session 資訊），所以伺服器會變得更輕鬆，不需要額外花費時間和資源去保存每個人的資料，特別是在大量用戶同時訪問時，效能的提升會很明顯。
- 擴展性強：如果有多個伺服器，它們不需要互相告訴對方誰來過，每個伺服器只要能讀懂通行證就行。
Passport 和 JWT 的完美配合
現在，讓我們看看 Passport 和 JWT 是如何一起工作的：
⓵ 用 Passport 檢查身份：Passport 負責初始的身份驗證，就像機場的安檢。如果你的證件沒問題（帳密正確或第三方登入成功），Passport 就會放行。
➔ 後端工程師會使用 Passport 來處理使用者的登入邏輯。這包括驗證帳號密碼或使用第三方登入（例如 Google、Facebook 等）。如果使用者提供的登入資訊正確（例如：帳號密碼匹配，或是第三方登入成功），Passport 會回傳一個認證成功的結果。
⓶ 生成 JWT token：通過安檢後，會給你一張登機證。
➔ 當 Passport 驗證成功後，後端會生成一個 JWT token，這個 token 包含使用者的一些基本資訊（例如：用戶 ID、角色等），並且會被加密。
⓷ 將 JWT token 發送給前端：
➔ 驗證成功後，後端將這個 JWT token 傳送給前端（通常是回應的一部分）。這代表前端現在有了用來進行未來 API 請求的認證方式。
⓸ 前端儲存 JWT token：
➔ 前端工程師會接收到這個 JWT token，並將它儲存在瀏覽器的 localStorage、sessionStorage，或者 cookie 內（具體看應用需求和安全性考量）。
⓹ 前端在 API 請求中使用 JWT token：
➔ 每當前端發出需要身份驗證的 API 請求時，會將這個 token 附加到請求的 Authorization 頭部中。後端收到這個請求後，會驗證 token 是否有效，從而判斷該請求是否有權限執行。
通過這種方式，Passport 負責嚴格的入口驗證，而 JWT 則提供了輕量級的持續身份確認，兩者完美配合，既保證了安全性，又提高了效率。
技術在不斷發展，安全標準也在不斷提高。保持學習和更新知識是每個開發者的必修課。希望這篇文章能讓你對 Passport 和 JWT 的認證流程有更深入的了解，如果您對文章內容有任何疑問、補充或建議，還請不吝賜教！您的每一個回饋都是幫助我們共同進步的寶貴資源，讓我們一起在這個充滿挑戰和機遇的領域中成長吧！
