問題一 http協議是無狀態的，那麼大多數網站是如何記住使用者身份的？

問題二 類似於第一個問題，但又略微有些不同，基於http協議的app應用又是如何記錄使用者身份的？

問題三 如何保持自動登入狀態？

其實，做過相關開發的同學很快就能說出很多，你們說的都對。問題一，通過session和cookie。問題二，可以有很多種方式，較為常用的可能是app本地儲存+服務端快取。問題三，同問題二。

所以，問題來了，目前這樣的方式到底合不合理，到底安不安全？！！

答案總是那麼令人沮喪，但是又是非常現實。

不安全，不安全，不安全！

事實上，黑客總有10000種方式來利用我們的系統的安全漏洞，我們能做的就是儘量減少安全漏洞。然而，當我們的系統前端完全暴露給黑客的時候，我們很多的安全工作只能儘量往後端轉移，特別是身份認證相關內容。

數字簽名的應用

這裡我們不考慮黑客進行中間人攻擊，我們主要關心的是如何利用我們現有的資源（包括各種加密方法，http協議等）設計一個可以首先確保正常身份認證功能的並且可以有效防止儲存在前端的資訊被篡改的方式。

通常首次使用者身份驗證是通過使用者輸入使用者名稱密碼或者通過OAuth2協議（如微信登入等）來實現的，這裡我們在服務端判斷使用者登入成功後，首先會在服務端快取使用者資訊，用於之後的身份驗證，而又會給前端返回一個資訊，在之後前端需要驗證身份的時候，傳入相應的資訊給服務端，服務端會去根據該資訊搜尋快取，找到了即為使用者為登入狀態且身份未過期，未找到需要重新走一遍登入流程。事實上，問題一、二、三種基本都是這麼做的，不同的是，問題一是利用了http的cookie和session，在cookie中儲存了session資訊，從而找到相應的session也就找到了使用者資訊。但是這樣會有黑客在前端故意儲存別人的資訊，從而可以冒用別人的身份，特別在前端儲存資訊特別有規律的情況下，如為使用者的資料庫id數字，或者使用者名稱等。

所以這裡就開始說到主角了，數字簽名，有些時候為了方便，可能直接在前端儲存使用者id作為身份認證資料，這個其實可以理解。但是這很容易進行偽造（事實上，隨便猜一個數字就可以猜到某個使用者的id或者用程式根據字典去暴力跑）。所以，在便利的情況下，在前端不能簡簡單單隻存一個資訊，還要儲存一個數字簽名，這個簽名由使用者登入成功後伺服器返回（通常通過一系列加密演算法，為不可逆）。在之後前端需要根據該資訊向服務端請求使用者身份資訊時（不考慮expire等內容），首先將前端傳來的身份認證資料（如上述的使用者id）再用相同演算法進行加密一遍，和傳來的數字簽名進行比對，比對成功後再進行其他相關操作。

另外，歡迎大家轉載，轉載時請註明出處，謝謝！

童鞋們如果有疑問或者想和我交流的話有兩種方式：

第一種

評論留言

第二種