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；