如果後端是分散式的話（例如雲端伺服器），建議使用 oauth2.0中的token驗證方式，如果只是開發的話，可以用cookie。
oauth登入流程如下:

1. 新建token表，欄位 token,user_id,login_at,expire_at

2. 用戶使用帳號密碼登入

3. 登入成功則在資料表token插入一條記錄，並刪除該使用者之前所有token或設定為過期，並把token回傳給前端

4. 前端使用ajax的時候加上headerAuthorization=token

5. 後端讀取請求頭中的Authorization，並與資料庫比對，如果存在且未過期，則視為合法用戶，否則返回錯誤

1 使用者登入一般就是cookie + session，伺服器不是同一台也一樣呀，其中一台多一個請求轉送功能就好了，因為同源策略的限制，訪問另一個網域是不能帶上cookie的。

2 一般會在前端會有個摘要函數來產生資料的摘要，雖然隨資料post上去，然後後端用同樣的摘要函數產生post上來的資料的摘要，與post上來的摘要進行比對，如果一致就證明數據沒被修改過。但是使用者如果知道你用的摘要函數是什麼它也可以自己產生資料的摘要post上去，所以其實理論上是沒法判斷的，但實際中普通使用者並不知道這些。

1. JWT, json web token.

2. 後端怎麼判斷這個資料是否被更改? 什麼意思? 後端db不是存了資料嗎?

後端資料驗證，這個是前後端分離資料安全必須要做的。
通常的做法就是做sign加密
需要用到的是key和secret
例如淘寶api的加密方式 淘寶sign

key為使用者標識，表名你是誰，secret代表你的鑰匙。鑰匙為服務端生成，只能在客戶端加密時使用，在資料傳輸過程中不能包含sercet資訊。
客戶端根據特定規則對所有請求資料進行加密後，後端取得到所提交的資料在用同樣方式加密，然後對比sign參數是否一致，一致則說明資料在傳輸過程中未遭到竄改。
另外還需要時間的時效性檢測比如timestamp參數，要求時間誤差不得超過前後5分鐘
還有一點，數據重複請求，後端接收到sign後做個cache把sign存起來，失效時間5分鐘（和上面時間對應），同一個sign表示本次請求已經重複請求過，然後拒絕

基本上都是這個流程，確保資料安全，時效性，防重複等。

sessionStorage或localStorage 儲存後台自己產生的特殊密碼。每次請求透過head帶上，透過後台驗證資料合法