Node.js + JWT Authentication 專案(三) - 專案 Controller 與 Middleware
最後一章就要來完成整個專案,把剩下的 Controller、Middleware 與 Routes 完成即可。 ...
最後一章就要來完成整個專案,把剩下的 Controller、Middleware 與 Routes 完成即可。 ...
此篇章會使用 Typegoose 來建立資料庫的 models,並且設定獲得與驗證 JWT 的方法。 ...
這個專案會使用 Node.js 和 TypeScript 來建構 REST API 後端,使用 JWT 來實作身分認證與授權。 此專案會遵循我慣用的 OOP 架構 et860525/express-project-architecture,有鑑於上一次專案的經驗,由於這些都只是小專案,我不會把所有東西都全部都包在 class 裡面 建構此專案會用到的重要套件: Package Usage Express Web 應用框架 TypeScript 開發工具 Mongoose 訪問資料庫 Docker 應用容器化 MongoDB 儲存使用者的資料庫 Redis 儲存使用者緩存的 session 資料庫 JsonWebToken 產生 JWTs Bcryptjs 密碼加密 Zod 驗證使用者的輸入 Typegoose 使用 TypeScript 優化 Mongoose 模型 Dotenv 讀取環境變數 Cors 允許資料能在前端與後端之間分享 lodash 對 JavaScript 的功能擴充 ts-node-dev 當檔案變更時自動重啟 ...
OAuth 2.0 最大的優勢是可擴展性與模塊化,但這樣的靈活性也導致於在不同的實現之間,會存在著相容性問題。當開發人員想在不同的系統上實現 OAuth 時,它提供很多的自定義選項容易讓人很困惑。 OAuth 2.0 一共定義了 7 種授權類型,可以根據不同的情況與環境使用不同的模式: Legacy: 密碼模式 ( Password Grant ) Legacy: 隱含模式 ( Implicit Flow ) 授權碼 ( Authorization Code ) 刷新令牌 ( Refresh Token ) 客戶憑證 ( Client Credentials ) PKCE ( Proof Key for Code Exchange ) 設備碼 ( Device Code ) 起初,OAuth 設計是基於 HTTP 的,但實現方法的細節可以有很多種。 在上一篇有提到,OAuth 裡定義的四種角色。其中的客戶端還可以分為兩種: 前端客戶端:通常前端客戶端指的是瀏覽器 後端客戶端:後端客戶端指的是,實際需要取得存取權杖 ( Access Token ) 的服務 通常的流程為: 資源擁有者 透過瀏覽器登入 ( 此步驟意同瀏覽器向資源擁有者授權請求 ) 授權伺服器 驗證身分並確認授權 授權給客戶端 ( 獲得存取權杖 ) 客戶端取得受保護的資源 客戶端提供資源擁有者服務 以上流程為 1....
OAuth 是一個開放標準的授權協議,它允許使用者讓第三方應用存取該使用者在某網站儲存的私密資源。 試想有一棟房子,裡面有很多個房間,裡面有一位房東 ( 使用者 ) 擁有一把萬能鑰匙,可以開啟所有的房間門。除此之外,這把萬能鑰匙還有一個作用,就是可以產出特定門的鑰匙,而產生出來的鑰匙可以交給其他人,這樣其他人就可以進出特定的房間,這個動作就是「授權」。 OAuth 2.0 是 OAuth 的進化版,它是授權框架 ( authorization framework ),允許應用向使用者請求授權,然後取得 Token,並且用它來訪問資源。 The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. - RFC 6749...