BASIC 認證
BASIC 認證（基本認證）是從 HTTP/1.0 就定義的認證方式。
BASIC 認證會將“用戶名:密碼”經過 Base64 加密後放入請求頭部的 Authorization 字段用於服務端校驗，因為採用的是 Base64 加密，密碼被盜用的風險極高，另外一般的瀏覽器也無法實現認證註銷操作。
若在網站中使用 BASIC 認證，最好加上 SSL 認證（即開啟 HTTPS），否則無法保障密碼傳輸的安全。
DIGEST 認證
為彌補 BASIC 認證存在的弱點，HTTP/1.1 起就有了 DIGEST 認證。DIGEST 認證會將用戶密碼經過 MD5 加密後傳輸給服務端，降低了密碼被盜用的風險，但是仍然沒有解決用戶偽裝的問題。
步驟2中 response 也可叫做 Request-Digest，存放經過 MD5 運算後的密碼字符串，形成相應碼。
無論是 BASIC 認證還是 DIGEST 認證，他們都達不到多數 Web 網站對高度安全等級的追求標準。
SSL 客戶端認證
SSL客戶端認證是藉由 HTTPS 的客戶端證書完成認證的方式，憑藉客戶端證書認證，服務器可確認訪問是否來自已登錄的客戶端。
大多數情況下，SSL 客戶端認證是與其他認證方式組合使用的，很明顯，SSL 客戶端認證只能證明請求是來自於安全的客戶端，並沒法證明請求是來自於安全的用戶。
Bearer 認證
Bearer 認證也屬於 HTTP 協議標準驗證，它隨著 OAuth 協議而流行。
Bearer 認證中的憑證稱為 BEARER_TOKEN，或者是 access_token，它的頒發和驗證完全由我們自己的應用程序來控制，而不依賴於系統和 Web 服務器，Bearer 認證的標準請求方式如下：
<code>Authorization: Bearer [BEARER_TOKEN]/<code>
Bearer 認證的核心便是 BEARER_TOKEN，而最流行的 Token 編碼方式便是：JSON WEB TOKEN。
Json web token (JWT), 特別適用於分佈式站點的單點登錄（SSO）場景。JWT 的聲明一般被用來在身份提供者和服務提供者間傳遞被認證的用戶身份信息，也可以增加一些額外的其它業務邏輯所必須的聲明信息，該 token 也可直接被用於認證，也可被加密。
表單認證
基於表單的認證方法並不是在 HTTP 協議中定義的。客戶端會向服務器上的 Web 應用程序發送登錄信息（Credential），登錄信息的驗證結果認證。
表單認證不具備共同標準規範，在每個 Web 網站上都會有各不相同的實現方式，一般會使用 Cookie + Session 的方式管理會話。
表單認證因為需要自主實現，如果全面考慮過安全性能問題，就能夠具備高度的安全等級。但在表單認證的實現中存在問題的 Web 網站也是屢見不鮮。
OAuth2 + OpenID
OAuth 與 OpenID 可以歸類為第三方認證方式，即對該用戶的認證通過非本服務進行認證。
OAuth 是一個開放標準，允許用戶讓第三方應用訪問該用戶在某一網站上存儲的私密的資源（如照片，視頻，聯繫人列表），而無需將用戶名和密碼提供給第三方應用。目前，OAuth 的最新版本為 2.0。
OAuth 強調授權（authorization），舉個例子帶大家瞭解 OAuth 授權過程。大家都用過微信授權吧？首先，客戶端會請求用戶是否允許微信授權，用戶允許後，微信端會返回 code 信息；然後，服務端使用 code 信息授權登錄微信平臺，登錄成功後會返回用戶認證信息 access_token； 最後，服務端再拿著 access_token 信息獲取到用戶相關的資源。大致過程如下所示。
那 OpenID 又是什麼呢？OpenID 強調認證（authentication），試想一下，客戶端請求微信授權的時候，如果用戶未登錄微信或者沒有微信賬戶呢？是不是就要跳到微信登錄頁面？而這就是 OpenID 做的事，OpenID 僅僅做一個用戶認證的功能，不能拿到用戶的任何信息，用戶的信息都安全的存儲在 OpenID 服務器上（你可以自己建立一個 OpenID 服務網站，也可以選擇一個可信任的 OpenID 服務網站來完成註冊）。
OpenID 往往在不同服務之間單點登錄的時候較為常用。
推薦閱讀：
- 《圖解 HTTP》
- 瞭解第三方認證方式：OAuth與OpenID
