看看有哪些 Web 認證技術.

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 認證的标準請求方式如下：

Authorization: Bearer [BEARER_TOKEN]

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 往往在不同服務之間單點登入的時候較為常用。