認證小教室｜理解 Passport 和 JWT 的認證流程

關於這篇文章：

在現代應用程式中，使用者認證是不可或缺的一部分。本文將為您深入淺出地介紹兩個重要的認證工具：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 的認證流程有更深入的了解，如果您對文章內容有任何疑問、補充或建議，還請不吝賜教！您的每一個回饋都是幫助我們共同進步的寶貴資源，讓我們一起在這個充滿挑戰和機遇的領域中成長吧！