常見的登錄驗證方式

1. http basic auth

每次請求API時都提供用戶的username和password。

容易把帳號密碼暴露給第三方客戶端，在生產環境下被使用的愈來愈少。

1. Oauth

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

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

 

+--------+                               +---------------+
     |        |--(A)- Authorization Request ->|   Resource    |
     |        |                               |     Owner     |
     |        |<-(B)-- Authorization Grant ---|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(C)-- Authorization Grant -->| Authorization |
     | Client |                               |     Server    |
     |        |<-(D)----- Access Token -------|               |
     |        |                               +---------------+
     |        |
     |        |                               +---------------+
     |        |--(E)----- Access Token ------>|    Resource   |
     |        |                               |     Server    |
     |        |<-(F)--- Protected Resource ---|               |
     +--------+                               +---------------+

1. Cookies-session Auth

Cookie-session 認證機制就是爲一次請求認證在服務端建立一個Session對象，同時在客戶端的瀏覽器端建立了一個Cookie對象；經過客戶端帶上來Cookie對象來與服務器端的session對象匹配來實現狀態管理的。默認的，當咱們關閉瀏覽器的時候，cookie會被刪除。但能夠經過修改cookie 的expire time使cookie在必定時間內有效。Session 是存儲在服務器端的，避免在客戶端 Cookie 中存儲敏感數據。Session 能夠存儲在 HTTP 服務器的內存中，也能夠存在內存數據庫（如redis）中。
可是這種基於cookie-session的認證使應用自己很可貴到擴展，隨着不一樣客戶端用戶的增長，獨立的服務器已沒法承載更多的用戶，而這時候基於session認證應用的問題就會暴露出來。

• Session :每一個用戶通過咱們的應用認證以後，咱們的應用都要在服務端作一次記錄，以方便用戶下次請求的鑑別，一般而言session都是保存在內存中，而隨着認證用戶的增多，服務端的開銷會明顯增大。
• 擴展性 :用戶認證以後，服務端作認證記錄，若是認證的記錄被保存在內存中的話，這意味着用戶下次請求還必需要請求在這臺服務器上,這樣才能拿到受權的資源，這樣在分佈式的應用上，相應的限制了負載均衡器的能力。這也意味着限制了應用的擴展能力。
• CSRF :由於是基於cookie來進行用戶識別的, cookie若是被截獲，用戶就會很容易受到跨站請求僞造的***.

1. Token Auth

基於token的鑑權機制相似於http協議也是無狀態的，它不須要在服務端去保留用戶的認證信息或者會話信息。這就意味着基於token認證機制的應用不須要去考慮用戶在哪一臺服務器登陸了，這就爲應用的擴展提供了便利。

流程：

• 用戶使用用戶名密碼來請求服務器
• 服務器進行驗證用戶的信息
• 服務器經過驗證發送給用戶一個token
• 客戶端存儲token，並在每次請求時附送上這個token值
• 服務端驗證token值，並返回數據

這個token必需要在每次請求時傳遞給服務端，它應該保存在請求頭裏， 另外，服務端要支持CORS(跨來源資源共享)策略，通常咱們在服務端這麼作就能夠了Access-Control-Allow-Origin。

Token Auth的優勢

• 支持跨域訪問
  Cookie是不容許垮域訪問的，這一點對Token機制是不存在的，前提是傳輸的用戶認證信息經過HTTP頭傳輸.
• 無狀態(服務端可擴展行)
  Token機制在服務端不須要存儲session信息，由於Token 自身包含了全部登陸用戶的信息，只須要在客戶端的cookie或本地介質存儲狀態信息.
• 更適用CDN:
  能夠經過內容分發網絡請求你服務端的全部資料（如：javascript，HTML,圖片等），而你的服務端只要提供API便可.
• 去耦:
  不須要綁定到一個特定的身份驗證方案。Token能夠在任何地方生成，只要在你的API被調用的時候，你能夠進行Token生成調用便可.
• 更適用於移動應用
  當你的客戶端是一個原平生臺（iOS, Android，Windows 8等）時，Cookie是不被支持的（你須要經過Cookie容器進行處理），這時採用Token認證機制就會簡單得多。
• CSRF(跨站請求僞造Cross-site request forgery)
  由於再也不依賴於Cookie，因此你就不須要考慮對CSRF（跨站請求僞造）的防範。
• 性能:
  一次網絡往返時間（經過數據庫查詢session信息）總比作一次HMACSHA256計算 的Token驗證和解析要費時得多.
• 不須要爲登陸頁面作特殊處理:
  若是你使用Protractor 作功能測試的時候，再也不須要爲登陸頁面作特殊處理.
• 基於標準化
  你的API能夠採用標準化的 JSON Web Token (JWT). 這個標準已經存在多個後端庫（.NET, Ruby, Java,Python, PHP）和多家公司的支持（如：Firebase,Google, Microsoft）

缺點�：

1. 存在泄露的風險。若是別人拿到你的 Token，在 Token過時以前，均可以以你的身份在別的地方登陸
2. 若是存在 Web Storage（指sessionStorage和localStorage）。因爲Web Storage 能夠被同源下的JavaScript直接獲取到，這也就意味着網站下全部的JavaScript代碼均可以獲取到web Storage，這就給了XSS機會
3. 若是存在Cookie中。雖然存在Cookie可使用HttpOnly來防止XSS，可是使用 Cookie 卻又引起了CSRF

對Token認證的五點認識

• 一個Token就是一些信息的集合；
• 在Token中包含足夠多的信息，以便在後續請求中減小查詢數據庫的概率；
• 服務端須要對cookie和HTTP Authrorization Header進行Token信息的檢查；
• 基於上一點，你能夠用一套token認證代碼來面對瀏覽器類客戶端和非瀏覽器類客戶端；
• 由於token是被簽名的，因此咱們能夠認爲一個能夠解碼認證經過的token是由咱們系統發放的，其中帶的信息是合法有效的；

1. JWT

• 身份認證
  在這種場景下，一旦用戶完成了登錄，在接下來的每一個請求中包含JWT，能夠用來驗證用戶身份以及對路由，服務和資源的訪問權限進行驗證。因爲它的開銷很是小，能夠輕鬆的在不一樣域名的系統中傳遞，全部目前在單點登陸（SSO）中比較普遍的使用了該技術。
• 信息交換
  在通訊的雙方之間使用JWT對數據進行編碼是一種很是安全的方式，因爲它的信息是通過簽名的，能夠確保發送者發送的信息是沒有通過僞造的。

1. SSO

SSO（Single Sign On）單點登陸。

指在多系統應用羣中登陸一個系統，即可在其餘全部系統中獲得受權而無需再次登陸，包括單點登陸與單點註銷兩部分。

實現方式：

• 有一個公共緩存cache用來驗證登陸
• cookie保存登陸信息

做者：DamaoShao著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。