近期在做一些小專案，因此在思考要透過類似 supabase 這種 BaaS 還是要自己建立後端？老實說從訓練營結業後，幾乎沒有寫過後端。但我仍然記得第一份工作時的主管說的話「了解後端，會讓你更能寫出貼近後端 API 返回的數據結構」，其實我一直都不是很理解這究竟是不是真的， 畢竟後端寫的是商業邏輯，更多時候對於前端來說很難真正地理解，除非整個工作流程中，前端與後端一樣都相當清楚專案以及每個需求的細節和商業邏輯，因此與後端的溝通，想當然爾是家常便飯，雙方也勢必會需要妥協以及釐清需求。
我想紀錄自己重溫後端的過程也蠻有趣的，那就先從 Authentication 開始吧。
Auth 到底要幹嘛？
Auth 有三個層次：
- 誰要登入？
- 誰已經登入了，能否持續登入中？
- 登入後可以做什麼？
不同的認證系統
截至目前為止，我做過的產品都是比較面向大眾的，今年有幸協助朋友做電商後台，因此也有接觸面向內部的認證。
面向大眾的身份認證系統
這種最常見的就是註冊跟登入，對前端來說精簡一點的註冊或登入，可能只有重要的幾種資料，例如：帳號，密碼，信箱；但也有可能複雜到需要更多使用者資料，但不論如何這些都是個資，是需要好好地被保護的。 而前端的資料基本上在瀏覽器是一覽無遺的，因此被攻擊也是常態，因此如何從前端到後端的資安維護也是至關重要。
不過這篇對於資安不會過於著墨，讓我把焦點拉回來到在思考建立一個身份認證系統時，我們通常可以怎麼思考？
我們作為使用者時，註冊跟登入只是一瞬間的事情，填完資料，驗證完，進入頁面看到自己的資料，但對於工程師來說，可以大致上拆成：
- 核心
- 註冊
- 登入
- 取得自己的資料
- 登入
- access token 過期，自動 refresh
- 附加的功能
- 忘記 / 重設 / 修改密碼
- 驗證 email 或是 OTP 等
- 登入管理（多種裝置管理）
- 風險控管（例如不同的 IP，登入失敗次數等）
- 進階功能
- Oauth (不同服務商提供的接口，例如：Google, FB, Apple)
- 2FA 雙重驗證
- RBAC/ABAC (權限系統)
- SSO / SAML (B2B)
針對這類型的身份認證，在規劃的時候我們可以針對以下幾大重點來進行決策：
要自己建立還是託管
- 託管服務的 survey
- 優點？
- 缺點？
- 框架的 survey
- 優點？
- 缺點？
核心的驗證機制
- Session (Stateful)
- 由 Server 掌控登入狀態，server 存 session ID
- JWT (Stateless)
- 只驗證簽名，不查狀態，無法撤銷權限，需要等 token 過期
- 混合 (Access JWT + Refresh Token)
- Access Token: Stateless，用在 API 驗證
- Refresh Token: Stateful(存DB)，用在換發 Access Token
Token 儲存與傳輸
- Access Token 放哪？
- LocalStorage vs. Memory
- Refresh Token 放哪？
- LocalStorage vs. HttpOnly Cookie
- Token Rotation
- 如果舊的 Refresh Token 被偷走，該怎麼辦？
憑證與註冊策略
- 登入方式
- 有密碼或無密碼？
- 密碼怎麼存？
- 要用哪種演算法？
- 要不要加 pepper？
- 密碼強度規則
防禦與風控
- 限流
- 針對登入或是 refresh token 接口建立嚴格的次數限制
- 記錄 IP 或失敗次數
- 雙重驗證
- 是否開啟或是建置？
錯誤處理與回應
- 安全隱私
- 如果登入失敗，要回怎樣的訊息？
- 註冊驗證，若已被註冊，要寄信還是直接顯示？
- 前端顯示錯誤訊息跟代碼
- 除了 HTTP Status 之外，還需要什麼？
- 是否有明確地錯誤訊息讓前端判斷？
下一篇，我想要記錄在認證系統中常見的，將角色跟權限封裝以及如何處理權限的問題。
回到部落格 🏃🏽♀️