基于token的登入認證

最近新做移動端項目，h5的頁面嵌入app中，資訊userinfo的擷取，頁面與app的協定傳遞，聯調的很心累啊。Token知識點一直是自己想要深入了解，這周就想了解下這個知識點，順便對自己這周的工作做個總結。性能上報，還需要抽時間來學習。廢話不多說，go ~

目的：用戶端和伺服器端進行通信，進行使用者認證。

優勢：

• 支援跨域通路: Cookie是不允許垮域通路的，這一點對Token機制是不存在的，前提是傳輸的使用者認證資訊通過HTTP頭傳輸.
• 無狀态(也稱：服務端可擴充行):Token機制在服務端不需要存儲session資訊，因為Token 自身包含了所有登入使用者的資訊，隻需要在用戶端的cookie或本地媒體存儲狀态資訊.
• 更适用CDN: 可以通過内容分發網絡請求服務端的所有資料（如：javascript，HTML,圖檔等），而你的服務端隻要提供API即可.
• 去耦: 不需要綁定到一個特定的身份驗證方案。Token可以在任何地方生成，隻要在API被調用的時候，你可以進行Token生成調用即可.
• 更适用于移動應用: 當你的用戶端是一個原生平台（iOS, Android，Windows 8等）時，Cookie是不被支援的（你需要通過Cookie容器進行處理），這時采用Token認證機制就會簡單得多。
• CSRF:因為不再依賴于Cookie，是以你就不需要考慮對CSRF（跨站請求僞造）的防範。
• 性能: 一次網絡往返時間（通過資料庫查詢session資訊）總比做一次HMACSHA256計算 的Token驗證和解析要費時得多.
• 不需要為登入頁面做特殊處理: 如果你使用Protractor 做功能測試的時候，不再需要為登入頁面做特殊處理.

實作方法：

- 第一次請求時，使用者發送賬号與密碼 

- 背景校驗通過，則會生成一個有時效性的token,再将此token發送給使用者 

- 使用者獲得token後，将此token存儲在本地，一般存儲在localstorage或cookie 

- 之後的每次請求都會将此token添加在請求頭裡，所有需要校驗身份的接口都會被校驗token，若token解析後的資料包含使用者身份資訊，則身份驗證通過。