登陸認證方式

HTTP Basic Auth

HTTP Basic Auth簡單點說明就是每次請求API時都提供用戶的username和password，簡言之，Basic Auth是配合RESTful API 使用的最簡單的認證方式，只需提供用戶名密碼便可，但因爲有把用戶名密碼暴露給第三方客戶端的風險，在生產環境下被使用的愈來愈少。所以，在開發對外開放的RESTful API時，儘可能避免採用HTTP Basic Auth

OAuth

OAuth（開放受權）是一個開放的受權標準，容許用戶讓第三方應用訪問該用戶在某一web服務上存儲的私密的資源（如照片，視頻，聯繫人列表），而無需將用戶名和密碼提供給第三方應用。

OAuth容許用戶提供一個令牌，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數據。每個令牌受權一個特定的第三方系統（例如，視頻編輯網站)在特定的時段（例如，接下來的2小時內）內訪問特定的資源（例如僅僅是某一相冊中的視頻）。這樣，OAuth讓用戶能夠受權第三方網站訪問他們存儲在另外服務提供者的某些特定信息，而非全部內容

下面是OAuth2.0的流程：

客戶端：第三方應用，如微信...

資源擁有者：用戶

驗證服務器：認證客戶端的身份，最終頒發受權令牌（access token），在物理上，驗證服務器能夠和資源服務器由一個服務器來提供。

資源服務器：存儲用戶的資源，處理對資源的訪問請求

這種基於OAuth的認證機制適用於我的消費者類的互聯網產品，如社交類APP等應用，可是不太適合擁有自有認證權限管理的企業應用；

如微信公衆號的受權：

1. 用戶關注微信公衆帳號。

2. 微信公衆帳號提供用戶請求受權頁面URL。

3. 用戶點擊受權頁面URL，將向服務器發起請求

4. 服務器詢問用戶是否贊成受權給微信公衆帳號(第一步，請求受權)

5. 用戶贊成(scope爲snsapi_base時無此步驟)

6. 服務器將CODE經過回調傳給微信公衆帳號（第二步，客戶端獲得用戶的受權許可）

7. 微信公衆帳號得到CODE

8. 微信公衆帳號經過CODE向服務器請求Access Token（第三步）

9. 服務器返回Access Token和OpenID給微信公衆帳號（第四步，服務器返回令牌）

10. 微信公衆帳號經過Access Token向服務器請求用戶信息(第五步)

11. 服務器將用戶信息回送給微信公衆帳號(scope爲snsapi_base時無此步驟)

Cookie+session

HTTP 是一種沒有狀態的協議，也就是它並不知道是誰是訪問應用。這裏咱們把用戶當作是客戶端，客戶端使用用戶名還有密碼經過了身份驗證，不過下回這個客戶端再發送請求時候，還得再驗證一下。

Session，咱們須要在服務端存儲爲登陸的用戶生成的 Session ，這些 Session 可能會存儲在內存，磁盤，或者數據庫裏。咱們可能須要在服務端按期的去清理過時的 Session 。

當用戶請求登陸的時候，若是沒有問題，咱們在服務端生成一條記錄，這個記錄裏能夠說明一下登陸的用戶是誰，而後把這條記錄的 ID 號發送給客戶端，客戶端收到之後把這個 ID 號存儲在 Cookie 裏，下次這個用戶再向服務端發送請求的時候，能夠帶着這個 Cookie ，這樣服務端會驗證一個這個 Cookie 裏的信息，看看能不能在服務端這裏找到對應的記錄，若是能夠，說明用戶已經經過了身份驗證，就把用戶請求的數據返回給客戶端。

基於 Token 的身份驗證方法

使用基於 Token 的身份驗證方法，在服務端不須要存儲用戶的登陸記錄。大概的流程是這樣的：

客戶端使用用戶名跟密碼請求登陸

服務端收到請求，去驗證用戶名與密碼

驗證成功後，服務端會簽發一個 Token，再把這個 Token 發送給客戶端

客戶端收到 Token 之後能夠把它存儲起來，好比放在 Cookie 裏或者 Local Storage 裏

客戶端每次向服務端請求資源的時候須要帶着服務端簽發的 Token

服務端收到請求，而後去驗證客戶端請求裏面帶着的 Token，若是驗證成功，就向客戶端返回請求的數據

        

Token機制相對於Cookie機制又有什麼好處呢？

支持跨域訪問: 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 作功能測試的時候，再也不須要爲登陸頁面作特殊處理.

基於標準化:你的API能夠採用標準化的 JSON Web Token (JWT). 這個標準已經存在多個後端庫（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）.

JWT

JSON Web Token（JWT）是一個很是輕巧的規範。這個規範容許咱們使用JWT在用戶和服務器之間傳遞安全可靠的信息。一個JWT實際上就是一個字符串，它由三部分組成，頭部、載荷與簽名。

認證過程

登陸

第一次認證：第一次登陸，用戶從瀏覽器輸入用戶名/密碼，提交後到服務器的登陸處理的Action層（Login Action）；

Login Action調用認證服務進行用戶名密碼認證，若是認證經過，Login Action層調用用戶信息服務獲取用戶信息（包括完整的用戶信息及對應權限信息）；

返回用戶信息後，Login Action從配置文件中獲取Token簽名生成的祕鑰信息，進行Token的生成；

生成Token的過程當中能夠調用第三方的JWT Lib生成簽名後的JWT數據；

完成JWT數據簽名後，將其設置到COOKIE對象中，並重定向到首頁，完成登陸過程；

        

請求認證

基於Token的認證機制會在每一次請求中都帶上完成簽名的Token信息，這個Token信息可能在COOKIE中，也可能在HTTP的Authorization頭中；

客戶端（APP客戶端或瀏覽器）經過GET或POST請求訪問資源（頁面或調用API）；

認證服務做爲一個Middleware HOOK 對請求進行攔截，首先在cookie中查找Token信息，若是沒有找到，則在HTTP Authorization Head中查找；

若是找到Token信息，則根據配置文件中的簽名加密祕鑰，調用JWT Lib對Token信息進行解密和解碼；

完成解碼並驗證簽名經過後，對Token中的exp、nbf、aud等信息進行驗證；

所有經過後，根據獲取的用戶的角色權限信息，進行對請求的資源的權限邏輯判斷；

若是權限邏輯判斷經過則經過Response對象返回；不然則返回HTTP 401；