如今web服務隨處可見，成千上萬的web程序被部署到公網上供用戶訪問，有些系統只針對指定用戶開放，屬於安全級別較高的web應用，他們需要有一種認證機制以保護系統資源的安全，本文將探討五種常用的認證機制及優缺點。
HTTP基本認證（HTTP Basic Auth）
在HTTP中，HTTP基本認證是一種允許Web瀏覽器或者其他客戶端在請求時提供用戶名和口令形式的身份憑證的一種登錄驗證方式。
簡單而言，HTTP基本認證就是我們平時在網站中最常用的通過用戶名和密碼登錄來認證的機制。
優點:
HTTP 基本認證是基本上所有流行的網頁瀏覽器都支持。但是基本認證很少在可公開訪問的互聯網網站上使用，有時候會在小的私有系統中使用。
缺點:
HTTP 基本認證雖然足夠簡單，但是前提是在客戶端和服務器主機之間的連接足夠安全。如果沒有使用SSL/TLS這樣的傳輸層安全的協議，那么以明文傳輸的密鑰和口令很容易被攔截。 由於現存的瀏覽器保存認證信息直到標簽頁或瀏覽器關閉，或者用戶清除歷史記錄。導致了服務器端無法主動來當前用戶登出或者認證失效。
OAuth（開放授權）
OAuth（開放授權）是一個開放的授權標准，允許用戶讓第三方應用訪問該用戶在某一web服務上存儲的私密的資源（如照片，視頻，聯系人列表），而無需將用戶名和密碼提供給第三方應用。
OAuth允許用戶提供一個令牌，而不是用戶名和密碼來訪問他們存放在特定服務提供者的數據。每一個令牌授權一個特定的第三方系統（例如，視頻編輯網站)在特定的時段（例如，接下來的2小時內）內訪問特定的資源（例如僅僅是某一相冊中的視頻）。這樣，OAuth讓用戶可以授權第三方網站訪問他們存儲在另外服務提供者的某些特定信息，而非所有內容
下面是OAuth2.0的流程：
（1）客戶端（Client）向資源擁有者（Resource Owner）發送授權請求（Authorization Request）
（2）資源擁有者授權許可（Authorization Grant）
（3）客戶端向驗證服務器（Authorization Server）發送通過（2）獲取的授權許可
（4）驗證服務器驗證授權許可，通過的話，則返回Access Token給客戶端
（5）客戶端通過Access Token 訪問資源服務器（Resource Server）
（6）資源服務器返回受保護的資源（Protected Resource）
這種基於OAuth的認證機制適用於個人消費者類的互聯網產品，如社交類APP、豆瓣、微信js-SDK等應用，但是不太適合擁有自有認證權限管理的企業應用；
Cookie/Session
Cookie 是由客戶端保存的小型文本文件，其內容為一系列的鍵值對。Cookie 是由 HTTP 服務器設置的，保存在瀏覽器中。Cookie會隨着 HTTP請求一起發送。
Session 是存儲在服務器端的，避免在客戶端 Cookie 中存儲敏感數據。Session 可以存儲在 HTTP 服務器的內存中，也可以存在內存數據庫（如redis）中。
Cookie/Session認證機制就是為一次請求認證在服務端創建一個Session對象，同時在客戶端的瀏覽器端創建了一個Cookie對象；通過客戶端帶上來Cookie對象來與服務器端的session對象匹配來實現狀態管理的。默認的，當我們關閉瀏覽器的時候，cookie會被刪除。但可以通過修改cookie 的expire time使cookie在一定時間內有效。
Token認證
基於 Token的認證機制，有着無需長期保存用戶名和密碼，服務器端能主動讓token失效等諸多好處，非常實用於 Web 應用和 App 已經被很多大型網站采用，比如Facebook、Github、Google+等。
其流程如下：
1. 客戶端使用用戶名和密碼請求登錄
2. 服務端收到請求，去驗證用戶名與密碼
3. 驗證成功后，服務器會簽發一個 Token， 再把這個 Token 發送給客戶端
4. 客戶端收到 Token 以后可以把它存儲起來，如Cookie或者Web Storage
5. 客戶單每次向服務端請求資源的時候，都需要帶着服務器端簽發的 Token
6. 服務器端收到請求，驗證客戶端請求里面帶着的 Token，如果驗證成功，就向客戶端返回請求的數據；否的話，則返回對應的錯誤信息。
字由https://www.wode007.com/sites/73248.html 中國字體設計網https://www.wode007.com/sites/73245.html
Token認證的優點：
- 支持跨域訪問: 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 存在幾個問題：
1. 存在泄露的風險。如果別人拿到你的 Token，在 Token過期之前，都可以以你的身份在別的地方登錄
2. 如果存在 Web Storage（指sessionStorage和localStorage）。由於Web Storage 可以被同源下的JavaScript直接獲取到，這也就意味着網站下所有的JavaScript代碼都可以獲取到web Storage，這就給了XSS機會
3. 如果存在Cookie中。雖然存在Cookie可以使用HttpOnly來防止XSS，但是使用 Cookie 卻又引發了CSRF
對於泄露的風險，可以采取對Token進行對稱加密，用時再解密。 對於XSS而言，在處理數據時，都應該 escape and encode 所有不信任的數據。 與CSRF相比，XSS更加容易防范和意識到，因此並不建議將Token存在Cookie中。
最后，網站或者應用一定要使用HTTPS。畢竟在網絡層面上 Token 明文傳輸的話，還是非常的危險。