背景

最近在開發restful風格的數據倉庫，使用的是阿里云的函數計算，技術棧是：Vue+Flask(部分用Go)，后端API采用restul風格。
由于數據比較敏感，安全系數肯定要比較高才行，但由于我是個人開發，限于成本，只能盡可能的優化代碼邏輯，平衡存儲和計算成本。

遇到的問題與自己的解決方案

權限管理這個地方，遇到的問題

是否開放賬號密碼注冊的方式？
我參考了國內多數app/web應用，發現相當一部分僅開放了手機號驗證注冊/登錄，或者開放第三方如微信/支付寶之類的，但是最后還是要綁定手機，于是我想了下，就僅開放外部用戶使用手機號注冊登錄，但是還是以賬號為用戶的唯一標識，同過手機號注冊的，初始化一個賬戶即可；另外自己留一個接口可以直接生成賬號，不用綁定手機號，登錄方式還是賬密/手機號登錄。

惡意批量使用手機號申請驗證碼，導致短信驗證碼套餐消耗量過大的問題
這個無法杜絕，只能讓其成本大于我的成本即可，看了下，一個網易的行為驗證碼也就一萬多一年，前期不限制，業務有點起色了，加上就行了，不限量，但是限制QPS，我多花一萬塊錢，對方可能需要花10萬

token登錄的安全性問題
理論上用戶登錄后，返回攜帶用戶信息的token，加上https防止中間人攻擊，就可以有效遏制大部分安全問題，且不需要服務端存儲token。但有一點很煩，僅僅通過客戶端存儲token只能驗證其正確性和時效性。那加入你的賬號密碼泄露，異地登錄，單用token就無法解決了，我的解決方式是將客戶端的ip一并添加到token的載荷，token驗證/續約的時候對請求的ip與載荷中的ip一起校驗，不通過則。由于DHCP租期比較長，一次登錄期間很小概率會出現租約到期導致IP地址變動問題，因此問題不大
*補充：又想到一個場景，跨省/跨地區前后，ip一定會變，這個后面再考慮。

token續約問題
看了好多回答，想不通為什么需要用redis，用在請求驗證上，過于浪費，基于上面的第3條，可以確定token的安全性，那我對請求的生命周期做判定，小于某個時長，在響應頭中攜帶新的token，js攔截器判定有這個頭，就刷新本地的存儲的token不就ok了？

手機驗證碼二次校驗問題
用的是網易云盾，流程是：第一次請求，發送驗證碼，云盾返回requestId，第二次，攜帶requestId+驗證碼，進行校驗。
這個用在注冊場景上，第二次客戶端發給服務端是需要攜帶注冊信息的，比如手機號。
那么假設我第二次請求，更改了手機號，但驗證碼和requestId都保持正確，那么服務端收到的手機號就是錯誤的，但驗證是通過的。
這時可以在第一次請求中，將requestId與手機號放入token的載荷中，返回給客戶端，第二次客戶端直接將這個token與其他信息一起發送至服務端

總結

以上是生活随笔為你收集整理的web低成本的安全登录方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。