會話驗證與令牌驗證：深入比較及其關鍵差異
微服務為何需要不同的身份驗證方式
想像一下，試圖解開一個浸泡過膠水的巨大紗球，這就是當你嘗試擴展一個單體身份驗證系統時會遇到的情況。當所有用戶資料、會話和憑證都集中在一個大型數據庫中時，問題會迅速變得複雜。例如，在黑色星期五的促銷活動中，零售應用的登錄服務可能會被大量流量壓垮，導致整個結帳過程因爭奪相同的數據庫連接而停滯。
單一數據庫的挑戰
- 緊密耦合降低速度：如果你想更新醫療數據隱私處理方式，不應該需要重新部署整個計費引擎。
- 共享數據庫的風險：在傳統的 "一體化" 身份驗證模塊中，一次洩漏可能讓黑客獲得所有資料的訪問權。
- 延遲問題：普華永道（PwC）2024年的報告顯示，32% 的客戶在一次糟糕的體驗後會離開品牌，而緩慢的身份驗證是失去客戶的最快方法。
我們需要將身份驗證視為一個獨立的服務，專注於做好單一工作。使用 JSON Web Token（JWT），服務之間可以互相信任，而不需要頻繁的數據庫查詢。雖然 JWT 的無狀態特性極具優勢，但它也有折衷：例如，進行全域登出時，可能需要短期令牌或集中化的撤銷列表來提前終止會話。
架構無密碼的世界
密碼已經成為一大災難。隨著微服務的構建，應該將 "登錄" 視為一種安全握手，而非僅僅是填寫表單。這就是像 MojoAuth 這樣的工具的用武之地，讓你能夠在不編寫大量自定義邏輯的情況下實現無密碼流程。
實現無密碼架構的好處
- 快速集成：使用預構建的組件處理前端問題，而不是為每個移動應用和網絡門戶構建自定義界面。
- 會話管理：在微服務環境中，MojoAuth 使用令牌將身份在不同服務間傳遞，使 "計費" 服務能夠識別剛剛由 "個人資料" 服務驗證的用戶。
- 降低開發負擔：無需具備專業的安全知識即可實現魔法鏈接或電子郵件 OTP。
例如，以下是如何調用無密碼 API 來啟動登錄：
mojoauth.signInWithEmail(email).then(response => {
console.log("檢查你的收件箱，朋友");
});
終極目標：使用通行密鑰
通行密鑰是 b2c 的終極目標。它利用手機上的生物識別技術（如 FaceID 或指紋）來創建加密密鑰對，從而消除代碼和釣魚攻擊。
根據 FIDO 聯盟 2023 年的報告，超過 50% 的消費者認為通行密鑰比傳統密碼更易於使用。