當前端開始思考後端架構第一篇

近期在做一些小專案，因此在思考要透過類似 supabase 這種 BaaS 還是要自己建立後端？老實說從訓練營結業後，幾乎沒有寫過後端。但我仍然記得第一份工作時的主管說的話「了解後端，會讓你更能寫出貼近後端 API 返回的數據結構」，其實我一直都不是很理解這究竟是不是真的， 畢竟後端寫的是商業邏輯，更多時候對於前端來說很難真正地理解，除非整個工作流程中，前端與後端一樣都相當清楚專案以及每個需求的細節和商業邏輯，因此與後端的溝通，想當然爾是家常便飯，雙方也勢必會需要妥協以及釐清需求。

我想紀錄自己重溫後端的過程也蠻有趣的，那就先從 Authentication 開始吧。

Auth 到底要幹嘛？

Auth 有三個層次：

1. 誰要登入？
2. 誰已經登入了，能否持續登入中？
3. 登入後可以做什麼？

不同的認證系統

截至目前為止，我做過的產品都是比較面向大眾的，今年有幸協助朋友做電商後台，因此也有接觸面向內部的認證。

面向大眾的身份認證系統

這種最常見的就是註冊跟登入，對前端來說精簡一點的註冊或登入，可能只有重要的幾種資料，例如：帳號，密碼，信箱；但也有可能複雜到需要更多使用者資料，但不論如何這些都是個資，是需要好好地被保護的。 而前端的資料基本上在瀏覽器是一覽無遺的，因此被攻擊也是常態，因此如何從前端到後端的資安維護也是至關重要。

不過這篇對於資安不會過於著墨，讓我把焦點拉回來到在思考建立一個身份認證系統時，我們通常可以怎麼思考？

我們作為使用者時，註冊跟登入只是一瞬間的事情，填完資料，驗證完，進入頁面看到自己的資料，但對於工程師來說，可以大致上拆成：

• 核心
  • 註冊
  • 登入
  • 取得自己的資料
  • 登入
  • 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 之外，還需要什麼？
  • 是否有明確地錯誤訊息讓前端判斷？

下一篇，我想要記錄在認證系統中常見的，將角色跟權限封裝以及如何處理權限的問題。